1. Introduction: Context and Initial Challenge
As a software engineer and project leader, at Adevinta in salestech department, we realized we were wasting a significant amount of money on computing resources that were barely used. Our original architecture in Azure was based on App Service Plans, a common solution, but one that had become an economic and operational burden for us.
We managed a variety of diferent apps, each with specific requirements. To accommodate these needs, we had implemented a complex architecture with different types of App Service Plans: simple plans for applications without special requirements, plans associated with App Service Environments (ASE) for those needing a fixed outbound IP, and segregated plans for Linux and Windows applications. This fragmentation, while addressing initial needs, generated complex and inefficient management.
I conducted a thorough analysis of the actual usage of our applications over the past month, and the results were striking. I discovered that, on average, 99% of our applications were only active for 5% of the day. Despite this very low utilization, we were religiously paying $3000 per month for computing resources that remained idle most of the time. It was clear: we were unnecessarily reserving resources, generating considerable expense, and wasting the potential of the cloud. I decided we needed a radical change. And the need was even more pressing given that we were immersed in a major "splitting" project, where we must quadruple our current infrastructure. This exponential growth, if we maintained the previous architecture, would have tripled our already high costs, making the project economically unviable. Cost optimization was not just desirable; it was essential!
2. Problems with the App Service Plans Architecture (The "Why" of the Change)
Our App Service Plans-based architecture, although initially functional, was generating several critical problems for us:
Exorbitant Costs: The main headache was, undoubtedly, cost. Paying $3000 per month for resources that were used intermittently was unacceptable. We were incurring significant economic waste due to a pricing model based on constant resource reservation, rather than actual consumption.
"Backside Effects": The Undesirable Neighbor Effect: We experienced the dreaded "backside effects." When one of our applications, due to a point demand spike, consumed most of the resources of its App Service Plan, the other applications hosted on the same plan were directly affected. This translated into performance degradation, instability, and an inconsistent user experience.
Inefficient and Costly Scaling: Scaling was another weak point. If a single application within an App Service Plan needed to scale to cope with an increase in traffic, the entire App Service Plan scaled, even for those applications that did not require it. This "block" scaling was not only inefficient in terms of resources but also further increased our costs.
Management Complexity: Managing multiple App Service Plans of different types, with their specific configurations, had become a complex and laborious task. This consumed valuable team time and increased the risk of configuration errors.
It was clear that we needed a solution that would allow us to optimize costs, improve scalability, and simplify the management of our infrastructure. We were looking for a more modern, efficient architecture adapted to the usage characteristics of our applications.
3. Azure Container Apps: The Solution (The "How" We Did It)
After evaluating various alternatives, the answer to our problems came from Azure Container Apps. This platform, based on Kubernetes and serverless, presented itself as the ideal solution for our specific use case. Why Azure Container Apps? Because of its key features that directly addressed our main concerns:
Consumption Model: Pay Only for What You Use: Azure Container Apps operates under a consumption model. We only pay for the CPU and memory resources that our applications actually use, and only for the time they are active. This eliminated the problem of the fixed cost of resource reservation at its root, allowing for drastic savings.
Automatic and Precise Scaling: The platform scales automatically and individually each Container App according to demand. If an application needs more resources, Container Apps scales it granularly, without affecting other applications and without scaling the entire infrastructure unnecessarily. This guaranteed us efficient and cost-optimized scalability.
Total Application Isolation: Each Container App runs in its own isolated environment. This completely eliminated "backside effects." The performance of one application would no longer be affected by the resource consumption of another, ensuring a consistent experience for each user.
Radical Architecture Simplification: With Azure Container Apps, we were able to consolidate all our applications into a single Azure Container Environment. Goodbye to the complexity of managing multiple App Service Plans. A simpler architecture, easier to manage and maintain.
CI/CD Homogenization and Dockerization: Azure Container Apps requires applications to run in Docker containers. This requirement prompted us to adopt Dockerization across our entire application portfolio. While this involved an initial adaptation effort, the result has been a complete homogenization of our CI/CD. Previously, we managed different CI/CD pipelines for web apps and functions. Now, thanks to containerization, we have a single unified CI/CD process for all our applications.
4. The Migration Process: Step by Step and Dual Environment (Pre and Pro)
I designed a gradual and planned migration process, App Service Plan by App Service Plan. This strategy allowed us to minimize risks, validate each step of the process, and ensure a smooth transition.
A key part of my strategy was the implementation of duplicate Pre-production (Pre) and Production (Pro) environments. We created a "Pre" environment completely identical to our current production environment. In this "Pre" environment, we performed exhaustive tests of the migration to Azure Container Apps, validating the functionality, performance, and stability of the migrated applications without affecting our production services at all.
Once the tests in "Pre" were passed and with the confidence of a validated process, we proceeded to replicate the migration in our "Pro" Production environment. This approach gave us security and control throughout the migration process.
It is important to note that we have not yet completed 50% of the total migration. We are migrating App Service Plan by App Service Plan, but even at this early stage, the results are already extraordinary.
5. The New Architecture with Azure Container Apps (The "Result")
The new architecture based on Azure Container Apps is radically simpler and more efficient. We have gone from a constellation of App Service Plans to a single Azure Container Environment that hosts all our containerized applications.
This simplification translates into:
- Centralized Management: Managing a single environment instead of multiple fragmented plans drastically reduces operational complexity.
- Unified Visibility: Having all applications in the same environment facilitates monitoring, tracking, and overall infrastructure management.
- Less Maintenance: A simpler architecture implies fewer components to maintain, reducing effort and the risk of errors.
6. Tangible Results and Benefits: Over 99% Savings, Expansion Viability, and Homogenized CI/CD!
The results of the migration to Azure Container Apps have exceeded our most optimistic expectations. The most impactful data, and now even more relevant given our "splitting" project, is the cost savings of over 99%. We have gone from paying $3000 per month for our current infrastructure to a fraction of that amount, approximately $30 per month. But if we consider the expansion involved in quadrupling our infrastructure, the savings become colossal.
In a "splitting" scenario with the previous architecture, our projected monthly costs would have skyrocketed to $12000 (4 times the initial $3000). With Azure Container Apps, even with the infrastructure tripled, we maintain a minimal cost, estimated at less than $120 per month. These massive savings, exceeding $11800 per month, not only directly impact our budget but also make our expansion project economically viable. The migration to Azure Container Apps has been crucial to ensure the scalability of our infrastructure without compromising the financial sustainability of our growth.
In addition to savings and simplification, we have obtained significant benefits in our development processes:
- CI/CD Homogenized and Improved: Dockerization, driven by the migration to Azure Container Apps, has allowed us to radically unify and simplify our CI/CD. We now manage a single CI/CD pipeline for all our applications, regardless of whether they are web apps or functions. This homogenization greatly simplifies deployment management and reduces the operational complexity for our development teams.
- Efficient Versioning and Rollbacks: We implemented a repository versioning system within the CI/CD. This provides us with complete traceability of the code deployed in each version of each application. If necessary, we can perform rollbacks to previous versions quickly, easily, and with complete security. This version control has significantly improved our response capacity to potential problems and the overall stability of our applications in production.
7. Lessons Learned and Next Steps
The migration to Azure Container Apps has been a resounding success and a strategic key decision for the future of our infrastructure. One of the biggest lessons learned has been understanding the importance of planning cloud architecture not only for current needs but also anticipating future growth scenarios like our "splitting" project. Although initially the migration focused on immediate cost optimization, it has proven to be an even more valuable investment in preparing us for expansion. We have also learned the value of a robust and homogenized CI/CD, especially in containerized architectures. The migration to Azure Container Apps prompted us to improve our CI/CD processes, and this improvement in the development flow has become a very important additional benefit. If we were to start again, we would dedicate even more time to the planning and testing phase in the "Pre" environment to further refine the migration strategy and document each step for future migrations.
Our next step is to complete the migration of 100% of our App Service Plans to Azure Container Apps. We are also exploring other advanced features of the platform, such as autoscaling based on custom metrics and integration with other Azure services, to further optimize our infrastructure and improve the experience for our users.
8. Conclusion: The Future is Container Apps
In this project that I led and managed, Azure Container Apps has completely transformed our infrastructure in Azure. We have achieved spectacular cost savings, exceeding 99%, radical simplification of the architecture, significant improvement in the performance and scalability of our applications, a homogenized and efficient CI/CD, and most importantly, we have made our ambitious infrastructure expansion viable. For B2B companies with intermittent usage patterns like ours, and for any company looking to optimize costs, improve their development processes, and prepare for growth, Azure Container Apps has become the ideal platform to build a modern, efficient, scalable, cost-effective, and agile cloud infrastructure. If you are looking for a solution to the same challenges, we highly recommend you explore Azure Container Apps! This project, which I conceived and managed personally, has demonstrated the enormous potential of Azure Container Apps to optimize costs and scale cloud infrastructures, as well as to modernize development workflows.
9. Further Reading
If you want to delve deeper into our previous architecture and the initial challenges we faced with App Service Plans, you can read my previous blog post:
Top comments (0)