4 Different Approaches for Kubernetes in the Enterprise
The world of Kubernetes at the moment is like a giant public swimming pool where everyone is learning how to swim at the same time. While a lot of people have already got the hang of things, like the chosen few at Google and Netflix among others, the majority are still wading in the shallows, figuring out how to breathe. The good thing about swimming is that you can do it any way you like, freestyle, backstroke or even a dog paddle, there aren’t any hard and fast rules as long as you keep your head above water and manage not to drown.
Similarly, with the Kubernetes open source container orchestration engine, there are multiple ways of getting things done and it’s a “whatever works for you” policy that’s usually followed. That being said, we’re going to try and bring some order into this somewhat chaotic system, by categorizing Kubernetes solutions into four subcategories and framing some questions you can ask yourself to help you choose between them. In addition to the more obvious benefits and limitations that come with each choice, we’re also going to look at how ultimately your own requirements should dictate what your ideal Kubernetes solution is.
1. To PaaS or Not to PaaS
PaaS solutions have been around for a while and are probably the most tried and true subcategory that we’re going to be looking at. The most prominent examples are Pivotal Container Service (PKS) and Red Hat’s OpenShift. If your priority is ease-of-use and customizability is not something you’ll need now or in the near future, a PaaS solution is a pretty safe bet. This is because all that’s being done here is code interpretation, followed by dependency installations, containerization, and voilà, your product is deployed. Just don’t expect to be able to do anything “fancy” like installing custom software on an instance.
Organizations that use a PaaS solution generally require their entire Dev team to operate on the same platform. While this approach is good for consistency across the board, it leads to bottlenecks in large organizations. It limits what developers can do with their Kubernetes installation. Importantly, it restricts how software is developed, putting restrictions at various points and forcing a culture of “workarounds.” If given a choice between opinionated and open tools — a developer will almost always choose open.
A good question to ask yourself before going this route is whether you’re willing to give up complete infrastructural control to your PaaS provider. A good example of an organization that went this route is SnapChat, which is now pretty much joined at the hip with Google App Engine. While a PaaS solution is great if you want to be able to solely focus on your apps and not worry about infrastructure, you lose out on fine-grained customizability in favor of whatever your provider decides is best for you. In short, the PaaS vs non-PaaS decision should be made based on the level of control you need.
2. The Cloud: Convenient and Easy
Moving on to our next subcategory: cloud-hosted Kubernetes. The main reason people choose this category is convenience. At least that’s the only conceivable reason someone would willfully subject themselves to vendor lock-ins, which is something most developers go out of their way to avoid. What this means is that though you can’t deny the time and money saved by just letting your cloud provider manage Kubernetes for you, your choices are again restricted to what your provider chooses for you. So if there’s a specific version of Kubernetes you’d rather use, for example, tough luck.
Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE) are services that aim to make it really easy to get started, especially for organizations that have not yet developed internal Kubernetes expertise. Before moving to any of these providers, ask yourself if you’re able (or willing) to give up control (e.g. configuration of parameters) to your provider. If you believe you’ll need the ability to integrate with other enterprise solutions and/or run in a hybrid/multi-cloud setup, it’s likely not the right solution for you. If that’s not the case, it’s probably the easiest and most cost-effective alternative — so go for it! Cloud vendors today are taking steps to integrate across the board and especially with the most popular open source tools like Istio, and Prometheus.
3. Managing Kubernetes for You
This brings us to our next category: managed Kubernetes. Platform9 is likely the most prominent example here. These vendors offer managed Kubernetes clusters in their own data center, on-premise or in public clouds with 24/7 management and enterprise support. They allow you to deploy to multiple public cloud platforms, and in some cases to serverless platforms as well. Having started delivering Kubernetes services even before the big cloud vendors, these managed service providers have evolved along with the Kubernetes ecosystem.
Similar to cloud-hosted, this alternative is great for organizations that are still building their Kubernetes expertise. They offer remote management of a Kubernetes cluster which greatly simplifies management. Their key promise is high availability with a 99.9% SLA, and the reason they can offer this promise is that they “manage everything.” If you like a hands-off approach, this works great, but if you want to manage key pieces of the toolchain, you’ll need to check with the provider before committing to their platform.
4. Native Kubernetes Platforms: Dev vs. Ops
This last category is where it gets interesting. Built around Kubernetes, they are the closest thing to pure open-source Kubernetes. Integrating with multiple cloud providers, they allow users to manage all their Kubernetes clusters across multiple environments from one control panel. In short, a single Kubernetes management layer for all your environments. Where they tend to differ, is in their main user focus: developer vs. operations focus. Now, while the former is without a doubt geared toward user-friendliness and ease of use, it’s the latter you want if you really need operational control to take advantage of Kubernetes’ more advanced capabilities.
Rancher is a good example of a dev-centric Kubernetes platform and includes a catalog of application templates that make it pretty straightforward to deploy complex stacks. It also lets you use a catalog of Helm charts when you need to repeatedly deploy applications. They are open sourced and getting a ton of traction in the dev community.
Operational teams, on the other hand, have different requirements for successful Kubernetes deployments — it’s all about reliability and security. RBAC, default centralized logging and monitoring are just a few asks. This is where enterprise-focused Kubernetes platforms like Kublr stand out. The real challenge for large enterprises is reliable and secure production clusters. Centralized multicluster management with RBAC and the ability to fully customize clusters (and thus giving enterprises full control over their clusters) are some of the capabilities they offer. These platforms are clearly more relevant to companies with large deployments used by multiple teams across heterogeneous environments than companies managing only a few clusters in one cloud.
In conclusion, which solution you choose will depend on how much control you want, how much ease of use you’d like, how flexible you’d like the solution to be, and how far down the line your organization is in terms of cloud adoption. While selecting a solution may seem overwhelming, start by evaluating the category that fits your company’s needs first. Then, continue with the options within that category. Clearly, there is something for everyone’s needs.
The author of this post has done consulting work with Rancher and Kublr.
