Here's a contentious topic that is sure to raise a few eyebrows....
In the current age of containerization, the need (or want) to deliver a hyper-flexible Kubernetes platform with rich functionality has seemingly caused us to overlook the benefits of a simple and intuitive, easy to understand/use, easy to triage, platform. We seem to have become obsessed by Kubernetes for the sake of Kubernetes without any consideration for how it will be used by our internal users, and supported by our internal Ops teams later.
Let me explain.
First up, ease of use..
Development teams want to use Kubernetes, right? Wrong, well kind of....
What development teams (which encompasses Devs and DevOps) want is a platform that allows them to deploy and manage their applications in a repeatable and consistent, declarative manner. They want to be able to easily enable things like auto-scaling, define the use of load balancing and reverse proxies, add monitoring and logging capability, and safely persist data in their application; and they want to be able to do all of this themselves through a simple developer experience focussed toolset, without having to open JIRA or ServiceNow tickets and waiting (potentially hours or even days) for someone to do it for them.
Development teams have latched onto the fact that Kubernetes (and Docker for more junior teams) gives them this capability, and so development teams are often the driving force behind the adoption of Kubernetes. That doesn't mean for one second that they want to take on the operational overhead of running a Kubernetes platform, nor do they want to exclusively use the raw Kubernetes CLI, far from it, they want its benefits, but none of its operational complexity. This is especially true when you have development teams that do not include "full stack" developers, or if you do not have the support of DevOps professionals. In this case, the development team genuinely don't want to engage with raw Kubernetes at all, but for sure they still want the benefits it brings. In this case the development team would be looking to the Ops team to provide a radically simple "Heroku" or "cPanel" style interface for Kubernetes.
When development teams are pushing for Kubernetes, its because the legacy way of deploying applications inside your organisation is not fast/flexible enough for them, and so they see Kubernetes as an enabler. The responsibility of deploying and operating the Kubernetes platform sits squarely with your internal operations/engineering team. But as an Operations team, what are you expected to provide? Simple, a Kubernetes platform that is reliable, performant, maintained, and delivers a rich developer UX to your internal users, allowing them to self-serve in a way that is safe and secure. What that doesnt allow you to do is break the real reason devs want Kubernetes in the first place, so make sure you keep self-service front of mind. Development teams should be able to deploy any applications they like; they should be able to choose how they want to expose their applications to the world (within reason); and they should be able to do this in a manner of their choosing, either using CLI, API, or a self-service UI. Remember, your job as Ops/Engineering is to enable your users, not constrain them. Sure it is your responsibility to give a reliable SLA to your users, but a 99.9% SLA is useless if its impossible to use.
Secondly, Operations..
As described above, Operations / Engineering are the team responsible for deploying and managing the Kubernetes Platform. But what liberties does that give to you? Should you have the freedom to build something that only one person can support? Surely not. You need to build a platform that is flexible and extendable, but more importantly, you need to build something that is supportable by as many people inside your engineering team as possible. If this means building something slightly less "cool" then thats what needs to happen. Don't fall into the trap of building something using the latest technologies just because they are trending on reddit/twitter/medium. Build something using the technology you can support.
Far too often we see Kubernetes environments built by individuals that are wanting "the best Kubernetes platform ever seen", but in doing so, create a massive risk for the organization, as the complexity makes support a nightmare. Even worse, we see engineering teams relying solely on tools that bootstrap a self-hosted Kubernetes cluster in minutes. That same team rarely have the knowledge of HOW that platform was built by the tooling, and so when (not if) it fails, they are completely in the dark on how to triage. Don't be fooled by the "bootstrap" tools, they don't help you one bit when things fail. If your team do not posses the required knowledge to deploy a Kubernetes cluster following Kelsey Hightower's "Kubernetes the hard way" instructions, and if they don't know how to triage etc, KubeDNS, etc, then I strongly recommend adopting Kubernetes managed offerings from supported providers rather than take the risk of an unsupportable self-hosted Kubernetes platform (or one you need to pay $$$ to a 3rd party to support).
As a word of advice, I always recommend putting your Kubernetes platform through the 3am test.. "Assume it's 3am, the platform has gone offline, how many staff do you have in your organization that can start a triage process and identify the cause of the issue?" If your answer is "one person" you are almost certainly in trouble. Equally, even if you have a team of people who can jump in and start to triage, it can still take them hours to get to a fix if your environment is even slightly complex.
In IT Operations, there is a holy trinity of metrics; Mean Time to Identify (MTTI), Mean Time to Know (MTTK) and Mean Time to Fix (MTTF). This essentially translates to "how quickly do you know an issue is occurring", "how long will it take to figure out what's wrong and what to do about it", and "how long will it take to fix it". Combined these three are known as "Mean time to Resolve" (MTTR).
If your Kubernetes Platform will cause you to have an extended MTTR due to an inability to alert, rapidly triage, root cause, and remedy, then you are making a big mistake.
So, from an Operations perspective, keep ongoing supportablilty front-of-mind... unless everyone in your team can support the platform, is it really a safe bet relying on a subset of engineers?
So how does Portainer address both of these?
The answer is with simplicity. Simplicity of the platform, and simplicity of the tooling. Sure, it's possible to build a Container/Kubernetes Management Platform from a multitude of the 1051!!! products that make up the CNCF landscape, but in doing so, you are forcing yourself to remain competent in all of these tools. Good luck with that.
Do you really want your team to have to learn how to deploy, support. patch, upgrade dozens of different tools, just to deliver a Kubernetes platform? Can you imagine the research and version compatibility matrix validation needed before upgrading ANY ONE of these components? I think not.
To keep things simple and supportable (KISS), we built Portainer to provide a single tool that "just works" out of the box... We deliberately made it super simple to deploy/configure, simple to use, and simple to support.. With Portainer, there is no need to adopt other tools (but you can, as we don't lock you in!), Portainer has you covered.
Your Ops/Engineering team can deploy Portainer and use it to onboard clusters from ANY Kubernetes (or for that matter, Docker) provider, Cloud or on-premise, they can configure centralised authentication for the Clusters, they can instantly configure RBAC for all clusters, they can define resource quotas and limits, pre-configure ingress controllers to simplify the developer experience, enable metrics for simplified performance monitoring, and all of this can be done without needing any advanced Kubernetes knowledge, which combined with Cloud provide KaaS solutions is a great no-risk enabler.
Even better, whilst Portainer really helps your Ops/Engineering teams, it has an equally impressive developer UX, allowing developers with a wide array of background experience to get started with Docker, Kubernetes, and even self-serve GitOps TODAY. Your developers don't need to know how to write YAML manifests, they don't need to learn Kubernetes lingo, heck, they don't even need to know or care that the platform is Kubernetes; all your developers need to know is that they have a rich platform within which they can deploy their applications in a repeatable and consistent, declarative manner.
Portainer is the only tool you need, from Devs, DevOps, GitOps, Platform Management, Triage. We you got you covered.
Give Portainer a try today, experience simplified Kubernetes Operations today.
COMMENTS