When we set up our online education platform here at Silicon Valley High School in 2013, we were operating with a dedicated physical server running in a colocation data center. This was a good solution, until we had to upgrade the server. At that point, we had to migrate all our software and data to another server, then test it to make sure it was all working. It’s like buying a new PC. In fact, it’s exactly like buying a new PC, because that’s exactly what we were doing. Our server was a physical computer. Yes, with hardware and cables and everything. So, the hassle you encountered when you replace a PC was the same type of hassle we experienced when upgrading servers, except in our case we had thousands of students waiting for the upgrade to complete so they could continue with their studies.
Then we moved to a cloud-based solution hosted by Amazon Web Services (“AWS”) where our server was virtual, using a system called Amazon Elastic Compute Cloud (Amazon EC2). We specified a server, with RAM and disk storage, etc. and AWS would then provide us with a “virtual server” with those specifications. We didn’t need to worry about a disk drive failing or any other hardware issues as these were all taken care of by AWS. Problem was that we still outgrew the server and had to upgrade regularly as traffic increased. Upgrading to a larger virtual server was somewhat easier than it was with a real physical server, but still it was an engineering challenge to get the system running on the new server without taking it offline for an undue period of time and disrupting our student body.
We’re not the only AWS EC2 client looking for a flexible platform that will grow with us, and fortunately AWS has now provided us with Amazon Fargate, a “serverless” platform. Amazon Fargate is a fully managed compute engine for running containerized applications on Amazon Web Services (AWS). It’s a part of the Amazon Elastic Container Service (ECS) platform, which is a container orchestration service that allows users to run, manage, and scale containerized applications.
Containerization allows our developer to package up our entire “application” with all the parts it needs, such as libraries and other dependencies, and make it operational online as a single package.
Fargate removes the need for our engineers to manage their own EC2 instances or clusters, and instead allows them to simply specify the desired number of containers and the resources needed to run them. Fargate handles the underlying infrastructure, such as provisioning and scaling the necessary compute resources, and provides a seamless experience for running containers. This allows our IT team to focus on building and deploying their applications, rather than managing the underlying infrastructure.
As I discussed previously in another blog, our platform here at Silicon Valley High School runs on the LAMP stack. This is how we run our applications on Fargate:
- Package the application in a container: Containerization tools like Docker enable engineers to package the application code, libraries, and dependencies in a container. This enables us to run the application in a consistent environment, regardless of the underlying server infrastructure.
- Deploy the container on Fargate: Once the container is ready, we use the AWS Management Console, AWS CLI, or an AWS SDK to deploy it on Fargate. Our team still needs to specify the required resources, such as CPU and memory, as well as the networking and security configurations.
- Run the application: After the container is deployed, it starts running the application code, calling the My SQL database the Apache server on a Linux host, like all LAMP stack applications.
Setting up Fargate is not exactly child’s play as it needs to be integrated with other AWS services:
- Amazon CloudFront: Amazon CloudFront is a content delivery network (CDN) that speeds up the delivery of static and dynamic web content, such as HTML, CSS, JavaScript, and images. Fargate can be used to host and run containerized applications that are fronted by CloudFront. This can help improve the performance and scalability of the application by offloading serving of static content to CloudFront, while Fargate handles dynamic content generation.
- Amazon Elastic Container Service (ECS): Amazon ECS is the container orchestration service that makes it easy to deploy and run containerized applications. Fargate is a deployment option for ECS that allows users to run containerized applications without having to manage the underlying infrastructure. With Fargate, users can specify the number of tasks or pods to run for a particular application, and Fargate will automatically provision the necessary compute resources to run the tasks.
- AWS Cloud Development Kit (CDK): The AWS CDK is a framework for defining cloud infrastructure in code. It allows users to use familiar programming languages, such as TypeScript and Python, to define cloud resources and connect them together. Fargate can be used as a deployment option for CDK-defined infrastructure. This allows users to define their containerized applications and the underlying infrastructure needed to run them using code, and deploy the application to Fargate with a single command.
- Amazon Elastic File System (EFS): Amazon EFS is a fully managed file storage service that is designed to be used with Amazon EC2 instances. Fargate tasks or pods can be mounted to an EFS file system, allowing them to access and share data stored on the file system. This can be useful for applications that need to share data across multiple tasks or pods, or for applications that need to persist data beyond the lifetime of a single task or pod.
So it’s important that our IT team has specialist engineers who are familiar and experienced with all these technologies as they all need to be integrated to build a system that then “automatically” expands as our traffic grows.
In the weeks running up to the end of a semester, students tend to become more active on our platform and our traffic increases considerably. Then, the traffic drops off after the semester ends and the cycle starts again. With this new “serverless” architecture, we can scale up and down much more easily and we can manage huge growth in student enrollments, which we often experience for summer school. We’re no longer bound by the limitations of a server, even a virtual server, and we’re well placed to ramp up as we grow in future, without being forced to take the servers offline and disrupt our students.
By David Smith, Founder & CEO of Silicon Valley High School
A former Apple World Marketing Manager, David has more than 30 years’ experience of founding and managing technology startups. He holds a JD from Santa Clara University School of Law, Post Graduate Diploma in Marketing from the University of Westminster and a BS (Honors) Computer Science and Economics from the University of Leeds. In the 1990’s David founded and acted as CEO for SurfMonkey, the leading web browser and Internet safety service for children. David has authored several books on business and intellectual property and is recognized by IAM magazine as one of the world’s leading intellectual property strategists.