I became frustrated with the lack of control over resources and data on our API and DB. Qovery provided flexibility and control over multiple environments and debugging.

#Managing multiple environments on Kubernetes

Working as the lead machine learning engineer in his Agency before switching to the web, Pierre was no newbie to AWS, having used services such as Lambda and S3. While the first version of Spayr’s API and DB were released on Heroku, he quickly became frustrated with the fact that he did not have full control over what resources he was using, where the data was hosted, and fine-tuning his CI/CD pipeline. He wasted time building an efficient pipeline that easily integrates with their workflow.

With Heroku, they experienced a kind of a "black box" problem where they couldn’t access the pieces of information needed, such as knowing exactly what they were using and also monitoring it so that they could be able to figure out which part should be more efficient on their side.

To reach their objectives of lower the time from the feature need to its release in production, creating the best developer experience for the team, and using tools that will help them scale up easily (they have intense spikes in user count each time they onboard new customers), they knew that more would be needed.

Quote from Pierre

The entire team can follow the quick pace they need to deliver new features, debugging and monitoring their infrastructure. Namely, they can bring value to their customers, which is the sole purpose of a company like Spayr.

#How Spayr operated the migration with Qovery

According to Pierre, the migration went relatively smoothly after a first call with Romaric (our CEO), and then within a week, they were ready to switch to Qovery.

And to be super specific, here is precisely how the migration went:

• For the first two days, the goal was to migrate the API (simple Rails app in API mode). The only problem was that there was a Dockerfile to prepare for production on such type of application. That’s where the Qovery team helped by giving an example they used with their existing customers, so everything went smoothly, no problem there. The app was up and running in two days, and the team used this environment as a staging environment.
• Afterwards, it was time to migrate the demo app (rails PWA) and the dashboard (Vue.js app) in the same cluster, which was quickly done. They were glad they did not have to use Buildpacks anymore, gaining more flexibility and control over how they were deploying those apps.
• The entire application portfolio was deployed in four days using Qovery on AWS.
• Before using it for production, they wanted to properly connect the dev management tools (GitHub, Linear, etc...) to follow their workflow; since migrating to AWS x Qovery did not change the workflow, it was pretty easy.
• Then, the last steps were:
  - Clone the staging environment to a 'production' environment
  - Set the resources settings so that there are no unpleasant surprises once in production
  - Migrate the production database (done in 5mn top)
  - Update the DNS Settings
  - A quick call with the Qovery team to see what was ok
  - All setup and ready to go 🚀