Myth busted: There is no such thing as vanilla Kubernetes
(Dutch version below)
See also: https://youtu.be/7pqU1tt9_II
The speed at which companies develop and master new applications in times of digital transformation makes the difference between building a lead or lagging behind the competition. The window between idea and roll-out must therefore become ever shorter. A development cycle of a year or even six months is a definite no-go. In the time-to-deployment of new applications, containers and the container orchestration platforms to manage them, play an important role.
Kubernetes is the first container orchestration platform of its kind and today’s standard. About five years ago, the platform had to compete with other players such as Mesosphere Marathon, Docker Swarm and Cloud Foundry, but now almost the entire market has come to rely on the platform developed and open-sourced by Google. Thorough experience with Kubernetes really makes all the difference. After all, Kubernetes is the foundation, as it were, and the house you want to build on this foundation still requires a lot of components that have to come together according to everyone's taste and needs.
Market standard
Although from the launch it was clear that Kubernetes is 'the way forward', many vendors halted to see which way the wind blew. Now that K8s is the market standard, they rushingly jump on the bandwagon. Throwing elbows, these 'late to the party-players' make it clear that they are closest to the essence of Kubernetes and less 'unchanged'. They are 'more vanilla'. But they are not. What's more, there is no such thing as 'vanilla Kubernetes'.
Every vendor configures Kubernetes in their own way. Red Hat, for example, has made it impossible by default to run containers with root permissions. The number of configuration possibilities is endless and the management of the platform differs from vendor to vendor as well. There is no vanilla Kubernetes or other flavor that sets the tone, there is only the most ideal configuration of the platform that differs each time from customer to customer.
Easy migration
How do these vanilla vendors try to distinguish themselves? First of all, they promise ultimate portability. The client can easily migrate his applications from one vanilla version to another, while this is not the case with non-vanilla flavors. In other words, they promise no vendor lock in. But there is a catch here. Portability is fine indeed, but having to switch from version A to B rarely runs as smoothly as hoped or promised.
Under-equipped
Secondly, they claim to be more responsive because they use a more trimmed version of Kubernetes. Configuring Kubernetes is indeed very complex. A lot needs to be integrated: metrics collection, log management, deployment, scale-out, application build processes, container registry,... And these are just the basics.
To be "faster", the "late to the party-players" merely focus on their own operation framework, deployment method and metrics collection, which is the minimum minimorum needed to make the platform operational. They are supposedly more vanilla, but actually they are just under-equipped. For the customer it is important to be able to choose between the minimum or more services that run on the platform. If all the components are there, the choice remains whether or not to invest in them.
Compliant
The Kubectl command line and the Kube-API server and interface are the components with which a Kubernetes version must be compatible and for which an official Kubernetes conformance test and certification exist. But these apply to everyone. Vanilla vendors like to boast about being compliant, but that's not how they distinguish themselves from the rest, nor by stating that they respect the API and CLI (Command Line Interface), because everyone has to and does that too.
These trimmed versions of vanilla vendors contain too little to pack a punch but they are attractively packaged as nimble, sleek and fast. Stripped of many features this should be beneficial for the customer but it is anything but.
Extra needs
This is not helped by the fact that often only one link in a company makes the decisions, too often outside the input of the developers. The people responsible for infrastructure are touted for a trimmed version and like the sound of this streamlined story. But afterwards, the developers express their extra needs. Suddenly components are thrown together that do not belong in the framework. The customer knows what he is paying for, but does not realize that there is still a lot of work to be done afterwards. This is how he ends up disappointed.
The alternative is the certainty and freedom of choice that you find in experience. Kubernetes 1.0 was released in 2015 and Red Hat immediately jumped at its potential. As a result, Red Hat not only has the most experience with this technology, but has also been able to build a complete solution around it. In addition to being a fully-integrated product in terms of infrastructure components, Red Hat OpenShift also offers a wide range of optional components for application administrators and developers. These include application runtimes, frameworks and middleware. Also the necessary components for a DevOps collaboration are present, such as CI/CD pipelines.
The edge in experience with Kubernetes led to Red Hat being able to get a feel for where the extra needs are for the infrastructure and operations people. Installation, maintenance and upgrades of OpenShift are maximally automated, just as maintenance of applications in containers is automated using 'operators' in the platform. And when you - like many customers - end up running a handful or more clusters, including the public cloud in your environment, Red Hat provides a solution to centrally monitor and manage everything.
Kubernetes is a beautiful technology but it's a rough diamond. The choice you have as a user is to cut the diamond yourself, or to call on an experienced diamond trader who can offer you all kinds of shapes and options.
Author: Bob Dubois, Cloud Specialist, Red Hat
---------------------------------------------------------------------------------------
Bubbel doorprikt: There is no such thing as vanilla Kubernetes
zie ook: https://youtu.be/7pqU1tt9_II
In tijden van digitale transformatie maakt de snelheid waarmee bedrijven nieuwe toepassingen ontwikkelen en deze zich eigen maken, het verschil tussen een voorsprong opbouwen of achterop hinken op de concurrentie. De tijd tussen idee en uitrol moet dus alsmaar korter. Een ontwikkelingscyclus van een jaar of zelfs een half jaar is dan ook een dooddoener. In de time-to-deployment van nieuwe applicaties, spelen containers en de container orchestrator platforms om die te beheren, een belangrijke rol.
Kubernetes is het eerste container orchestrator platform in zijn soort en vandaag de standaard. Het platform moest zo’n vijf jaar geleden nog de concurrentie dulden van andere spelers zoals Mesosphere Marathon, Docker Swarm en Cloud Foundry maar inmiddels beroept zowat de hele markt op het platform ontwikkeld en open-sourced door Google. Gedegen ervaring met Kubernetes maakt daarbij echt het verschil. Kubernetes is immers als het ware de fundering en het huis dat je erop wil bouwen heeft nog heel wat componenten nodig die naar ieders smaak en noden moeten ingevuld worden.
Marktstandaard
Hoewel van bij de lancering duidelijk was dat Kubernetes ‘the way forward’ is, keken veel vendors de kat uit de boom. Nu K8s de marktstandaard is, springen zij alsnog op de kar. Met veel elleboogwerk maken deze ‘late to the party-players’ zich sterk dat ze het dichtst aanleunen tegen de essentie van Kubernetes en minder ‘unchanged’ zijn. Ze zijn ‘meer vanilla’. Maar dat is niet zo. Meer nog, there is no such thing as ‘Vanilla Kubernetes’.
Iedere vendor configureert Kubernetes op een eigen manier. Red Hat bijvoorbeeld heeft by default ingesteld dat het niet mogelijk is om containers met rootpermissie te draaien. Het aantal configuratiemogelijkheden is eindeloos en ook het beheer van het platform verschilt van vendor tot vendor. Er is niet één vanilla Kubernetes of andere smaak die de toon zet, wel de meest ideale configuratie van het platform die keer op keer verschilt van klant tot klant.
Makkelijke migratie
Hoe trachten deze vanilla vendors zich te onderscheiden? Ten eerste beloven ze ultieme portability. De klant kan zijn applicaties steeds makkelijk van één vanilla-versie naar een andere migreren, terwijl dit niet het geval is bij niet vanilla flavors. In andere woorden, ze beloven no vendor lock in. Portability is positief, maar moeten overschakelen van versie A naar B loopt zelden zo vlot als gehoopt. Hier schuilt een addertje onder het gras.
Under-equipped
Ten tweede claimen ze dat ze korter op de bal kunnen spelen door gebruik te maken van een meer getrimde versie van Kubernetes. Kubernetes configureren is inderdaad bijzonder complex. Er moet zeer veel ge?ntegreerd worden: metrics collection, log management, deployment, scale-out, application build processes, container registry … En dit is nog maar de basis.
Om “sneller” te zijn, leggen de ‘late to the party-players’ zich daarom enkel toe op een eigen operation framework, deployment method en metrics collection: het minimum minimorum nodig om het platform operationeel te maken. Ze zijn zogezegd meer vanilla, maar eigenlijk zijn ze gewoon under-equipped. Voor de klant is het net belangrijk om te kunnen kiezen tussen het minimum of meer services die op het platform draaien. Als alle componenten er zijn, heeft hij nog de keuze of hij hier wil in investeren of niet.
Conform
De Kubectl command line en de Kube-API server en interface zijn de componenten waarmee een Kubernetes versie zeker compatibel moet zijn en waarvoor dan ook een offici?le Kubernetes conformance-test en -certificatie bestaan. Maar die gelden voor iedereen. Vanilla vendors pakken graag uit met het feit dat ze conform zijn maar zo onderscheiden ze zich niet van de rest, evenmin door te stellen dat ze de API en CLI (Command Line Interface) respecteren, want ook dat moet en doet iedereen.
Deze trimmed versies van vanilla vendoren hebben te weinig om het lijf maar worden aantrekkelijk verpakt als nimble, sleek en snel. Ontdaan van tal van features zou dit voordelig moeten zijn voor de klant maar dat is het allesbehalve.
Extra noden
Dit wordt niet geholpen door het feit dat vaak slechts één schakel in een bedrijf de knopen doorhakt, te vaak buiten de input van de developers om. De verantwoordelijken voor infrastructuur wordt een trimmed versie aangeprezen en zij zien wel heil in dit gestroomlijnd verhaal. Maar nadien leggen de developers extra noden op tafel. Dan moet er plots nog geknutseld worden met componenten die niet thuis horen in dat framework. De klant weet wel waar hij voor betaalt maar beseft niet dat er achteraf nog veel werk aan de winkel is. Zo komt hij toch bedrogen uit.
Het alternatief is zekerheid en keuzevrijheid die je vindt in ervaring. Kubernetes 1.0 kwam uit in 2015 en Red Hat is toen meteen op de kar gesprongen. Hierdoor heeft Red Hat niet alleen de meeste ervaring met deze technologie, maar is het ook in staat geweest om een complete oplossing errond op te bouwen. Naast het feit dat Red Hat OpenShift een volledig ge?ntegreerd product is op vlak van infrastructuur-componenten, biedt het ook een brede waaier aan van optionele componenten voor de applicatiebeheerders en -ontwikkelaars. Denk hierbij aan application runtimes, frameworks en middleware. Ook de benodigde componenten voor een DevOps-samenwerking zijn aanwezig, zoals CI/CD pipelines.
De voorsprong in ervaring met Kubernetes heeft ertoe geleid dat Red Hat kon ervaren waar de extra noden zitten voor de infrastructuur & operations-mensen. Installatie, onderhoud en upgrades van OpenShift zijn maximaal geautomatiseerd, net zoals onderhoud van applicaties in containers geautomatiseerd wordt aan de hand van ‘operators’ in het platform. En wanneer je – zoals veel klanten – uiteindelijk een handvol of meer clusters, inclusief de public cloud in je omgeving draait, zorgt Red Hat voor een oplossing om alles centraal te monitoren en te beheren.
Kubernetes is prachtige technologie maar het is een ruwe diamant. De keuze die je als gebruiker hebt, is om die diamant zelf te slijpen, dan wel om een beroep te doen op een ervaren diamantair die je bovendien nog eens allerlei vormen en opties aan kan bieden.
Auteur: Bob Dubois, Cloud Specialist, Red Hat