How CodeCrafters Helps Devs Upskill Faster

Customer
CodeCrafters
Founders
Sarup Banskota
Paul Kuruvilla

Learning complex new programming skills isn't for the faint of heart. The founders of CodeCrafters wanted to make it easier, so they built a structured learning platform to help devs upskill on their own time.

Faster, More Flexible Learning

Rather than reading a textbook, CodeCrafters' users learn by working through its interactive playground of structured challenges. Each challenge leads the user through writing code that CodeCrafters then analyzes and returns, pointing out errors to help the user figure out where to concentrate on next.

Devs can pick different challenges, depending on their interests and goals. Some drop into the platform once in a while to brush up on rusty skills; others use it more like a bootcamp, spending 8-10 hours a day on the platform to fast-track knowledge that might otherwise have taken the first year of "learning on the job." Paul Kuruvilla, CodeCrafters' CTO, says that many devs use it to build projects that become the basis for new ideas and experiments at work.

Spiky Traffic Gets Expensive

When they started out, CodeCrafters decided to host their tech stack in-house, using their own implementation of Firecracker VMs. Their traffic is pretty variable; the platform is busy on Sundays, for example, when users are off work and diving into lessons, but quieter during the week. Initially, they tackled this variability by over provisioning and paying for extra capacity, rather than spending time to figure out an autoscaling solution.

But they quickly ran into an issue: paying for excess server capacity was expensive, especially as CodeCrafters took off and started to get featured by YouTube gurus. Their traffic spikes got more intense, making the need for autoscaling more pressing, so the team started looking for a platform. When they found Fly.io, and discovered that they could use their microVM architecture without having to over-provision (or manage scaling at all), they decided to switch.

Machines API + Custom Logic = Speed

CodeCrafters' platform has two big components. One is a web app that runs on Heroku, using Ruby on Rails on the back end and Ember.js on the front. The other piece—which runs and evaluates the code that users submit for "grading" and ships the resulting logs back to them—is run on Fly.io and written in Go.

Now that CodeCrafters runs their testing element on Fly.io, says Kuruvilla, "we don't have the need for auto scaling, it just works." When users push code from their sandboxes for review, CodeCrafters uses the Fly.io Machines API to spin up an ephemeral Machine to run the submitted code safely, in a completely isolated environment, evaluating the output. They cap the number of machines they use, deleting unused Machines when they're not needed, which helps them control costs.

CodeCrafters uses additional custom logic to manage their Fly.io machines, caching them ahead of time so they consistently have a fleet of Machines available. When a new user comes in, they simply assign them a Machine that's ready to go. They also built logic around user behavior that speeds things up: after a user visits the CodeCrafters website and signs up for an account, there's a predictable interval after which they'll probably be ready to run some tests. CodeCrafters gets a Machine spun up in the background just in time, so the user doesn't incur a delay.

Offloading the Headache

Using Fly.io means CodeCrafters' 3-person engineering team can spend more time focused on features, instead of handling scaling snafus. With their previous set-up, CodeCrafters dealt with non-trivial provisioning and performance issues at least once a week. For example: they invested a nontrivial amount of effort converting Docker images into rootfs tarballs to be able to run them on a Linux-based VM, caching each step of the process. Now, says Kuruvilla, "I just throw the image over [to Fly.io] and it works, versus us having to worry about it."