Why and how we migrated Preply to Kubernetes

In this article, I’ll share our experiences migrating the Preply platform to Kubernetes, how and why did we did it, the difficulties we’ve faced, and the benefits we’ve seen since the migration.

My name is Amet Umerov and I’m a DevOps Engineer at Preply.com. Let’s get started!

Kubernetes for Kubernetes? No, for business requirements!

There’s a lot of hype around Kubernetes. While many people say it will solve all your problems, there’s much discussion about why you shouldn’t use Kubernetes: some say you should avoid it because it’s not a silver bullet.

But that’s a discussion for another article. Let’s talk about a little bit about business requirements and how Preply worked before the Kubernetes era:

• When we used Skullcandy flow, we had a pool of features merged to the stage-rc branch which was deployed to the staging environment. The QA team tested in this environment, the branch was merged to the master, then deploy to the production was started. It took 3–4 hours to test and deploy to the environment, and we were able to deploy 0–2 times/day.
• When we deployed broken code on production we had to revert all the features in the scope. It was also hard to find which task was causing the problem that broke production.
• We used AWS Elastic Beanstalk for application hosting, and every Beanstalk deploy ran 45 min (all pipeline with tests ran 90 min). Our rollback time to the previous app version was 45 min.

To improve our product and processes, we wanted to:

• Migrate to microservices
• Deploy faster and more often
• Be able to roll back faster
• Change our current development flow because our old one wasn’t effective anymore

Our needs

Changing the development flow

To implement features using our previous development flow, we had to create a dynamic staging environment for every…