Why Azure Container Apps MIGHT be better than Kubernetes

Architecture is all about balancing trade-offs at a specific point in time, but it’s important to keep in mind our state architectures — both our current setup and our target architectures for future iterations.

Every decision should be made with an eye toward where you are now and where you want to go next, ensuring that your architecture can evolve as your needs change.

Remember, there is no one-size-fits-all solution, and nothing is inherently wrong as long as you balance your trade-offs wisely and plan for the future.

I have attended this session at the NDC Conference in Oslo. You can check it out here.

Since it’s an hour-long session

The session provides an in-depth look at the functionalities and advantages of Azure Container Apps (ACA) compared to Azure Kubernetes Service (AKS) (Though it does seem a bit biased towards the speaker’s expertise.)

This is my take on this session when deciding on the underlying architecture, especially when balancing trade-offs.

Considering Simplicity and Ease of Use

Managed Infrastructure

ACA abstracts much of the complexity associated with Kubernetes. Developers do not need to manage nodes, virtual machines, or the Kubernetes cluster. This makes ACA more accessible, especially for teams focused on delivering solutions without the need for deep Kubernetes expertise.

This appears to be a choice for teams that follow “You built it, you own it”.

Scaling and Serverless Capabilities

ACA offers a built-in, serverless consumption model, allowing applications to scale down to zero when not in use. This is particularly beneficial for SaaS applications with different workloads, as it looks like can lead to considerable cost savings. AKS, while powerful, requires more manual configuration and management for scaling, including setting up auto-scalers and managing resource allocation.

Considering Flexibility and Abstraction

Built on Kubernetes

ACA is built on top of AKS, providing some of the benefits of Kubernetes (like container orchestration) without requiring users to manage the complexities of a full Kubernetes setup. This is ideal for SaaS applications that need the robustness of Kubernetes but not the overhead.

Pre-Installed Open-Source Components

ACA comes with pre-configured tools like KEDA (Kubernetes-based Event-Driven Autoscaler), Dapr (Distributed Application Runtime), and Envoy for proxying and load balancing. These tools enhance the development and deployment experience by simplifying common tasks like scaling, service-to-service communication, and load balancing, which would require additional setup and management in AKS.

Support for the Rapid Development and Deployment

Developer Experience

ACA integrates well with common developer tools and workflows, offering a straightforward path from development to deployment. This is important for applications that need to iterate quickly and focus on delivering features rather than managing infrastructure.

Revisions and Rollbacks

ACA’s built-in support for revisions give us flexibility for easy A/B testing and gradual rollouts of new features, which is a significant advantage for SaaS applications needing frequent updates with minimal downtime. Looks like not much different what Kubernates supports except configuration overhead.

Let’s focus on balancing the Trade-offs between ACA and Kubernetes.

While ACA offers many advantages, there are scenarios where AKS might still be necessary, particularly for more complex or large-scale applications. Here is my take on deciding factors.

Complexity vs. Control

If the application requires highly customized orchestration, specific networking configurations, or runs complex, multi-tenant workloads, AKS might be more appropriate despite its complexity. But, if ease of use and reduced management overhead are priorities, ACA is likely the better choice.

Cost Management

ACA’s serverless model is cost-effective for workloads with variable or unpredictable demand, as you only pay for what you use. However, for consistently high-demand applications, AKS might be more cost-effective in the long run, given its ability to run workloads on dedicated resources.

Ecosystem and Integration Needs

If the application ecosystem heavily relies on Kubernetes-native tools or requires integration with existing Kubernetes clusters, AKS is the natural fit. On the other hand, ACA’s integration with open-source components like Dapr and KEDA makes it a choice for applications that can benefit from these abstractions without requiring deep Kubernetes integrations.

Scalability and Performance

For the applications with large scale requirements or those needing fine-grained control over resource allocation, AKS provides more flexibility. However, for many applications, ACA’s scalability (including the ability to run containers and scale them automatically) will be sufficient and far simpler to manage.

Let’s talk about security aspects

Impact on Zero Trust Implementation

Service Isolation

ACA automatically provides service isolation within its container environments. Each container app can be configured with its own identity and policies, aligning well with the principles of Zero Trust by ensuring that each service is treated as a separate, secure entity.

Network Security

ACA environments allow to define virtual networks (VNet) and subnet configurations, ensuring that communications between services within the environment can be restricted and controlled according to Zero Trust principles. In AKS, achieving a similar setup requires more manual configuration, including setting up network policies and managing ingress and egress controls for each pod.

Authentication and Authorization

Managed Identities

ACA natively supports Managed Identities, allowing each container app to securely authenticate against Azure services without managing credentials. This simplifies the implementation of secure, identity-based access controls. AKS supports Managed Identities too, but it appears to be it involves more complex configurations, particularly when dealing with multiple identities across pods and services.

Azure API Management Integration

ACA can easily integrate with Azure API Management (APIM) to handle external-facing authentication and authorization. APIM allows to implement OAuth 2.0, OpenID Connect, and other industry-standard protocols, ensuring that only authenticated and authorized requests reach your container apps. In AKS, integrating with APIM is also possible, but it seems to be typically requires additional work to manage and expose services securely, especially when dealing with service meshes or ingress controllers.

Service-to-Service Communications

mTLS (Mutual TLS)

Appears to be ACA abstracts much of the complexity around securing service-to-service communications. With ACA, services can communicate over HTTPS by default, and can enforce mTLS without needing to manually configure certificates and trust relationships. In AKS, setting up mTLS requires configuring a service mesh tools which adds complexity.

Dapr Integration

ACA’s native support for Dapr (Distributed Application Runtime) enhances security by automatically securing service-to-service communications with sidecar proxies that handle encryption and mTLS. Dapr also simplifies secure access to secrets, reducing the risk of credentials being exposed. While Dapr can also be used in AKS, the setup is more involved, require to manually manage Dapr components and ensure that all services are correctly configured.

Integrating External Identity Providers (IDPs) such as Auth0, Frontegg, and Keycloak

It appears to be ACA simplifies the integration of external IDPs by providing out-of-the-box support for identity management through Azure AD, which can easily federate with external IDPs like Auth0, Frontegg, or Keycloak. By using Azure API Management to handle OAuth 2.0, OpenID Connect, and SAML, providing a unified gateway for external IDP integration without needing extensive custom configurations.

While AKS can also integrate with external IDPs, the process can be more complex and requires additional configuration. We will require need to manage custom ingress controllers, OAuth2 proxies, or service meshes to facilitate secure communication between applications and the IDP. This adds a layer of complexity that might require more expertise and maintenance.

ACA, with its seamless integration with Azure AD and API Management, simplifies token validation, refresh, and role-based access control (RBAC). AKS, on the other hand, might require custom middleware or sidecar containers to handle token validation, increasing the complexity of managing authentication and authorization.

Happy Archiecting!!!

If you enjoyed this article and found it insightful, please consider supporting it with some 👏 claps, sharing it 🔄, and following me on LinkedIn 🔗. I value your feedback and would love to hear your opinions and ideas 💡. Don’t hesitate to comment below with topics you’re interested in or thoughts you’d like to share 💬. Let’s keep the conversation going and explore together!

Are you looking for expert freelance services or professional consultation? Visit https://devinsights.tech/ for top-notch solutions tailored to your needs. Let’s turn your vision into reality!