Company: I have an application that evolves as business needs change and functionalities are implemented.
Amazon: Sure, I can help you with deploying your applications, managing the scaling of your application based on traffic.
C: That will be great. What service can I use?
A: You can use ECS (Elastic Container Service)
C: Containerization is in vogue. We have containerized our application too, and we do have code pipeline that pushes the container image into Elastic Container Registry (ECR)
A: Right — container is the basic building block. We have a few abstractions that let you configure the deployments. For instance, if you have an application for which you expect more compute in order to handle more requests, and more functionality, you can have more instances of the container running. And for functionality that is minimal, you would have less number of instances running.
C: Sure. Let us take one more step back. I think it would help for me to understand the ecosystem better. It is your service, so I will let you explain in terms of abstractions that you have.
A: ECS is basically a container orchestration service. It orchestrates containers in the sense that it brings more instances of a container A, while it makes even more instances of a container B, while it shuts down multiple instances of container C, and totally shuts down instances of container D, based on traffic rules say.
Different applications would have different lifecycles in terms of when new functionalities come in. It is like a garden of flowers, some bloom early, some bloom late, some are whithering down.
The garden must go on.
C: You guys say that you simplify the deployment. I have to agree to do that. I have to write code as my functionality changes. That is something I just have to do. There is no way, I can expect any help there. And I have my code pipeline running that automatically deploys the latest version of the application behavior into ECS automatically. There is absolutely no work that I need to do to have the latest functionality deployed.
A: That is great to hear. That is our goal — that with minimal friction, you get to deploy your code. However, I would guess there are hiccups still — this is not an ideal world. What kind of hiccups have you faced?
C: Sometimes I make mistakes while I code. So my unit tests fail — and so my functionality does not make it to the customer. Or my integration tests fail, or my DB scripts fail. Those have nothing to do with you. Sometimes, DB container does not startup, and there are networking issues.
A: Sorry to hear that. Eitherways, it would enable you to understand the philosophy of how we are looking at the service.
C: You say you that you help with management of containerized applications. That is correct — I hardly have to manage anything once I have the code pipelines setup to make the deployments automatically. You also say that you help with the scaling of the application. That is correct too — based on production load, you bring more container instances up, or bring down container instances.
A: You need to describe your application in terms of the resources needed.
C: That is correct. I have done that. I remember increasing memory limit for applications that need more memory to work with, and reducing memory for applications that do not need as much memory.
“Amazon ECS will launch your application.”
From my perspective, I had a gitlab CI pipeline, which has a job to execute cloudformation. Cloudformation internally invokes Amazon ECS. And yes, it is the Amazon ECS service that actually spawns the EC2 instances and deploys the container images that I have specified into these EC2 instances.
“Amazon ECS will monitor your application”
I have seen this in action too as I track the cloud trail logs for application behavior that needed to be analyzed.
These are the three layers of Amazon Elastic Container Service.
Capacity options
Compute capacity is what we are talking about. We can run the compute, the functionality on EC2 instances, on Fargate, or on-premises. I have done all three. I use Fargate for my standard QA deployments. I had specific requirements that would not be addressed by Fargate, and to handle such use cases, I have deployments into EC2 instances. Certain customers do not let me store their data in the cloud. So I have installed my applications in the premises of the customer.
Controller
Looks like this is the guy who takes in the requests and deploys applications into the capacity options.
Provisioning
Tools that you use to interface with the controller. I have mostly used AWS CLI commands from my code pipeline to invoke the controller. I have used the AWS Console UI to provision the instances.
A: Above is the overall view of ECS. This is how ECS functions. You as the customer does not have much say on how ECS functions. It helps to have the understanding though.
C: That is true. I had not exactly thought of it like this. I can relate to the provisioning tools like the command line interface, cloudformation scripts etc as I have used them directly. I can also relate to the capacity options of FARGATE versus EC2 as I have both running for me to serve different use cases. What I was oblivious to was the controller. That is a detail that I was not directly exposed to. It is a detail that was very much there but under the surface.
A: What you do not have a choice to not have understanding about is on how to specify your application functionality. You have to tell me which image to use for instance, you also need to tell me how much memory I should allot on the compute instance. Abstractions relevant to such a specification are task definition, and service definition.
C: Sure. I have had to work with these. Specifically, I wire the image tagged as “latest” into my task defintion, and have specified higher number of instances for “bigger” applications, have specified higher “memory” limit for applications needing as much and so on.
Service is an abstraction on top of tasks — where you can specify that this service needs 4 instances of the particular task running.
A: There is something called the container agent that I run in the container along with your application image. The purpose of this is to interface with the orchestrator — the Amazon Elastic Container Service. The agent would send information about the current resource utilization, and the number of tasks to ECS……
