Overview
Following on from deployments, I wanted to talk about containerisation as part of the overall cloud ecosystem. It seems important enough too, as the AWS Developer Associate certification page suggest our experience should include:
Ability to apply a basic understanding of cloud-native applications to write code.
Which really is a fancy way of saying we need to understand containers, microservices and the way we scale/load balance them. I got some questions on ECS during my exam practice, but getting broad knowledge of principles meant I would feel confident in applying them to EKS, for example.
BTW I’m going to have to assume that you already know some rudimentary Docker – if you’re not even across that, start here first.
Background and Fundamentals
When doing the exam practice papers, I got questions on ECS. But I didn’t want to get good at just doing ECS questions. I already had microservice experience in my day job but I wanted to see how to play the exam game. In short:
I wanted to learn content general enough to be able to understand variations in practice questions.
But also:
I wanted to learn content specific enough to be be within the context of AWS.
With that in mind, I worked backwards to put a guide together. Let’s start with the ideas of the 12 factor app which is mentioned in one of the whitepapers we’ll look at.
The 12 factor app
The idea of the 12 factor app is a good way to understand what AWS is driving at with their technologies. Think of it as the ‘greater good’, the goal that transcends AWS. In this context, AWS is just an implementation detail. Maybe have a think of how many AWS technologies you recognise as contributing to this methodology?
I. Codebase
One codebase tracked in revision control, many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup and graceful shutdown
X. Dev/prod parity
Keep development, staging, and production as similar as possible
XI. Logs
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off processes
With this under our belt, we can extract meaning from any of the whitepapers (should we choose to take a read).
Whitepapers
Personally I think reading the Containerised Microservices whitepaper is overkill, so I’ll leave that one up to you. However, I did get some value in reading the Implementing Microservices whitepaper since it gave me a view of the specific technologies to implement the principles of the 12 factor app. Therefore I’d recommend skimming the 12 factor app (the home page is fine) and then skimming the Implementing Microservices whitepaper for the following:
- The abstract.
- The deployment patterns (Lambda, ECS fronted with an ALB, Microservices fronted with a gateway etc).
- The difference between the API driven, event driven, and data streaming models – you don’t need extensive detail, just to know that they exist.
I’d especially encourage you to look at the deployment architecture in the whitepaper so that you’re doing your learning with the full picture in mind. Last week we covered how API gateway fronts a Lambda service, so we don’t need to revisit that. But looking at this white paper, the takeaway is that we can use API gateway to also front ECS services. So that seems a good enough place to start – behind the gateway, looking at ECS service itself.
Understanding ECS
Let’s review the developer overview, and get an idea about what we might have to learn.
Amazon Elastic Container Service (Amazon ECS) is a highly scalable, fast container management service that makes it easy to run, stop, and manage containers on a cluster. Your containers are defined in a task definition that you use to run individual tasks or tasks within a service. In this context, a service is a configuration that enables you to run and maintain a specified number of tasks simultaneously in a cluster. You can run your tasks and services on a serverless infrastructure that is managed by AWS Fargate. Alternatively, for more control over your infrastructure, you can run your tasks and services on a cluster of Amazon EC2 instances that you manage.
Awesome, this gives me everything I need for some active testing. To save you some time, here are some questions I have distilled from that intro to reinforce the big picture. We’ll take a look at the architecture, using the Fargate model first.
Fargate and ECS
So the interaction between a task definition and an image I think of as:
- Application code lives within an image in ECR.
- The task definition knows which image to pull.
- The task is the instantiation of the task definition.
- The service has the criteria for how many instances of the task to maintain.
- The task runs and in the case, of ECS Fargate has a network interface to collaborate with other tasks/other AWS services/the outside world).
There is also the EC2 model, it’s worth skimming through how that differs from the Fargate model. Long story short, Fargate is the ‘we manage it for you’ option, so think about that when given an exam question that offers “cost vs control” for a container based solution.
EC2 and ECS
In short ECS container instances refer to containers orchestrated by EC2 instances running a container agent.
I would skim the container concepts and make some flashcards for yourself to test that you grasp the architecture.
Intro tutorial
So it’s probably easiest to start with the Fargate Tutorial but I didn’t find it useful in and of itself. There are also several useful videos of concepts in the ECS getting started page if you prefer that kind of content for your learning.
However, in terms of the tutorial – if you just follow the wizard steps and get a “Hello World” example working, it’s not that useful. It’s not really helped you to understand the concepts much. I’d use it only to tie back concepts that exist from my questions sheet and on the various components pages.
See if you can find the following during the tutorial, or even reflect on it afterwards :
- The idea of clusters – where can we find information about the state changing using the AWS console?
- The idea of task definitions – where do the points covered in that AWS page tie into the sample provided in the tutorial?
- The idea of services – where is that in the console? Is there anything I can do to see the various states.
- The idea of launch types – what is the difference in architecture between using EC2 and ECS?
- What is the lifecycle of a task – how do I visualise that?
- Optionally you can do the EC2 tutorial as well, to reinforce the ECS container concepts we touched on in the previous section.
We don’t need to spend too long on this, but actively investigating under the hood, will help you to understand some concepts. Invest a bit of time here, and then it becomes easier to skim the rest of the content.
What about the exam?
If you’ve been following along by now you’ve done a simple tutorial and tested yourself on some of the architectural concepts. With that done, you should be good to get a breadth of knowledge on the remaining.
Use cases
These can be found under the overview page – these are great to just understand when an exam question might be leading you towards ECS as an option.
Security
I’d look at the main security page and the topics on IAM and Logging and monitoring – since if I got an exam question on troubleshooting I’d want to know how the security model works and what the logs might tell me.
EKS
I’d look at the overview page now I’d done my homework on container fundamental so I had built my exam breadth. Mabe try and understand how they’re the same (orchestration) and how they differ.
Load Balancing
Get across the types of load balancing that ECS supports, and likewise autoscaling – understanding these will help you to tie back to the original white paper, understand variations in exam questions, and be able to do the day job rather than just get the piece of piece of paper.
Conclusion
In terms of what you need to cover for the exam, I found that once I had a coverage of the architectural concepts, I really just had to tighten up the gaps with some practice tests, which in turn directed me to the correct pages within the ECS documentation.
If you can start with the white papers and see how a containerised solution looks, then you’re well set. Build on that with understanding the ECS concepts (EC2 vs Fargate), and the key players. Then cover the auxiliary areas, such as security and monitoring. Finally test yourself with some sample exams.
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 be looking at how CI and CD pipelines work, since containerisation lends itself to that quite neatly.