Cloud App Journey - Ep. 3: Publishing my Backend in Containers exploring the Cloud

If you've been following the previous episodes of our "App na Cloud" series, you've already seen how easy it is to start deploying applications to the cloud—whether it's authentication with Azure services, publishing full-stack applications via App Service, or deploying lightweight and cost-effective frontends.

Now it's time to talk about a very relevant topic in a developer's daily life: containers.

Why Containers?

Containers are one of the most flexible and portable ways to package and distribute applications today. With them, we can:

• Ensure the application runs the same way in any environment.
• Quickly deploy new versions without configuration headaches.
• Take the same image to different clouds or even run it locally.

In other words, if you have a backend API, for example, you can package it into an image and run it exactly the same on your laptop, an on-premises server, or any cloud.

Where to Store My Images?

Before publishing containers on Azure, we need an image repository. Here are some options:

1. Docker Hub (Free and Popular)

• By creating an account on Docker Hub, you can upload your images and use them from anywhere.
• Ideal for personal projects, prototypes, or when you don't need fine-grained security control.

Example of publishing an image:

# Build the image
docker build -t my-user/my-backend:1.0 .

# Login to Docker Hub
docker login

# Push to the repository
docker push my-user/my-backend:1.0

2. Azure Container Registry (ACR)

• Microsoft's private image repository on Azure.
• Offers security, integration with Active Directory, and can be used in corporate scenarios.

Creating an ACR via Azure CLI:

az acr create --resource-group my-group \
  --name myacrregistry \
  --sku Basic

Logging in and pushing the image:

# Login to the registry
az acr login --name myacrregistry

# Tag for ACR
docker tag my-backend:1.0 myacrregistry.azurecr.io/my-backend:1.0

# Push
docker push myacrregistry.azurecr.io/my-backend:1.0

Now your image is securely stored in Azure.

Publishing Containers on Azure

Once we have the image, we need a service on Azure to run it. Here are some alternatives:

1. Azure Container Apps (Recommended for Simplicity)
2. Serverless service for containers.
3. Automatic scaling, and you only pay for usage.
4. Great for backends and APIs.

Quick creation example:

az containerapp create \
  --name my-backend-app \
  --resource-group my-group \
  --environment my-env \
  --image myacrregistry.azurecr.io/my-backend:1.0 \
  --target-port 8080 \
  --ingress external

Your backend will now be available at a public endpoint.

2. Azure Container Instances (ACI)

• Still a valid service, focused on simplicity.
• Allows quickly running a single container without much configuration.

It's like a "docker run" in the cloud.

Example:

az container create \
  --resource-group my-group \
  --name my-backend-aci \
  --image myacrregistry.azurecr.io/my-backend:1.0 \
  --ports 8080

3. Azure Kubernetes Services (AKS)

• More powerful and comprehensive, but also more complex.
• Suitable for scaling and high availability scenarios.

Not the focus of this article, but worth noting as the alternative for robust production scenarios.

Which Path to Follow?

• Personal project / study → Docker Hub + Container Apps or Container Instances
• Simple corporate project → ACR + Container Apps
• Larger-scale production → ACR + AKS

Conclusion

We've reached the end of another episode of the "App na Cloud" series. Today, we saw that deploying backends in containers can be much simpler than it seems—whether using a public repository on Docker Hub or exploring the power of Azure Container Registry combined with Azure App Service or Azure Container Apps.

But publishing is just the first part of the journey. The real challenge begins when your application needs to run in production in a stable, secure, and observable manner. This is when monitoring practices and services come into play, ensuring you truly know what's happening with your app, whether it's consuming many resources, handling failures, or serving thousands of simultaneous users.

In the next episode, we'll delve into these monitoring practices and tools.