In the first part of our blog series about Kubernetes, we focused on the specific characteristics of Kubernetes. The second part explains how it differs from end-to-end or multi-domain service orchestrators like Inmanta.
Comparing K8s with Inmanta, is like comparing apples with oranges. Like K8s, Inmanta’s orchestrator is a very well-designed piece of software, but with a very different purpose. As an end-to-end or multi-domain service orchestrator, its purpose is to deploy and manage services end to end across multiple domains. It must go wherever the service goes.
Although they are different, there are quite some synergies between Inmanta and K8s that result in a powerful combination.
Multi-domain by design
Inmanta is a purpose-built multi-domain service orchestrator. It orchestrates whatever is required to deliver the service. This means it cannot make some of the assumptions that K8s makes. For example, K8s, as a container orchestrator, assumes that the things it manages can be packaged into containers, can be replicated, deleted and recreated. Inmanta, however, also has to manage and configure physical telecom equipment. Because these devices are real, physical boxes, we cannot just delete and re-create them. Another example of resources managed by Inmanta are third party services that require specific one-time authorizations or have significant setup costs. Deleting and re-creating such services can be expensive or even impossible. This makes them a lot less convenient to orchestrate.
The general-purpose nature of Inmanta has profound implications. K8s can delegate many complex operations like sequencing of steps, performing updates,… to the applications running IN K8s. While this is absolutely a brilliant choice when running software at scale, it is not economically feasible in a telecommunications setting. Intrinsically, Inmanta has support for assembling a service from existing building blocks. Inmanta fully supports operations like ordering of actions.
Of course, both Inmanta and K8s are orchestrators, so they do share a lot of technological foundations, for example a strict adherence to the concepts of desired state (aka intent-based orchestration).
Synergies
Inmanta and K8s are very different things, but they do work together nicely.
Running Inmanta in K8s
Inmanta is one of those pieces of software that are suitable for running in K8s. You don’t need a K8s cluster to deploy Inmanta, but if you have one already, it is a good way of deploying Inmanta.
Inmanta for cross-domain K8s
K8s is very good at managing things inside K8s. However, there is often a need to have multiple K8s clusters (e.g. for high availability or at different edge locations) and the applications inside K8s often have to work with things outside K8s (e.g. specific network breakout, external service,…).
K8s cannot manage things that extend beyond a single K8s cluster. This coordination of components across domains is exactly the purpose of Inmanta. Here, Inmanta can stitch together the separate domains and ensure consistency throughout, while it can perfectly delegate the work within a cluster to K8s. The fact that both orchestrators are intent-based, makes this combination very powerful and reliable.
The K8s extension API
K8s is very extensible. However, it is important to realize that a K8s extension can mean many different things. Some K8s extensions deeply integrate with how K8s works, such as network or storage plugins. At the other end of the spectrum, some extensions merely use the K8s API server as a reverse proxy.
From a technical perspective, this flexibility shows the maturity and design quality of K8s. But from a marketing perspective, the reverse proxy capability is gold. When people hear: solution ABC is a K8s extension that provides capabilities X, Y and Z, they immediately associate the quality of K8s with this new solution ABC. Because surely, if it extends K8s, it must inherit its intrinsic qualities, right? Often, this is effectively the case. But sometimes, K8s is just an incredibly over-engineered reverse proxy in front of whatever ABC actually is.
One notable extension point is ‘Custom Resource Definitions (CRD)’. A CRD allows an extension to expose a service via the K8s API and provide a custom controller to implement this resource. CRDs extend K8s to manage a bewildering array of things, from databases inside K8s to network devices outside K8s.
CRDs are very powerful, because they cleanly integrate into the K8s API and all associated tooling. They represent a desired state (intent) that can be manipulated in a controlled manner.
When building a CRD, the challenge is to build the controller that sits behind it. When building a controller to manage things inside K8s, the built-in facilities of K8s provide a good basis. However, when managing the external world, K8s can provide much less facilities.
Here, Inmanta can provide the advantage as the platform to build the controller on. Managing desired state and building services out of existing building blocks are the essential functions of Inmanta, so it is ideal for building controllers!
First understand, then automate
At Inmanta, we recognize (and use) the power of K8s. But as engineers, we are not happy with the hype. There are impossible expectations that are actively exploited to sell impossible promises.
Many people are doing great things in the field of automation, using K8s and/or other tools. But the hype makes it hard to see what is real and what is not. When this bubble bursts, the whole field will suffer.
This is why we try to provide some counterweight by sharing tangible, technical content. Here and on our YouTube channel.
As an industry we've been pushing: Automate. Automate. Automate.
— Kelsey Hightower (@kelseyhightower) April 17, 2022
We should have been saying: Understand. Understand. Understand. Because if you understand what you're doing, you can automate if you want to. https://t.co/LDDSru7x0J