Preview Environments automatically deploy pull requests as their own small application or service, making it easy for engineers and QA teams to work together.

#An Autoscaling Rollercoaster

As you probably already understood, Papershift is a solution for businesses, which means that they have traffic peaks from Monday to Friday (9-5) but not too much at night and during weekends. This means they need to ensure that there are enough instances for the peak times and that those instances are reduced accordingly when the usage is low, so you don’t overspend: good autoscaling was absolutely mandatory!

#Heroku: Simple but Costly

The first version of Papershift was completely hosted and managed on Heroku, which was great for the start as Heroku is easy to use, a couple of commands, and you have a running system where you just need to push your code.

Victim of its success, Papershift started to grow, and the cost of Heroku became an issue because the configuration is limited on Heroku, they realized that they needed a much more flexible solution, and that’s where they decided to move to AWS for hosting and have the deployment managed through Cloud 66.

Heroku is super easy, a couple of commands, and you have a running system. The problem is that the more you grow, the more expensive it gets, and the cost is a painful factor. - Florian Suchan (CTO and Co-Founder at Papershift)

#AWS + Cloud 66: Autoscaling Limitation

While Cloud 66 gave them the flexibility to use AWS, a good UI and the possibility to do some troubleshooting, that’s where the issue raised above arose. They realized that their platform’s usage fluctuated over the week, with peak times from Monday to Friday (9-5) and the opposite at night and on weekends. On Cloud 66, they had EC2 instances, which they paid for all the time no matter the usage where you might need more sometimes and while also cutting 80% of it on Saturdays and Sundays on their case. After looking for the best solution, they decided to containerize the whole infrastructure so that, depending on the need, the entire infrastructure would scale up and down accordingly.

#Infrastructure Containerized by an Engineer: No Visibility for the Rest of the Team

They hired an Infrastructure Engineer who built a whole container setup himself on AWS directly.

They had a container registry integrated into their CI, so everything got deployed and pushed whenever they pushed to the production branch, and it worked like a charm.

As much as they were pretty happy with the result, everything was technically built. So they lost the good UI they had on Heroku and Cloud 66, so whenever something happened, the troubleshooting could only be done by one person. Eventually, the Infrastructure Engineer left the company, and that’s where they decided that they needed to combine both worlds:

• A good UI and the possibility to troubleshoot
• Containerized setup using AWS

And one thing leading to another, Papershift’s Head of Engineering found Qovery!

The major problem was that it was built very technically, and we lost the good UI we had on Heroku and Cloud 66 before. - Florian Suchan (CTO and Co-Founder at Papershift)

#Qovery: One solution to Rule Them All

After hearing about Qovery from his Head of Engineering, Florian decided to give Qovery a go by himself on a private project. He was surprised to see how fast he could deploy, all the possibilities that the solution held, and that with a good interface! After a bit more testing and several chats with our team, Papershift decided to give a go to Qovery. 💜

We wanted to combine the good UI and troubleshooting from Heroku and Cloud 66 with a containerized approach, and then we found Qovery! - Florian Suchan (CTO and Co-Founder at Papershift)

#Migration to Qovery

#A smooth sailing journey

The full implementation took less than a month, and we are talking about a big cluster here, more precisely an EKS cluster with many m5.xlarge instances, 4CPU and 16GB of RAM, where a few things had to be done differently, but let me give you a timeline:

• Within less than two weeks, the staging cluster was up and running with all its requirements and without any particular issues.
• Then it was time to take care of the production cluster! This one was a bit more touchy as it had mode dependencies such as read replicas in different areas/AZs. their old cluster was in a version about to be deprecated. They created a new cluster on Qovery with no traffic to start, both clusters were running, and the production branch was now deployed on both clusters sequentially. to ensure everything was ok. The database remained in the old cluster using VPC peering to connect to the new cluster. After a good amount of testing, they felt confident switching the traffic to the new cluster, always having the chance to reverse within minutes as the old cluster still existed. After a week or two of running on the new cluster, nothing unforeseen happened, and It was time to move the Database from the old cluster to the new one with VPC peering, and when they felt confident with everything, they switched the traffic to the new endpoint of Qovery. They continued to have both the old and new clusters running for a week more to be able to reverse if something went wrong, but as no issue happened during this week, they then decided to let go of the old cluster.
• The next step was then moving the database to the new cluster.
• The last step was cleaning up and migrating some old Cloud 66 backups that they still had to Qovery, and then everything one done in less than one month!

#The Results

After several months of using Qovery, the whole Papershift team enjoy its power; every Engineer can use it, the QA team is also using Qovery for testing, and the autoscaling is working well, which gives them total control at the right price and all of that, managed in one place!

With the Preview Environments, every pull request is automatically deployed as its own small application or service. And it's heavily used by our engineers who worked on this branch but at the same time QA. - Florian Suchan (CTO and Co-Founder at Papershift)