There’s Always a Server Behind the Cloud: Nikita Kuznetsov on the Hidden Side of IT Infrastructure

Cloud services create the impression that physical hardware no longer plays a significant role. You simply open the provider’s dashboard, select a configuration, and receive a ready-to-use virtual machine within minutes. Yet, applications still run on processors, data is stored on drives, and requests pass through actual network devices. All of this resides in specific data centers. According to IT engineer Nikita Kuznetsov, the cloud does not eliminate infrastructure; it merely conceals it behind a user-friendly interface. As long as the system is running smoothly, this goes unnoticed. However, in the event of a failure, details suddenly matter: where the data is located, who controls the hardware, and what limitations the provider has imposed. "As long as the service loads, nobody cares whose cabinet it is or how many shelves it has. People start caring when a shelf breaks and the key to the cabinet turns out to be in someone else's hands." A virtual server is part of a larger system A virtual machine appears to be a standalone computer. It has a processor, memory, storage, an operating system, and a network address. Physically, however, it consists of resources allocated on a shared server. A hypervisor distributes computing power among multiple clients. This allows a company to rent only the necessary portion of a server rather than purchasing the entire unit. In most cases, this approach is convenient and efficient. But when issues arise, it becomes clear that the virtual machine depends on the physical host, the provider's platform, and resource migration policies. Changes can occur even without an application update: the virtual machine might be moved to a different server, platform parameters might be altered, or new restrictions might be introduced. Consequently, developers may waste time hunting for bugs in the code when the actual problem lies at the infrastructure level. It is easy to lose track of cloud resources You cannot set up a physical server unnoticed; it must be purchased, installed, and connected. A virtual instance, however, appears in minutes. Initially intended for testing, it might later be used for integration, a temporary production copy, or an experiment. Over time, it becomes unclear which machines are truly necessary and which ones are simply running out of inertia. This is how an infrastructure "zoo" forms. Machines with names like `test`, `stage-old`, or `prod-copy` can exist for years without an owner or a clear purpose. Therefore, for every resource, it is essential to define its purpose, the person responsible for it, and its lifespan. Otherwise, the virtual infrastructure turns into a source of ever-increasing costs. **The cloud means renting, not the disappearance of risk** The cloud model allows you to quickly scale capacity, launch projects in different regions, and avoid building your own data center. However, the company becomes dependent on someone else's buildings, hardware, and operational procedures. As Kuznetsov notes: "The cloud isn't actually in the clouds. It resides in someone else's building, on someone else's disks, governed by someone else's rules—and paid for by your credit card subscription." When designing a system, you must account for potential regional outages, dependency on a specific provider, recovery procedures, and possible API limitations. Cost control is another distinct challenge. Cloud resources are easy to create because they don't feel like a major hardware purchase. Yet, an unused disk, a backup, or a forgotten virtual machine will continue to incur charges. **Why more servers can mean more problems** Adding a server is technically simple. Making multiple machines actually function as a unified system is much harder. You need to decide in advance: how requests are distributed; how a malfunctioning instance is detected; where user state is stored; how application versions are synchronized; where files and caches are located; how background tasks are launched. Without this, one server might run an old version, another might fail to see a local file, and multiple instances might execute the same task simultaneously. That is why Nikita Kuznetsov believes that true scaling is measured not by the number of servers, but by the consistency of their operation. **The same failure—different causes** The user sees only one result: the site is running slowly or won't open. However, the underlying causes can vary widely. When the disk is full, the application loses the ability to write data. When memory runs low, the system begins using swap space or terminating processes. Under high CPU load, requests slow down even if the disk is functioning normally. Therefore, automatically upgrading the service plan is pointless. Additional memory will not solve a logging issue, and a new server will not help with an application memory leak. Diagnosis should begin by identifying the specific resource that has become the bottleneck.