A long time coming, blue-green deployment now live.

Blue-Green Deploy

Blue-green deployment

Picnic has arrived.

But first...

What is it

From docs.pivotal.io:

Blue-green deployment is a release technique that reduces downtime and risk by running two identical production environments called Blue and Green. At any time, only one of the environments is live, with the live environment serving all production traffic.

Another good read is the Martin Folwer post on the topic, image credit to him.

Our Journey

When we first started building our applications to run on AWS our focus was on scalability so our technology choices to support this was primarily RabbitMQ to support a subscription based service approach of the application components.

To be able to deliver our applications to market in a timely fashion we could only choose to build and deploy a subset of our broader architecture vision at first. Other technology choices were introduced slowly to further support various objectives. In the beginning we set up some Amazon Machine Image (AMIs) and got set up with a solid test driven continuous deployment pipeline via Octopus Deploy. Scalability in response to load here was primarily human driven.

The next set of technical evolution were mostly focused improving the development process for the sake of accuracy and ease of development. The key technology choices were: - F# - used to write the core logic for the Aggregates that are core business logic. - Event Sourcing - as the source of truth for what user actions have happened. - NoSQL - for the projected read stores to service data requests.

Moving away from a relational database to a document database NoSQL approach was and continues to be a great choice. But in the real world with our choice of RavenDB and attempting to solve a too broad a set of application concerns it proved to be quite a challenge. We intend to write more about this particular topic, but Paul Stovell from Octopus Deploy has a great post that covers many of our frustrations too.

Technical Debt

Getting the level of technical debt right is one of the great challenges in delivering software to your customers. We were able to pay off a lot of our technical debt with the hard work from Andrew Browne our previous Solution Architect and his Eventful project, that was the extraction of our long iterated core logic. Along with hard work from the rest of the team, and our new Solution Architect, Dave getting us even more scalable with Neo4j which took the pressure off of RavenDB.

The Blue-Green world

We've been running blue-green internally for many weeks now, and it's been great: creating and deploying new clusters of machines in AWS, deploying code to those machines, switching between environments and replaying/rebuilding our NoSQL and Neo4j read stores from our EventStore. Yesterday we shipped this version of our application into production; and with real users continuing to do their work without adverse affect we can declare it a success.

With this configuration now our architecture is much simpler, requires less machines, is easier to backup / restores / deploy and most importantly allows us to scale automatically.

This also puts an end to outside of business hours deploys and allows for more accurate testing on an environment that is / will soon be actually production infrastructure.

Nick Josevski
Posted by: Nick Josevski  
Last revised: 08 Jul, 2015 06:20 AM


No comments yet. Be the first!

blog comments powered by Disqus