This series will discuss the Elastic Beanstalk service from Amazon Web Services. In this first part we will discuss what Elastic Beanstalk is and its architecture.

Elastic Beanstalk allows users to deploy and manage applications in the AWS cloud without having to worry about the infrastructure on top of which the applications run. Elastic Beanstalk takes care of computing provisioning, scaling, load balancing and monitoring.

VMware Training – Resources (Intense)

In fact, Elastic Beanstalk uses several AWS services to implement the platform on which the applications will run.

To use Elastic Beanstalk, these are the basic steps:

  • Create the application.
  • Upload the application version.
  • Launch the environment.
  • Manage the environment.

The first step, application creation, is not strictly related to Elastic Beanstalk. The application has to be created somewhere else and the first interaction with Elastic Beanstalk is when you actually upload the application version.

Let’s briefly discuss the components of Elastic Beanstalk:

  • Application – A collection of Elastic Beanstalk components, which can include the environment and the environment configuration.
  • Application version – A specific version of the code that is deployed. An application can have multiple versions and each is unique. Multiple versions of applications can be uploaded to compare differences between them.
  • Environment – A version of the application that is deployed. Each environment can only run a single version at a time. However, different versions of the application can run in different environments at the same time. Each environment is provisioned separately by Elastic Beanstalk.
  • Environment configuration – A list of parameters that define how an environment behaves. If an environment configuration is updated, then Elastic Beanstalk applies the changes to the resources allocated to the environment. That means that some resources can be deleted and others can be added.
  • Configuration template – A starting point for new environments.

There are two types of environment tiers. An environment cannot support both tiers at the same time.

  • Web server tier – An environment that processes web requests.
  • Worker tier – An environment that runs background jobs.

We will focus mostly on the web server tier in this series. In the second part of the series we will launch an application using the web server tier environment.

When an environment is created, you will be asked about the platform type, which is the underlying infrastructure on top of which your application will sit. It can be a standalone instance (a single EC2 instance) or an auto-scaled and load-balanced infrastructure. The latter means that an auto-scaling group will be created and an Elastic Load Balancer will sit in front of them.

Below is the architecture for a web server tier environment:

The above architecture describes the auto-scaled, load-balanced platform type. As you can see, it features the EC2 instances, the auto scaling group and the Elastic Load Balancer. Moreover, the EC2 instances are all part of a security group that allows connections on HTTP ports.

The software stack running on the EC2 instance is dependent on the platform type. The platform type is the programming language used to deploy the application. Based on the platform type, a specific EC2 instance operating system will be used along with the specific software to accommodate the type of the platform.

There is another critical component that runs on each EC2 instance and this is host manager. It has the following roles:

  • Application deployment
  • Metrics and events aggregation
  • Instance events generation
  • Log rotation
  • Application log files and application server monitoring

The other environment is worker environment tier and the difference is that Elastic Beanstalk creates an Amazon Message Queue Service (SQS) queue. Once the worker tier environment is launched, the daemon installed on the EC2 instance created during the environment launch pulls the requests from the SQS queue and sends the data to the web application running in the worker tier environment, which will then process the messages. The daemon is installed on each EC2 instance, but all daemons read from the same SQS queue.

When an environment is created, two IAM roles are requested, a service role and an instance profile.

  • Service role – Allows Elastic Beanstalk to use other AWS on your behalf. This is used when Elastic Beanstalk needs services to gather information about the health of the resources.
  • Instance profile – Allows EC2 instances to call AWS for features like health reporting and container management. The instance profile is used to write logs in S3 buckets, read from the SQS queue or publish metrics to CloudWatch.

Let’s discuss a few design considerations:

  • Scalability – Thi is achieved by using Auto Scaling that can monitor different metrics before it scales the resources allocated up or down.
  • Security – SSL should be configured to protect the data received from the clients. This encrypted data is between the client and the Elastic Load Balancer.
  • Storage – Elastic Beanstalk runs on an EC2 instance with no persistent storage. Options for persistent storage are Amazon S3 buckets, Elastic Block Stores (EBS), Amazon DynamoDB or Amazon RDS.
  • Fault Tolerance – The environment should be deployed using multiple EC2 instances in different Availability Zones.
  • Connectivity – For single instance environments, an Elastic IP address is allocated to the EC2 instance. For load balancing and autoscaling environments in a VPC with public and private subnets, several things have to be done: an ELB should route inbound traffic from the Internet to the EC2 instances; a NAT instance should route the traffic from the EC2 instance from the private instances to the Internet.

We are now done with the introductory part of Elastic Beanstalk.

By reaching this point in the series, you should know what Elastic Beanstalk is, its components and its architecture.

You can check the references section below for pointers on where to look for additional information about Elastic Beanstalk.

In the second part of the series we will have some hands-on activity to see how to deploy a PHP application and then deploy a new version of the application in another environment.