A few months ago, while discussing the architecture for a new client project, a junior engineer on the team asked, “Of course we’ll use Kubernetes, right?” At that moment, I thought to myself, “No, of course we won’t!” because my 20 years of experience have taught me that not every shiny technology is a panacea. Kubernetes is undoubtedly a powerful tool, but it’s not suitable for every project, every budget, or every team.
This question actually reflects a common misconception I encounter in the industry: the idea that every new project, regardless of its complexity, should start with the most popular and “coolest” technology. However, for me, architecture is about balancing a project’s real needs, the team’s capabilities, and the budget; one should not underestimate the power of simple solutions.
What Does Kubernetes Really Offer and When Is It Necessary?
Kubernetes is a revolutionary orchestration tool designed specifically for managing containers in large-scale and dynamic infrastructures. It offers many advantages such as automatic scaling, self-healing capabilities, declarative configuration, and efficient resource utilization. For example, when managing sudden spikes in orders during peak periods like Black Friday for a large Turkish e-commerce site, Kubernetes’ automatic scaling capability provided us with immense flexibility.
Similarly, when running hundreds of microservices on an internal banking platform, Kubernetes’ ability to centrally manage distributed systems and perform seamless updates was critical. However, even in such scenarios, you must have an expert team and a significant budget to manage the complexity and operational overhead that Kubernetes brings. These benefits typically become meaningful for projects with high traffic, multiple services, and constantly changing workloads.
When Should a Simpler Approach Be Preferred?
Despite all the advantages Kubernetes offers, for many projects, the added complexity and cost it brings can far outweigh the benefits gained. Especially for small to medium-sized projects, startups, or products in the MVP (Minimum Viable Product) stage, migrating to Kubernetes creates unnecessary operational overhead. When I first set up the backend for my side product, installing Kubernetes for a single FastAPI service and PostgreSQL took longer than writing the application itself.
In such cases, simpler and more direct solutions both accelerate development and reduce operational costs. For a production ERP, we calculated that the additional operational cost of Kubernetes for modular but relatively small services would be 3 times higher than running them on bare-metal or Docker Compose. A small team or insufficient experience with Kubernetes is also an important factor. For the backend of my Android spam application, a VPS and Nginx/Docker Compose were sufficient; I didn’t even consider Kubernetes.
Is Scalability Possible with Docker Compose and SystemD Without Sacrificing Simplicity?
Yes, absolutely. Not every project starts at the scale of a giant like Netflix or Google, and often, most never reach that scale. For many applications, tools like Docker Compose and SystemD offer sufficient scalability and reliability at initial and even medium scales. Docker Compose is excellent for easily managing containers, especially in development environments and single-server deployments.
I managed the first version of the data platform for my own site on a single VPS using Docker Compose and SystemD units. Service restarts, log monitoring, and resource limits (like cgroup memory.high) were seamlessly provided by SystemD. I used Nginx as a reverse proxy, Redis for caching, and PostgreSQL as the database. This simple setup worked flawlessly for years, and I only moved to more complex solutions when I truly needed them. This once again showed me that “sufficient” is often more valuable than “best.”
What Do I Consider When Making a Decision?
When designing a project’s architecture and deciding whether to use Kubernetes, I focus on a few key points:
- Team Competency: Does the team have the knowledge and experience to manage Kubernetes? Can they handle the learning curve and operational overhead?
- Project Growth Potential and Complexity: How many services will the application consist of? What is the expected traffic? Is dynamic scaling truly needed, or is periodic manual scaling sufficient?
- Budget and Time Constraints: Are the setup, maintenance, and cloud costs of a Kubernetes infrastructure compatible with the project’s budget? Is it more important to launch quickly, or to build the ideal architecture?
- Operational Overhead: Kubernetes is an operationally heavy system. Monitoring, logging, security patches, and updates require continuous effort. Are there resources to meet this burden?
Conclusion: Choosing the Right Tool for the Right Job
Kubernetes is undoubtedly an important part of modern software architectures and indispensable for many large-scale systems. However, this does not mean that every project needs it. As an architect, my job is to analyze the project’s real needs, without getting caught up in the hype, and to propose the most suitable, sustainable, and cost-effective solution. Sometimes this is a few services managed with Docker Compose on a single VPS, and sometimes it’s a full-fledged Kubernetes cluster.
The important thing is to understand the problem at hand and choose the right tool to solve that problem, not because it’s popular, but because it will actually work. Have you experienced similar dilemmas in your own projects? What were your “unnecessary complexity” situations, and how did you handle them?