The software in question was a CakePHP web application that was running on -premises. The team faced frequent issues with data-center outages and networking, thereby struggling to meet the dynamic scale of the application.
Aligning with the overall organizational strategy to adopt AWS offerings, the team was obviously looking for some quick wins through the elasticity and endless possibilities offered by the cloud.
Note
This is a common scenario you will come across when teams are on a transition path from on-premises to the cloud. PaaS clearly stands out in such situations by offering a solid foundation the teams can begin with. It safeguards teams from falling down before they begin.
With the need justified and the challenges well understood, my next step was to explore which AWS service could meet these requirements. AWS Elastic Beanstalk seemed to be a promising candidate. It offered a unique combination of managed operating systems, web servers, programming language runtime, and application servers. The user just needs to design and target the web application to a particular platform, and Beanstalk takes care of the rest.
Creating a new PHP-based Beanstalk application provisioned the following resources out of the box:
- EC2 instances – These are the compute servers that host the chosen application platform, in this case, CakePHP.
- AWS Elastic Load Balancer (ELB) with a custom domain name – As a security best practice, the EC2 instances are not directly exposed over the internet. Beanstalk additionally configures a Route53 CNAME record, which makes the ELB available on a custom domain name. It forwards incoming requests to the underlying EC2 instances.
- Security groups (SG) – SGs are configured at the instance level and the ELB level. They allow the incoming traffic to pass through both components only when specified ports are used.
- Auto-scaling group – Depending on application usage metrics, the EC2 instances are configured to automatically scale out or scale in. This allows for adapting the application based on user demand by leveraging cloud elasticity.
- Amazon S3 bucket – This is where the user can upload code archives. Post-upload, theseare unzipped, and Elastic Beanstalk takes care of provisioning the recent application binaries to the attached servers.
- CloudWatch Alarms – Beanstalk also sets up CloudWatch alarms to trigger alerts based on pre-defined load thresholds such as CPU, memory, or network usage.
All of this with just a few clicks in the AWS web console!
As you can see in Figure 2.1, an entire environment starting from the infrastructure up until the external domain name was provisioned by the service – that’s the power of PaaS:
Figure 2.1: Managing applications via AWS Elastic Beanstalk
After playing around for a week or so with the newly provisioned environments, the developers gained the confidence to work with it and migrated their existing codebase to Elastic Beanstalk.
To support data storage in the cloud, an Amazon Relational Database Service (RDS) cluster was also spun up that provided data persistence in the cloud. Beanstalk offers possibilities to inject customized environment variables that can then be read inside the application code.
Replicating these application stacks across multiple environments was super easy with the creation of new environments linked to the same parent application. So, within a few hours, the developers had development, staging, and production environments up and running in the AWS cloud. It took around 8-10 days to completely migrate the application from an on-premises static infrastructure to the cloud.
There are a few important areas to assess when selecting a PaaS offering.