The Origin of KAOPS, Making Kubernetes Work

It Started With Virtualization

Since the mid 1990s, I’ve been designing, building, installing, and operating all sorts of data center equipment.  I started with networking switches and routers, then moved on to servers and storage arrays.  Virtualization was the first major technology shift I saw in the data center.  Network virtualization came in the form of VLANs and later VXLANs.  Compute virtualization was easier to understand, partly because it was so well named as Virtual Machines. These technologies made the cloud possible. The large public cloud providers perfected virtualization, each in their own proprietary way, and built a trillion-dollar industry.  My favorite definition of the cloud, by SunMicro leader’s Tom Lyon, is, “There is no cloud, it’s just somebody else’s computer.”  Users of cloud and virtualization could make the jump because the concepts were so similar to their historical physical data center counterparts.

The Rise of Kubernetes

In 2010, virtualization took on a new form, called containers, which was different because, unlike VMs, you don’t operate it like a computer.  Instead of pretending to be a computer, containers share a computer.  This had a major impact and unintended consequences on the rest of the data center. Containers were so different, that a new method had to be created to operate them.  Kubernetes was born to manage containers, and they set lofty goals, not just to manage the containers and the cluster of servers they run on, but also the virtual network for the containers to connect, and virtual storage for the containers to store data.  Kubernetes had control of all three building blocks: compute, storage, and networking.  If named better, Kubernetes could well have been called Virtual Data Center (for containers). 

Failure to Convert to Kubernetes

With its lofty charter, Kubernetes experienced a lot of growing pains, and users have had a long and difficult learning curve.  In 2018, I witnessed first-hand a large international telephone and telegraph company fail at their first few attempts.  Prior to Kubernetes, they built an extremely savvy operation, with 7000 servers and exabytes of storage, executing billions of web transactions a day with 99.999 uptime.  There was no challenge too large for this team - until they attempted Kubernetes. Upon their first failed attempt, their leader said, “Kubernetes just doesn’t work. It requires a magical network.”  On their second attempt, they assigned their smartest engineer.  It took him a year to build a working prototype, but that also failed, because it was too complex for the rest of the team to operationalize.  As a solution architect, I just wanted to get Kubernetes to work, which we eventually did.  Along the way, I took note of what went wrong and how to fix it.

  KAOPS is a great choice giving you a functional platform in weeks (not years), for a fraction of the cost of building one yourself; and you don’t need to support it yourself.  

Nethopper KAOPS Is Born

In 2020, I reasoned that if my sophisticated telephone company’s DevOps team was having problems getting Kubernetes to work, then likely so did thousands of other companies. 

So, I decided to create Nethopper, a company with the goal of helping others get Kubernetes to work, avoiding the pain and pitfalls that I had just witnessed. Our product, KAOPS (Kubernetes Application Operations Platform as a Service), is now helping define a new market category.

Key KAOPS principles:

Principle #1 - Cloud and Kubernetes Agnostic

We must allow users to choose any cloud (private or public) and any Kubernetes. Many companies have tried to lock users into using their cloud or their flavor of Kubernetes. We work with all cloud providers and all Kubernetes flavors (e.g. Rancher, Openshift, EKS, GKE, AKS, etc). 

Principle #2 - Delivered as a PaaS

KAOPS was born in the cloud and is best delivered as a cloud PaaS.  The old enterprise software model is actually part of the problem, making Kubernetes complex. In practice, users must download and install Kubernetes, and then download and install a dozen tools, all without support and guidance. The newer PaaS consumption model is better for Kubernetes users than the old model, because it has the advantages of guiding them to use the best practices and saving them time and headache.

Principle #3 - GitOps for Versioning and Auditability

One of the biggest faults that many Kubernetes users commit is attempting to control Kubernetes via command line (CLI). When Kubernetes trouble happens (and it will), they put a team of experts to work, typing an ever-changing sequence of CLI commands to fix the issue.  Even when fixed, it’s nearly impossible to tell who did what, when, and in what order to fix the problem. In short, it’s not collaborative, repeatable, or auditable.  The best collaboration tool in IT is Git.  It’s where almost every software team goes to collaborate to write and version their code.  Using Git to configure Kubernetes solves most of the operational issues compared to CLI.  KAOPS uses GitOps for everything, whenever possible.

A Toolbox for Your Tools

Open source is awesome.  The CNCF is at 120 open-source tools - and growing - for GitOps, Continuous Delivery, Security, Monitoring, Logging, Upgrading, Backup, etc.  However, the pendulum has swung so far that IT and DevOps don’t need more open-source tools. What they need is a ‘toolbox’ that integrates those tools to work together.  The tools also need to be used by a collaborative team, with a secure access method - and be easier to use and automate.  Most IT/DevOps teams can’t afford the time or money for 120 tool experts, each with their specialized tool.  How does one automate a process with 120 tools in it?  IT/Devops teams have determined an answer called Platform Engineering.

The Rise of Platform Engineering

It only stands to reason that if IT/DevOps teams are failing so often that they would create a solution.  Enter “Platform Engineering,” which is the discipline of designing and building Internal Developer Platforms, toolchains and workflows that enable self-service capabilities for software engineering organizations.  The idea is that you form a separate software team whose task is to figure out why your current software team is failing and develop a product (a.k.a. platform) to solve the problem.  As a hybrid engineer and a business-minded person, I can tell that an engineer came up with this idea. A business-minded person would dismiss this idea very quickly, especially when they learn that it requires an average of two years and $5M to create such a platform, and then even more to support it forever.  Business-minded professionals need the problem solved now - and for far less money.  This is why “platforms” are being outsourced to Managed Service Providers, System Integrators, or even the cloud providers themselves.  KAOPS is a great choice giving you a functional platform in weeks (not years), for a fraction of the cost of building one yourself; and you don’t need to support it yourself. You even get support for all those open-source tools your team likely already uses.

The Future of Kubernetes Is KAOPS

Kubernetes is great and powerful, but it’s just infrastructure (compute, storage, network).  Apps and data don’t deploy themselves onto Kubernetes, nor do they monitor, secure, upgrade, log, or debug themselves. These operational functions have always needed to be done on top of the infrastructure, and the Kubernetes era is no different. What is different with Kubernetes is that there’s an opportunity to standardize the way data centers and applications are operated, so that it works the same way in all clouds, private and public.  KAOPS is that operational layer that sits on top of Kubernetes.  The cloud providers all offer “Managed Kubernetes.”  In the future, we will look back and chuckle that we called today’s cloud services “Managed Kubernetes,” as this is just infrastructure.  “Managed Kubernetes” is going to evolve to include all the operations functions to automate how apps and data are run on top of Kubernetes.  IT/DevOps teams will simply write application code, and a very small operations team will easily deploy and operate those apps in any cloud they choose. Well, the future is already here, and it’s called KAOPS. Start using KAOPS here or visit www.nethopper.io to learn more.  Also, follow us on Linkedin.