So your team is suggesting you replatform to Kubernetes and you’re wondering if this is the right thing to do?
Kubernetes is an impressive technology that will allow you to solve many problems and future proof your applications. But there are some things you should know before you replatform.
Nolan Bushnell, the video game pioneer who invented Pong in the early 1970s, said on the subject of video games, “All the best games are easy to learn and difficult to master.” Bushnell’s Law or Nolan’s Law applies rather nicely to Kubernetes. It’s easy to spin up your first Kubernetes cluster thanks to GKE, EKS or AKS. It’s also relatively straightforward to get an instance running on your raspberry pi. However, while easy to start, it’s difficult to do well.
A proof of concept that you can “run your application on Kubernetes” is not truly reflective of your ability to “run your application on Kubernetes in production securely, scalably and reliably.”
If you are a lean, agile company and you’ve had your specialist run a Kubernetes POC, they’ll be able to show you that the app can run on Kubernetes - it connects and everything is fine. The challenge is that a POC isn’t reflective of a true environment. The app isn’t run under production load, it isn’t necessarily stress tested to scale on the right “things.” You and your team won’t know yet how it ties into the development workload or CI/CD pipelines or what it’s going to take to replace or upgrade a cluster in place. That’s just the operational side of it.
On the other side, do you know if you’re running the right software? Have you configured Kubernetes correctly? Do you know if the tools you put in (that were barely functional in the POC) are actually what you’re going to use in production? Do you have the knowledge and experience to know that using a particular add-on is the right choice for you going forward? And if you proceed with that add-on, what would it take to switch away from that choice in the future as your infrastructure evolves? How will your team know that their POC platform is “future-proof”?
There is a really big difference between making Kubernetes work and making it production ready. And there’s a bigger skills gap than many other technologies because of the complication due to so many moving pieces.
I’ve met many teams wanting to adopt Kubernetes. A lot of the time, these teams think they can get away migrating without doing anything to the application. That’s simply not true - a lift and shift is highly unlikely unless you’ve already built your application using the 12-factor methodology. Even then, while you can move your application into Kubernetes, it might fight you.
Instead when you move to Kubernetes, you’ll probably be running parallel systems. Your costs are most likely going to go up for a period of time as you run two systems and migrate over.
The other thing about Kubernetes and cost is that it might save you money, but it might not depending on how you deploy it. You need to weigh the many benefits of the platform, cost included, when you consider replatforming.
You are not going to roll out Kubernetes in a month. It will take time to learn, roll out, configure and optimize Kubernetes. There is no prescribed timeframe for when you should be seeing the benefits. You will be optimizing and tweaking your clusters to make improvements for at least the first year as you find new features and new ways of doing things. So when you think you’re done, you are not!
In fact, Kubernetes is growing fast, adding new features quarterly and you will always have the opportunity to optimize. The goal, however, is for you to be able to make small changes with minimal effort that make a big impact.
If you have an older style architecture that’s running well, you don’t have new revenue targets, scalability goals or cost optimization requirements, then don’t replatform. After all, if it ain’t broke, don’t fix it.
That said, if it is broken, and you know you want to fix it, then look at what Kubernetes can do for you. Kubernetes is great and makes sense for many types of applications and workloads. Kubernetes can help you:
Avoid lock-in, fully open source: Kubernetes can be used without having to re-architect your container orchestration strategy. The software is fully open source and can be redeployed without incurring traditional software licensing fees.
High availability and scalability: Kubernetes includes built-in high availability features that help with load balancing and self-healing. Autoscaling ensures your workloads always have the right amount of compute available.
Support standards: Kubernetes is an active community with a breadth of modular, open source extensions that have the backing of major companies and institutions like the CNCF. Several thousand developers and many large corporations contribute to Kubernetes, making it the platform of choice for modern software infrastructure.
Deploy a long term solution: Given the rise of Kubernetes, many cloud providers are shifting their R&D focus to expanding their managed Kubernetes services over legacy options. Consider Kubernetes as you develop your long term IT strategy.
And while nothing in Kubernetes is free because the barrier of entry is high, and nothing comes out of the box (you will always add new tools and different configurations), Kubernetes provides functionality in a way that requires configuration changes vs. engineering changes.
You can install a program, write a YAML file and your cluster will automatically scale. You do not need to write a sensor and a scaling loop - you do not need to write any code. Kubernetes has a lot of functionality for which you do not need to write anything new because you are writing configuration not code.
To revisit your older platform, we can guarantee that underlying it, there is a lot of bespoke code. However it’s hugely complex, hard to maintain and takes a lot of internal domain/tribal knowledge. Kubernetes exposes that tribal knowledge and turns that engineering work into configuration for your team.
Kubernetes changes the specialty and builds the larger community around the same scalable, declarative, API-driven technology. The benefit is that your team now can understand a common configuration.
For example, if you have a new employee, that person can look through your configurations to see you are using cluster autoscaler, a public open source project with lots of collaborators. The team member can google it to compare your company's configuration against the documentation and ask questions on the public Slack channel.
Kubernetes helps share knowledge, better and faster and creates a greater overall solution so that you need fewer internal bespoke solutions around Kubernetes itself.
Because Kubernetes is so popular with such a large community, when you replatform, you are future proofing your platform. It helps you avoid situations where only one or two team members have domain knowledge leaving you in a precarious position should that team member leave the company.
I’m a huge fan of Kubernetes, having used it since its inception and helped many companies replatform to it. Everything I’ve mentioned must be considered when you evaluate making the move. If you are uncertain about what to do, that’s where a Kubernetes managed service can help. The team at Fairwinds lives and breathes Kubernetes and the open source technologies needed to make it work. If you want some expert Kubernetes advice, get in touch.
