Coursera Case Study On AWS

 

AMAZON WEB SERVICES

In 2006, Amazon Web Services (AWS) began offering IT infrastructure services to businesses like web services — now commonly known as cloud computing. One of the key benefits of cloud computing is the opportunity to replace upfront capital infrastructure expenses with low variable costs that scale with your business. With the cloud, businesses no longer need to plan for and procure servers and other IT infrastructure weeks or months in advance. Instead, they can instantly spin up hundreds or thousands of servers in minutes and deliver results faster.

Today, AWS provides a highly reliable, scalable, low-cost infrastructure platform in the cloud that powers hundreds of thousands of businesses in 190 countries around the world.

Coursera is the world’s largest provider of massive open online classes (MOOC), with more than 150 university partners from 29 countries and more than 25 million registered students. Since its launch in 2012, the company’s educational offering has expanded from a handful of courses to some 2,000 offerings in 160 specializations, including business, computer science, and the humanities.

To host its website and support its rapidly expanding business, Coursera relies heavily on Amazon Web Services (AWS). Until recently, the company focused on setting up its backend services and AWS infrastructure. Now, it is needed to streamline its front-end processes as well. “We wanted to improve the front-end developer experience and improve our website’s reliability and performance,” says Bryan Kane, senior engineer at Coursera.

CHALLENGED BY LIMITED BUILD CAPACITY

Coursera’s website, a single-page application written in JavaScript, is hosted on Amazon Simple Storage Service (Amazon S3) and served using Amazon CloudFront.

To build and deploy its web application, the company used eight Jenkins machines running on Amazon Elastic Compute Cloud (Amazon EC2) instances. The Jenkins instances were spun up each morning and sat idle until there was a job. When a change was committed to GitHub, it would trigger Jenkins to build the JavaScript and upload it to Amazon S3. “This process worked well for a while,” says Kane. “But as our application code grew, builds began to take a long time.”

Besides, its web applications were deployed as a single monolithic build. A problem with one application would stop the deployment of the entire build.

To improve build safety, Coursera broke up its monolithic web application into 50 individual applications containing different parts of the website that could be built and deployed separately. It also developed a new system to work with the 50 applications — however, this process also had issues.

“Any time we needed a build of the entire web application, we had to start 50 different Jenkins jobs to build all the individual applications,” says Kane. “However, we didn’t have sufficient capacity to run 50 jobs at once, so they would queue up and it would take a long time to go through them.”

The Jenkins instances were also used to run tests, backend builds, and other scheduled jobs. These jobs were delayed during the application build, causing frustration for backend developers. “We were looking for a solution that would allow us to run jobs in parallel — so we wouldn’t need to wait for a job to finish to run the next one,” says Kane.

USING AWS CODE BUILD TO BUILD AND DEPLOY JAVASCRIPT

Coursera chose to use AWS CodeBuild to build its JavaScript applications because it wanted a managed build service that could scale automatically and process multiple builds concurrently. “It took us less than two weeks to set up our containers to run on AWS CodeBuild,” says Kane. “Now we can run 50 or 60 jobs in parallel, and the build time is only the time it takes for the longest application to build.”

The company also started using Amazon EC2 Container Service (Amazon ECS) to deploy its JavaScript — and then used AWS CodeBuild to automate this step as well. Along with building the JavaScript assets and uploading them to Amazon S3, AWS CodeBuild also creates a Docker container that includes the assets and uploads it to Amazon EC2 Container Registry (Amazon ECR). “Now, whenever we want to deploy an application update, we use a tool that works with Amazon ECS to spin up a new service with the container running the new code,” says Kane.

As a further optimization, Coursera uses a custom build environment in its projects — and uses AWS CodeBuild for that also. Instead of using the standard Node.js container for its builds, it uses AWS CodeBuild to create a separate Docker container that includes the JavaScript dependencies as cache. The container is pushed to Amazon ECR and referenced in the project configuration.

“To build an application, all we need to do is retrieve the Docker image from the container registry, run the scripts, and upload to Amazon S3,” says Kane. “We don’t need to wait for the JavaScript dependencies to download because they are already pre-warmed in the container cache.”

INCREASED SPEED, SCALABILITY, AND COST SAVINGS USING AWS CODE BUILD

By using AWS CodeBuild, Coursera has reduced its web-application build times by 83 percent while achieving significant cost savings. “With AWS CodeBuild, our application build now takes about 10 minutes; using Jenkins it used to take up to an hour,” says Kane. “To get the same performance on Jenkins would cost four times as much because we would need to spin up 50 Jenkins instances to have the builds finish that quickly.”

On average, the company runs 300–500 builds each day using AWS CodeBuild, and because the service scales continuously and processes multiple builds in parallel, builds are not left waiting in the queue. “If we needed to run 70 builds all at once, we could do so,” says Kane. “It’s great to be able to execute on-demand and have the elastic capacity that’s ready to go.”

AWS CodeBuild also supports continuous integration and continuous delivery (CI/CD) and has increased developer productivity by streamlining the QA process. Each time a production run is submitted, AWS CodeBuild builds a full staging environment that is ready to use for QA. “If there are bugs, our team can fix them and iterate much more quickly,” says Kane. “Our staging environment makes it much easier to do that.”

Using containers for its web applications has also made builds more consistent and reliable. “Having everything inside a Docker container that starts fresh each time provides build isolation,” says Kane. “Our developers are spending less time debugging builds that don’t run.”

With the benefits it has seen using AWS CodeBuild for its front-end platform, Coursera is considering other ways to use the service. This include

• Reduced build times by 83%
• Runs 300–500 builds a day
• Runs multiple jobs concurrently
• Able to scale continuously for build processing
• Creates build environments

“Next, we’re going to add some of our backend services to AWS CodeBuild and see what that looks like.”

SERVICES USED

• AWS CodeBuild
• Amazon ECS
• Amazon S3
• Amazon CloudFront
• Amazon ECR
• Amazon EC2

Benefits

Serverless option

ECS supports Fargate to provide serverless compute for containers. Fargate removes the need to provision and manage servers, lets you specify and pay for resources per application, and improves security through application isolation by design.

The application first with Capacity Providers

ECS capacity providers help you to focus on building and managing applications instead of infrastructure. With capacity provider, the demands of your application determine the compute capacity allocated to it and you get the flexibility to use a mix of EC2 and Fargate with Spot and On-Demand pricing options for your applications.

Performance at scale

ECS powers several key services at Amazon and is built on technology developed from many years of experience running highly scalable services. You can rapidly launch thousands of containers using ECS with no additional complexity.

Secure

ECS launches your containers in your own Amazon VPC, allowing you to use your VPC security groups and network ACLs. No computing resources are shared with other customers. You can also assign granular access permissions for each of your containers using IAM to restrict access to each service and what resources a container can access. This high level of isolation helps you use ECS to build highly secure applications.

Reliable

ECS runs on the best global infrastructure with 69 Availability Zones (AZ) across 22 Regions. AWS provides >2x more regions with multiple availability zones than the next largest cloud provider (22 vs. 8). ECS is backed by the AWS Compute SLA which guarantees a Monthly Uptime Percentage of at least 99.99% for ECS giving you the ease of mind.

Optimized for cost

With ECS, you can use Fargate Spot tasks or EC2 Spot instances to realize up to 90% discounts compared to on-demand prices for running stateless and fault-tolerant applications. You can use a savings plan and realize up to 50% discount for persistent workloads. You can easily run ECS clusters at scale by mixing Spot Instances with On-Demand and Reserved Instances.

Thank you for reading ...