Virtualization Technology News and Information
Gluing together the Cloud Native Landscape

By Sander Rodenhuis, CEO, Red Kubes

The CNCF Cloud Native landscape counts hundreds of open and closed source point solutions. By now we all know that Kubernetes alone is not enough. You need to integrate additional solutions to offer a complete container platform experience. Kubernetes is just the foundation. Integrating applications leads to technical debt and has a huge impact on resilience and inertia. Wouldn't it be time for a new CNCF initiative that provides some framework or standards that can avoid the technical debt allowing all applications to take advantage of some generic integrations like user awareness, roles, and permissions? The Otomi open source project is trying to make the first steps here.

The Kubernetes platform pitfall

We've all seen it: The CNCF Cloud Native Landscape. Hundreds and hundreds of open and closed source projects. And mostly all of them focus on only a single piece of the enormous complex Kubernetes infrastructure puzzle. Integrating software for storage management, networking, security, monitoring, service mesh, continuous integration and delivery, registries and more to create an enterprise-grade platform. Kubernetes is only the foundation. All of this integration work itself has zero value to an organization. It is simply something that must be done before more valuable work, like deploying new features, can be done. From a company perspective, it makes sense to try and minimize the amount of work spent on building and operating a container platform and avoiding technical debt.

The technical debt of the integrations between different products tends to have the biggest impact on resilience and inertia, causing outages or forcing re-work to fix issues. So, it stands to reason that to remove this technical debt, we need a solution for keeping cracks from forming in the glue.

Kubernetes is becoming more and more popular. We see organizations being forced to move towards using Kubernetes because of external factors, like vendors pushing towards containerization. But these organizations have no real clue on what they're stepping into. Kubernetes is still way too difficult. It's far from being a point-and-click affair. So how can we make Kubernetes easy by abstracting away the complexity of configuring and integrating all of the applications that together complete the puzzle?

Providing the glue

At this point, we do not see any CNCF initiatives focusing on just this. How can we avoid technical debt and move towards a complete new Kubernetes user experience? I can imagine a kind of framework that offers generic open integration points where different projects can hook into and that offers some kind of Operating System experience where you can install applications like Harbor or HashiCorp Vault, just by dragging them to your Kubernetes desktop. And when installed users can immediately access these applications based on their permissions.

You would expect to have the CNCF take the lead here right? Or is this a utopia with some of the big vendors trying to lead the way forward here by wrapping all of these beautiful open source building blocks into their offering?

The first steps

The Otomi open source project is trying to set the first steps here. Otomi offers an out-of-the-box container platform solution (on top of Kubernetes) that increases developer efficiency and reduces complexity. It integrates upstream Kubernetes with proven open source components. With carefully crafted sane defaults at every step, it minimizes configuration effort and strives to automate as much as possible, and allows for customization and extensibility. Incorporating Open Source standards and best practices, Otomi aims to bring new features and stability with every iteration. Otomi offers maturity and speed while still supporting customization if desired.

The Otomi project's primary goal is to prevent everybody from reinventing the wheel themselves. Coming from developers working with the 12-factor app methodology, Otomi was designed to be open and flexible, embracing open-source projects and inevitable change. The best way to do that is to avoid technical debt and contribute effort where it makes the most sense: in these projects we've come to love and use. Many companies try to wrap open-source building blocks into their own abstraction/experience, offering a unified interface to all these wonderful functionalities. This looks great, but this custom wiring and gluing create huge technical debt. They are on their own when it comes to patching/updating these parts.

One of the most important design decisions of Otomi is to use those apps as they come and make them aware of the bigger context they serve in: users that have roles and permissions to work with them. Otomi ultimately is an integration platform that strives to make these open-source apps work together.

Dealing with a multitude of applications and configurations, it is important to ease the developers' workflow. Developers have to adopt this way of working, and so Otomi aims for:

  • No local installs: build tooling images to run code in containers, so it behaves the same locally as in the cloud
  • Automate everything: input/output validation, testing, deployment, issue management. Limit errors and let developers focus on features
  • Less integration points: Easily add apps or wire them together, abstracting configuration away to a single repository
  • Coding support: deliver json schema for validation in vscode
  • API oriented: easily create openapi clients for tasks to do CRUD operations on the apps, giving autocompletion while developing
  • Sane configuration defaults: Wherever possible, provide configuration for the most common use case(s).

A new Kubernetes user experience

Otomi not only strives to provide a framework with generic integration features, it also strives to offer a new Kubernetes user experience. Applications that take advantage of the provided wiring are made available as a shortcut on a desktop like user interface.


Otomi Kubernetes desktop

This offers a single entrypoint to all the integrated applications. When a user logs in into the interface, only the applications the user is allowed to access (based on roles) are made available. This makes Kubernetes a true point-and-click affair.


Like to know more about the Otomi open source project? Come and visit the Red Kubes virtual booth at KubeCon + CoudNativeCon Europe, May 4-7 or visit


Sander Rodenhuis 

Sander is the CEO of Red Kubes. Red Kubes mission is to make Kubernetes adoption a less expensive and simple experience with Otomi Container Platform. Connect with Sander on Linkedin or Twitter if you like to know more about Red Kubes and their product Otomi Container Platform or visit

Published Tuesday, April 20, 2021 7:36 AM by David Marshall
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
<April 2021>