Building a tool for Kubernetes developers means solving a bunch of problems (e.g., multiple clusters, kubeconfigs, secrets, kubectl functionality, how to represent the hierarchy of abstractions inside a cluster, etc.) and creating a user experience that promotes speed. A good dashboard lets you select from among multiple clusters and:

See the states of everything and work with whatever you’re permissioned to access (this translates into zero need for IT operators to centrally administer dashboard-specific permissions).
Drill into abstractions—see what’s running and what’s dependent on what.
Identify what’s relevant to your work right now—i.e., let you constrain context.
Accelerate your work: navigate around local directories, control local applications (e.g., Git, VSCode, etc.) from the command line, view/edit/reapply abstractions, grab container logs, log into container shells, etc.
Browse and apply Helm charts, etc.
And maybe also maintain several contextualized work-sessions in parallel (different projects, different clusters, etc.), so you never need to spend cycles finding your place.
What’s interesting is that solving these problems well means you’ve already solved some important additional problems. You know how to create and maintain contexts in which work can happen efficiently. And in so doing, you’ve mastered important aspects of the integration puzzle that turns a ‘context’ into a ‘workflow.’

Specifically, you’ve mastered the terminal, which is the interface most devs use to coordinate local (and remote) applications, CLIs, and the artifacts they create and consume. You’ve mastered the Kubernetes API, and through that, the substrate of tools (e.g., Helm) used to configure, deploy and lifecycle-manage applications, components and services, including the integrated, non-Kubernetes-native solutions on which you depend to support your bespoke applications (such as [third-party] Ingress or Message Queue or Metrics or Database, etc.).

This given, a strong Kubernetes dashboard can, in principle, become a full-fledged Kubernetes IDE by creating some relatively simple integration ‘glue’: code that lets contributors build ‘extensions’ in a simple, secure, standardized way. A way that lets extensions automate what you, yourself could do manually (assuming you knew how).

For a specific kind of app, say an ingress controller, this might involve:

Inheriting your permissions (or, in some cases, organizing and remembering separate permissions for certain services).
Discovering relevant applications/services (i.e., ingress controller components, sidecars, manager workloads, operators, etc.) in the cluster you’re now looking at.
Dynamically representing the state of those ingress components within the ‘dashboard’ webUI.
Extending the webUI and/or dashboard configuration dialog(s) with bespoke sections that simplify ingress configuration.
Plus other features, such as automatically extracting parts of, or the whole hierarchy of ingress objects so you can store these files locally and place them in version control.
It’s easy to imagine extending this fundamentally-simple (in principle; obviously, it can be tricky to implement in practice) model to let extensions drive all sorts of components and provide a wide range of valuable services to developers. Assuming your dashboard already knows how to import and apply Helm charts; it should be simple to create the extension equivalent of an IaaS database-as-a-service (DBaaS) framework, where the extension maintains a perpetually-updated list of trusted sources for 15 major databases and provides basic configuration options and one-click installation for each type, bookmarking access to product-specific configuration tools for further work.

Such an arrangement around an extensible dashboard could benefit the entire community, including:

Developers: Who are free to install (or build) open source extensions for their favorite tools, thus creating flexible, highly-customizable, and efficient working environments within the dashboard. (Working environments that can, in principle, be packaged and shared among, for example, developers collaborating on a given project).

Operators: Who are also free to create and share collections of extensions, so able to ‘soft-standardize’ working environments without making developers feel as though they’re being dictated to. Operators can, meanwhile, closely-manage RBAC permissions on any cluster, ensuring that dashboard+extension users are never able to go ‘out of bounds.’

CNCF ecosystem participants: Building extensions to manage components under inherited RBAC permissions from within a dashboard environment that supports terminal and Kubernetes API/kubectl sessions, and that also provides sophisticated, widget-rich weblike functionality for visualization and interaction, is easier than maintaining many integrations to specific development tools. It’s also potentially far more useful to developers, who can adopt subsystem/tool-specific extensions as part of their evolving workflows—improving quality of life as opposed to learning yet another UI, CLI, or REST API. Making tools and components more consumable by developers (and operators) can be an important selling proposition in an ecosystem dominated by YAML and crude interaction principles (e.g., edit YAML, change YAML, reapply YAML, rinse, repeat).

The critical factor, of course, is whether such an extensible dashboard can reach sufficient critical mass to become the preferred way of packaging functionality and accelerating development—completing its evolution into an ‘IDE,’ and perhaps even becoming a sort of framework.

Here, it feels to me as though what’s most important is that the dashboard sits where a certain subset of Kubernetes coders and operators do most of their work, which is in the tight, iterative loop between the desktop and the cluster. This is quite different from classic IDEs, built around code editors. Obviously, the latter are still vitally important when work is focused on new application coding or on maintaining mature application code, particularly where back-end processes are fully automated with CI/CD.

But as most Kubernetes-centric developers are coming to realize, there tend to be big gaps (and latencies) in this model that only a dashboard-centric, context-aware, extensible IDE is ‘fast enough’ to fill. Once the containers are built, people need tools purpose-designed for iteratively tweaking the abstractions that put those containers to work. Once those YAML files are tested and made part of application lifecycle and/or infra-as-code repositories, and when the CI/CD has been extended to apply them automatically (in our ideal universe), there’s now forensics, break/fix and other new tasks that need to happen on that bleeding edge of dev-to-cluster iteration.

It may seem as if these days everybody is using Kubernetes. There’s a lot of hype. But the truth is, most companies are still using virtual machines and on-premises data centers, and that’s quite fine. Before you go and adopt Kubernetes, I want to share with you some misconceptions about Kubernetes and help you understand those problems won’t be magically solved by adopting it.

Will Kubernetes Reduce Your Costs?
One of the most popular reasons to adopt Kubernetes is to reduce costs. After all, if you can magically reschedule all your workloads in a much more efficient way, won’t your cloud bill suddenly go down?

First things first—you have to understand microservices are very inefficient by nature. Every time you hand off work across the (virtual) network, you pay for serialization and deserialization costs, memory copies (which traditionally both the kernel and the runtime have been working hard to avoid) and potentially various middlewares such as service-meshes and security software.

This pattern does not offer efficiency—it offers scalability, which is quite a different beast. And it’s obviously only relevant once you pass a certain scale. If you can run much of your workload on as many cores as fit inside a single computer, you are not at that scale yet!

The truth is that Kubernetes is quite good at packing lots and lots of light container workloads into fewer nodes. But, if your workload is containerized by nature, you are probably already using Kubernetes (or Docker Swarm, or Mesos, for that matter). On the other hand, if your workload is not heavily containerized, you have little to gain by moving to Kubernetes.

Will Kubernetes Be Transparent for Your Developers?
If your domain lies in site reliability engineering or DevOps, you might be thinking that adopting Kubernetes is in your realm and has little or nothing to do with your software engineering team. The truth is quite different. While running workloads on Kubernetes won’t require every single member of the team to understand the intricacies of Kubernetes ingresses, they are definitely going to have to know their way around.

Whether it’s spinning up a development environment (local or in the cloud), running basic `kubectl` commands on it or just being able to have a bird’s eye view of the architecture, your developers are going to be a part of this journey. You better have them onboard.

Will Kubernetes Help Break Down Your Monolith?
Many companies are struggling with an out-of-date monolith (often written in Java or C#) that they are looking to revolutionize. You might be one of them. The promise of migrating to a modern cloud-native technology seems enticing.

And yet, you have to realize most migration processes tend to be more of the “lift and shift” kind. Meaning, you are gonna be stuck with the same old monolith, except it’s gonna be running inside a much more complex and hard-to-access environment, instead of a plain old VM.

Breaking down a monolith into microservices should start with the Strangler methodology and you shouldn’t worry too much about the orchestration method when getting started. As things start to take shape, Kubernetes is definitely an awesome candidate.

Will Kubernetes Allow You to Move Faster?
So many tech-savvy companies out there are using Kubernetes. And they are definitely moving fast. Won’t we be moving faster as well by adopting Kubernetes?

Unfortunately, the answer to that question is almost certainly “no.” The most common reasons I have encountered that prevent teams from moving fast are:

Slow or inadequate tests.
Lack of automated build and deployment capabilities.
Poor understandability of the application.
Each of those problems is separate, and none of them are directly related to Kubernetes. Go ahead and invest in CI, CD and understandability. Containerization may definitely help. Kubernetes might come later, or it might not. But there are almost certainly higher-priority concerns to address if increasing velocity is your goal.

Is Kubernetes Better Than What You Currently Have?
If you have read this far, you are probably not satisfied with whatever orchestration solution you already have (or you just might be reading through before you roast me in the comments). And while Kubernetes is definitely awesome, it’s a complex system with many shortcomings. To be honest, it’s quite likely to cause as many problems as it’s going to solve for you.

If you are using a remote configuration tool such as Chef, Puppet or Ansible, that just might be what’s right for you. I would definitely recommend considering containers for most of those workloads, but that can still be carried out with those simple orchestration techniques and without a dedicated container orchestration platform.

If you are using virtual machines, or even physical machines, you might not understand some of the performance benefits you are getting out of those environments (which is why many tech-savvy companies still use them for high-performance workloads). If you move to more containerized, higher-abstraction workloads, you just might encounter performance degradations you are not expecting.

Summary
Whatever your complaints may be about your current architecture, Kubernetes is certainly not magic that will fix all or even most of your problems. My advice is to keep track of what you are happy about with your existing infrastructure and test to make sure what Kubernetes will not fail you in those areas or even make existing problems worse.

The truth is that most of us aren’t Google. We don’t always need the latest trend in software engineering, whether it’s distributed tracing or serverless or, yes, even Kubernetes. To be clear, we use all of these things to some extent at Rookout, so don’t misinterpret this article as a case against Kubernetes. Kubernetes is amazing. It just may not be for you, despite the hype.