Preface

As a software provider you want to avoid downtimes for your application. On the other hand you have to ensure the growth and quality of your applications by providing new features and adjustments and deploy them as soon as possible.
anynines allows you to deploy your changes without any downtime by using two different application deployments.
One deployment will offer the live application to your customers while the other deployment can be updated to a new version. After finishing the update you just have to switch your application’s routes to the updated deployment and all of the live traffic will hit the updated application deployment.

Step by Step

This section will guide you through your first zero downtime deployment. Feel free to use our Sinatra example application for experimentation purposes. This guide assumes that you bind all needed services to both application instances so both deployments can access live data.

1) Deploy your application as usual

At first you will have to push your application to anynines using the following command:
cf push <first_instance_name> -n <live_subdomain>

e.g.: cf push sinatra_a -n sinatralive

After finishing the deployment process your application will be available under .de.a9sapp.eu (sinatralive.de.a9sapp.eu).

2) Deploy an updated instance

When code changes have been commited and tested through your production pipeline you can start with the zero downtime deployment process.

You will have to push a second instance with a different application name to your current space by issuing the following command:

cf push <second_instance_name> -n <staging_subdomain>
e.g.: cf push sinatra_b -n sinatrastaging

After finishing the deployment process your updated application instance will be available under <staging_subdomain>.de.a9sapp.eu (sinatrastaging.de.a9sapp.eu). You can use this url to perform a last check on your new features and bugfixes.

3) Re-map the routes to the updated instance

At this time both application deployments are accessible via the urls <live_subdomain>.de.a9sapp.eu and <staging_subdomain>.de.a9sapp.eu .
It’s time to remap the live route to the updated application deployment:

cf map-route <second_instance_name> de.a9sapp.eu -n <live_subdomain>
e.g.: cf map-route sinatra_b de.a9sapp.eu -n sinatralive

Right now all traffic to <live_subdomain>.de.a9sapp.eu will be load balanced between your two application instances.

4) Remove the live route from the outdated deployment

Now we can remove the route from the outdated application deployment:

cf unmap-route <first_instance_name> de.a9sapp.eu -n <live_subdomain>
e.g.: cf unmap-route sinatra_a de.a9sapp.eu -n sinatralive

From now on all requests to <live_subdomain>.de.a9sapp.eu will be routed to the updated application instance.

5) Remove the staging route

As we don’t need the staging route we can delete it from the updated deployment using the unmap-route command:

cf unmap-route <second_instance_name> de.a9sapp.eu -n <staging_subdomain>
e.g.: cf unmap-route sinatra_b de.a9sapp.eu -n sinatrastaging

6) Stop the outdated instance
Finally, let’s stop the outdated instance to save resources:

cf stop <first_instance_name>
e.g.: cf stop sinatra_a

If we run into any problems with the new application version we can easily fall back to the old state by starting up the deployment and remapping the live route to it again.

Additional thoughts

A lot of updates to your application can be deployed without any downtime using the instructions above, but this scenario is not applicable for each kind of application update. If you need to do changes on your databases or have complicated changes that don’t allow a parallel run of two different versions you will have to make a plan suitable for your application structure to perform updates. Even in those scenarios downtime can be avoided or kept really small.

Since the cf CLI is made for scripting the no downtime deployment process can be automated by writing a simple bash script customized to your application’s needs.

The EuroPython 2014 conference took place last week at the BCC Berlin (Alexanderstraße 11). As I attended Brighton Ruby on Monday, you will have to do without a summary of that day. Summarized are my favorite talks.

Tuesday July 22

For Hynek Schlawack’s (@hynek) The Sorry State of SSL talk I should refer to his blog post on the topic. If SSL (or TLS) interests you, this is a go-to resource.

Web Scraping in Python 101

Muhammad Yasoob Ullah Khalid (@yasoobkhalid) is (amongst other things) the creator of freepythontips, which is cool. And he’s very much into web scraping, a method to extract data from a website that does not have an API, or a helpful tool when we want to extract a LOT of data (like product info or job postings) – which we can not do through an API due to rate limiting. read more

Sunday I embarked on a crazy travel to Brighton, to attend Brighton Ruby ( @brightonruby) the day after – only to board the plane that would bring me from London back to Berlin little after the forlast talk. Naturally I summarized everything for your enjoyment.

May the Ruby be with you

Terence Lee (@Hone02) and Zachary Scott (@_zzak) turned Brighton Ruby in Star Wars Conf with their jedi do’s. This was one of those talks you need to experience, but I will try to summarize it a bit. Zachary, as a member of the ‘Ruby Order’ (Ruby Core) – archiving and documenting Ruby standard libraries – told how he teaches younglings in order to give back to the force. Talking weaknesses (heartbleed, Rails Security issues) in the trade routes, Heroku – employing padawan Terence – was mentioned as a member of the Trade Federation calling the Ruby Order for help. After a Skype session via the Holonet with Grand Master Matsumoto, Terence joined the Republic. One of the goals of the Ruby Order is said to create less dependency on the order. Teaching younglings himself, Terence now tries to improve the relationship with alliances in the Trade Federation. And we can apparently all help here. read more