How Does KaaS Affect Your DevOps Regime?

It wasn’t so long ago that DevOps was considered a “new” trend and people were unsure of whether it would stick. Certainly, that’s no longer in question, so when other new trends come along, the big question is how they affect your DevOps practice.

One such trend is Kubernetes as a service, or KaaS.

What Does KaaS Do?

Just as some DevOps tools make it easier for non-operators to perform tasks that were traditionally reserved for operators, Kubernetes as a service makes it possible for developers to much more easily manage Kubernetes clusters for themselves by providing a UI or API interface that enables users to deploy and manage their own clusters on-demand, just as technologies such as OpenStack and VMware made it possible for developers to request their own virtual machines.

This democratization of Kubernetes has several advantages over and above decreasing time to market. For one thing, because developers can freely create and manage their clusters, it’s easier for them to try different architectures to see what works best for them and their applications.

Perhaps the most important capability KaaS brings is that Kubernetes deployment becomes automatable.

Why Does It Need To Be Automatable?

While developers don’t always think of the advantages of infrastructure automation, DevOps professionals know that it brings a number of different capabilities that just don’t exist when infrastructure is created “on the fly.”

Obviously having the ability to automate infrastructure creation and management enables you to incorporate your customers into your DevOps workflow, but you also get the advantages that come with that.

For example, when you can automate your infrastructure, you can also test the buildouts, ensuring that fixes get carried over into the next iteration. That gives you a certainty regarding what’s running and where, as the scripts, of course, get saved to a version control system.

Being able to automate creation also means that you can improve performance more easily because it is then possible to automate tests that create new architectures and test them for improvements in performance.

What Needs To Be Automated for Kubernetes?

OK, so now that we’ve established that automation is a good idea, what should you be automating when it comes to your Kubenetes clusters? There are five areas to which you need to pay attention, and KaaS has lesser and greater degrees of involvement in each of them.

• Clusters: Obviously clusters are the heart of your Kubernetes management, acting as a logical grouping for your resources. By enabling users to create their own clusters, you make it possible for clusters to be “right-sized”—you don’t need one massive cluster because everyone is on it; instead, you can have many small clusters.
• Nodes: The cluster runs on hardware (or VM-based) nodes, so KaaS should be able to provision new nodes, or at least add nodes that have already been provisioned to a cluster—preferably over multiple clouds. Ideally, it will also work with Kubernetes to make it possible for you to more easily manage those nodes should there be a hardware fault.
• Storage: Storage is something developers always need, and rarely want to set up on their own. You should be able to leverage your KaaS system to provision storage and make it available to clusters—and ultimately, to users.
• Networks: As it stands today, containers running in a Kubernetes cluster don’t generally worry about networking; they just assume that it’s in place. Your KaaS system must ensure that at least rudimentary networking is available, but ideally, it will give you additional control over that aspect of your infrastructure.
• Applications: Here things get a little less black and white. Applications aren’t usually part of your infrastructure, and they can be handled by your normal DevOps channels, which themselves will be integrated with KaaS. So you might have a script that takes advantage of the KaaS API to deploy a cluster, then uses other means to deploy the application on the cluster.

Where Does the GUI Fit In?

As handy as an API is, and as useful as it is for integrating KaaS into your DevOps workstream, for users, a GUI is going to be a better option. It enables developers to interact with their clusters more easily by accessing monitoring tools such as Grafana and making changes, and it can add additional features such as an application catalog.

However—and this is an important “however”—you must make sure that the GUI is an adjunct to how your KaaS is used. It’s a way for developers to decide what they want to do before ultimately scripting their interactions, because, at the end of the day, the scripts are the source of truth.

Who Watches the Watchmen?

There’s one more thing to think about when it comes to Kubernetes as a service, and that’s the health of the KaaS platform itself. You can have the most meticulously groomed clusters, but if your control plan is out of date, missing features or, worse, suffers a security flaw, it’s all for nothing.

So when you’re choosing a Kubernetes as a service infrastructure, make certain that it’s easy to update and upgrade without disrupting running clusters and workloads—or even better, that it updates itself without leaving you on the hook to do it.