I’ve seen many circumstances where only the production environment for an application runs on AWS. The primary reasons given for this are often cost and the time taken to provision the environment.
I believe this is a mistake and here I discuss my top 5 reasons for running your dev and test environments on AWS along with production.
1: CloudFormation and other ops tools make provisioning quick and repeatable
I often find that tools such as CloudFormation are over looked when it comes to provisioning environments. CloudFormation is a way for you to describe in JSON the resources that make up an AWS environment for your application and how those resources should be connected together.
Whilst there is some initial up-front overhead in creating the CloudFormation template for your environment, once it is done it can be used again and again to provision new environments. Need a new test environment, simply upload the CloudFormation template and create a new stack. Voila. AWS even provides a handy export tool that will produce a CloudFormation template from your existing running resources, which makes it even easier to create.
2: Consistency breeds confidence
Deployment failures are littered with stories where configuration in the production environment was not the same as the test environment. I’ve worked on projects where test environments has different OS’s and even different Java versions from the production environment.
The upshot of this was often deployment failures and downtime for users when trying to resolve those issues. It also dramatically reduced business confidence in the update procedure meaning new releases were often postponed at “critical” times.
With tools like CloudFormation, OpsWorks or CodeDeploy, you can be extremely confident that your AWS environments are identical bar some minor application configuration. This not only gives you confidence that what works in one environment will work in the next, it dramatically reduces the number of areas to look when attempting to troubleshoot production problems.
3: Practice makes perfect
Often the application is only updated in the production AWS environment after a significant period of development (weeks or even months). This means that deployments only happen infrequently and are often only done by a select group of individuals.
By running dev and test environments on AWS, you democratise the deployment process. Deploying becomes the norm and not something to avoid. Under rapid development scenarios, you may be deploying to dev and test environments tens of times per-day. Not only does this let you perfect your deployment process, it allows all members of the team to be educated as to how deployments work meaning production deployments can be a shared responsibility.
4: Easily prototype environment changes
One of the major benefits of AWS is that is allows you to tinker with your environments very easily. As most resources can be provisioned at the press of a button, it makes introducing new resources e.g. caching very low-risk.
To reduce risk even further, if your dev and test environments run on AWS and match production, then you can prototype any environment changes before applying them to the live application.
When the time comes to apply the changes to your production environment, simply update the CloudFormation template and apply the changes (you can test this process when applying it to either your dev or test environment).
5: It will probably save you money
The true cost of having inconsistent environments is rarely seen. Developers spend hours tracking down why an application works in one environment but not the other. Users cannot use the application whilst a failed production deployment is resolved. Dev teams are blocked waiting for Ops teams to apply requested changes to the environments.
The upfront dollar cost of an environment on AWS is easy to see and this often puts people off investing the time and effort in them. However the decision to run multiple environments on AWS often quickly pays back in developer productivity and business confidence in its deployment process. If monetary costs really are a problem, then they can be lowered further by judicious use of reserved instances or even turning off environments when they are not in use (something that is again made easy by the use of things like CloudFormation templates).
We’re big fans of running all environments on AWS as we believe it brings consistency and confidence to the development and deployment of an application. We believe the upfront cost of getting to that scenario is quickly repaid through developer productivity and reduced chance of error.
We help and advise all our clients to try and move towards this model and strongly recommend you to consider it too.