Whilst browsing through social media, and absorbing the plethora of information in the world of Cloud Native, we came across an interesting post. In this post, the author states "Kubernetes has single-handed set our industry back a decade. Companies are going to die because they spend more time “managing Kubernetes” than building a product."
The commentary on this post was swift, extensive, and quite polar. You either agreed with his comment or you 100% disagreed. Generally, technologists who have spent considerable time learning Kubernetes came down on the side of "it’s not that hard, once you know how". whereas everyone else echoed the author's sentiment in that the day 1 skills ramp, and day 2 operational overhead was often greater than the benefit gained.
As always, the ever present and always insightful, Kelsey Hightower weighed in, with "If you don't need Kubernetes don't use it." He followed on with all the reasons where Kubernetes is a great fit, and where it’s not, and how he keeps seeing, time and time again, people forcing Kubernetes into solutions where it just doesn’t belong.
Here at Portainer, we have some thoughts on this too...
Kubernetes is an amazing piece of technology. For sure if you have the problems that Kubernetes solves, it truly is a game changer. If you need auto-scaling, declarative deployments, a self-healing platform, and a common deployment API framework, regardless of where you are deploying, then Kubernetes is likely the best choice for your needs.
However, as an industry, where we keep going wrong, is thinking that it’s the ONLY solution to every single problem we have. Spoiler alert… it’s NOT.
Over the last 3 years, the way technology is introduced into organizations has changed. Whereas it used to be led by an enterprise architecture team, through a considered architectural design process with operational considerations, cost-benefit assessments, supportability research etc, now it’s transitioned. Since 2020 (and maybe even earlier for innovators), technology is generally championed and introduced by the engineering team, in a “build a bespoke solution using the latest technology” construct.
The consequences of this switch are two-fold.
Engineers enjoy the challenge that adopting new technology offers, which means they have a naturally high pain threshold for technology hurdles and complexity. They are also far more likely to turn a blind eye to the ongoing management of the technology, feeling it’s just part of their job to maintain it. Whilst this is true, there is no consideration given to the cost of this maintenance PRIOR to adopting it. Sometimes the ongoing cost far exceeds what most organizations would consider acceptable.
Secondly, engineers are in high demand, and this same engineering team that bought the technology into the company, went through the pain of getting it operational, and babysat it day in, day out, well those engineers get headhunted. Then what do you do? You had better understand the risks and have a rock-solid succession plan. The problem is, most IT leaders are not aware of the risks until they manifest into pain.
So back to the original poster's point: has Kubernetes set us back 10 years?
We don’t believe so, but we do believe that there are far too many engineering teams operating without consideration for the overall cost of ownership of technology, and that once the true costs are seen by IT management, there will be a number of hard questions being asked. After all, if the development engineering team is not shipping new software features fast enough because they are too busy managing Kubernetes, then that’s not good for business. Equally, if you must retain dozens of highly trained platform engineers, just to keep the Kubernetes lights on, then that’s not good for the bottom line.
Yes, there are other options out there. Something as simple as standalone Docker Hosts offer a lot of the benefits as Kubernetes, as does the (under-represented and often mocked) Docker Swarm, Hashicorp Nomad, or even cloud services like AWS ECS (which has been around for a very long time, because, well, it just works!), and Google CloudRun. Sure, those technologies are not as “cool” as Kubernetes, but sometimes what's cool, is having a highly cost-effective and operationally efficient infrastructure platform, not just the latest and greatest tech.
Portainer purposely remains container platform neutral, and it's why we support multiple runtimes and orchestrators. Which platform is appropriate varies, depending on the need. In summary, it's a case of choosing the right tool for the right job.
Try Portainer with 3 Nodes Free
If you're ready to get started with Portainer Business, 3 nodes free is a great place to begin. If you'd prefer to get in touch with us, we'd love to hear from you!
Neil
COMMENTS