Six years ago: one mid-size project on real hardware
About six years ago we ran a mid-size project. It lived for a long time, relatively calmly, in KVM on a real server: rent a machine, install a hypervisor, ship features. Until the hardware started to fail — RAM, HDDs, weird symptoms you first dismiss as “temporary glitches”.
By the time we understood what was actually dying, the workday was already over. Management was offline — there was nobody left to approve a plan. Business does not wait for Monday morning: while tickets and “let’s schedule a call” drag on, the customer risks losing clients. That is no longer an infra incident; it is project rescue.
Decided — done
I had to decide alone. The lucky part: when I joined the project I had already wrapped services in Docker and built a proper docker-compose stack. Without that, a night migration would have meant installing runtimes by hand, hunting paths, and rediscovering “the other server had a different PHP”.
I know how to set up servers. Overnight we:
- stood up a new environment;
- deployed the compose stack;
- hooked up backups;
- switched traffic.
The only real pain was long file synchronization — gigabytes do not teleport, no matter how fast docker pull is. By morning the service was alive again. End users kept using the product. The customer mostly experienced it as a “confusing situation”, not as an engineering operation — which is fair: they care that it works, not that the host changed under the hood.
It helped that load was much lower then than it is now. At that volume a manual overnight cutover was still realistic.
From “saved on Docker” to Kubernetes rails
Over time the picture changed: more microservices, higher load, and a couple of compose hosts stopped being enough. We decided to move onto new rails — Kubernetes.
While approvals, prep, access, and topology choices ran their course, roughly two weeks passed. Yes — after a night of heroics, the formal K8s move took grown-up calendar days. But the foundation was already there: containers, clear services, and a habit of not treating a snowflake server as the only source of truth.
That was our entry into K8s: first a forced rescue jump onto Docker, then a deliberate orchestration migration — with two weeks of bureaucracy in between.
What practice showed
I did not pick wrong. Today we run a microservice architecture split by domains: more independent releases, clearer ownership, easier scaling of what actually burns. That night taught the main lesson early: if services are already containerized, you can save the business in hours. If not, you will be repairing disks while customers leave.
Checklist from that story
- Containerize before the crisis — not “someday after the next disk failure”.
- Compose/manifests and backups must come up on a clean machine without shamanism.
- Agree emergency decision rights with the business in advance — otherwise you still decide alone at night, just with more stress.
- K8s pays off when services and load are already “many”; saving the project can still be Docker if images exist.
- Domain-sliced microservices are the next level after “we finally left bare KVM”.
Takeaway
Our move to Kubernetes did not start with a slide deck. It started on an evening when KVM ran out of RAM and disks and management was already gone. Docker Compose and the ability to stand up a server overnight saved the customer’s clients. Then came two weeks of approvals and the jump to K8s. Looking at today’s domain-based microservice system under higher load, the bet paid off. Incidents do not ask your calendar — you prepare service packaging in advance.