Deploying a Monolith
This chapter defines a monolith and covers the history and mechanics of deployment, using HopPress and CourseTracker as running examples. It starts with bare-metal servers, moves through virtual machines and containers, and gets to Docker. Along the way, it explains why the deployment boundary is a design decision, not only an operations detail.
After reading this chapter, you should be able to:
- Define a monolith as an application with one deployment boundary, using WordPress, HopPress, and CourseTracker as examples
- Explain why bare-metal, one-application-per-server deployment wasted capacity and tied an application to one particular machine over time
- Explain how virtual machines let multiple isolated systems share one physical server, and identify the operating-system overhead each virtual machine still carries
- Explain a container as an isolated application process that shares the host’s kernel, and the trade-off of shared fate between containers on the same host
- Distinguish a container image from a running container, and explain how Docker’s image and registry workflow splits responsibility between developers and IT
- Explain why the number and shape of a deployment boundary is a design decision, with consequences for failure, change, capacity, and ownership
- Explain how DevOps changed the relationship between writing software and running it, and why a designer needs a working picture of deployment
- Explain that a container and a monolith are independent ideas: a container is how one deployable unit is packaged, and an architecture decides how many such units exist