August 21st we attended the London Cloud Foundry User Group (LCFUG) meetup at Pivotal Labs (there were flags). After a chat by Duncan Winn, Director CF EMEA at Pivotal, on Cloud Foundry internals and interaction flows, I shared some of anynines experiences running Cloud Foundry. Focusing on ‘how (not) to shoot yourself in the leg with your over-commitment settings‘, I recollected from over 12 months of experience.  You can find my slides on SlideShare, or just read on.  read more


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 (

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> ( 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> and <staging_subdomain> .
It’s time to remap the live route to the updated application deployment:

cf map-route <second_instance_name> -n <live_subdomain>

e.g.: cf map-route sinatra_b -n sinatralive

Right now all traffic to <live_subdomain> 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> -n <live_subdomain>

e.g.: cf unmap-route sinatra_a -n sinatralive

From now on all requests to <live_subdomain> 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> -n <staging_subdomain>

e.g.: cf unmap-route sinatra_b -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 (@europython) took place late July at the BCC Berlin (Alexanderstraße 11). Friday was (big) data day and I summarized my favorite talks:

Friday July 25

Combining the powerful worlds of Python and R

Ralph Heinkel (@ralhei) talked about the ‘powerful statistical open-source ecosystem called R, little known in the Python community’. Mostly used in scientific contexts it provides lots of functionality for doing statistical analysis, generation of various kinds of plots and graphs. R, Rserve, and pyRserve allows for R-functions to be called from Python as if they were implemented in Pytho. Even complete R scripts can be executed through this connection. Ralph’s demo’s looked pretty impressive, and he is coincidentally the creator and maintainer of pyRserve. Reading his blog is recommended.

Building Realtime Web Applications with WebRTC and Python

Tarashish Mishra (@tarashish) evangelized building peer to peer real time web applications with WebRTC. WebRTC enables web browsers with real-time communications (RTC) capabilities via simple JS api’s without the use of external plugins – with 3 main use cases: access and acquire video and audio streams, establishing connections between peers and streaming audio/video, or to communicate arbitrary data.

Tarashish discussed 3 API’s, getUserMedia which represents a stream of audio/video and can optain multiple tracks,
RTCPeerConnection for signal processing, Codec handling, peer-to-peer communication, security, bandwith management and more and RTCDataChannel. For his slides on the topic, plus an example app, head over to GitHub.

Lightning talks

Lightning talks! My favorite part of any conference! We heard about Sparts, a python library developed at Facebook that “aims to eliminate as much of the skeleton code as possible, making it as dead simple to write new services with little to no excess code.” Then a chat explaining library changes and (how to weapon against) them changing, featuring the incredibly cute ‘blinky’(0-0).

For conference announcements: Tryton Unconference Leipzig taking place November 14th and Django under the Hood – getting the Django core team together – taking place around the same time in Amsterdam.

Then there was a talk about the PaaS Cocaine and one on zipa’s ‘magic python REST clients’. Abraham Martin showed how HSTS (HTTP Strict Transport Security) is less man-in-the-middle-attack prone than HTTPS.

And apparently the Python community in Argentina is thriving, with 1300+ members and fully booked conferences and PyCamps. ScipyConAr will take place in October for the second year. PyLadies and DjangoGirls workshops will be given.

Last but not least there was a chat by Erika on CodeWeekEU. We should all submit our coding workshops and dojo’s to be displayed to a bigger audience.