I see blue/green deployment are a good approach for the code part of an application. But what about the data? When you switch over, you can probably use a preloaded data set (surely not up to the latest changes, or you have a downtime), okay; but if you have to switch back, you need to replicate the changes that happened between the last switch the the current switch somehow ?!?
5 Answers
Hi Marcel, you can use the same RDS (or and S3 bucket) as data store for blue/green deployment as an example.
https://techblog.bozho.net/blue-green-deployment/ explains this well
The challenges here are what if the blue and and green deployments have different database schemas. It’s complicated when taking database as factor in Green/blue deployment
Bluegreen deployment majority of the time is not down to the DB/Data level(You wouldn’t frequently modify your DB), just on the FE application and BE processes like API that connects to a persistent data storage i.e your DB or Datastore. Your FE application can change often with new features going in but your DB stays the same. When you have a new feature on your application you spin up a separate instance that connects to the same persistent Data/DB as the existing to instance, test your new instance to ensure your feature is all good and still function as normal I.e making calls to backend processes or having access to data etc and then you switch to your new instance, Route53 and ElasticBeanstalk architecture and other services simplifies blue/green deployments.
"You don’t develop new features to your DB/DataStore!(Stores your data and stays the same (Persistent) always available for your application to connect to) You develop your applications that connect to the DB/Store(Again which is always stays the same)"
If that makes any sense lol, that’s how i understand blue/green deployment.
This is a major design challenge and consideration in blue/green, and there’s no simple pattern that addresses it for most cases. It very much depends on your application. In a cloud context, I think designing your application to be as stateless and decoupled as possible can simplify some of the challenges.
If you can separate code, configuration, and content in such a way that your updates don’t make difficult-to-revert changes to data, your data layer can stay consistent between deploys. Or, you can use a microservices architecture which presents a consistent interface to the data to your app regardless of the backend data store. You can handle data migrations through that model (I’ve done it to gradually change the hashing function for passwords stored in a database), eg:
1. Call is made to retrieve data
2. Code queries database
2a. Data in old format? Update database with new format, return data
2b. Data in new format? Return data
Overtime, this will migrate everything, without need for downtime.
This blog post is a good concise summary of those kinds of approaches: https://phauer.com/2015/databases-challenge-continuous-delivery/