The Bare-Metal Starting Point

The university’s IT may have a few unused physical servers. The university could install HopPress on one of those servers, and the application would be ready to run. The server would have an operating system, a web server, a database, and the HopPress application itself. The university may use a subdomain like hoppress.university.edu to let people reach the application over the network.

This is a bare-metal deployment. The application runs directly on the operating system of a physical server. The server is the deployment boundary: it contains the application and its environment, and it is the unit that the university can move, upgrade, or replace.

The bare-metal model used to be the only way to deploy software. If an organization needed another application, it gave that application another server. The university would do the same for CourseTracker: a second physical server, entirely separate from HopPress’s.

This arrangement created a simple boundary. Each application owned its server, its operating-system installation, and the resources attached to that server. But the arrangement was expensive. The organization had to buy, install, and maintain a new physical server before it could run the next application. It also had to guess how much capacity the application would need.

Those guesses were often wrong. If the server was too small, the application could fail under load. If it was too large, most of its CPU and memory could sit unused.

The problem was not only the cost of hardware. Each physical server became part of how the application was deployed: which libraries were available, which versions were installed, which configuration files were present. Over years of maintenance, those specifics accumulated until the application could run only on that particular server, with that particular operating system.