Load Balanced environment - release strategy

Mike Pullin

Does anybody have a process/strategy for upgrading applications or databases in a load balanced environment please?
I am looking for a 'best practice' strategy in order to create an internal company high level process which details the order to complete the tasks required...for example: update databases before applications, roll-back actions, backups etc etc...

Rob C

Hi Mike,

It basically depends on what your requirements are. Assuming that you don't want any downtime and you don't want any breaking changes, then you release process would probably be something like this...

• You have v1.0.0 of your application running as multiple instances and you are ready to release v1.1.0.
• Firstly release the database changes that are compatible with v1.0.0 of your application so that it keeps functioning.
• Deploy v1.1.0 into a staging environment, preferably a staging instance per each production instance.
• When all staging instances for v1.1.0 are up and running, flip the switch on your load balancer (e.g. like HAProxy: http://www.haproxy.org/ or AWS ELB: https://aws.amazon.com/elasticloadbalancing/) to direct traffic to the staging instances. This is basically promoting staging to be production. Note that you don't kill v1.0.0 instances immediately here as you want the on-flight requests to be drained there. Here's a useful article on this concept: http://docs.aws.amazon.com/ElasticLoadB ... drain.html
• When you are ready to release v1.2.0 you can clean up your database a bit to remove things that you kept around to make v1.0.0 happy, as it no longer runs.

This deployment strategy can get more complicated if you have different needs such as canary releases, A/B testing, etc. So there is no generic approach that you can apply - it all depends on what you want to do. In terms of database deployment, you are doing so called fast-forward changes which doesn't break existing deployments. Changes such as dropping a column, dropping a table, etc. are not what you would want at all.

You can also make this work for rollback scenarios. Here's an example: If you have just released v1.1.0 and it is not working as you expected, you can roll it back to v1.0.0 as it will work with the new database changes. 99.9% of the time you won't want to roll back the database changes unless you are OK with data loss.

Here are some good resources on the topic -

• https://vimeo.com/131641269
• http://martinfowler.com/bliki/BlueGreenDeployment.html

Additionally you might want to ask on the SQLServerCentral.com forums to see if anyone there has experience of what you are trying to do.

I hope this helps.

Mike Pullin

Robert,
Many thanks for taking the time to provide such an informative response. Your strategy looks to be something that we would look to implement, as it makes perfect sense to our SW Engineering Team.

Thanks again for your help

Mike Pullin
Business Analyst
ASE-Global