It’s estimated that there are some 75,000,000 (75 million) websites currently running on top of the WordPress Content Management System. Of those 75 million, it’s estimated that 33% are hosted with Amazon Web Services. Fifteen moved from a Dedicated Server infrastructure to a cloud based (AWS) service around 2 years ago and we haven’t looked back. Downtime is virtually non-existent, our development workflow is seamless, scalability is easily accomplished and best of all, we’re self reliant. Our internal Development Operations team has grown in both manpower and skillset. We’re no longer in a position whereby, if we have a problem, we have to raise a support ticket and sit back and wait for help. We managed our own servers and fix our own problems, under our own timescales.
One thing that took us a while to get our heads around was scalability, more specifically, horizontal scaling.
What is horizontal (and vertical) scaling?
Scaling in its top level form is the process of giving more hardware power to a server to allow an application to scale in size, either by demand or by traffic levels.
The approach of giving more resource to an application by increasing the hardware power of the server in which it resides.
The methodology of adding more servers to your infrastructure to create a “cluster”.
Vertical scaling is easily accomplished within AWS especially with the new wave of T3 burstable EC2 instances, however, automation and budget control can be hard to control.
Horizontal Scaling is the methodology we choose to utilise at Fifteen. Easily controllable, automated and granular when it comes to budget control.
Why would you need automated scaling?
If you have an application which is heavily resource intensive, or quite simply you receive a lot of traffic any sort of basic hosting offering isn’t going to cut the mustard. Think of it like a car, if you have 6 kids, 3 dogs and a partner, you’re not going to fit them all in a Vauxhall Corsa. If you’re wanting to drag race quarter miles at Santa Pod, you’re probably going to struggle to keep up with a Nissan Micra. If you’re wanting to tour the world and cover 50,000 miles in a year, what are the chances that you’ll do it with no problems driving a Renault Clio? You could buy a Ferrari but that comes with a monumental price tag.
The Ferrari metaphor would be the simplest method of covering all bases when it comes to hosting, but what if you could switch and swap cars based on the requirement at any given time and even better, you could pay for only what you use?
Consider an eCommerce website that sells mens shoes in the UK. Generally, your peak traffic times will be, evenings (when people have finished work) and weekends. There would be very little point in running multiple expensive servers at 3am on a Wednesday for very little return. Automated scaling allows you to run the amount of servers that your application and traffic levels require, this also means you only pay for the server run time that you utilise.
Exploring horizontal scaling in AWS
When we first started looking at implementing horizontal scaling we went down the CloudFormation (CFn) route. Initially googling CFn scripts and attempting to mould them to our own requirements. Once we had got our heads around the CFn learning curve we began writing our own scripts for deployment. This worked well initially but it soon became apparent that this methodology was going to be time consuming in terms of maintenance and upkeep. This is when we stumbled across Elastic Beanstalk.
What is CloudFormation (CFn)?
CloudFormation is a lightweight, low-level abstraction over existing AWS APIs. Using a static JSON/YAML template document, you declare a set of Resources (such as an EC2 instance or an S3 bucket) that correspond to CRUD operations on the AWS APIs.
What is Elastic Beanstalk (EB)?
Elastic Beanstalk (EB) is a higher-level, managed ‘platform as a service’ (PaaS) for hosting web applications, similar in scope to Heroku. Rather than deal with low-level AWS resources directly, EB provides a fully-managed platform where you create an application environment using a web interface, select which platform your application uses, create and upload a source bundle, and EB handles the rest.
Using EB, you get all sorts of built-in features for monitoring your application environment and deploying new versions of your application.
Elastic Beanstalk Infrastructure
When we provision a horizontal scaling infrastructure under AWS we use a multitude of their product offerings. Most can be controlled under Elastic Beanstalk. From top to bottom, here’s a summary of how we utilise AWS products:
We utilise CloudFront for its content distribution network and caching capabilities.
EC2 (Elastic Cloud Computing)
Elastic Load Balancer
Elastic Load balancing improves responsiveness and increases availability of applications. A load balancer sits between the client and the server cluster accepting incoming network and application traffic and distributing the traffic across multiple EC2 Instances using various methods.
An EC2 instance is a virtual server in Amazon’s Elastic Compute Cloud (EC2) for running applications on the Amazon Web Services (AWS) infrastructure. AWS is a comprehensive, evolving cloud computing platform; EC2 is a service that allows business subscribers to run application programs in the computing environment.
RDS (Relational Database Service)
This is a web service that makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient, resizable capacity for an industry-standard relational database and manages common database administration tasks.
S3 (Simple Storage Service)
S3 is a scalable, high-speed, web-based cloud storage service designed for online media / file storage and serving. Extremely resilient and secure.
ACM (Amazon Certificate Manager)
ACM is a Private Certificate Authority (CA) is a managed private CA service that helps you easily and securely manage the lifecycle of your SSL certificates.
SES (Simple Email Service)
Amazon Simple Email Service (SES) is a cost-effective email service built on the reliable and scalable infrastructure that Amazon.com developed to serve its own customer base.
Amazon CloudWatch is a monitoring service for AWS cloud resources and the applications you run on AWS.
Tips and Tricks
Over the past couple of years, we’ve provisioned dozens if not hundreds of infrastructures under Elastic Beanstalk, it’s fair to say we’ve learnt a trick or two. Here are a few of our favourites to help you out along the way:
Accept connections via CloudFront over port 443 (redirect HTTP to HTTPS). Connections from the load balancer to EC2 Instances should be completed over port 80 – this will alleviate AWS asking for 2 SSL certificates.
HTTPS = ON
In your application, ensure you are forcing HTTPS, your system may not know this as traffic is delivered from load balancer to ec2 instance over port 80. In PHP $_SERVER[‘HTTPS’] = “on” saves a lot of hardship and infinite loops.
Provision SSL in the correct region
CloudFront will only utilise SSL certificates provisioned under ACM in the North Virginia Region
Keep your repository lightweight
The manner in which Elastic Beanstalk deploys is great, it switches between application versions to accommodate zero downtime. That being said, every time you do a deployment it will upload the application in its entirety.
Enable Session Stickiness
This will keep users on the same server for the duration of their session. Otherwise, anything stored in the session will be lost whilst bouncing around servers.
If you would like to discuss a new website development project, how scaling can help with the performance of your existing site or support, get in touch with Fifteen’s dedicated web dev team can give you the edge over your competition.