Cloudformation (the previous module) laid out the building blocks of a reproducible deployment, which in turn is so fundamental to cloud computing that it should be second nature. As I mentioned previously, the exam didn’t cover CloudFormation in a huge amount of detail, but deployment technologies (which we’ll cover here) did appear a fair amount.
The two concepts also build nicely on each-other in any case – Cloudformation gives us the ‘unit of currency’ when we talk stacks and resources, but you need a way of making the CloudFormation template a reality – resources have to go ‘somewhere’ after all.
As ever, here are the sections and resources for you so you can skip to what you need:
Blue Green Deployments Overview
If you’re really interested, there is a white paper on Blue/Green Deployments, but the essence of it is quite straightforward – see my own flashcards on those. Simply put, blue is current, green is new. You provision a new version of the app alongside the existing one. Once that’s good to go and you cut over to it virtually instantaneously. If it goes wrong, you switch back to the old version of the app.
Here’s a simple illustration where the green environment is being set up for a deployment and DNS is being used as the ‘cutover’ mechanism. Think about this for a second – let’s extract the fundamentals here:
- The deployment needs some means of cutover – in this case it’s a DNS endpoint to load balancer – but maybe you’ve used something like Nginx configuration to switch the underlying hosts in your day job? The point is the cutover is much quicker than the deployment.
- The new environment is being prepared whilst the old is still running – anyone who has worked with load balancers or application clusters would be familiar with that idea, but just in case – you make sure the new is ready alongside the old, rather than deploying ‘over the top’.
- When the new instance is up and running, ideally we want ways of testing the new deployment before the customer finds problems (far more stressful) – we’ll cover that in more detail.
- Not in this diagram, but a reality of the job (and addressed in the Whitepaper) – often the database (SQL or otherwise) has to change with the application. As a consequence, either your application has to support old and new data formats, or your database does.
If you can learn the strategies around that, and the different terminology, you should be good to go. This was the part that I initially struggled with – all the various technologies and approaches in pace to support that concept. I’ve created this table as a cheat sheet for this reason. I can also say that from all the practice papers I did (disclaimer, that’s an affiliate link) Elastic Beanstalk came up a lot.
Blue Green Deployments Flashcards
You’re welcome to use this set of flashcards from Blue/Green white paper if you’d like. I am also doing an offer in conjunction with Whizlabs where you can get ALL my flashcards for free (over 50 sets) when you buy exam guides through my affiliate link – and it won’t cost you any extra. See this page if you’re interested.
Blue Green Tools and Services
The white paper makes mention of the following tools and services to carry out a deployment – I’ll just summaries so you have the idea of the key-players in the scene as it were – you can do your own reading of them if you’re not overly familiar.
|Route53||How you switch over to a new environment using DNS.|
Points to old or new ELB.
Has the risk of caching, so pay attention to Time -to-live (TTL).
|ELB||Bring in new servers, check they’re healthy before allowing traffic in.|
Dovetails with autoscaling group by reporting on health.
|AutoScaling Groups||Use a new launch configuration to create the new (green) environment.|
Then you can leave old set of instances in standby state for a while, just in case.
Or use a termination policy to work out how to phase out old instances.
|Elastic Beanstalk||The ‘wizard’ of deployment templates.|
Gives you servers, scaling groups etc.
Support Blue/Green through ELB and Auto Scaling support.
Their ‘unit of currency’ for Blue/Green is the environments url.
|OpsWork||Works by cloning stacks,and updating the clone with new app version.|
Then switching a DNS record over once the new app is ready.
|CloudFormation||How we provision|
Lends itself to CI/CD processes.
|CloudWatch||How we create alerts based on what the ELB tells us.|
How we consequently trigger the autoscaling.
If you need to know where to look for more info on autoscaling and ELB, my earlier article might be a good starting point. In terms of the exam and practice papers, I got a single question on ops works but quite a few on Elastic Beanstalk. I’d like to cover that next.
Elastic Beanstalk Basic Concepts
Elastic Beanstalk essentially is a service for abstracting the provisioning of resources, so I suppose can be thought of as giving developers a lower barrier to entry. If you get a question along the lines of ‘what is the easiest way to get started with a deployment?’ – Elastic Beanstalk might be a candidate.
Applications, source and environments
The concept of environments and applications is especially important, as per the diagram from the page just linked.
I got a little confused at the terminology initially, but I think of it as:
- You create an application (an AWS Elastic Beanstalk application) –
- Then you upload YOUR business application (source code in this context).
- The assignment of your application source to an AWS Beanstalk application automatically launches an environment.
- Managing the environment updates the version of the (Beanstalk) application – so it follows that any given Beanstalk application must be immutable.
- Also the terminology tells us that an application is a container that includes an environment – it’s just you can use the managing of the environment to create a new version of an application, quite a nice pattern.
I would spend a little time understanding the concepts page so that you can understand questions on deployments.
The low barrier to entry of most frameworks we deal with are ‘opinionated defaults’. Maven and Spring are just two examples that occur to me. Elastic Beanstalk is no different, but of course it also allows overrides. I had enough practice questions to assume that learning the hierarchy and priority of overrides would be important. I’d start from here and would read all the entries under ‘Topics’.
The topics will help you understand the priorities used during provisioning and deployment. Next we’ll look at the types of Deployment that Elastic Beanstalk supports.
Elastic Beanstalk Deployment Policies
The table here gives you a list of all the deployment policies supported – I strongly suggest you set up some flashcards to understand how they work and what the differences are. Note that Blue/Green deployments are separate to these policies. We’ll look at the summary of all these approaches later. For now, we’ll move to AWS CodeDeploy.
CodeDeploy is slightly different in that it’s focused more on the end to end process – getting source to an deployed environment through automation. The overall concepts are on this page and there’s an intro below:
I included a snippet from a mind-map to help you see how it fits into the overall deployment picture of this article.
In my exam and practice papers, I got questions that require knowledge of the deployment configurations used by CodeDeploy. I’d read through that and Primary Components page to be able to handle variations on questions that occur about a deployment.
Table of breakdowns
Finally, a breakdown of deployments by technology and strategy, based on the deployment technology.
|Elastic Beanstalk||EC2||Yes||Yes||All at once|
Rolling with an additional batch
There is quite a bit to get to grips with the various deployment types, so you need to be aware of your use case. Are you looking to get started quickly, or looking to build a CI//CD solution? Do you want to abstract the environment provisioning, or have more control over it? There’s no right or wrong answer of course.
I hope this was helpful to you. If you have any feedback, questions, queries about this (or any) article, please feel free to contact me.
Next time we’ll look at even more abstraction of servers, namely something you intentionally have no control over. We’ll be looking at Lambda and Serverless solutions then.