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 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.
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.”
In addition, its web applications were deployed as a single monolithic build. A problem with one application would stop 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.
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."
By using AWS CodeBuild, Coursera has reduced its web-application build times by 83 percent while achieving a 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 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 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. Kane says, “Next, we’re going to add some of our backend services to AWS CodeBuild and see what that looks like.”
Learn how to build and test code with continuous scaling using AWS CodeBuild.