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. In this arrangement, the university dedicates a server and its operating-system environment to the application. The application can be updated independently, but its environment is installed and maintained on that server.

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.