If you are working in IT you must have noticed, we are living in the cloud era. Most of the online IT related startups choose to deploy their product to the public cloud. Elasticity, high availability and continuity seem to be the biggest and most convincing selling points. I personally am a big cloud enthousiast and enjoy working in the cloud. At this point the most populair cloud providers have such a rich and mature cloud platform that there are hardly any use-cases to choose something else. The cloud and its concepts are here to stay.
Unfortunately, There’s a Big Flaw
When architecting software for the cloud most architects respect a couple of core design concepts. Separating the data from the service layers in order to scale separately, designing for failure (chaos monkey concept), scalability and cost efficiency seem to be most respected ones. The architectural choices in the project are based on these variables.
At the end of the project the CTO reads the exit strategy document which the architect made at the end of the project and realises that there is a serious vendor lock-in. Right now that is not a problem, the application is working perfectly in the cloud and AWS (or GCP, Azure) is the new cool thing to do. However, 5 years from now, the demand of the market has changed which triggers a couple of software architectural changes. The newly hired architect convinces the CTO to also rethink their choice for infrastructure vendor, because at this point in time the public cloud is not populair anymore (this is a real threat, technology is moving extremely fast. Do you remember Puppet before Docker was cool?). They decide to move a private cloud based on OpenStack. Because the exit strategy was not a part of the architectural choices 5 years ago, the entire application stack needs to be rewritten in a multiple years project. This is where the term ‘design for exit’ comes into play.
Being cloud agnostic is not a new concept, it means that your application is not tied to a specific cloud vendor and can easily be moved to another. In designs which are based on this you mostly see a platform build on open source tooling. The difference between being cloud agnostic and ‘design for exit’ is that cloud agnostic means you are 100% compatible with a different vendor, which translated to no vendor lock-in at all. Designing for exit means you should choose between cost efficiency (or any other design concepts) and the impact on the exit strategy. Sometimes the lower costs of a SaaS solution weighs more then the negative impact on the exit strategy.
Design for Exit
Now that we understand the concept behind ‘design for exit’ let’s look at some examples. In my examples I will focus on AWS services, but GCP and Azure have similar services.
MySQL vs Relational Database Service (RDS)
You could choose to host a MySQL node on EC2. But setting up RDS in a Multi-AZ setup with monitoring and alerting can be done in a couple of minutes. In this case the cost efficiency and scalability weighs more then the impact on the exit strategy. When moving away from AWS you would need to build up a MySQL node (or a couple of them), but because there is no changes needed on the application side (other then changing connection parameters) it is not a very big issue.
AWS DynamoDB vs MongoDB
DynamoDB is a custom NoSQL database from AWS. MongoDB is also a NoSQL solution but it is based on open source software. For cost efficiency you would go for DynamoDB, because MongoDB needs to run in a cluster setup on several EC2 nodes. However, DynamoDB has a very negative impact on the exit strategy because you need to rewrite a lot of software in order to support another database back-end. In this case the exit strategy impact is too high and I would choose MongoDB.
CloudFormation vs Terraform
CloudFormation is an ‘infrastructure as code’ service specifically for AWS. Terraform does the same, but is open source and not limited to only the AWS cloud (it supports many providers). Although the feature set for Terraform in combination with AWS might be a little bit less, I would still choose for Terraform. This choice has no impact on cost efficiency or any other design concept, but it has a big impact on the exit strategy. There is a big chance that your new provider is supported by Terraform so you only have to rewrite a couple of lines of code in order to use it.
Conclusion
If you want to use the public cloud right, you cannot be fully cloud agnostic. There will always be some vendor lock-in, the question is how much? Make sure that designing for exit is a concept you will use when making architectural choices. Application changes seem to be heaviest motive there. Just remember, it’s easy to get in the public cloud, the difficulty of the exit is a choice.
