July 7, 2016 | Written by: Bobby Woolf
Categorized: Compute Services | How-tos
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.
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.
The 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,
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.