Blog Azure Cloud Native

Containers vs Serverless in Azure: Do You Really Have To Choose?

As businesses are looking for ways to modernise their applications, there are often many choices along the way. “Should you use serverless or containers in Azure?”

This article will help you decide between containers and serverless architectures.

Whether starting from scratch or breaking up a monolith, we help you pick the right approach for your business requirements.

Author

Niels Kroeze IT Business Copywriter

Reading time 12 minutes Published: 20 June 2025

What is serverless computing?

Serverless computing is a cloud model where you run your code without managing servers. The cloud providers, such as Microsoft Azure handle the underlying infrastructure needed to run applications for you.

Comparison of cloud computing services including pre-cloud BYO servers, IaaS, PaaS, and serverless models.

Being “serverless” doesn’t mean there are no servers involved. In fact, they are still there. Instead, in serverless computing, the complexity of these servers is abstracted from developers, system admins and operation teams.

In other words: You focus on the business logic while Microsoft oversees the infrastructure.

Key characteristics of Serverless

The servers are abstracted away

Servers still exist, but you don’t have to manage them.
Scaling, execution and resource allocation are all fully managed by the cloud provider.
You focus on the application level – writing code

Pay-per-use billing

With virtual machines, you pay a flat rate based on size, even if it sits idle.
With serverless, you only pay while your code runs.
This can significantly reduce costs, especially for bursty or unpredictable workloads.

Automatic scaling

The serverless platform will automatically scale out – adding compute resources as needed.
If there’s no traffic, it scales down to zero (and you don’t pay).
This elasticity is built-in and fully managed.

Which Services are Serverless in Azure?

So, what options are there for going “serverless” in Azure? There are plenty of choices when it comes to serverless computing.

Azure Functions: Let’s you write small bits of code (functions), and they run in response to specific events. Rather than running full apps, you just run individual functions which are tied to triggers.
Azure Logic Apps: A service for automating tasks, workflows, and business processes. Especially helpful when you're integrating different applications, systems, data, and services across an organisation.
Azure Event Grid: A fully managed event routing service from Microsoft. It uses a publish/subscribe model to deliver events in near real-time, helping you build event-driven architectures across Azure and beyond.
Azure App Services (Consumption Plan): Great for web apps needing serverless benefits without full rewrite.
Azure Service Bus: A fully managed enterprise message broker designed for asynchronous data transfer and application decoupling.
Azure Container Apps: Serverless containers for running microservices, APIs, event-driven apps and background jobs – no VM or orchestrator needed.
Azure SQL Database (Serverless): Auto-pausing SQL database with per-second billing. You only pay for the compute you use. Scales automatically based on load.
Azure Cosmos DB (Serverless): Globally distributed, multi-model NoSQL database with pay-per-operation pricing.

Benefits of Serverless

As more organisations adopt the cloud, many are turning to serverless computing for hosting applications and solutions.

The key benefits include:

Event-driven and stateless by design: It forces good microservice design patterns from the start.
Cost savings with pay-per-use billing: Serverless uses a consumption-based model, so you’re only charged for when it is running. If it's idle, you pay nothing – saving costs. Additionally, as developer, you don’t need to worry about provisioning resources or incurring costs from unused capacity. And on top of that, Azure includes a free monthly grant:
- 1 million function executions
- 400,000 GB-seconds
  So you may even experiment or prototype without paying anything at all.
Rapid development with bindings and integrations: If you use the services Azure Functions connects to natively (e.g. Storage, Service Bus), you can build things extremely fast.
Faster time to market: Focus on writing business logic instead of managing infrastructure, so you ship features quicker.
Less code to write and maintain: Use triggers, bindings, and managed services to reduce boilerplate and integration code.
Automatic, built-in scaling: You don’t need to size VMs or overprovision. Serverless apps scale automatically, up or down, based on real demand.

Use Cases for Serverless

Event-driven applications: this includes scenarios like IoT (Internet of Things), data processing, and real-time analytics. With serverless, you can efficiently handle bursts of incoming events without worrying about provisioning or managing servers.
Sporadic workloads: Serverless is well suited for tasks that don't follow a consistent schedule, such as scheduled tasks and batch processing. For instance, you might have periodic data clean-up or report generation tasks that occur at irregular intervals.

What are containers?

Simply put, they are a way of packaging your application along with its dependencies.

"Containers are self-contained software units that encapsulate an application along with its dependencies, libraries and configuration files."

Once you’ve packaged an application in a container, anything that can run containers can successfully run your app – without needing anything else installed. That means your app becomes highly portable. It can run on your local development machine, in an on-premises data centre, or any cloud.

Compared to traditional virtual machines (VMs), containers are faster and more efficient.

Containers in Azure

There are multiple ways to run containers in Azure. One of them is spinning up a Linux or Windows VM with containers enabled. Alternatively, you could even run a bunch of virtual machines and install Kubernetes on them. However, that will take some time and effort.

Now, you might ask: are there any ways of running containers in Azure where we don’t have to manage the servers?

The short answer = yes. There are services such as Azure Container Apps or Azure Container Instances which can make that happen.

Azure Container Instances

Azure Container Instances are one of the easiest ways to run containers. You point Azure to your container image – typically stored in a registry, and ask it to run it. There's no need to manage VMs. You only pay while the container runs. Meaning, once it stops, billing stops too. This makes it a great for short-lived tasks (like batch jobs) where you only need compute for a limited time.

Azure Web App

You can host web apps with Azure App Service without containers. But if you want to containerise your application you can use Azure Web App for Containers. This lets you run custom container images while keeping all the usual benefits: like custom domains, autoscaling, and easy configuration.

Azure Container Apps

If you're looking for a simpler way to run containers without managing the underlying Kubernetes infrastructure, Azure Container Apps is worth considering. It supports microservice architectures, autoscaling, and event-driven patterns and is ideal for modern apps. It's particularly useful when you don’t want the full complexity of AKS but still need features like traffic splitting, revisions, or Dapr integration. ACA runs containers directly and scales to zero when idle, which helps reduce cost for intermittent workloads.

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) is managed Kubernetes in Azure. For some time now, it has been the platform for orchestrating containers. AKS makes it easy to get started: with just a few clicks or lines of code, you’ve got an AKS cluster up and running. Better yet, it allows you to manage your containers easily.

Benefits of Containers

If you want to move away from static, monolithic applications towards a cloud native one, containers are often the best choice.

By decoupling the app into a microservice architecture, where each service runs in its own container, you can develop, manage, and scale them separately.

But there are more benefits containers bring to the table:

Best for legacy app migration: Container architectures are ideal for migrating legacy apps to the cloud. You can usually write a single DockerFile for it, get it containerised, and have it up and running inside a Windows container hosting system relatively quickly.
Resource efficiency: You can basically run multiple isolated containers on a single VM, making it easy to host several lightweight microservices without conflicts or wasted capacity.
Lower cost: Since all containers share the same resources, containers are more cost-effective.
No overhead: Containers don’t add any overhead compared to running it directly on the host computer. It doesn’t have large extra startup times or extra memory requirements.
Easily adopt 3rd party dependencies: There’s a vast library of excellent containerised apps. You can easily pick the tools and components you want in your microservices architecture, without being limited to just what your cloud provider offers.
Supports both Linux and Windows: While most containers run on Linux, Windows containers are fully supported too. That’s a plus if you need to run legacy .NET Framework apps or other workloads tied to Windows.
Ecosystem around containers: Containers are now an industry standard, supported across all major languages and cloud platforms. That gives you access to a wide range of tools for monitoring, deployment, security, and CI/CD. This makes integration consistent and straightforward.

Use Cases for Containers

Microservices architecture: Containers excel at breaking down complex applications into smaller, independently deployable services. Each microservice runs within its own container, enabling teams to develop, deploy, and scale components independently. For example, a large e-commerce platform might consist of separate microservices for inventory management, payment processing, and user authentication.
Consistent workloads: Applications with predictable resource requirements benefit from containerisation. These workloads typically require a stable environment with controlled resource allocation. Consider a web application serving a steady stream of user requests. By containerising each component, you ensure consistent performance and resource utilisation across deployments.

Key differences between serverless and containers

The table below shows how serverless and containers compare:

Feature	Serverless	Containers
Management overhead	Minimal	Moderate
Scalability	Automatic scaling	Manual or automatic scaling
Cold start	Might have cold start times	Faster start-up times
Resource utilisation	Optimised for individual function requests	Depends on the container size
Pricing model	Pay-per-use	Pay for provisioned resources
Flexibility	Limited control over runtime environment	Greater control over runtime environment

Another important thing to consider is that serverless functions run on shared Azure infrastructure, which is secure, but in some industries, shared environments don’t meet compliance needs.

Similarities between Serverless and Containers

Serverless and containers facilitate building applications using a microservices architecture.

Both serverless and containers abstract the underlying infrastructure, freeing developers to focus on writing code rather than managing servers. They are also very scalable. Serverless architectures automatically scale in response to events, and container orchestration platforms like Kubernetes can scale container instances based on demand.

In addition, as well serverless and container-based applications integrate well with DevOps practices, supporting continuous integration and continuous deployment (CI/CD) pipelines.

Which one should you choose?

Choosing between serverless and containers is crucial when modernising your application. So, which architecture should you choose?

You can create a 100% serverless system where every piece of code is a small Azure Function, triggered by events, paired with PaaS services for storage, messaging and more.
Or, you can go 100% containerised: where you have your Kubernetes cluster, and all of your microservices containerised.

Alongside that, you might even decide to containerise your databases and message queuing systems. Containerising everything results in a much more cross-cloud portable solution.

In other words: you can easily take your microservice application from Azure and run it in AWS or on-prem.

Why go for serverless

Going serverless in Azure, for example, adopting Azure Functions, may be a solid use case in some scenarios.

With serverless, you don’t have to worry about what the file system is doing, nor your environmental dependencies nor you don’t have to set up Docker containers. If you have short-lived or sporadic workloads, serverless means you only pay when code runs.

Generally, they are a good fit for workloads that are event-driven, run briefly and need to scale on demand. But they especially excel if you want to get your business to the market quickly. You’ve got an idea and need to get code into production quickly to start generating revenue – then it works, even when temporarily. You can ship code fast using Azure Functions.

But what if it gains traction? Ultimately, you reach a certain point where serverless will take you no farther.

As long as your business logic sits behind an API controller, it’s usually easy to migrate. You can move it into containers, adopting Kubernetes, leaving serverless behind.

Why go for containers

Although we just mentioned how serverless encourages event-driven apps… that’s not to say you can’t do event-driven, stateless programming with containers. You can.

And there are so many reasons to adopt a container architecture, so let’s break down some of them:

One of the key advantages of containers is how well they handle legacy app migration. Even older .NET apps like .NET 4 can often be containerised quickly with just a Dockerfile and run on Windows containers.
In contrary to serverless, containers can often be started in seconds, and once written, they can be run almost everywhere.
Whereas in serverless you are more tied to vendor lock-in, you aren’t with containers.
Also, containers are not limited to languages; they can run on any.

Do you even have to choose?

You don’t have to commit to 100% containers, nor 100% serverless. A hybrid architecture is also possible, where you get the best of both worlds. You might run a monolithic app on a virtual machine, while using Azure Functions for specific tasks and containers for others.

Besides, you can run Azure Functions inside a container or use functions to trigger and manage containerised workloads. Now, imagine you’ve already committed to containers.

You have a Kubernetes cluster, and you think: “Now I cannot use Azure Functions anymore.” Think again…

You possibly can containerise an Azure Function app and run it inside a container – in AKS, any cloud, or even locally.

Closing thoughts

In the end, the best choice for deploying and managing modern applications in the cloud depends on your needs and use case, regardless whether that’s serverless or in a container architecture.

While serverless can be great for small, focused bits of business logic, in practice, it might not stay as small or clean as you hope once the app grows. If you’re building a larger, enterprise-grade application, you’ll probably hit limits.
On the other hand, containers are best suited for applications following a microservices architecture and those with consistent workloads.