Liberty and Bluemix: Bluemix deployment concepts

Share this post:

WebSphere Liberty is the next generation application server. Liberty and Eclipse make a great local development environment for developing and deploying Java EE applications to Bluemix, especially to the Liberty for Java instant runtime. To be able to deploy applications to Bluemix, you first need to understand how applications are organized within Bluemix.

In this excerpt from “Java EE, the next inception: Install a local Java EE development environment for Bluemix,” we’ll explore Bluemix deployment concepts: How Bluemix is organized, how to connect to it, and how to specify a deployment target. Next, we’ll discuss installing the Bluemix tools and connecting Eclipse to Bluemix.

To start at the beginning of this series, see WebSphere Liberty: Developing Java EE applications for the cloud.

Bluemix deployment concepts

To deploy and otherwise manage an application in Bluemix — whether using the command line or the Eclipse tooling, and whether using the Liberty for Java runtime or a runtime for another language — you need to understand how applications are deployed to Bluemix. Specifically, that:

  • You must be authorized to use Bluemix.
  • You must specify a location within Bluemix that will host the application.
  • You can specify deployment options for how the application is deployed.

These points are explained in the next sections.

Bluemix account

To use Bluemix, you’ll need a Bluemix account. If you do not already have one, you can register for a free trial account.

An account authorizes you to use Bluemix, and is also how IBM bills you for using Bluemix. An account is owned by a user, someone who is authorized to perform operations within Bluemix. To authenticate yourself as an account owner, you log in with a username and password, where your username is usually your email address. See Managing your account: Users and roles.

Bluemix deployment locations

Although Bluemix is logically one big cloud, it is subdivided into multiple clouds and partitioned into administrative domains. When you deploy an application, you push it to one of these specific locations.

The deployment location is ultimately what’s called a space, but a space is hosted in a region and administered by an organization. Thus, a location is specified in three aspects:

  • Region – Each region is a separate installation of Bluemix. While a cloud can seem like it has no location – that it’s worldwide – a region has a location in a specific data center located in a particular geography. For Bluemix Public, regions include US South and Europe United Kingdom. Each installation of Bluemix Dedicated and Bluemix Local is also its own region. Each region has a cf API endpoint that client tools use to connect to the region.
  • Organization – An organization is a set of users authorized to control a quota of resources available for deploying and running applications. An organization spans regions so that portions of the quota can be used in separate regions. Each corresponds to a Bluemix account, whose owner is the administrator of the organization. The administrator can add other users to the organization. For a single-user account, the organization is typically named the same as the username.
  • Space – A space is a group of runtime artifacts — like applications and services — hosted within a region, and belonging to an organization. Separate spaces might represent development lifecycle stages, like test and production, or different teams that are working on unrelated applications but want to share resources. The following figure shows how spaces might be located within two organizations and two regions.
    Regions, organizations, and spacesThe previous figure illustrates how a fictional ACME Corporation might use quotas in Bluemix. The company has a developer in the United States named John who has an organization with two spaces, dev and test, which he uses for developing his parts of applications. The company also has an administration team that is responsible for deploying apps into production. That team has spaces for staging as well as production, and production is hosted in two prod spaces that they’ll use to deploy applications active/active across two data centers.

Application deployment options

When pushing an application to Cloud Foundry, the push process can be customized with a number of optional settings that specify the application’s deployment options: name, memory, host, and so on. These can all be specified on the command line or in a deployment GUI, but often it’s convenient to package them with the application in an application manifest file, manifest.yml. See Managing Apps: Deploying apps.

That’s a quick overview of the Bluemix deployment concepts. These concepts will be helpful when connecting the Cloud Foundry CLI or Eclipse to Bluemix and how to deploy applications to Bluemix.

More How-tos stories
May 3, 2019

Kubernetes Tutorials: 5 Ways to Get You Building Fast

Ready to start working with Kubernetes? Want to build your Kubernetes skills? The five tutorials in this post will teach you everything you need to know about how to manage your containerized apps with Kubernetes.

Continue reading

May 3, 2019

Using Portworx to Deploy and Manage an HA MySQL Cluster on IBM Cloud Kubernetes Service

This tutorial is a walkthrough of the steps involved in deploying and managing a highly available MySQL cluster on IBM Cloud Kubernetes Service.

Continue reading

May 2, 2019

Kubernetes v1.14.1 Now Available in IBM Cloud Kubernetes Service

We are excited to announce the availability of Kubernetes v1.14.1 for your clusters that are running in IBM Cloud Kubernetes Service. IBM Cloud Kubernetes Service continues to be the first public managed Kubernetes service to support the latest upstream versions from the community.

Continue reading