During our conversations and meetings we often get this question “So what is the difference between Onteon and Kubernetes?”. In this article we will try to answer this question.
We chose several categories for a comparison based on the highest number of questions we got from the market. We know it does not exhaust the topic and there may be some other categories you might be interested in. Feel free to contact us with your questions.
At first let us set the scene of what we are comparing. Is it “apples to apples” comparison?
It is not. Therefore providing any kind of table with yes/no, has/doesn’t have check boxes would not dispel doubts.
According to kubernetes.io, Kubernetes is “an open-source system for automating deployment, scaling, and management of containerized applications.”
According to onteon.tech, Onteon is “a software stack to orchestrate, scale, communicate and manage modern applications and legacy ones in an efficient and effortless way.” Just from the definitions we can see the first difference - “containerized applications” vs “modern applications and legacy ones”, so let me start with this topic. Kubernetes was born to orchestrate containers. It’s predecessor, Borg, was internal container-oriented cluster-management system written by Google.
Onteon is a system to manage containerized and non-containerized applications. It’s predecessor was JLupin, a microservices platform developed for JVM languages. So the base unit for orchestration in Kubernetes is container. Onteon can also manage containers, however In Onteon the base unit is operating system process. It is considered “application” to deploy and manage.
What implications does it have for the use of any of these products? Managing non-containerized applications is much easier when you deal with existing applications. It does not matter if it’s monolith or not, or in which languages they are written. If you want to move existing applications to new, distributed environment, in Onteon you can do it without containerization. This allows you to maintain or modernize these applications easier.
Often we hear from customers that some applications are not easily containerized, so they are virtualized and then containerized. Handling such applications is not a straightforward task. Using native applications instead of containerized can also save on resources and performance (like network communication) if this is case - using older equipment or resource-limited devices.
On the other hand, if your company standarized on containers only and set all the processes to work with containers without exception, then this capability may not be useful for you. Unless you find these exceptions…
Feature set
Kubernetes is a container orchestration system. However during the years hundreds of other tools were created to work with Kubernetes and provide additional capabilities K8S itself didn’t have. Therefore when talking about Kubernetes we often have whole eco-system in mind. In this area Kubernetes is unbeatable.
Onteon was created to provide the set of capabilities more than orchestration out of the box. So you will get for example service mesh, log management, monitoring built-in and available as part of the platform.
Easy installation and configuration
There are various distributions of Kubernetes, and it’s also available as managed service in many cloud providers’ services portfolio. Thus the answer if this is easy to install and configure may vary from “hard” when you take the open source software and install it from scratch or “very easy” when you just pick the managed service from cloud provider. There are also additional tools to help you with Kubernetes cluster deployment like kubespray, so you don’t have to start from scratch.
Also there is a question: are we taking about Kubernetes only or a whole environment in which we want to deploy and manage applications?
If you need service mesh for example, you can use products like open sourced Istio or Linkerd and install them from scratch on any environment (on-premise or cloud), you can use commercial version like Red Hat OpenShift Service Mesh based on Istio. In the cloud you can use managed service-mesh offered by cloud providers like AWS App Mesh.
Onteon is a software with the tools built-in or integrated (like service mesh or log management), delivered as one package and provided with installer.
The installation and configuration is similar no matter if on-premise or in the cloud.
Portability
Onteon and Kubernetes clusters can be used in any environment from on-premise to public cloud.
The more you use open source versions of Kubernetes, the higher portability you can achieve. I am not talking here about the cost of it, but about technical side. You can use any IaaS, bare metal or virtual environment to set up the same Kubernetes & tools. If you start to use managed services from any cloud providers, the architecture, implementation details make these services different. By using managed service in public cloud you will not become skilled to do on-premise installation. Some cloud providers would offer options like using managed Kubernetes service on-premise (for example EKS nodes on AWS Outpost).
However the greatest portability you will have by using open source or any commercial version of K8S requiring OS or virtual machine, so you can bring it to any IT environment . The same will be here with Onteon offered as software you can install wherever you need.
Another aspect of this topic for consideration is how many additional tools you use and want to use together with Kubernetes and how many subsystems are your clusters integrated with (identity and access management, log gathering, monitoring, etc.)
Ease of use
Ease of use is very subjective. This can also have two meanings, the learning curve “from zero to hero” and how easy it is to run the tasks in everyday work.
For any Kubernetes distribution you will find documentation, tons of guides, tutorials, and other supporting materials. If you use other tools you integrated with Kubernetes (like Istio, Linkerd or Prometheus) you will have to wade through the separate documentations and products.
Kubernetes is complex, or complicated, and even vendors delivering commercial distributions openly admit it. If you add additional tools, it can be even more complicated.
No matter how much integration in a box you get, with how smart additional tools you will cover the Kubernetes, it’s still the same code beneath.
Onteon was built with ease of use in mind, to allow system administrators start to work with the cluster in a short time. For example with only one command you enable encryption in control plane and between all applications and microservices within the cluster, plus automatic key rotation enabled. Something you will not achieve easily in other solutions.
Edge use
In most cases Kubernetes deployments are on-premise in data centers or in the cloud. There is certain area, where there is growing demand for application orchestration with slighty different requirements. Let’s call it edge. It could be in a factory, where you want applications to process data close to machines before they reach data canter or the cloud. You have more limited resources there, hardware is not easily replacable, skills onsite could be also lower than average. What is also important, you need very often to support existing applications which may not be easily containerized.
You cannot use there managed service, you cannot often install full commercial versions of Kubernetes. There are lightweight distributions of Kubernetes like K3s or MikroK8S, however if they fit such limited resources it’s tough to assess upfront.
Onteon is lightweight as well, it was written from scratch, not by copying millions of lines of code from K8S. It can handle non-containerized applications, thus using less resources or providing better performance with the same resources. It also consumes less energy than Kubernetes distributions.
In context of edge, it’s worth to check if available solutions would allow to manage each nodes separately, the same is about applications working on the nodes.
Platform upgrades and high availability
The main role of clusters is to provide high availability for applications and management for variable workloads. All platforms have also mechanisms for online applications upgrades.
What about cluster upgrades? With Kubernetes there are two main strategies: rolling update
and migration with node pools. For rolling update you drain node by node and set new nodes up with newer version. With node pools you need an additional node pools to move the workloads, so you need to have new resources, at least for migration time.
Onteon, apart from two above techniques, provides an option for non-disruptive upgrade of the nodes, without draining them and stopping running applications. It is very quick, does not require too much preparation and has minimal impact on existing workloads.
Networking
In Kubernetes networking is defined by container runtime. Container runtimes use add-ons extending Kubernetes to manage network. You have a great choice of them, at least 17 add-ons are listed on kubernetes.io page.
In commercial versions like Tanzu Kubernetes by VMware, you can use a combination of services provided by vSphere, NSX-T Data Center and open-source software like Calico or Antrea. It gives you a great bunch of options for configuration.
Onteon uses network delivered by you or your provider. There are many integration or automation possible though.
Service mesh, being part of the networking, was mentioned at the beginning of the article.
Storage
In Onteon it is possible to map shared disks available in the OS from control plane and reuse them by applications. It can be used both for persistent and ephemeral storage.
Kubernetes works with containers, and files in containers are ephemeral. Therefore for persisent volumes it uses volumes attached to the Pod in which containers reside.
CI/CD support and automation
Onteon supports CI/CD processes with HTTP/HTTPS API (or CLI using this API) with any tool like Jenkins or Buddy. Fully documented management API allows to integrate it with any other tool.
For Kubernetes there are many tools already integrated or prepared to work with Kubernetes applications.
Security
The more components, the more risk, the more security tools to mitigate the risk. Security is on the agenda in every project, product and system. “Security by design” is incorporated in most companies’ services and products.
When I think of security I think of two areas: security of the platform and security of the applications. The ultimate goal is we want our applications working without interruptions and any data leakage, the platform needs to provide these capabilities for applications, being itself resistant to errors and attacks.
Kubernetes is highly customizable with many configuration options (not mentioning additional tools you need to provide complete platform for applications). According to Red Hat report, 53% respondents detected misconfiguration related to containers or Kubernetes during last 12 months. It means you need to have very skilled people onboard, skilled partner or combine both.
With managed Kubernetes in public clouds, you have shared responsibility in security and compliance area with cloud provider, although it’s only part of what you are responsible for. Kubernetes cluster is part of the whole system architecture. Applications are outside of scope of cloud vendor responsibility. Also you can have managed Kubernetes (container orchestration only) but you would add service mesh on your own, then you also need to secure it.
With companies offering their Kubernetes distribution, commercial ones, you have in the subscription all the fixes for vulnerabilities found, you have more integration delivered in a product or service, thus minimizing the possible misconfigurations.
Onteon is a commercial product, comes as integrated set of functionalities. Support is offered directly by the company that written the code. Security enforcement is achieved by simplified mechanisms to avoid mistakes by the operators, like encrypted traffic in control plane and between applications.
Prices (or TCO)
We know from life that price of any product or service cannot be evaluated without terms and conditions, available options, additional costs the product or service drags, etc.
We would rather have in mind project costs, or TCO for a given period, where product or service is just one item on the list.
This is a topic for another article we will publish soon.
Summary
Above comparison is very generic. First of all the number of categories could be longer. Secondly, we couldn’t prioritize these categories. This is very subjective, depending on where the tools are to be used, what is the goal of the project and what the KPIs are.
Well, the goal…
Often I see the titles of posts or announcements that a company X successfully finished project and deployed Kubernetes cluster(s), mainly on-premise. If the goal of the project was to successfully deployed Kubernetes cluster, what is the value for the company? Did someone shout in the past that they had successfully installed Linux? If they deployed Kubernetes cluster, how much time will pass until they deploy applications on production and the system will bring tangible benefits?
Thus the goal of the business project, it’s KPIs, limitations and resources you have, will define which categories from abovementioned will be important and how much important for you.