Hello and welcome to the final lecture of this course which has covered the introduction and fundamentals of Elastic Beanstalk. I started off by explaining what AWS Elastic Beanstalk is and within this lecture, we learned that Elastic Beanstalk is an AWS managed service that automatically provisions and deploys resources required to run your web application based on uploaded source code. Resources can include other AWS services and features such as EC2, Route 53, Auto Scaling, application health-monitoring and ELBs. Elastic Beanstalk allows engineers who may not the skills and confidence within AWS to deploy, provision, monitor and scale the correct environment. The ability to do so for a simplified framework. AWS Elastic Beanstalk can operate with different platforms and languages as shown. There is no cost associated with Elastic Beanstalk, however, any resources that are created, you'll be charged for as per the standard pricing policies. And the core components of the service include: the application version, which is a very specific reference to a section of deployable code, the environment, and this refers to an application version that has been deployed with AWS resources. The environment is comprised of all the resources created by Elastic Beanstalk. Environment configurations, this is a collection of parameters and settings that dictate how an environment will have its resources provisioned. The environment tier, this determines how Elastic Beanstalk provisions resources based on what the application is designed to do, either a web or worker tier. Configuration template, this provides the baseline for creating a new, unique environment configuration. The platform is a culmination of components including the operating system, the programming language, the server type and components of Elastic Beanstalk itself. Applications, a collection of different elements such as environments, environment configurations and application versions. 

Following this lecture, I then look to the differences between the web server and the work environment tiers and here I explain that if an application manages and handles HTTP requests, then the app will be run in a web server environment. If the application pulls data from an SQS queue, then it would run in a worker environment. Now looking at the web server tier, it's typically used for standard web applications serving requests over port 80. Their tier typically uses the following services and features: Route 53, ELB, Auto Scaling, EC2 and Security Groups and a host manager is installed on every EC2 instance. The host manager responsibilities include to aid in the deployment of your application, it collates different metrics and different events from the EC2 instance which can then be reviewed within the console or via the AWS CLI, it generates instance-level events, it monitors both the application log files and the application server itself, it can be used to patch instance components and it manages the log files allowing them to be published to S3. With the worker tier, this is used by applications that will have a back-end processing task that interacts with SQS and this tier typically uses the following AWS resources in the environment, SQS Queue and IAM Service Role, Auto Scaling and EC2 Instances. A minimum of one EC2 instance is used and is attached to the auto scaling group and each EC2 instance in the environment will read from the same SQS Queue. A daemon is installed on every EC2 instance to pull requests from your SQS Queue and it's likely that you'll end up using two tiers in conjunction with each other. You can develop and add your own Elastic Beanstalk configuration files within your application source code and these need to be saved with a .config file extension and then stored within the .ebextensions folder of your source code. Following this I then discussed different deployment options that are available to help you update your environment. These work all at once, rolling, rolling with additional batch and immutable. All at once is the default option and it will update your application to your resources all at the same time causing a service disruption during the update. Rolling deployments deploy your applications in batches, performing an update to just a portion of your resources at a time. Once update is complete, it will then perform the update on the next batch. Rolling with additional batch, here Elastic Beanstalk adds another batch of instances to your existing resource pool to ensure application availability is not impacted during the update. And this provides a greater application availability compared to that of the rolling deployment option. Immutable. Immutable deployments will create an entirely new set of instances with your update applied to your environment alongside your existing resources. 

I then provided a demonstration on how to configure the Elastic Beanstalk service using the AWS sample code. 

Following the demonstration, I explained some of the methods that Elastic Beanstalk uses to provide health-monitoring and reporting. In this lecture, we learned that there were two levels of monitoring with Elastic Beanstalk. Basic health reporting and enhanced health reporting and monitoring. With basic health reporting, it provides information and data to allow you to gain a high level overview of how your environment is performing and resources running in your environment will send metrics to Amazon CloudWatch in five minute intervals. There are four colors within the AWS Elastic Beanstalk dashboard that show the health status as shown and every 10 seconds the ELB will send a health check request to every instance in the auto scaling group and wait for a response to confirm its health. For single instance environments, the health of the instance is determined by its EC2 instance status check. Elastic Beanstalk will ensure that in a a Web environment, an auto scaling group has a minimum of one instance running that is healthy and it checks to ensure the CNAME in Route 53 is redirecting to the correct ELB. It will also check to ensure that the security group for your EC2 instances allows port 80 inbound and in Worker environments, there will be a check to make sure that the SQS Queue being used is being polled every three minutes at a minimum. For enhanced health reporting and monitoring, the color index signifying the health of the environment is different to the color index used in basic monitoring. Enhanced health monitoring displays additional information to that over the basic. AMI is used for EC2 instances have a health agent installed and running. The health agent captures additional information such as system metrics and web server logs. And these metrics can then be sent to CloudWatch as custom metrics for an additional cost. Sending data to Amazon CloudWatch allows you to view the health of your environment over time. The health agent is a daemon or service installed onto a deployed EC2 instance and the health agent probes the instance at a deeper level and more frequently when compared to CloudWatch. 

That has now brought me to the end of this lecture and to the end of this introductory course. You should now have a clearer understanding of what the AWS Elastic Beanstalk service is and what it's used for along with how it's configured and the underlying components of the service itself. To gain additional hands on experience with Elastic Beanstalk, I suggest you take a look at the following labs that we have Firstly, run a controlled deploy with AWS Elastic Beanstalk and then deploy a PHP application using Beanstalk. 

If you have any feedback on this course, positive or negative, please contact us by sending an email to support@cloudacademy.com. Your feedback is greatly appreciated. 

Thank you for your time and good luck with your continued learning of Cloud Computing. Thank you.