You can find many great resources for getting smarter about Kubernetes out there. (Ahem, we’ve written a few ourselves.)
That’s good news for IT teams and professionals looking to boost their knowledge and consider how Kubernetes might solve problems in their organization. The excited chatter about Kubernetes has gotten so loud, however, that it can become difficult to make sense of it all. Moreover, it can be challenging to sort the actual business and technical benefits from the sales pitches.
[ Need to help others understand Kubernetes? Check out our related article, How to explain Kubernetes in plain English. ]
So we asked several IT leaders and Kubernetes users to share some advice that goes against the grain.
If you always take conventional wisdom – or straight-up hype – at face value, you’re bound to be disappointed at some point. So consider these bits of contrarian thinking as another important dimension of your Kubernetes learning.
1. Don’t treat Kubernetes as a silver bullet
Interest in Kubernetes is astronomical for good reason: It’s a powerful tool when properly used. But if you treat Kubernetes as a cure-all for anything and everything that ails your applications and infrastructure, expect new challenges ahead.
“Kubernetes is not a silver bullet for all solutions,” Raghu Kishore Vempati, principal systems engineer at Aricent. “Understand and use it carefully.”
Indeed, the spotlight on Kubernetes has grown so bright as to suggest that it’s some kind of IT sorcery: Just put and everything in containers, deploy ’em to production, and let Kubernetes handle the rest while you plan your next vacation.
Even if you’re more realistic about it, it may be tempting to assume Kubernetes will automatically solve existing issues with, say, your application design. It won’t. (Even Kubernetes’ original co-creators agree with this.) Focus on what it’s good at rather than trying to use it as a blanket solution.
“Containers and Kubernetes provide an opportunity to create solutions that previously would have required a lot of effort and code plumbing with higher costs,” Vempati says. “While Kubernetes can provide orchestration, it doesn’t solve any of the inherent design problems or limitations of the applications hosted on it. In short, application overheads cannot be addressed using Kubernetes.”
[ Related read: Getting started with Kubernetes: 5 misunderstandings, explained. ]
2. You don’t have to immediately refactor everything for microservices
Microservices and containers pair well together, so it’s reasonable to assume that Kubernetes and containerized microservices are a good match, too.
“Kubernetes is ideal for new and refactored applications that don’t carry the baggage – and requirements – of traditional and monolithic applications,” says Ranga Rajagopalan, CTO and cofounder at Avi Networks.
Just don’t mistake the ideal scenario as the only scenario.
“The conventional wisdom is to refactor or rewrite your monoliths before deploying them within a Kubernetes environment,” Rajagopalan says. “However, this can be a massive undertaking that risks putting your team in analysis paralysis.”
Rajagopalan notes that you can indeed run a monolith in a container and then begin to incrementally break off pieces of the application as microservices, rather than trying to do everything at once.
“This can jumpstart your modernization efforts and deliver value well before the application has been completely refactored,” Rajagopalan says. “You don’t have to be a purist about microservices.”
Vempati concurs, noting that there might be some legacy applications that you never refactor because the costs outweigh the benefits.
3. Account for feature differences on public clouds
One of the overarching appeals of containers is greater portability among environments, especially as multi-cloud and hybrid cloud environments proliferate. Indeed, Vempati notes that it’s a common scenario for a team to deploy Kubernetes clusters on public cloud platforms. But you can’t always assume "vendor-neutral" as a default.
“The native Kubernetes capabilities on public clouds differ. It is important to understand the features and workflows carefully,” Vempati advises. “All the key public cloud service providers provide native Kubernetes cluster services. While these are much similar, there will be certain features that are different. When designing the solution with an aim to keep it vendor-neutral, while still choosing one of the vendors, such differences must be taken into account.”
Vempati shares as an example that one public cloud provider will assign public (or external) IPs to nodes when a cluster is created with its Kubernetes service, while another does not. “So if there is any dynamic behavior of the apps to infer/use external IP, it may work with [one platform] but not on [another],” Vempati says.
