3 Different Ways to Deploy on Bluemix

The motto of Bluemix seems to be that developers should be able to use whatever tools they want to build their dream application. Bluemix does not intend to lock developers into a specific tool set. Vendor lock-in is an easy trap to fall into and one that can deter users from certain platforms. However, in terms of deployment, Bluemix takes measures to ensure that developers are comfortable with the way they deploy their applications.

In short, there are three main ways to deploy an application on Bluemix as summarized below:

1. Command line

Bluemix leverages the Cloud Foundry command line interface to help developers push their application through the standard command line. This interface is incredibly easy to download – you can get started with using it in a matter of seconds. It allows you to scale your applications with a simple plug-in to use.

The commands start with a “cf”, standing for the open source Cloud Foundry. In order to push an application onto Bluemix, the entire command would consist of ‘cf push my_application_name”. The source code can be found here and as a developer, it is always nice to know that the code is being pushed on a daily basis.

In essence, the command line is extremely easy to use, familiar to most developers, and allows you to see logs while pushing applications.

2. Eclipse plug-in

Next, Bluemix allows developers to use Eclipse to push their applications. IBM has developed a plug-in that makes it incredibly easy to push their applications. In order to download the plug-in, you can check out the Eclipse marketplace. Note that this is intended for Eclipse Luna for Java EE Developers.

Eclipse Plugin


The key takeaway here is that Bluemix caters to Eclipse developers. You can push your application to the cloud without having to leave your development environment. The process for sending over your application to your customers has never been easier. For more information, please see this fantastic tutorial on getting an application started with the Eclipse plugin.

3. ibm devops services

Lastly, IBM DevOps Services can be used for the developers that want to utilize a web IDE to write their code, store their code, track their code, and push their code. The pro of IBM DevOps Services is that there is a ton of features and functionality. The con of IBM DevOps Services is that there is a ton of features and functionality. The learning curve can be steep to understand this product, but it will be well worth it in the long run.

IBM DevOps is directly built in and integrated into Bluemix. There is even a button to “Add Git” in Bluemix which creates a code repository for you in IBM DevOps. Or you can link your source code to a GitHub repository for ease of use. The features of this product is too vast to discuss here and is beyond the scope of this post, but they are summarized below.

  • Create, build, test, and deploy applications on Bluemix with IBM DevOps Services
  • Agile tracking and planning
  • Automated builds, test execution, and delivery pipeline deployments


In conclusion, Bluemix is a fantastic platform. The true power of Bluemix comes from the flexibility that it provides developers in terms of allowing them to use the tools of their choice. So, whether you want to use the command line interface, Eclipse, or a web IDE, you can push your applications on Bluemix with any or all of these choices. Happy development.


The Platform-as-a-Service Analogy

In the marketplace, there are numerous definitions of what a computing platform-as-a-service (PaaS) actually means. There are some variances about which types of services should be bundled in the infrastructure-as-a-service component as well as some open debate for the boundaries when platform-as-a-service and software-as-a-service. Most technology folks can appreciate these theoretical debates.

However, from my experience, non-IT individuals need to know what is a PaaS and what problems PaaS solves. The intent of this blog post is to explain a PaaS through the use of an analogy.  I will compare, at a high level, the similarities between the IT industry and the construction industry that readers might be more familiar with. Just as programmers use software tools to help write code, construction workers leverage tools to build s physical object.

Setting Up the Analogy

In the IT world, a PaaS is built upon infrastructure (hardware) and middleware provided over the cloud which are composed of the following components:

Infrastructure: Servers, Storage, Networking, etc.

Middleware: Virtualization, Runtime, Operating System, etc.

In construction and architecture, an equivalent of a PaaS includes the physical tools used to build a work of art as well as the “middleware”. To help explain this a bit further, we break up this business model into to two categories as well.

Hardware: Hammer, Wrench, Power Tools, Materials, etc.

“Middleware”: Electricity, Plumbing, Air Conditioning, etc.

Difficulties Without a PaaS

Now, imagine an architect wants to build something useful, such as a house, a table, a door. Let’s assume that this architect is extremely brilliant, and he wants to build a house. If he is the only one working on this project, he might run into some difficulties. First off, he might need a wide range of tools ranging from power tools to precise tools, depending on the item he is building and the scale.

Without a PaaS, the architect would have to buy all of these tools, despite the fact that he might only use it for a few minutes. Seems very wasteful. Not only that, but every time the architect needed a new tool or an additional nail or screw, he would have to put his project on hold to go procure the resources.

Furthermore, the architect is skilled at designing and building solutions. He is not an expert in middleware. Meaning, that this brilliant architect can design and construct a beautiful three story house. He knows how to incorporate electricity, plumbing, and air conditioning, but he would prefer to buy it as a service, so that he can devote his intellect to designing more houses.

In summary, this architect has a lot of problems that he might encounter in his quest to build a house. Here is a short list of difficulties without a PaaS summarized below:

  • The architect has to buy an entire tool shed despite the fact he might only use a tool only once.
  • The architect has to spend time buying all of the nails, screws, wood, etc. that he will need to build his house
  • The architect has to spend precious intellectual time to configure the middleware when in reality, his efforts are better spent perfecting the house he wants to build or building a new one
  • The architect has to constantly ask his customer whether the customer is liking the house as it is being constructed.

Here is a good read on coming to terms with your PaaS.

How a PaaS Can Help the Architect

Thankfully, our architect has the support of a PaaS. What will be different for him with a PaaS?

Imagine that the architect has a shed right next to the house he wants to build. Now, imagine that this shed is filled with every imaginable tool made to man kind. The architect only has to pay for what he uses too! He pays per minute of tool usage or per nail, etc. If the architect needs any other tools, the shed brings the exact tool that the architect needs to build his house.

What is also nice about a PaaS is that the architect can devote all of his time to designing blueprints and telling workers what to do in order to build an extravagant house with a wonderful living experience. The architect does not need to configure the electricity and air conditioning himself. The magic shed does it for the architect – it just works!

Lastly, imagine that the architect can get feedback on his design instantaneously. The architect’s can easily send pictures, videos, and other online tools to get feedback from his customers. Therefore, the architect can use agile development to receive feedback and continuously integrate those changes into the final design.

See the below diagram for the benefits of a PaaS across different roles. Corresponding construction analogies can be drawn from developer to builder, IT department to architect, and CIO/LOB to project manager.

Wrap Up: Bluemix

The same benefits apply to the IT world. Developers can entire a PaaS environment, such as Bluemix, and have everything they need. Developers have access to 70+ services. Not only does Bluemix provide a free tier to these services, but also lets developers pay as they go. Only need 1 GB of storage? That is all you pay for.

From what I’ve seen, many developers only care about two things: their code and their data. A PaaS allows developers to focus only on their code and their data. They don’t have to configure servers and storage nor set up the middleware to their environment. To deploy an application in less than 45 seconds is amazing – it just works! Therefore, developers don’t have to allocate precious IP towards middleware, and can utilize their time and energy on building the actual application user interface, back end, and logic.

Lastly, Bluemix provides a way for development teams to seek agile feedback. Bluemix creates a url for web applications at my_app_name.mybluemix.net. In this case, developers can seek out the feedback they need on their application. This is extremely useful when teams are pushing new code twenty to thirty times a day. They need the validation that their changes are having an impact on the end user. Click here to see more benefits of Bluemix.

Final Thoughts

In conclusion, whether we are discussing construction or information technology, platforms exist to help people build things. Just as an architect borrows other people’s tools and concentrate on designing a beautiful interior and exterior blueprint, developers can use the platform of infrastructure and middleware to build their application extremely quickly.

See how Bluemix can support lean startup principles just as an architect would leverage these same principles for designing this house.