The main reason why every CIO should consider Kubernetes

Imagine you need to deploy and maintain roughly ten services, including your application and several AWS-managed components. Even with a strong and experienced engineering team, coordinating that many moving parts manually becomes harder over time.

As systems grow, complexity grows with them. Small differences between environments appear. Configuration details evolve. Deployment steps multiply. Over time, even disciplined teams can face inconsistencies between staging and production or unexpected behavior during releases.

Manual processes naturally introduce variation. Variation increases the likelihood of incidents.

Without orchestration, engineers babysit servers. With Kubernetes, the system manages itself. It keeps applications running, automatically replaces failed components, and rolls out updates without disrupting users. It reacts to traffic spikes in seconds and reduces unused capacity just as quickly. Engineers do not need to wake up and intervene every time something crashes.

When we combine Kubernetes with tools like Helm and a proper CI/CD pipeline, deployments become repeatable and auditable. Every change leaves a trace. Every release can be rolled back cleanly. Instead of hoping nothing breaks, we create a system that expects failure and handles it.

Will all the services you use be run inside Kubernetes?

No. And they shouldn’t.

Kubernetes works best for application services. To be more specific, the parts of your system that process requests, respond to users, and can safely restart if something goes wrong.

However, not every component behaves that way.

Your database and storage hold your company’s memory. They store transactions, files, and historical data. If they restart incorrectly or lose data, we don’t just lose a request — we lose business information.

For that reason, we should not automatically deploy everything to Kubernetes just because we use it.

We recommend separating storage and the database. For example, you can use Hetzner block storage for persistent data and run the database on a dedicated VM. You will avoid forcing stateful systems into a model that favors stateless workloads.

We recommend running the database on a dedicated virtual machine and attaching persistent block storage, such as Hetzner's.

That approach gives us something very simple and very important: clarity.

The application layer lives inside Kubernetes. It scales, restarts, and updates automatically. The data layer lives outside Kubernetes. It focuses on stability, backups, and controlled recovery. If an application crashes, Kubernetes restores it in seconds.

If the database server crashes, we restore the machine and reattach the storage. The application continues running but waits for the data layer to respond.

This separation reduces architectural complexity and avoids unnecessary risk at your current scale.

At the same time, we place most operational services in the cluster because Kubernetes manages them more reliably than manual VM setups.

The real killer feature here is self-healing. When an application crashes, Kubernetes automatically restarts it. When a container fails, Kubernetes replaces it. That mechanism reduces downtime for application-layer issues.

What services benefit most from Kubernetes?

Kubernetes delivers the most value where automation, restartability, and scaling matter.

Firstly, the application layer clearly belongs inside the cluster. These services process requests, handle business logic, and must remain available even when individual components fail. Kubernetes continuously monitors them, automatically restarts them, and scales them as traffic increases.

Beyond the application itself, observability tools benefit significantly from running inside the cluster. We recommend using Prometheus for collecting metrics, Grafana for dashboards, and Loki for log aggregation. These systems rely on consistent deployment and health monitoring, which Kubernetes handles very well.

Operational dependencies also fit naturally inside the cluster. Services such as RabbitMQ, Redis, and Memcached benefit from Kubernetes’ scheduling logic, health checks, and automatic restarts. If one instance fails, Kubernetes replaces it quickly and keeps the system stable.

But hey, remember that, not everything needs to live inside the cluster.

For content delivery, we recommend Cloudflare. Their free plan covers early-stage needs and simplifies edge caching and traffic routing without adding operational burden.

For object storage, you can continue using Amazon S3 or migrate to Hetzner block storage, depending on your cost structure and long-term infrastructure strategy. Both options work; the choice depends on economics and vendor preference.

The guiding principle is simple: We run services inside Kubernetes when automation, scaling, and self-healing increase stability.

We keep services external when managed platforms already solve the problem efficiently. Kubernetes should simplify your architecture — not absorb everything by default.

Understanding the limits of Kubernetes

The database sits outside the cluster on a single VM with attached block storage. That decision simplifies management and reduces Kubernetes complexity, but it introduces a clear trade-off.

If the database VM goes down at 3 a.m., Kubernetes will continue running the application. The application servers will stay alive, but they will not read or write data. From a user perspective, anything that depends on the database will fail.

Kubernetes cannot restart a database that lives outside the cluster. We must restore the VM or recreate it. Once the VM boots and mounts its storage, we can bring the database back online using backups and persistent storage.

In the case of a simple server crash without data corruption, recovery time equals server boot time plus database startup time. That typically means a few minutes.

If data corruption occurs, recovery time increases significantly. We need to restore from backups. That process can take hours, depending on database size and backup strategy.

If we want stronger guarantees, we can introduce a primary–replica setup. A replica reduces downtime during maintenance and provides failover options. However, replication increases operational complexity. Every architectural decision shifts cost and responsibility elsewhere.

Kubernetes resiliency (RTO/RPO) in the cluster

When we talk about resiliency in a Kubernetes setup, we need to separate two very different questions:

1. How quickly can the system come back online? 
2. How much data can we afford to lose?

The first one is about RTO (Recovery Time Objective). Kubernetes helps here by automatically restarting application components and keeping the compute layer alive. Engineers do not need to redeploy everything manually.

If the failure involves only infrastructure and no corrupted data, the Recovery Time Objective (RTO) is likely within minutes. The server boots, MySQL starts, and the application reconnects.

The second, Recovery Point Objective (RPO), depends entirely on backup frequency. If we back up continuously or replicate in near-real time, we lose almost no data. If we rely on periodic backups, we risk losing whatever happened since the last snapshot.

If the failure affects the data layer itself, recovery time can stretch into hours. No orchestration platform eliminates that reality. Only redundancy and disciplined backup strategies reduce that exposure.

Why you should consider Kubernetes?

Kubernetes does not eliminate risk. No technology does. What Kubernetes does is change the nature of that risk. It moves you away from unpredictable operational mistakes and toward structured, manageable infrastructure.

Without Kubernetes, engineers must manually coordinate ten services across multiple environments. Each deployment introduces small differences. Each maintenance window increases the risk of human error. Over time, complexity accumulates quietly until it surfaces as an incident.

With Kubernetes, you replace ad-hoc coordination with enforced consistency. The system standardizes deployments, automates application-layer recovery, and reduces the number of routine decisions engineers must make under pressure.

If you want to assess whether this model fits your specific situation, we would be happy to review your architecture and discuss it in detail.