By Maish Saidel-Keesing, IOD Expert
Does the following sound familiar to you?
The industry latches on to a new technology and everyone falls under its spell, a spell that makes them think this latest technology will solve any and all of the problems we have suffered from in the past.
The Evolution of Illusion
I experienced this phenomenon when our IT department first discovered blades. It would solve all our problems, everyone said, cabling, cooling, power, and real estate. And, at first, that seemed true; that is until it brought with it a whole new set of problems, such as insufficient bandwidth, network contention, and congestion.
Then came virtualization and VMware. Better utilization! Faster time to delivery! Consolidation! But… we soon was revealed a whole new set of problems, like insufficient disk throughput, greater blast radius when a single server goes down, not to mention VM sprawl and increased licensing costs.
And let’s not forget all the bets placed on public cloud being the great savior: “Infinite” scalability, even faster time to market, increased velocity, new technologies such as database as a service (ie. DynamoDB and Aurora), and infinite storage (such as S3). Until we started becoming aware of and impacted by billing fog, cloud sprawl, and security non-compliance.
IOD is a content creation and research company working with some of the top names in IT. Our philosophy is experts are not writers and writers are not experts, so we pair tech experts with experienced editors to produce high quality, deeply technical content. The author of this post is one of our top experts. You can be too! JOIN US.
Kubernetes Is Not the Solution to Your Problems
So, finally we get to the latest trend and the topic at hand: Kubernetes and the theories for why and how it will “solve all our problems.”
- Scaling: Kubernetes can scale pods on demand.
- Recovery: Kubernetes will auto restart pods if they fail.
- Monitoring: Kubernetes gives you rich metrics out of the box.
- Freedom to choose: Kubernetes can run on any cloud.
Are you working with Kubernetes? Do you want to blog about your experience and your tips? JOIN US.
The list doesn’t end there. So it’s not surprising that high level executives want their products on Kubernetes…. yesterday. It is why all the major cloud players (Google, Amazon, Microsoft) have a Kubernetes offering.
Why do I call them “theories?” Let me offer a brief explanation of why I think this solution is not as simple as it sounds.
When You Look More Closely
Taking an old Model T Ford (which by the way, was a work of art in its time) and plastering on a nice shiny bit of plastic and a sexy coat of paint so that the vehicle looks like a Maserati does not mean you own a Maserati. When you don’t look closely, you might mistake it for one, but it sure as hell won’t run like one.
Kubernetes is supposed to actually help you deploy your applications faster and with greater ease. Playing with the thought of stuffing one of your legacy applications into a container, but not taking into account the benefits of a new platform and deployment mechanism, is the same as stuffing a Model T Ford into a Maserati shell. It might help with restarting an application if a pod fails, but if the docker image you have is 40GB in size because you stuffed garbage in, it will not help. You will need enormous nodes to run all your containers, and the cost for these nodes will soar. Updating images will take forever, and traffic costs to move these into the cloud will not be cheap either.
I distinctly remember a case in which someone wanted to take a legacy application that was using an Oracle database and the application decided to jump on the container bandwagon and decided to deploy the whole thing in Kubernetes. Not only did it not add additional value, but it also exposed the company to a huge potential licensing issue due to the application owner’s lack of knowledge on how Oracle is licensed.
You will have all these new-fangled metrics to understand what your pod is doing, but to integrate this into your current monitoring infrastructure is not always a straightforward task. You might end up having two monitoring systems, one for your pods and another for everything else. Talk about a single pain of glass…. Of course you might kid yourself and say this arrangement is only temporary and everything will move to Kubernetes in the near future, but consider this: how many of you still have physical servers and VMs in your arsenal? And subsequently a monitoring solution for your physical SAP servers, another for your virtual infra, another for your cloud workloads? Things do not change overnight. They can and do change, but time is often not on your side. The longer you have to support multiple platforms multiple solutions, the more complicated it becomes and more you expose yourself to complexity.
And when the time comes you think you can consolidate more, you are probably right. But this also has a cost. It means you need to have a deep understanding of how your application works, its needs, how it can scale. All of these insights will be required to use Kubernetes in a way its meant to be used. Things hardly ever work out of the box, no matter what it might be.
On a weekly basis, IOD publishes original top tech content written by one of our experts. We hire and pay freelancers from all over the world to research and write about new technologies.
Right Tool for the Right Job
I have nothing against adopting Kubernetes. It’s an amazing platform. It has a great use case for certain kinds of workloads and is something that you should definitely look into implementing.
Things that are born in the cloud, designed to work as part of a microservices architecture, and have defined APIs and standards are a great fit for Kubernetes. Stateless microservices that can scale well in the cloud are also great candidates for living in a Kubernetes world.
But take care, Kubernetes is not a catch-all bucket. It will not be the silver bullet solution to all your problems, and it will certainly not be as simple to implement as it initially might seem. Choose your tools wisely, for the right reasons, and not just because it’s the tool all the cool kids are using.
