Microservices Architecture Using Azure Container APPS & DAPR & KEDA

What is Azure Container Apps?

Building containerized applications and following a microservices architecture is now one of the most common patterns in cloud-native application development. When it comes to containerization, creating highly available and scalable Kubernetes clusters is essential. Fortunately, major cloud providers offer Platform as a Service (PaaS) models. However, even with PaaS Kubernetes clusters, there are still administrative tasks involved, such as maintenance and upgrades of node pools and the Kubernetes API server master.

Microsoft and other major cloud providers offer various cloud services to develop, package, deploy, and manage cloud-native applications. In Microsoft Azure, the following PaaS services are commonly used:

• App Services
• Container Instances
• Azure Kubernetes Service (AKS)
• Azure Functions (Serverless)
• Azure Logic Apps

Each of these services supports specific architectural needs. For example, Azure Functions provides a serverless environment. Azure AKS offers a PaaS model for Kubernetes, but it still requires administrative tasks such as creating, configuring, and networking between services (e.g., Azure CNI or Kubenet), and deploying microservices workloads.

To abstract away these administrative tasks, Microsoft introduced Azure Container Apps.

Azure Container Apps Overview

Azure Container Apps is a fully managed, serverless container runtime designed for building Kubernetes and microservices-based applications. As a developer or DevOps engineer, you no longer need to worry about infrastructure management. Here are some of the features already built into Azure Container Apps:

• Dapr (Distributed Application Runtime)
• KEDA (Kubernetes Event-Driven Autoscaling)
• Blue/Green or A/B testing
• Auto-scaling based on various rules, such as:
  • Number of concurrent HTTP requests
  • Standard AKS metrics (CPU and Memory)
  • Event-driven scaling with KEDA

Demo Application Architecture

In the demo application architecture deployed into Azure Container Apps, we leverage Dapr for its distributed application runtime capabilities. Before diving into Dapr, let's refresh one of the design patterns called the Sidecar pattern, as Dapr is deployed as a sidecar. For more details, you can visit the Dapr website.

Benefits of Using Dapr

When building microservices with Dapr, several tasks can be offloaded, providing various features out of the box:

• Service Discovery
• Securing communication between microservices (mTLS)
• Handling transient failures (retries)
• Distributed tracing
• Observability

In the architecture, we use Dapr's building blocks such as State Store, Service-to-Service Invocation, and Pub-Sub. For instance, MongoDB is used to store the state, and Azure Service Topics/Queues are used for event publishing. If you want to switch to CosmosDB or AWS SQS/SNS, you can simply change the components' configuration (YAML file) without altering a single line of code.

Example Configuration

Here is an example YAML file for MongoDB and Azure Service Bus components used by Dapr when running microservices.

# MongoDB Component Configuration
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
spec:
  type: state.mongoDB
  version: v1
  metadata:
  - name: connectionString
    value: "mongodb://<username>:<password>@<host>:<port>"
  - name: database
    value: "<database_name>"
  - name: collection
    value: "<collection_name>"

# Azure Service Bus Component Configuration
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: pubsub
spec:
  type: pubsub.azure.servicebus
  version: v1
  metadata:
  - name: connectionString
    value: "Endpoint=sb://<namespace>.servicebus.windows.net/;SharedAccessKeyName=<key_name>;SharedAccessKey=<key_value>"
  - name: topic
    value: "<topic_name>"

Deployment Environment

• Azure Container Apps Environment: Deployed into a dedicated Azure Virtual Network (VNet).
• Single Container App Deployment: You can deploy your app into a single container app with multiple versions, offering compute-level isolation and logging.

Scaling and Cost Efficiency

As mentioned earlier, you can set different scaling rules. If no activity is detected, Azure Container Apps can scale to zero, meaning no costs are incurred. In contrast, with an AKS cluster, you would still pay for all running node pool VMs.

By using Azure Container Apps, you can focus on building and deploying your applications without worrying about the underlying infrastructure, making it a powerful tool for modern cloud-native development.

Thanks
Sreeni Ramadurai