Migration to Azure Container Apps Vol.1 Why?

Motivation

When embarking on a startup project, it's important to acknowledge that the final product will likely undergo significant changes compared to its initial state, including the software itself. In line with Martin Fowler's advice on architectural patterns, our team adopted a MonolithFirst approach (described in Martin Fowler's blog post). Initially, we chose Azure App Service as the app orchestrator (computing service in Azure terminology) in Microsoft Azure due to its simplicity and straightforwardness to validate MVP ASAP. We were fortunate to be part of the Microsoft for Startups program, which provided valuable support and a cloud budget for our project.

From the outset, we secured investment for our project and achieved a product-market fit. However, as the application continued to grow, we encountered challenges in terms of development complexity and scalability costs which is common. The current size of the application makes it cumbersome to work with, and the expenses associated with running and scaling the system have become prohibitively high.

Our current Azure App service is not suitable for the deployment of distributed architectures because of its cost and the reasons below. I am going to describe the basic story of our migration in dream.jobs to Azure Container Apps.

Why not continue with Azure App Service

While the Azure App Service is indeed a versatile deployment solution, Azure has made significant advancements since its inception, offering a range of computing services tailored to specific application needs. Here is an updated Azure architectural recommendation for computing services.

Our main reasons to migrate:

• Cost-inefficient scaling = The Azure App Service has one scaling rule for all applications. New nodes increase instances of all applications on Azure App Plan (server cluster) and for each instance, the whole tier is scaled and priced.

• Expensive horizontal scaling = With hosting AI models we started to reach the limits of common tiers and scaling become even more expensive

• Shared performance = Applications load influences other applications. Split applications to more servers are expensive

• Bad observability = Good observability requires a lot of configuration

• Slow learning curve = The complexity of the product is time-consuming for developers to learn and manage it

• Slow deployment and scaling

• Expensive application isolation = Hiding applications to private networks is expensive. Either an isolated tier must be used or for each application, a private endpoint must be created (communication through a private endpoint is charged). All scenarios are in the end quite expensive

Why not AKS

Although AKS (Azure Kubernetes Service) is a robust and powerful solution, it may not be the ideal fit for our current requirements. As a small startup with skilled developers, our team is built upon expertise, automation, and the utilization of managed services, enabling us to maintain a lean team and keep our development budget optimized. However, AKS can be relatively heavyweight and complex, demanding substantial maintenance efforts and time investments. Considering our current priorities, we find that AKS exceeds our immediate needs, and its implementation would not provide sufficient benefits for our present stage of growth.

Why Azure Container Apps

We are seeking a computing solution that addresses the limitations of Azure App service while providing enhanced management capabilities, without the time-intensive nature of AKS. Azure Container Apps fits our requirements by offering a streamlined and managed platform for deploying distributed applications. In the following post, I will delve into further details about how Azure Container Apps can meet our needs effectively.