After my last post about AWS Lambda and Serverless Computing, I got to thinking. How is Lambda different from Elastic Beanstalk(EB). AWS has been offering Elastic Beanstalk as a managed service for quite some time and from the looks of it, developers can just submit their application and AWS will take care of deploying, managing and scaling the infrastructure that is needed to run their application. So, I decided to dig deeper into what Elastic Beanstalk is, what the architecture looks like and what are the benefits of using this service.
So let’s get to it. According to AWS: “Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS”. This means that you can basically upload your application code, and AWS will do all the work to make it available to your end users. There are the following three basic architectures to choose from to build out your environment:
- Load Balanced and Auto-Scaled: This is the most common type of environment that is used for EB deployments. When you select this environment, AWS will spinup an Autoscaling Group(ASG) that will manage the EC2 Instances that are deployed to run your application. Along with that, it will also spin up an Elastic Load Balancer(ELB) to distribute traffic between the different EC2 instances that are part of your environment. You can configure the ASG, to modify the minimum and the maximum number of EC2 instances that you want.
- Single Instance: This type of environment is used if you do not want to spend those extra $$ to run an ELB. In this deployment, there is only one EC2 instance that is running your application, which is managed by an ASG. You might be wondering, why would I need an ASG, if I can only have a single instance at any given point in time. This is because, if that single instance goes down, ASG will automatically spin up a brand new instance to run your application. As you might have already figured out, while this new instance is coming up, your application will suffer some downtime. Your EC2 instance will have an Elastic IP(EIP) address assigned to it, and this EIP will move to the new instance if the original instance goes down for some reason. This makes sure that your end user always connects to the same end point, regardless of the instance that is running your application.
- Backend Worker: This type of environment is used when all you need are instances that take messages from an SQS queue and keep working in the background and finishing up tasks. Your end users cannot access these instances directly, the only way to pass messages to these instances is via the SQS queue. The EC2 instances are managed by an ASG, and since the end user never interacts with these instances directly, you do not need an ELB to manage the load.
Now that we have discussed the types of architectures, let’s dive deeper into what the different components of an Elastic Beanstalk environment are. From a high level, we know that it contains EC2 instances, Autoscaling groups and may or may not contain an Elastic Load Balancer. Apart from these, it also has a Control Plane, which is the heart of this managed service. It manages and controls all aspects of creating your applications, maintaining versions and managing the environments where your application is deployed. When you interact with the service using either the AWS Console or the APIs, you are talking to the control plane. The control plane talks to other AWS APIs to provision other resources like EC2, ELB etc., on your behalf. It also talks to an EB Agent, that runs inside each EC2 instance in your environment. If for some reason, it cannot contact the agent, it assumes that something is wrong, terminates that instance and spins up a new one to support your application.
The EC2 instance in itself contains the following components. Each instance has an Operating System, it has an EB Agent which is powered on when the instance is powered on for the first time, it has the language runtime environment and it also has the application code. When the EB Agent comes up, it goes and talks to the control plane and identifies if the OS needs to be patched. After that depending on the programming language of your application, it will spin up a runtime environment for your application. Next, the agent will go and talk to a private S3 bucket, which contains the exact application version that needs to be run on the instance. The agent downloads and installs the bundle and starts the application. Once the application is up and running, the agent then monitors the application, and if it finds any issues, it will communicate with the control plane, which then decides if it wants to terminate the instance and spin up a new one to support your application, thus going through the same cycle again.
Phew.. That was a lot to take in. If reading all this text has left you curious, you can check out the resources that I have listed below, and also you can deploy a sample application from your AWS account, and see all these different components at work.