21 May 2017, 16:45 Technologies Cloud Foundry Bluemix Development

Configuring a Bluemix Cloud Foundry Application To Run Locally

During the course of a typical day, a Bluemix Garage programming pair will deploy code around twenty times. Each of those code pushes will be unit tested in the Build and Deploy pipeline, integration-tested, and then be subjected to a final smoke test before going live. All of this cloud-based testing is marvellous, but it’s not a substitute for pre-push local testing.

Every Cloud Foundry application has a VCAP_SERVICES environment variable automatically created for it, with details of bound platform services and user-provided services. For unit tests we always stub services, but for integration tests and general ‘exploring the application locally,’ it’s convenient to run against the same services as the live application.

This is trivial to do by creating a local .secrets file (and .gitignore-ing it), and sourcing the .secrets file before running. The .secrets file can be assembled manually by reading from the Bluemix console or inspecting the output of cf env, but it’s easiest to generate it automatically. The Garage has a handy script for generating them. Generating it automatically has an extra advantage; some Bluemix services generate a new set of credentials every time they’re bound to an application. Manually maintaining a .secrets file can be hard work if pushes are frequent. In those cases, it’s best to create an extra set of credentials in the Bluemix console, and name them PERMANENT_CREDENTIALS. If this naming convention is used, the script will prefer the permanent credentials to the transient ones.

For example, the complete workflow to run a Node.js application locally would be:

cf login
script/generateSecrets
. .secrets 
npm start

where the first three steps only have to be done once per terminal window.

Using generateSecrets will pick up a Bluemix setting which puts Node.js into production mode, so you may prefer to comment out the line for sharing environment variables, as follows:

//  write(environmentVariables.join(''));

26 Aug 2016, 19:21 MVP Bluemix

Using Bluemix to build Minimum Viable Products

When setting out to build a new product, product development teams are confronted with a number of unknowns.

  • What capabilities should the team incorporate in the product?
  • Will the product be compelling to its intended users – i.e. achieve product/market fit?
  • How much effort should the team invest in building the product?

In the London Garage, as practitioners of the lean startup method, we use a technique called the Minimal Viable Product (MVP) to help us answer these questions.

What is an MVP?

Unfortunately there is no straightforward definition of an MVP. Eric Ries, the author of Lean Startup, offer this definition.

“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

However, the definition is also a source of confusion.

Is an MVP just a trendy name for something that used to be called proof-of-concept? After all, the definition speaks of a product to collect validated learning.

Is an MVP a product with a subset of capabilities with more to be added at a later time, in other words a beta version?

Some practitioners of Lean Startup have even suggested a MVP could be delivered in the form of a PowerPoint presentation, a video, etc. If so, can a PowerPoint version of an MVP be really considered a product?

What about least effort? How little effort would need to expanded to be considered least?

These are questions that are beyond the scope of this blog. For the Garage, we characterise an MVP as having these attributes:

  • A product with just enough capabilities to achieve product/market fit;
  • And a minimally viable or workable product or something that can be used by users to provide feedback;
  • And a product where we can make changes without incurring high costs.

To build an MVP, we in the Garage use IBM’s Bluemix cloud platform.

Why use Bluemix?

Bluemix is a platform that enable organisations to quickly create infrastructure and host apps in the cloud. Developers creating apps that require complex services such as databases, Watson analytics and many others, can do so by connecting to these services hosted in Bluemix via standard interfaces. This means that we could easily swap one services for another simply by reconfiguring the interfaces. With Bluemix’s OpenWisk, Cloud Foundry and Container technologies (based on Docker technology), developers are also offered the option to build apps in modular components known as microservices.

In the not too distant past, the effort needed to build up similar capabilities as Bluemix to host apps would have been considerable and we have not even begun to invest effort in building the apps! Clearly, this option for building MVP would not qualify as requiring least effort.

However, using Bluemix to build MVP offers these benefits:

  • A working apps with a functional backend systems can now be built quickly;
  • Whilst an MVP does not require a completely functioning backend system but building one with these capabilities, even a limited one, will enable us to more accurately predict work for the next iteration of development;
  • Should an MVP be validated to achieve product/market fit, it would not require additional effort to convert it in a production app;
  • Being able to build apps in modular architecture and with minimal effort, discarding capabilities that are found to have no value would incur little cost.

How to use Bluemix to build MVP?

We’ll use two projects that were built in the Garage to illustrate how we use Bluemix to build MVPs.

The first example is an app we refer to as the Marathon App. Whilst this is mainly an iOS app that runs on a phone and outside the Bluemix infrastructure, it requires a backend database. The app was built using Xcode. The backend was facilitated through a Bluemix Cloudant database service that took very little time and manpower to activate and configure. The connection between the iOS and Cloudant was implemented via a RESTful API. Had we decided to switch to a different database all we needed to do was to reconfigure the REST API.

The MVP was developed in an iterative manner; at the end of each iteration, a working app was presented to the user for review. After three iterations, about three weeks, the MVP was considered production ready and was used to support Simon Wheatcroft, a blind marathon runner, in his bid the do a 155-mile ultra-marathon in the Namibian desert.

The second example was a project the Garage delivered to a medical service provider. This was a more complex project than the Marathon App and the MVP had three separate elements:

  • A Web-based application;
  • An app utilising Bluemix Watson IoT services;
  • An iOS app.

For this project, we were able to build a minimally functional MVP with end-to-end connection, using a combination of REST API and MQTT protocol, across the three elements in the first iteration within a week. By having a working system available for the user to use, the engineering team was also able to predict the engineering challenges for the second iteration and adjust accordingly. The MVP only took three iterations to be declared acceptable for the project sponsor, who in turn was able to use it as a basis to secure more funds for follow-on work.

Conclusion

In the two projects described earlier and other Garage projects, Bluemix was a vital technology to rapidly build a working MVP - real code, not just PowerPoint! This enabled us to validate with the client that the solution that had been built suited their business needs, and make swift changes accordingly.

Without Bluemix, we would have had to incur the cost of setting up a hosting environment and backend services. With Bluemix we were able to use the backend services out-of-the-box, so to speak, and focus our effort in building a working product; and taking it from validation to production state quickly.

10 Mar 2015, 15:52 Bluemix Continuous Delivery XP

Blue-Green Deployment

One of our core principles is to deliver stories with the highest business value from day one. To deliver something means to put it in front of our customer. Regardless of whether our customer decides to make it public or not, it is available in production from the very first cf push. We strongly believe that having a partially complete solution in production from day 1 is more valuable than having the full solution delivered later.

All Bluemix Garage projects are continuously and automatically deployed into production, regardless whether they are internal tools or software components that we develop for customers.

One of the goals with any production environment is maintaining high availability for your application. The CloudFoundry platform helps with this by giving you the ability to scale your application horizontally to prevent downtime. There is another availability challenge when continuously deploying applications - if you cf push an existing application in production, your instances must be restarted to update your code. Not only does this inevitably introduce downtime, but you are left without a fallback if something goes wrong.

Blue Green deployment is not a new concept by any means. Nor is it tied to any particular platform. In short the idea is:

  1. Deploy a new instance of your application (leaving your current “green” environment untouched).
  2. Run smoke tests to verify the new environment, before taking it live.
  3. Switch over production traffic, keeping the old environment as a hot backup.

As we are deploying straight to production, using blue-green is imperative.

The current status-quo

We discovered these two tools:

  • Buildpack Utilities from the IBM WAS team — An interactive Bash script that will take you through the process
  • Autopilot from Concourse — A plugin for cf (We really like that it’s built into the tooling)

Both tools in fact do roughly the same thing:

  1. Rename the existing app while keeping all routes in place
  2. Push the new instance, which will automatically map the correct routes to it
  3. Delete the old instance

There are three problems with this approach:

  • They do not support running tests against the new app before making it available on the production route.
  • They immediately delete the app, making it impossible to revert to the old environment if something goes wrong
  • There is a chance that the old app could be serving requests at the time it is deleted.

While Blue-Green is quite a simple concept, we discovered several nuances in how we wanted to approach the problem so we decided to build our own.

Our Take

Our continuous delivery environment already consisted of a couple of shell scripts that provide app lifecycle management on top of the cf cli. We decided to build an extension to these scripts to manage Blue-Green with this process:

  1. Push new app instance to Bluemix with a different name
  2. Run end-to-end integration tests against the new app instance using the auto-generated route
  3. Map production routes (including domain aliases) to the new app instance
  4. Unmap routes from previous app instance
  5. Clean up all older app instances, leaving only the previous instance running as a hot backup

If any step fails then the CI server immediately gives up. We don’t want to continue the deployment if anything goes wrong!

The crucial difference is that we do not touch the production app until we know we have a good instance to replace it with. This means using a new app name for every deploy — as easy as passing a specific application-name when calling cf push. We chose to append the date and time for every deploy, but you could also use the git hash or CI build number.

After the new instance has been tested — with simple smoke tests in our case, the tool will then cf map-route the production route to the application. Now the new instance is handling production traffic, cf unmap-route can be used to disconnect the old instance from the world, leaving it untouched until the next deploy.

Deploying with a new application name each time, means we always run in a clean environment. However, without cleaning up, we’ll be left with a lot of redundant, idle applications consuming resources. This is easy to deal with, we simply delete all previous instances except the new app and the instance we just unmapped.

Blue, Green, Cloud.

Arguably what we’re doing here isn’t strictly Blue-Green deployment. The name “Blue-Green” stems from there being two separate environments on physical hardware, each of which could run an instance of the application. It wasn’t possible to throw away the old hardware and start with a completely fresh system for each install so it was necessary to flip between them.

Developing for a Cloud environment such as IBM Bluemix, means that creating whole new application environments is a simple cf push away, and deleting them is just as easy. With such a cheap way to create whole new environments it just doesn’t make sense to keep flipping between two apps when you can always start afresh.

We’ve been running several applications in this configuration for months now and we’re really pleased with what we’ve built. Everyone has different needs, this works for us but it’s just a different way to approach the problem.

Update 07/09/2015

We have recently open sourced our Blue-Green deploy script. It is now available as a Cloud Foundry CLI plugin. The source code and documentation can be found here:

https://github.com/bluemixgaragelondon/cf-blue-green-deploy