NET-Microservices-Architecture-for-Containerized-NET-Applications-(Microsoft-eBook)

You might find a scenario where you want multiple processes running in a single container. For that
scenario, since there can be only one entry point per container, you could run a script within the
container that launches as many programs as needed. For example, you can use Supervisor or a
similar tool to take care of launching multiple processes inside a single container. However, even
though you can find architectures that hold multiple processes per container, that approach it is not
very common.
Containerizing monolithic applications
You might want to build a single, monolithically deployed web application or service and deploy it as
a container. The application itself might not be internally monolithic, but structured as several
libraries, components, or even layers (application layer, domain layer, data-access layer, etc.).
Externally, however, it is a single container—a single process, a single web application, or a single
service.
To manage this model, you deploy a single container to represent the application. To scale up, you
just add more copies with a load balancer in front. The simplicity comes from managing a single
deployment in a single container or VM.
Figure 4-1. Example of the architecture of a containerized monolithic application
You can include multiple components, libraries, or internal layers in each container, as illustrated in
Figure 4-1. However, this monolithic pattern might conflict with the container principle “a container
does one thing, and does it in one process”, but might be ok for some cases.
The downside of this approach becomes evident if the application grows, requiring it to scale. If the
entire application can scale, it is not really a problem. However, in most cases, just a few parts of the
application are the choke points that requiring scaling, while other components are used less.
20 Architecting Container- and Microservice-Based Applications