Building a Reliable and Scalable Infrastructure: Partoo's Journey with Qovery

#Partoo Introduction

Antoine Boileau is the Engineering Manager at Partoo and previously the lead at Pulp, a click-and-collect company acquired by Partoo over a year ago. Partoo is a SaaS company that assists businesses in their customer journey. They focus on three key areas: Get Found, Get Chosen, and Get Clients. Get Found improves businesses' visibility on platforms like Google, Bing, and Facebook. Get Chosen enhances attractiveness through positive reviews and compelling profiles. Get Clients streamlines the conversion process, including click-and-collect and table ordering. They use Qovery to host transactional features, such as click-and-collect, payment, and table ordering.

#Learn How Qovery Helped Partoo to Build and Manage a Reliable and Scalable Infrastrucure in No Time!

#Partoo's Struggles With Heroku's Performance (CPU Consumption & Dowtimes)

Until the third quarter of 2022, the Pulp platform relied mostly on Heroku for hosting. The Pulp platform was a large monolith with several small surrounding services and various frontend applications deployed statically on DigitalOcean or server-side rendering (SSR). The system performed adequately with minimal time investment, showcasing stability and satisfactory response times. Still, problems emerged when the main server instances started randomly consuming 100% CPU without clear indications in the logs. Heroku's approach to such incidents exacerbated the issue, as they did not replace the affected instance but instead stopped the whole API from receiving HTTP calls, making the entire application unavailable. Consequently, a single server instance failure triggered a cascade effect, causing major disruptions during critical service periods.

They realized that by manually rebooting all the servers, they could make the API available again. They did it once, then twice, and after having to do it again on a Saturday, they started to look for a way to automate it. After some adjustments, a solution was found by having an instance on Scalingo, separate from Heroku, that received downtime alerts from Datadog through webhooks and used that call to reboot the server on Heroku using Heroku’s API, but this was only a workaround. Unfortunately, despite being on a premium plan, Heroku provided no assistance resolving the problem. The lack of dedicated support from Heroku added to the frustrations. The frequency of one or two production incidents per day amplified the need for a resolution, ultimately driving the decision to seek alternative options.

#Exploring Alternatives: The Limitations of Scalingo, Render, DigitalOcean, and AWS Elastic Beanstalk

The team's requirements included maintaining fine-grained control over servers for seamless Datadog integration and a robust deployment pipeline with minimal maintenance. The team also aimed to consolidate their workflows on a single platform.

They explored various options to find an alternative solution. Among the initial considerations was Scalingo, the French equivalent of Heroku, but they had encountered two production incidents, raising concerns over the production worthiness of the hosting solution. Render and DigitalOcean were also evaluated but lacked the necessary integration with Datadog. AWS Elastic Beanstalk was also assessed, but they posed challenges in losing essential features like auto-deploy from the Github repository and review apps. After eliminating most options, they discovered Qovery, the sole solution to meet all their needs.

#Seamless transition to Qovery: Integration, Scaling, and Developer Experience

The alignment with the integration vision of the Pulp application and Partoo's AWS infrastructure made Qovery an ideal choice. It provided a practical solution for integrating with Partoo's infrastructure, aligning with their long-term objective of gradually transitioning to Kubernetes.

Once the decision was made to migrate to Qovery, the testing phase became the most time-consuming aspect. The team focused on conducting comprehensive tests to ensure a smooth transition. They made necessary modifications, including Docker configurations, to meet their specific requirements. Learning how to configure Datadog and addressing migration concerns were also crucial. This process involved validating the newly created environment and collaborating with Partoo's operations team, who handled VPC configuration and database foundation setup. Although the effort did not span an entire month, it involved intermittent work as the team navigated the initial stages of collaboration. The most time-consuming task was to replace the timezone-aware cron tasks, available as a plugin on Heroku and not on Qovery (although Qovery has since introduced Cronjobs). That feature had to be redeveloped and integrated into their monolith. After creating an initial environment on Sandbox, they proceeded with the migration to production. The team expressed high satisfaction with the results and continues to utilize Qovery for its operations.

#Key Benefits After Several Months of Using Qovery

#The Full Flexibility of AWS and Kubernetes

The decision to migrate to AWS and gain full control over their resources was deemed necessary, aligning with the company's long-term vision of managing all aspects through an AWS account. The availability of a Kubernetes cluster that can be directly manipulated brings reassurance to the infrastructure team, who can monitor and make modifications themselves, leading to a deeper understanding of the system. That capacity to tinker directly with the native Kubernetes resources was the main reason to move to Qovery, as it allowed them to see clearly what was wrong with the servers that kept hitting 100% CPU. Being able to access the underlying AWS resources directly gives plenty of flexibility and allows a wide range of different workflows. While Qovery offers continuous deployment (CD), they have the autonomy to make any required adjustments independently.

#Speed of API Thanks to Autoscaling Options

Partoo has experienced significant API speed improvements thanks to the autoscaling implementation. Finer control over the scalability of particular applications and managing the desired load level enable them to have a more aggressive approach to autoscaling, resulting in an estimated speed boost of approximately 50% or even up to 60%, surpassing expectations.

#Reliable Support in Times of Need

Compared to their disappointing experience with Heroku, Partoo found exceptional support from Qovery throughout their journey. Despite making mistakes like updating their Kubernetes cluster before Qovery, which caused production concerns, Qovery's support team remained dedicated and responsive, and this support has become a great strength, fostering trust and confidence for Partoo.

#What's Next for Partoo and Qovery

#Project Nebula: Partoo is Empowering Customized Test Clusters with Qovery

Partoo is developing their own review environment custom workflow leveraging Qovery API (code name: Nebula). The aim is to have the best developer experience by enabling complete flexibility in the creation of bespoke clusters for development and testing.

That cluster would be composed of multiple apps (Front-tend and APIs) from different git repositories. The developers will be able to select individually the git branch from which the different apps would be configured to be auto-deployed. That extremely flexible setup for one-off bespoke review clusters in a multi-service environment needs custom development, but thanks to the ease of use of the Qovery API and the concept of App Blueprints, Partoo thought the challenge was manageable. The end of development on that feature for Nebula is expected to be around October