CASE STUDY - S3Bubble
S3Bubble needed to reduce manual labour surrounding day-to-day service delivery. Following an AWS Well-Architected Review, DevOpsGroup’s engineers introduced an automated approach to expand and scale capacity according to use. It enabled the business to improve reliability, security and performance. What’s more, enhanced user insights will underpin future customer-focused innovation.
Cloud Platform Engineering
Originally, S3Bubble’s configuration consisted of an AWS RDS-backed mySQL instance, a EC2 large instance hosting WordPress and an Elastic Beanstalk-managed cluster of EC2 servers hosting the API. Due to an unexplained CPU leak on the WordPress server, it had to be scaled up in order to maintain functionality. While customers were receiving the service they expected, it was taking S3Bubble’s team a considerable amount of time, effort and manual configuration to maintain. This resulted in an inevitable lag in between capacity demands being created and met, leaving customers briefly short of the resources required.
DevOpsGroup had previously performed a Well-Architected Review against S3Bubble’s infrastructure, identifying several required actions to remediate some urgent risks. To address the issue of capacity, AWS Auto Scaling Groups were implemented around both the WordPress and API services. This allows resources to be provisioned as demand rises and falls.
The original instance structure was replaced by a pool of burstable instances that are more able to cope with sudden spikes in traffic, as well as having the ability to call in a cavalry of further instances should the need arise. A Mixed Instance Policy also results in Spot Instances being used for part of the EC2 fleets, not compromising on reliability or performance.
The database was migrated to Amazon RDS Aurora. Its compatibility with MySQL allowed for a seamless migration with no code changes required, and the added benefits of durability and flexibility of capacity that Aurora natively provides.
Provisioning of the EC2 instances was performed using Ansible, with parameters stored in AWS Systems Manager and Secrets Manager to ensure the security of sensitive information. DevOpsGroup implemented the infrastructure, managed via Hashicorp’s Terraform platform, with an Infrastructure-as-Code approach allowing visibility of changes through the AWS CodeCommit repository. Should a breakage occur due to a change in infrastructure, rolling back and restoring service to customers would be straightforward.
Previously, visibility of the traffic that was hitting services was limited. With the availability of access logs from the Application Load Balancers in front of the Auto Scaling Groups – and AWS Athena’s ability to query those logs – S3Bubble was surprised to learn that the API processed over 1,170,000 requests during the first weekend that the new architecture was placed into production. Because of Athena’s SQL-like query functionality, S3Bubble is now able to drill down in vastly more detail to discern traffic patterns and customer use in order to improve its offering.
With the new architecture in place, S3Bubble has an automated ability to expand and scale its capacity according to use, without sacrificing service. The company is more able to inspect its users’ behaviour and has more insight into the use of its services. Because of the reconfiguration of the company’s AWS estate’s networking, the visible attack surface is vastly reduced, with only the load balancers and a lone bastion host being publicly accessible. Sensitive customer data is now protected to an exceptionally high standard both in transit and at rest. The work performed by DevOpsGroup has enabled S3Bubble to offer its already popular service in a more reliable, more scalable and more secure fashion.