Edition 0 Updated to asp. Net core 0

Deploying a monolithic application as a container 
There are benefits to using containers to manage monolithic application deployments. Scaling 
container instances is far faster and easier than deploying additional VMs. Even if you use virtual 
machine scale sets, VMs take time to start. When deployed as traditional application instances instead 
of containers, the configuration of th
e application is managed as part of the VM, which isn’t ideal.
Deploying updates as Docker images is far faster and network efficient. Docker images typically start 
in seconds, which speeds rollouts. Tearing down a Docker image instance is as easy as issuing a 
docker stop
command, and typically completes in less than a second. 
Because containers are immutable by design, you never need to worry about corrupted VMs. In 
contrast, update scripts for a VM might forget to account for some specific configuration or file left on 
disk. 
While monolithic applications can benefit from Docker, we’re touching only on the benefits. 
Additional benefits of managing containers come from deploying with container orchestrators, which 
manage the various instances and lifecycle of each container instance. Breaking up the monolithic 
application into subsystems that can be scaled, developed, and deployed individually is your entry 
point into the realm of microservices. 
Publishing a single-container-based application to Azure App Service 
Whether you want to get validation of a container deployed to Azure or when an application is simply 
a single-container application, Azure App Service provides a great way to provide scalable single-
container-based services. Using Azure App Service is simple. It provides great integration with Git to 
make it easy to take your code, build it in Visual Studio, and deploy it directly to Azure. 

---

22 
CHAPTER 3 | Architecting container and microservice-based applications 
Figure 4-4. Publishing a single-container application to Azure App Service from Visual Studio 2022 
Without Dock
er, if you needed other capabilities, frameworks, or dependencies that aren’t supported 
in Azure App Service, you had to wait until the Azure team updated those dependencies in App 
Service. Or you had to switch to other services like Azure Cloud Services or VMs, where you had 
further control and you could install a required component or framework for your application. 
Container support in Visual Studio 2017 and later gives you the ability to include whatever you want 
in your application environment, as shown in Figure 4-
4. Since you’re running it in a container, if you 
add a dependency to your application, you can include the dependency in your Dockerfile or Docker 
image. 
As also shown in Figure 4-4, the publish flow pushes an image through a container registry. This can 
be the Azure Container Registry (a registry close to your deployments in Azure and secured by Azure 
Active Directory groups and accounts), or any other Docker registry, like Docker Hub or an on-
premises registry. 
Manage state and data in Docker applications 
In most cases, you can think of a container as an instanc
e of a process. A process doesn’t maintain 
persistent state. While a container can write to its local storage, assuming that an instance will be 
around indefinitely would be like assuming that a single location in memory will be durable. You 

---

23 
CHAPTER 3 | Architecting container and microservice-based applications 
should assume that container images, like processes, have multiple instances or will eventually be 
killed. If they’re managed with a container orchestrator, you should assume that they might get 
moved from one node or VM to another. 
The following solutions are used to manage data in Docker applications: 
From the Docker host, as 
Docker Volumes
: 
•