Big tech promotes Kubernetes as a universal platform to run applications, selling you the expectation of not caring about the underlying operating system and infrastructure. When reading case studies, it is important to isolate the economic benefits of migration to Kubernetes from the change of the process, which usually implicitly happens with it. One notable ignored example is the introduction of self-service.
The under-resourced organization may not be willing to change their existing security policies to turn on self-service in existing virtualized environment. The “legacy” IT may also have a risk-minimization process with change review, and deployment only during the maintenance window. That’s why critical thinking, and hands-on knowledge in the field is required when reading about cost savings, especially if the report doesn’t mention long-term license cost of the platform. Understanding the details makes you more skeptical reading executive overviews.
It is crucial to understand interest of the promoter of “cloud native”, to which Kubernetes with service-oriented architecture propaganda belong. It is a lobby of cloud providers, software and hardware vendors. It could be very enlightening to hypothesize about the idealistic motivation behind such promotion as cynically as possible. To break the ice, let me start with these points:
- Commercial cloud providers are interested to sell you the “easy” solution for Kubernetes after imperfect DIY upgrades. Once there, it is hard to switch.
- Software vendors need to keep the base distribution bare to make room for paid add-ons, and long-term support options.
- Software vendors are interested to have your application broken-up into services, so that it is not practical to run it without the paid add-ons.
- Hardware vendors are motivated to sell expensive advanced NICs and switches, so that the Kubernetes overlay network can scale, be monitored and secured, particularly when application with confidential data is broken into many services.
- The Kubernetes lifecycle is short. Feature to support the first two points.
Containers are Linux, you still do have to manage it - install software updates, configs. But in marketing terms, it means you are managing your application, not the infrastructure. Hence the increase in business value.
What is the alternative?
Understand that, unless you sell Kubernetes, the most expensive is free. After giving alternatives an equal chance, hopefully, you’ll realize that you don’t need:
- Microservice architecture.
- Measuring the speed of application deployment.
- Pay premium for Kubernetes engineers, compared to standard Linux admins.
Then the proven and paid virtualization platforms, such as VMWare vSphere or similar alternatives, become an appealing option. As orchestrator isn't needed for soloistic applications.
