System Deployment

This section will cover some fundamental aspects of system deployment.

Deployment Options

Suppose we aim to deploy a system on a server. Let’s examine the most common options for achieving this:

Bare-metal Deployment

This is the most fundamental deployment method, where system components run as native processes directly on the server’s Operating System (OS).

This model typically yields the maximum performance because processes can access hardware resources with minimal overhead, as there are no virtualization layers.

However, all processes share the same host OS. This shared environment can be vulnerable to exploitation.

For instance, if an attacked process has incorrectly configured permissions for its executor, it could potentially abuse the OS to compromise other processes or even the entire server.

Virtual Machine

Virtual Machines (VMs) are employed to create a more strictly isolated environment. A virtual machine emulates a physical computer but runs on a software layer called a Hypervisor, rather than directly on physical hardware.

Although VMs rely on the host’s OS (via the hypervisor), they each possess their own independent OS and dedicated resources (files, users, processes, etc), ensuring they are completely isolated from one another.

System processes can then be deployed on different virtual machines. This approach offers a significant security benefit: even if some processes on one VM are compromised, they cannot directly affect processes on other VMs or the underlying physical machine.

However, virtual machines are not optimal in terms of resource efficiency. Each VM runs its own full operating system, which consumes considerable CPU, memory, and storage resources. Moreover, booting a virtual machine involves numerous setup steps and can take several minutes to complete. This can prolong the initialization time for system components, potentially affecting the system availability.

In the next topic, we will explore a more lightweight option known as Containerization.

Multi-tenant

In practice, organizations often rely on cloud providers for their system infrastructure rather than building it themselves. When a customer rents an entire physical machine and has full control over it, this is known as Single-tenancy or a Dedicated Server, as no other customer can access that server.

By default, many cloud platforms offer a Multi-tenant model. In this setup, cloud providers divide a single physical machine into multiple virtual machines, and each VM can be rented by a different customer.

Ultimately, in a multi-tenant environment, the virtual machines still share the same underlying hardware. This poses a potential risk of data leaks if there are flaws in the software isolation mechanisms. Consequently, multi-tenancy is sometimes prohibited in systems with extremely strict security requirements.