Back in 2019 we published a review of the most relevant serverless frameworks available for Kubernetes. That article became one of the most visited in our blog in the past two years, so we decided to return to this subject and provide an update for our readers.

TL;DR: Serverless in Kubernetes in 2022 means, to a large extent, Knative.

What’s in a Word

The „Serverless“ word is polarizing.

Robert Scoble, one of the first tech influencers, uttered it for the first time fourteen years ago, as James Potter reported recently. In those times, „Serverless“ just meant „not having servers and being an AWS EC2 customer“. Because, yes, companies used to have their own physical servers back then. Amazing, isn’t it?

Fast forward to 2022, and the CNCF Serverless Landscape has grown to such an extent that it can be very hard to figure out what „serverless“ truly means.

Even though for some it just represents the eternal return of 1970s style batch computing, in the past five years the „Serverless“ word has taken a different and very specific meaning.

The winning definition caters for the complete abstraction of the infrastructure required to run individual pieces of software, at scale, on a cloud infrastructure provider.

Or, in less buzzword-y terms, just upload your code, and let the platform figure out how to run it for you: the famous „FaaS“, also known as Function as a Service.

The IaaS Front

The three major Infrastructure as a Service providers in the world offer their own, more-or-less-proprietary version of the Serverless paradigm: AWS Lambda, Azure Functions, and Google Cloud Run (which complemented the previous Google Cloud Functions service). These are three different approaches to the subject of FaaS, each with its advantages and caveats.

Some companies, like A Cloud Guru, have successfully embraced the Serverless architecture from the very start (in this case, based on AWS Lambda), creating cost-effective solutions with incredible scalability.

But one of the aforementioned caveats, and not a small one for that matter, is platform lock-in. Portability has always been a major concern for enterprise computing: if building apps on AWS Lambda is an interesting prospect, could we move them to a different provider later on?

Well, we now have an answer to that question, thanks to our good old friend: the container.

The Debate Is Over

Almost exactly three years ago, Anthony Skipper wrote:

We will say it again… packaging code into containers should be considered a FaaS anti-pattern!

Containers or not? This was still a big debate at the time of our original article in 2019.

Some frameworks like Fission and IaaS services such as AWS Lambda and Google Cloud Functions did not require developers to package their apps as containers; just upload your code and watch it run. On the other hand, OpenFaaS and Knative-based offerings did require containers. Who would win this fight?

The world of Serverless solutions in 2022 has decided that wrapping functions in containers is the way to go. Even AWS Lambda started offering this option in December 2020. This is a huge move, allowing enterprises to run their code in whichever infrastructure they would like to.

In retrospect, the market has chosen wisely. Containers are now a common standard, allowing the same code to run unchanged, from a Raspberry Pi to your laptop to an IBM Mainframe. It is a natural choice, and it turned out that it was a matter of time before this happened.

Even better, with increased industry experience, container images got smaller and smaller, thanks to Alpine-based, scratch-based, and distroless-based images. Being lightweight allows containers to start and stop almost instantly, and makes scaling applications faster and easier than ever.

And this choice turned out to benefit one specific framework among all: Knative.

The Age of Knative

In the Kubernetes galaxy, Knative has slowly by steadily imposed its mark as the core infrastructure of Kubernetes serverless workloads.

In 2019, our article compared six different mechanisms to run serverless payloads on Kubernetes:

1. OpenFaaS
2. Fn Project
3. Fission
4. OpenWhisk
5. Kubeless
6. TriggerMesh

Of those, Fn Project and Kubeless have been simply abandoned. Other frameworks suffered the same fate: Riff has disappeared, just like Gestalt, including its parent company Galatic Fog. IronFunctions moved away from Kubernetes into its own PaaS product. Funktion has been sandboxed and abandoned; Leveros is abandoned too; BlueNimble does not show much activity.

On the other hand, new players have appeared in the serverless market: Rainbond, for example; or Nuclio, targeting the scientific computation market.

But many new contenders are based on Knative: apart from TriggerMesh, which we mentioned in 2019 already, we have now Kyma, Knix, and Red Hat’s OpenShift 4 serverless, all powered by Knative.

The interest in Knative is steadily growing these days: CERN uses it. IBM is talking about it. The Serverless Framework has a provider for it. Even Google Cloud Run is based on it! Which shouldn’t be surprising, knowing that Knative was originally created by Google, just like Kubernetes.

And now Knative has just been accepted as a CNCF incubating project!

Even though Knative is not exactly a FaaS per se, it deserves the top spot in our review of 2022 FaaS-on-K8s technologies, being the platform upon which other serverless services are built, receiving huge support from the major names of the cloud-native industry.

Getting Started with Knative

Want to see Knative in action? Getting started with Knative on your laptop now is easier than ever.

1. Install kind.
2. Run the following command on your terminal:

$ curl -sL install.konk.dev | bash

To work with Knative objects on your cluster, install the kn command-line tool. Once you have launched your new Knative-powered Kind cluster, create a file called knative-service.yaml with the contents below:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello
spec:
  template:
    metadata:
      name: hello-world
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          ports:
            - containerPort: 8080
          env:
            - name: TARGET
              value: "World"

And then just apply it: kubectl apply -f knative-service.yaml.

The kn service list command should now display your „helloworld“ service, which should become available after a few seconds. Once it’s ready, you can execute it simply with curl:

$ curl .sslip.io

(If you prefer to use Minikube, you can follow this tutorial instead.)

Thanks to Knative, developers can roll out new versions of their services (called „revisions“ in Knative terminology) while the old ones are still running, and even distribute traffic among them. This can be very useful in A/B testing sessions, for example. Knative services can be triggered by a large array of events, with great flexibility.

A full introduction to Knative is outside of the scope of this review, so here are some resources we recommend to learn everything about Knative serving and eventing:

• The excellent and funny „Knative in Action“ (2021) book by Jacques Chester, available for free courtesy of VMWare.
• A free, full introduction to Knative (July 2021) by Sebastian Goasguen, the founder of TriggerMesh; a video and its related source code are provided as well.
• And to top it off, the „Knative Cookbook“ (April 2020) by Burr Suter and Kamesh Sampath, also available for free, courtesy of Red Hat.

Interested in Knative and Red Hat OpenShift Serverless? Get in touch with us and let us help you in your FaaS journey!

As part of our ongoing improvement process, we evaluate the requirements and new features of each version of Red Hat OpenShift, not only for our customers, but also for our internal use. Version 4.9 of Red Hat’s flagship container platform was announced October 18th, 2021 and it included some very important changes, some of which are potentially breaking ones.

In this article, targeted towards DevOps engineers and maintenance crews, I will provide a short overview of the most important points to take care before upgrading to this new version.

Kubernetes 1.22

The most important change in OpenShift 4.9 is the update to Kubernetes 1.22. This release of Kubernetes has completely removed APIs marked as v1beta1. The complete list is available in the Red Hat documentation website, but suffice to say that common objects such as Role or RoleBinding (rbac.authorization.k8s.io/v1beta1) and even Ingress (networking.k8s.io/v1beta1) are no more.

This is a major change, and it needs to be taken care of for all users of your clusters before an upgrade takes place, and all manifest files using those resources should be updated accordingly. Red Hat’s Knowledge Base includes a special article explaining all the steps required for upgrading to OpenShift 4.9.

And of course, if you need any help regarding the upgrade process towards OpenShift 4.9, just contact us, we will be glad to help you and your teams.

Mutual TLS Authentication

Mutual TLS is a strong way to secure an application running in the cloud, allowing a server application to authenticate any client connecting to it. It comes with some complexity to setup and manage, as it requires a certificate authority. But thanks to its inclusion as a feature in OpenShift 4.9, its usage is much simpler now.

Please check the release notes section related to Mutual TLS for more information.

Registry Multiple Logins

In previous versions of OpenShift, you could only list one repository from a given registry per project. OpenShift 4.9 includes multiple logins to the same registry, which allows pods to pull images from specific repositories in the same registry, each with different credentials. You can even define a registry with a specific namespace. The documentation contains examples of manifests to use this feature.

Changes to lastTriggeredImageID Field Update

And finally, here’s a change that can cause unforeseen headaches to your teams: OpenShift 4.9 does not update anymore the buildConfig.spec.triggers[].imageChange.lastTriggeredImageID field when the ImageStreamTag changes and references a new image. This subtle change in behavior is easy to overlook, and if your team depends on this feature, beware for trouble.

Learn More about OpenShift 4.9

If you’re interested in knowing what else changed in OpenShift 4.9, here are some selected resources published by Red Hat to help you:

• Red Hat OpenShift 4.9 Is Now Generally Available
• OpenShift Container Platform 4.9 release notes
• Time Is On Your Side: A Change to the OpenShift 4 Lifecycle
• How Customer Feedback Shaped OpenShift 4.9
• Ask an OpenShift Admin Office Hour – What’s new in OpenShift 4.9?
• Kuryr in OpenShift 4.9
• Introducing New Virtualization Features in OpenShift 4.9

Lass uns das Thema der Microservices-Architektur ein wenig tangential angehen. Die meisten Diskussionen darüber drehen sich um technologische Aspekte: Welche Sprache man wählen sollte, wie man die meisten RESTful-Services erstellt, welches Service Mesh am leistungsfähigsten ist usw.

Bei VSHN haben wir jedoch schon vor langer Zeit herausgefunden, dass der wichtigste Erfolgsfaktor für Softwareprojekte die Menschen sind. Und die These dieses Artikels ist, dass die Wahl von Microservices als Architekturmuster mehr mit der Organisationsstruktur deines Unternehmens zu tun hat als mit den technologischen Zwängen und Funktionen des Endprodukts.

Oder anders ausgedrückt: Dein Team hat sich bereits für eine Architektur für ihre Software entschieden, auch wenn es sich dessen nicht ganz bewusst ist. Und siehe da: Microservices könnten das sein oder auch nicht.

Definition

Zunächst einmal müssen wir die Microservices-Architektur definieren. Was ist das?

„Microservices“ ist ein Architekturmuster, bei dem die Funktionalität des gesamten Systems in völlig unabhängige Komponenten zerlegt wird, die über das Netzwerk miteinander kommunizieren.

Das Gegenstück zur Microservices-Architektur ist der so genannte „Monolith“, der in den letzten 25 Jahren der häufigste Ansatz für Webapplikationen und -dienste war. In einem Monolithen sind alle Funktionen der Anwendung, von der Datenverwaltung bis zur Benutzeroberfläche, in einem einzigen Binary oder Paket enthalten.

Auf der gegenüberliegenden Seite der Strasse finden wir die Microservices-Architektur, bei der jeder Dienst für seine eigene Implementierung und Datenspeicherung verantwortlich ist.

Per Definition sind Microservices feingranular und haben einen einzigen Zweck. Sie weisen eine starke Kohäsion auf, d. h. die von ihnen eingekapselten Vorgänge sind in hohem Masse miteinander verbunden. Sie sind ein Beispiel für das „Single Responsibility Principle“. Sie werden auch separat bereitgestellt, mit deutlich abgegrenzten Kontexten, und sie erfordern DevOps-Ansätze für ihre Bereitstellung und Verwaltung, wie Automatisierung und CI/CD-Pipelines.

Sehr wichtig ist, dass die Microservices-Architektur eine „Share-Nothing-Architektur“ ist, bei der die einzelnen Dienste niemals gemeinsamen Code über Bibliotheken teilen, sondern die gesamte Interaktion und Kommunikation auf das sie verbindende Netzwerk beschränkt ist.

Und nicht zuletzt sollten Microservices (wie der Name schon sagt) so klein wie möglich sein, einen geringen Speicherbedarf haben und in Sekundenschnelle starten und stoppen können.

Angesichts all dieser Merkmale sind Microservices das mit Abstand komplexeste Architekturmuster, das je geschaffen wurde. Es ist schwer zu planen, kann die Komplexität von Projekten drastisch erhöhen und war für einige Teams erfahrungsgemäss nicht zu bewältigen.

Geschichte

Die Idee, dass sich „Komponenten gegenseitig Nachrichten schicken“, ist absolut nicht neu. Bereits 1966 prägte einer der grössten Informatiker aller Zeiten, Alan Kay, den Begriff „objektorientierte Programmierung“. Die Industrie hat seine ursprüngliche Definition, die wie folgt lautete, übernommen und verformt:

OOP bedeutet für mich nur Messaging, lokale Speicherung und Schutz und Verstecken von State-Process, und extreme Late-Binding aller Dinge.

Alan Kay, Quelle.

Dieser Text stammt aus dem Jahr 2003, der folgende aus dem Jahr 1998:

Die grosse Idee ist „Messaging“ – das ist es, worum es im Kern von Smalltalk/Squeak geht (…) Der Schlüssel zum Aufbau grossartiger und wachstumsfähiger Systeme liegt eher darin, zu entwerfen, wie die Module kommunizieren, als was ihre internen Eigenschaften und Verhaltensweisen sein sollten.

Alan Kay, Quelle.

Alan Kay entwickelte in den 1970er Jahren die Programmiersprache Smalltalk, die auf diesen Konzepten basiert. Und nach der Lektüre der obigen Texte wird klar, dass die Microservices-Architektur zu einem grossen Teil eine Umsetzung von Alan Kays Ideen von Messaging, Entkopplung und Abstraktion ist, die auf die Spitze getrieben wurde.

Um den heutigen Stand der Microservices zu erreichen, waren jedoch viele weitere Durchbrüche erforderlich. In den 2000er Jahren wurde mit dem Aufkommen von XML, dem SOAP-Protokoll und den damit zusammenhängenden Webdiensten der Begriff „serviceorientierte Architektur“ zu einem weit verbreiteten Grundnahrungsmittel in Architekturdiskussionen. Mit dem Aufkommen agiler Methoden wandte sich die Branche dem REST-Ansatz anstelle von SOAP zu. Im letzten Jahrzehnt ermöglichten das Aufkommen von DevOps und der Aufstieg der Containerisierung durch Docker und Kubernetes den Teams schliesslich die Bereitstellung von Tausenden von Containern als Microservice-Architektur, dank des gesamten Katalogs der Cloud-Native-Technologien.

Pro und Kontra

Wenn Microservice-Architekturen so komplex sind, warum sollten sie dann eingesetzt werden? Es stellt sich heraus, dass sie viele Vorteile bringen können:

• Da jede Komponente vollständig von den anderen isoliert werden kann, können die Teams, sobald sie sich auf ihre Schnittstellen geeinigt haben, diese zu 100 % unabhängig von den anderen entwickeln, dokumentieren und gründlich testen. Auf diese Weise können die Teams parallel vorgehen und Funktionen implementieren, die zu 0 % miteinander kollidieren können.
• Die Teams werden ausserdem ermutigt, die Programmiersprache zu wählen, die am besten zu der jeweiligen Aufgabe passt, die ihr Microservice erfüllen muss.
• Da es sich per definitionem um „Mikro“-Dienste handelt, sind sie so konzipiert, dass sie schnell gestartet und wieder beendet werden können, so dass sie nur bei Bedarf eingreifen und das gesamte System effizienter und reaktionsfähiger machen.
• Die Grösse von Microservices ermöglicht auch eine höhere Verfügbarkeit, da es möglich ist, viele von ihnen hinter einem Load Balancer zu haben; sollte eine Instanz eines Microservices ausfallen, kann sie schnell entlassen werden und eine neue an ihrer Stelle instanziiert werden, ohne dass die Verfügbarkeit verloren geht.
• Systeme können schrittweise aktualisiert werden, wobei jedes Team Fehler behebt und Funktionen hinzufügt, ohne die anderen zu stören. Solange die Schnittstellen beachtet (und schliesslich versioniert) werden, gibt es keinen Grund, dass das System unter den Aktualisierungen leidet.

Es gibt jedoch viele Gründe, sich nicht für die Microservices-Architektur zu entscheiden; unter den wichtigsten sind:

• Leistung: Ein mit Microservices aufgebautes System muss die Latenz zwischen diesen Diensten berücksichtigen; und in dieser Hinsicht sind monolithische Anwendungen schneller; ein Funktionsaufruf ist immer schneller als ein Netzwerkaufruf.
• Reife des Teams: Microservices erfordern von den Teams ein gewisses Mass an Erfahrung und Fachwissen; bei Teams, die neu im Bereich Microservices sind, ist die Wahrscheinlichkeit eines Projektfehlschlags höher.
• Kosten: Die Erstellung eines Microservices-Systems ist, wenn überhaupt, teurer, da jeder einzelne Dienst einen Overhead verursacht.
• Machbarkeit: Manchmal ist es einfach nicht möglich, Microservices zu nutzen, zum Beispiel wenn es um Altsysteme geht.
• Teamstruktur: Dies ist ein entscheidender Faktor, auf den wir später noch ausführlich eingehen werden.
• Komplexität: Es ist nicht ungewöhnlich, dass Systeme aus Tausenden von gleichzeitigen Diensten bestehen, und dies führt zu Herausforderungen, auf die wir später noch eingehen werden.

Ich möchte nun auf die letzten beiden Punkte eingehen, die unserer Erfahrung nach die grössten Probleme bei Microservice-Implementierungen darstellen: Teamstruktur und die Wahrnehmung und Bewältigung von Komplexität.

Conway’s Law

Einer der entscheidenden Faktoren, der die Fähigkeit von Teams zur Implementierung von Microservices einschränkt, ist oft unsichtbar und wird übersehen: Ihre eigene Struktur. Auch dieses Phänomen ist nicht neu. Im Jahr 1968 schrieb Melvin A. Conway für die Zeitschrift Datamation einen Artikel mit dem Titel „How Do Committees Invent?“, in dem die folgende Idee hervorsticht:

Die Grundthese dieses Artikels ist, dass Organisationen, die Systeme entwerfen (…), gezwungen sind, Designs zu produzieren, die Kopien der Kommunikationsstrukturen dieser Organisationen sind.

Melvin Conway, Quelle.

Dafür gibt es umfangreiche Belege, sowohl anekdotische als auch empirische, die durch die Forschung belegt sind.

Die Konsequenz dieses Prinzips ist die folgende: Die Entscheidung zwischen einer monolithischen und einer Microservices-Architektur ist bereits im hierarchischen Diagramm einer jeden Organisation verankert.

Eine der Dienstleistungen, die wir bei VSHN anbieten, befasst sich genau mit diesem Thema. In unserem „DevOps-Enablement-Workshop“ bewerten wir den Grad der Agilität von Organisationen sowie das Ausmass und die Verbesserungen, die DevOps bringen könnte. Auf der Grundlage dieser Informationen führen wir ein Reverse-Engineering ihrer Struktur durch das Conway’sche Gesetz durch, um einen Ausgangspunkt für ihre digitale Transformation zu finden.

Komplex vs. Kompliziert

Ein weiterer wichtiger Punkt ist die Unterscheidung zwischen „komplex“ und „kompliziert“, da diese beiden Wörter in der Alltagssprache manchmal miteinander verwechselt werden können, und um die Sache noch schwieriger zu machen, kann das Wort „einfach“ als Antonym für beide verwendet werden.

„Komplex“ kommt aus dem Lateinischen complexus und bedeutet „aus ineinander verschlungenen Elementen bestehend“. Complexus ist wiederum von plectere („biegen, verflechten“) abgeleitet. Dieses Wort wird seit dem XVI. Jahrhundert verwendet, um etwas zu bezeichnen, das sich aus heterogenen Elementen zusammensetzt. Es hat dieselbe Wurzel (plectere) wie der medizinische Begriff „Plexus“, der „Geflecht“ bedeutet und seit dem 16. Jahrhundert als medizinischer Begriff für „Nerven- oder Blutgefässnetz“ verwendet wird.

(Quelle: Dictionnaire historique de la langue française von Alan Rey)

„Kompliziert“ hingegen hat einen ähnlichen Ursprung, aber eine andere Konstruktion: Es kommt vom lateinischen complicare, was wörtlich „zusammenfalten“ bedeutet. Im übertragenen Sinne wurde dies als Nähe zum Begriff der Peinlichkeit oder Unbeholfenheit verstanden. Das Wort setzt sich aus dem Wort plicare zusammen, das „falten“ bedeutet. Uhren, die gemeinhin als „Komplikationen“ bezeichnet werden (wie das Kaliber 89 von Patek Philippe, die Aeternitas Mega von Franck Muller und die „Référence 57260“ von Vacheron Constantin), sind per Definition komplizierte Maschinen.

Kurz gesagt, „komplex“ und „kompliziert“ stammen von leicht unterschiedlichen Wurzeln ab: Der lateinischen Wurzel plectere („verflechten“) für Ersteres und plicare („falten“) für Letzteres. Der Begriff „kompliziert“ vermittelt die Vorstellung eines Netzes von miteinander verflochtenen Objekten, deren Zustand und Verhalten sich durch die Interaktion mit anderen Objekten in diesem Netz ständig ändert. Das Wort kompliziert impliziert eine inhärente scheinbare „Unklarheit“ durch Faltung in sich selbst, die zu einem „sich entfaltenden“ Entdeckungsprozess einlädt.

Oder anders ausgedrückt: einzelne Microservices sollten nicht kompliziert sein, aber eine Microservice-Architektur ist per Definition komplex. Monolithen hingegen neigen dazu, mit der Zeit sehr kompliziert zu werden. Und natürlich sind beide nicht einfach.

Die Geschichte zeigt, dass Softwareentwickler ein leidenschaftliches Verhältnis zur Kompliziertheit haben; komplizierte Systeme sind grossartig, um auf Hacker News damit zu prahlen, während Maintainer auch privat über sie weinen.

Eine „Best Practice“ hat in diesem Zusammenhang eine und nur eine grundlegende Aufgabe: den Ingenieuren zu helfen, das Komplizierte in das Komplexe zu übersetzen. Die meisten softwarebezogenen Katastrophen werden durch eine einfache Tatsache verursacht: Aufgrund von Fristen, Organisation, Werkzeugen oder schlichtweg Unwissenheit neigen Softwareentwickler dazu, komplizierte statt komplexe Systeme zu bauen.

Dies ist ein weiterer Punkt, um den wir uns in unserem DevOps-Workshop kümmern, und zwar durch die Bewertung der aktuellen Ressourcen (nicht nur Quellcode, sondern auch aktuelle Datenbankschemata, Sicherheitsanforderungen, Netzwerktopologien, Bereitstellungsverfahren und -rhythmen usw.).

Migrieren oder umschreiben? Gleichgewicht

Die Kompliziertheit von Monolithen an sich ist nicht problematisch; sie führt zu eng gebundenen Systemen, die in der Regel sehr schnell sind, da, wie gesagt, ein Funktionsaufruf schneller ist als ein Netzaufruf. Schliesslich haben wir in der Vergangenheit sehr erfolgreich Monolithen gebaut. Aber die Erfahrung zeigt, dass sie in Bezug auf Verfügbarkeit und Skalierbarkeit Probleme bereiten. Microservices stellen einen diametral entgegengesetzten Ansatz dar, der eher auf Komplexität als auf Kompliziertheit beruht, der aber diese Probleme löst.

Es besteht also ein Spannungsverhältnis zwischen Komplexität und Kompliziertheit auf der einen und organisatorischen Zwängen auf der anderen Seite. Mit anderen Worten, es besteht ein Spannungsverhältnis zwischen monolithischen und Microservices-Systemen auf der einen Seite und mehr oder weniger hierarchischen Strukturen auf der anderen Seite. Ein Gleichgewicht zwischen diesen Kräften zu erreichen, ist also die technische Herausforderung, der sich Softwarearchitekten heutzutage stellen müssen.

Viele Teams stehen heute vor der Aufgabe, ihre Monolithen auf Microservice-basierte Architekturen zu migrieren, entweder auf Wunsch des Managements oder auf Grund von Kunden- oder Lieferantenanforderungen. Architekten können zum Glück einige Techniken anwenden, um ein Gleichgewicht zu finden:

1. Beginne den Migrationspfad im Bewusstsein, dass oft nicht die gesamte Anwendung auf Microservices umgestellt werden muss. Einige Teile können und sollten monolithisch bleiben, und insbesondere bewährte ältere Systeme, auch wenn sie in COBOL oder älteren Technologien geschrieben wurden, können immer noch einen Wert darstellen und eine sehr wichtige Rolle für den Erfolg des Übergangs spielen.
2. Identifiziere die Komponenten richtig, so dass sie im isolierten Zustand weder nur funktions-, noch nur daten-, noch nur anforderungsgesteuert sind, sondern von diesen drei Faktoren (Funktionalität, Daten und Anforderung) gleichzeitig gesteuert werden. Achte auf das Organigramm und verwende dieses als Grundlage für die Dekomposition in Microservices.
3. Denke daran, dass die Netzwerkbandbreite nicht unbegrenzt ist. Einige Schnittstellen sollten „klobig“ sein, während andere „gesprächig“ sein sollten. Plane von Anfang an Latenzprobleme ein.
4. Reduziere die Kommunikation zwischen den Dienststellen so weit wie möglich, was auf verschiedene Weise geschehen kann:
   1. Konsolidierung der Dienste
   2. Konsolidierung von Datendomänen (Kombination von Datenbankschemata oder Verwendung gemeinsamer Caches)
   3. Verwendung von Technologien wie GraphQL zur Verringerung der Netzwerkbandbreite
   4. Verwendung von Messaging-Warteschlangen, wie RabbitMQ.
5. Einführung von Microservice-freundlichen Technologien wie Docker-Container, Kubernetes, Knative oder Red Hat OpenShift und Quarkus.
6. Implementiere eine automatisierte Teststrategie für jeden einzelnen Microservice.
7. Standardisiere Technologie-Stacks rund um Container und Kubernetes und schaffe eine gemeinsame Basis für ein echtes Microservice-Ökosystem in Unternehmen.
8. Automatisiere die Arbeit so weit wie möglich, da sich der Aufwand für die Automatisierung (DevOps, CI/CD) über viele Dienste hinweg amortisieren kann und sich somit langfristig als Nettoinvestition erweist.

Wie bereits erwähnt, helfen wir Organisationen regelmässig bei ihrer digitalen Transformation in Richtung Microservices, Kubernetes, OpenShift, DevOps, CI/CD, GitLab und DevOps im Allgemeinen, um ihre Teams mit den Werkzeugen zu unterstützen, die sie in der Zukunft benötigen werden. In Anlehnung an das Konzept der Team-Topologien von Henny Portman kann VSHN sowohl als „Enabling Team“ (DevOps-Workshops, Beratung) als auch als „Platform Team“ (Kubernetes/OpenShift) unterstützen, um Microservices zu entwickeln und Stabilität und Sicherheit zu gewährleisten.

Schlussfolgerung

Microservice-Architekturen sind nicht nur ein Hype, sondern bringen auch grosse Vorteile mit sich, können aber auch eine grosse Herausforderung für Software-Teams darstellen.

Der beste Weg, diese Herausforderungen zu bewältigen, besteht darin, das Conway’sche Gesetz umzukehren und zunächst die menschliche Organisation deiner Teams zu analysieren. Mach sie unabhängig, agil und frei in der Wahl der besten Werkzeuge für ihre Arbeit. Ermutige sie, untereinander die Schnittstellen ihrer jeweiligen Komponenten auszuhandeln.

Lass uns komplexe, nicht komplizierte Systeme schaffen und betreiben. Wir können uns nicht von der Komplexität lösen; das ist unsere Aufgabe als Ingenieure. Aber wir können den komplizierten Teil loswerden.

Abschliessend möchte ich meinen ehemaligen Kollegen und lebenslangen Freund Adam Jones, einen unabhängigen IT-Berater aus Genf, zitieren: Um mit der Microservice-Architektur Erfolg zu haben, musst du Struktur in deine Aktivitäten einbetten und sie aus der Hierarchie entfernen. Es geht nicht darum, die Struktur verschwinden zu lassen, sondern sie dorthin zu verlagern, wo sie am meisten Nutzen bringt.

On the evening of August 25th, 1991, Linus Torvalds wrote a short message on the comp.os.minix Usenet newsgroup:

I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.

Fast-forward 30 years, and to make a long story short, well: Linux is now both big and professional. It’s nearly everywhere, hidden behind the shiny graphical user interface of your smartphone or tablet (well, except for iOS users), in your gaming box, in your car, and even on Mars.

I discovered Linux as a young boy still at school, in 1998. It was in a book store where I was attracted by a shiny package (I had no idea what Linux was) called „SuSE Linux 6.0“ (nowadays available for download from archive.org), and since then I couldn’t stop working with it.

Over time, I got more and more into Linux, and it became an important hobby, with all my PCs running Linux, and also on my home server under my desk at home. Many years later, in 2011, I could finally start working full-time as a Linux administrator. My desktop computer has been only powered by Linux since around 2004, and I’ve been a big fan of KDE ever since.

Today, the Linux Kernel is more present, yet less visible than ever. We interact with it on containers and in VMs on the cloud, and it gets more and more abstracted away, deep down in serverless architectures, making the Kernel even more invisible than ever before. Albeit out of sight of most users, Linux has become much more solid, mature, and pervasive, and does its great job behind the scenes without interruption.

Linux empowers VSHN at all levels; not only it is the dominating technology we use every day, empowering Kubernetes, containers, and cloud VMs, but it is also the operating system that the majority of VSHNeers (around 66%, according to an internal poll) use for their daily job, the remaining third using macOS or Windows.

Some numbers: of those two thirds of VSHNeers that use Linux every day in their laptops, 61% chose Ubuntu (or one of its various derivatives); 17% use Arch, 11% Fedora, and others use Debian, Mint, and other distributions. Some even contemplate switching to Qubes OS soon! As for desktop environments, around 35% use GNOME, 25% use KDE, 20% use i3, and 6% use Cinnamon.

Each one of us VSHNeers has a unique feeling about Linux; here are some thoughts about what Linux means to us:

Before using Linux, I was primarily focused on how to use and work with computer systems. With the switch to Linux I started to understand how they actually work.

What I really appreciate about Linux is that it’s (still relatively) lightweight, powerful, transparent and adaptable. I do heavyweight gaming and video livestreaming on the same OS that runs my file servers and backup systems (not all on the same machine, don’t worry). Even my car and my television run Linux! This universality combined with the permissive licenses means that whenever one industry improves Linux (the kernel), every other industry profits.

I originally just wanted to play Minecraft with my friends. Suddenly I had to learn how to host this on a Linux server, which then turned into a fascination on how things work on the backstage. It’s the urge to see how our modern society works!

Linux is the operating system of our software-driven world.

On to the next 30 years of Linux!

One of the most difficult subjects in the world of Kubernetes is storage. In our day-to-day operations we’ve often had to choose the best storage solution for our customers, but in a changing landscape of requirements and technical offerings, such choice becomes a major task.

Faced to many options, we decided to benchmark storage solutions in real life conditions, to generate the data required for a proper decision. In this article we’re going to share with you our methodology, our results, and our final choice.

The chosen storage providers for this evaluation were:

• Ceph on Rook and OpenShift Data Foundation (previously known as OpenShift Container Storage)
• Longhorn
• Gluster (benchmarked on APPUiO Exoscale OpenShift 3.11)

All of these benchmarks (except Gluster) were run on an OpenShift 4.7 cluster on Exoscale VMs.

We benchmarked Ceph both with unencrypted and encrypted storage for the OSDs (object-storage daemons). We included Gluster in our evaluation for reference and comparison only, as that’s the solution we offered for storage on OpenShift Container Platform 3.x. We never intended to use Gluster as the storage engine for our new Kubernetes storage cluster product.

Methodology

We first created a custom Python script driving kubestr, which in turn orchestrates Fio. This script performed ten (10) iterations for each benchmark, each of which included the following operations in an isolated Fio run:

• Read iops
• Read bandwidth
• Write iops, with different frequencies of calls to fsync:
  • no fsync calls during each benchmark iteration
  • an fsync call after each operation („fsync=1“)
  • an fsync call after every 32 operations („fsync=32“)
  • an fsync call after every 128 operations („fsync=128“)
• Write bandwidth, with different frequencies of calls to fsync:
  • no fsync calls during each benchmark iteration
  • an fsync call after each operation („fsync=1“)
  • an fsync call after every 32 operations („fsync=32“)
  • an fsync call after every 128 operations („fsync=128“)

This is the Fio configuration used for benchmarking:

[global]
randrepeat=0
verify=0
ioengine=libaio
direct=1
gtod_reduce=1
[job]
name=JOB_NAME     (1)
bs=BLOCKSIZE      (2)
iodepth=64
size=2G
readwrite=OP      (3)
time_based
ramp_time=5s
runtime=30s
fsync=X           (4)

1. We generate a descriptive fio job name based on the benchmark we’re executing. The job name is generated by taking the operation („read“ or „write“) and the measurement („bw“ or „iops“) and concatenating them as „OP_MEASUREMENT“, for example „read_iops“.
2. The blocksize for each operation executed by fio. We use a blocksize of 4K (4kB) for IOPS benchmarks and 128K (128kB) for bandwidth benchmarks.
3. The IO pattern which fio uses for the benchmark. randread for read benchmarks. randwrite for write benchmarks.
4. The number of operations to batch between fsync calls. This parameter doesn’t have an influence on read benchmarks.

If writing to a file, issue an fsync(2) (or its equivalent) of the dirty data for every number of blocks given. For example, if you give 32 as a parameter, fio will sync the file after every 32 writes issued. If fio is using non-buffered I/O, we may not sync the file. The exception is the sg I/O engine, which synchronizes the disk cache anyway. Defaults to 0, which means fio does not periodically issue and wait for a sync to complete. Also see end_fsync and fsync_on_close.

Fio documentation

Results

The following graph, taken from the full dataset for our benchmark (available for download and study) shows the type of comparison performed across all considered solutions.

The table below gives an overview over the data gathered during our evaluation (each column shows mean ± standard deviation):

Unencrypted Rook/OCS numbers are from OCS, encrypted Rook/OCS numbers from vanilla Rook.

Conclusion

After careful evaluation of the results shown above, we chose Rook to implement our APPUiO Managed Storage Cluster product. Rook allows us to have a single product for all the Kubernetes distributions we’re offering at VSHN.

We have released the scripts on GitHub for everyone to verify our results, and published even more data in our Products documentation. Feel free to check the data, run these tests in your own infrastructure, and of course, your pull requests are more than welcome.

Welcome to the third and last installment of our „Networking Security“ blog post series. If you didn’t read the previous ones yet, go ahead and read the first two parts:

• Part 1: What is TLS?
• Part 2: Verifying and Connecting
• Part 3: Trust and Certificate Chains

In this article we’ll talk about trust, and how it’s implemented thanks to certificate chains.

Chain of Trust

As explained in the previous posts, a server certificate can be signed by a CA certificate in order to confirm their identity. We trust that the CA has verified the contents of the server certificate before signing it, and hence we trust that the contents of the server certificate are valid.

Now, since a certificate that is used to sign other certificates, can in turn be signed by another certificate, we can build a whole „chain of trust“:

• At the top, there is the Root Certificate (also called the Anchor). It is signed by itself (self-signed).
• In between, there may be one or more Intermediate Certificates. They are signed by either other intermediates or the root certificate.
• On the bottom is our server (or client) certificate, called the Leaf Certificate.

In order to verify trust of a leaf certificate, we follow the „certificate chain“ upwards until we reach a root certificate we already know and trust.

Root Certificates

In order to know which root certificates to trust, we must have a „trust store“ containing all the root certificates. This store is usually provided by the operating systems, but some clients (most notably web browsers) have their own „trust store“.

In order for a CA to have its root certificate accepted into the trust store of an operating system or browser, they must meet certain quality criterias. They must prove that they take CSR validation seriously and that they have measures put in place to keep their private key confidential.

Having their private key stolen by an attacker is the absolute worst-case scenario for any CA. It would mean that the attacker could create and sign ANY certificate using the CA’s cert! And since the CA’s certificate is trusted by all operating systems, clients connecting to the attacker would be none the wiser!

The only way to react to a compromised key is to rotate it, that is, to create a new one using a new private key. This however would mean that the certificate also has to be replaced in all trust stores. Since this can take a long time for some operating systems or clients, CA’s usually only use Intermediate Certificates to sign your certificates, and store the root key somewhere safe (and by safe I mean printed out on a piece of paper and stored in an actual safe.)

Intermediate Certificates

As explained, CA’s usually use an Intermediate Certificate to sign your CSR’s. An Intermediate Certificate, in turn, can be signed by either the Root Certificate or another Intermediate Certificate. This means that, in theory, there could be any number of intermediate certificates between your server (leaf) certificate and the Root. In practice, however, there is usually only one or two intermediates.

CA Bundles

In order to verify a certificate, a client must possess the certificate that was used to sign it. So in order to verify the whole chain, it must have each intermediate certificate as well as the root certificate. The root certificate we already have in our trust store. But what about the intermediates?

When a CA has signed your CSR and sends you back the certificate, they will also send you all the intermediate certificates between your server cert and the Root. This is called the „CA bundle“ or „CA chain“.

When we install our Server certificate in our web server, we also provide it the CA bundle. And when a client connects to the server, the server will send along the bundle with the certificate. This is safe because as long as one of the certificates in the chain is signed by a trusted root certificate, we know that we can trust the whole chain.

Note that the root certificate itself must NOT be part of the chain. It MUST come from the client’s trust store! Unfortunately some CA’s have the bad habit to include their root in the CA bundle, so make sure to remove it before configuring your webserver.

If you check your website against SSL Labs‘ SSL Server Test, it will warn you if either intermediates are missing or the root („anchor“) is included.

Closing Words

Congratulations, you’ve made it! You should now have some basic understanding about TLS/SSL certificates, what they do, and how they work!

Thanks to various browser vendors‘ efforts, HTTPS has become the norm when surfing the web in recent years. And now that you’re armed with knowledge, there is no excuse anymore to serve your websites unencrypted!

Welcome to the second article of a series of three, about the subject of security in networking applications, TLS, certificates, keys, and more.

• Part 1: What is TLS?
• Part 2: Verifying and Connecting
• Part 3: Trust and Certificate Chains

In the first part, we learnt about TLS/SSL, certificates, CAs and Keys. If you haven’t read it yet, please do so now.

Now that we know all about the pieces of the puzzle, how do they all fit together? Let’s have a closer look!

Issuing Certificates

To begin with, we need to obtain a certificate. The process works something like this:

First, we need a public/private key pair. With it, we can now create a new CSR (short for „Certificate Signing Request“). The CSR contains all the details we want to include in the certificate (the „Subject“) as well as the public key. We then send the CSR to the CA (the „Certificate Authority“).

The CA then verifies the contents of our CSR, and signs it with their own certificate and private key. This results in a new certificate with the details from our CSR, its „Issuer“ field set to the „Subject“ of the CA’s certificate, and our public key embedded. The CA then sends the new certificate back to us.

And that’s it! We now have a certificate that is signed by the CA, and we have the accompanying private key. We can now install the certificate in our web server.

Establishing Connections

The whole purpose of certificates and keys is to create secure channels through which devices can exchange information, without the risk of snooping by third parties. In other words, security experts call this „being able to send secrets on a postcard“, and all things considered, the analogy is quite appropriate.

So, how do we establish a secure connection with SSL? The following things are required:

1. A (web) server with:
   • A CA certificate;
   • A server certificate;
   • And a server certificate key (with its corresponding passphrase).
2. And a client (usually a web browser) with a list of trusted CA certificates.

With all this in place, we can establish a trusted, secure connection between both:

1. The client opens a TLS connection to the server.
2. The server responds with its certificate.
3. The client verifies that the server certificate was indeed signed by a trusted CA.
4. The client verifies that the server certificate’s CN attribute (part of the „Subject“, remember?) matches the requested URL.
5. The client verifies that the server certificate is not expired.
6. The client can optionally check that the server’s certificate has not been revoked, either by using a CRL (a „Certificate Revocation List“), or a mechanism like OCSP (an „Online Certificate Status Protocol“).

After these steps, the client has established an encrypted connection, and verified that the server it is connected to is indeed the one it claims to be.

The client and the server can now exchange data securely with one another, without the risk of a third party being able to read their interactions, or even worse, manipulating them!

Client Certificates

There is however another use case for certificates, and that is Client Authentication. Remember how in the example above the server’s certificate was used to verify its identity? This works the other way around too!

If we have a client certificate that is signed by a CA known to the server, we can establish a mutually trusted, secured connection.

To achieve this, we need the following things:

1. A server with:
   • A CA certificate;
   • A server certificate;
   • And a server certificate key (with its corresponding passphrase).
2. A client with:
   • A CA certificate;
   • A client certificate;
   • And a client certificate key (again, with its corresponding passphrase).

Once all the things are in place, a mutually trusted, secured connection can be established:

1. The client opens a TLS connection to the server, sending its certificate.
2. The server responds with its own certificate.
3. The client verifies that the server certificate was indeed signed by a trusted root.
4. The client verifies that the server certificate’s CN attribute matches the requested URL.
5. The client verifies that the server certificate is not expired.
6. The client can optionally ensure the server’s certificate was not revoked.
7. The server verifies that the client certificate was indeed signed by a trusted root (our CA certificate in this case).
8. The server verifies that the client certificate is not expired.
9. The server can optionally ensure the client’s certificate was not revoked.

After these steps, both client and server have established an encrypted connection, one in which both parties are who they claim they are. The server can now read the client’s certificate details (mostly the Subject) to identify the client.

And just like previously, our connection is now fully encrypted and all communications flowing through it are confidential.

Coming Up

In the last part of this series, we are going to talk about some technical details about chains, roots, and intermediates. Stay tuned!

Tobias Brunner’s lightning talk at Crossplane Community Day Europe 2021.

Watch the recording

The Crossplane Service Broker exposes Crossplane primitives via the Open Service Broker API. Tobias will introduce the concepts behind the Crossplane Service Broker and demonstrate to the audience how it all works together. By leveraging the Open Service Broker API while coupling it with the powerful concept of Crossplane Compositions it’s very easy to enable users of a platform which exposes Open Service Broker API integration (like Kubernetes Service Catalog or Cloudfoundry) to provision services fully automated. In a demonstration a real use case will be shown how a Redis service can be provisioned using the Open Service Broker API, leveraging the Crossplane Compositions and the Helm provider.

Slides: https://speakerdeck.com/tobru/self-service-provisioning-with-the-crossplane-service-broker

Note: This talk was held at the Crossplane Community Day Europe 2021

Also see: Crossplane – The Control-Plane of the future

Welcome to this first article of a series of three, about the subject of security in networking applications, TLS, certificates, keys, and more.

• Part 1: What is TLS?
• Part 2: Verifying and Connecting
• Part 3: Trust and Certificate Chains

We have noticed that many of our customers struggle to understand how TLS certificates work on a conceptual level. For example, how does „signing“ work? What does it even mean? What are a „chain“, an „intermediate“ or a „root“? Why do intermediates belong to a chain, but not the root? What is a CSR? How do CSR, Key, and certificate work together? And so on.

This series is an attempt to explain these critical concepts to our customers, starting this first part with the basic vocabulary and knowledge to get started.

HTTPS – TLS – SSL

Let’s talk about what we want to achieve first. When you visit a website via plain old HTTP, an attacker could intercept your request and grab any private information like usernames and password. Additionally, there is no way for you to verify that you indeed connected to the server you intended. An attacker could have modified the DNS response (which is also unencrypted) to send your browser to their server instead. See Man-in-the-middle attack on Wikipedia for more examples.

So in order to verify the identity of the server we connected to, and to make sure nobody except the server and our browser can read the data we exchange, websites these days use TLS („Transport Layer Security“, or its predecessor SSL „Secure Sockets Layer“) to both authenticate the server and encrypt the traffic.

From a technical perspective, TLS sits between TCP and HTTP on the protocol stack, and while it’s mostly known for being the S (for Secure) part in HTTPS, it’s noteworthy that it can be used for other protocols as well. Some examples:

• Email protocols: IMAPS, POP3S, SMPTS, …​
• Database connections: MySQL, PostgreSQL, MongoDB, etcd, …​
• Data transfer: FTPS
• Telephony: SIPS
• Chat: XMPPS, IRCS, …​

The last thing to note here is that there are different versions of TLS (and SSL), and some of them are not considered secure anymore!

From oldest to newest, at the time of writing (March 2021):

• SSLv1: Insecure, not supported anymore
• SSLv2: Insecure, not supported anymore
• SSLv3: Insecure, not supported anymore
• TLS 1.0: Insecure, deprecated
• TLS 1.1: Insecure, deprecated
• TLS 1.2: OK
• TLS 1.3: OK

Keep this in mind when planning your environment! You wouldn’t want to protect your brand new microservice with outdated security protocols!

By the way, if you want to check which TLS versions a website supports, use SSL Labs‘ SSL Server Test. It’s a great debugging tool and will show you a lot of information about the topics of this Blog post series!

Certificates

The next thing we should have a look at are Certificates, or more specifically X.509 v3 public key certificates.

A Certificate is a cryptographically signed piece of information, of which the most important part is the Subject, which identifies who this certificate belongs to, as well as the Issuer. Other attributes include details about when the certificate is about to expire as well as a lot of technical information about the key and signature algorithms used, and so on.

The Subject and Issuer of a certificate are characterized by a set of attributes:

• CN – Common Name
• C – Country
• ST – State
• L – Location (City)
• O – Organisation
• OU – Organisational Unit

Together, those attributes form a Distinguished Name (DN). Most attributes are optional, except for the Common Name. In the case of Server Certificates, the CN must match the address used to connect, for example www.vshn.ch.

The Certificate also contains a Public Key (embedded in the certificate) and its matching Private Key.

The last important feature of X.509 certificates is that they are signed by other certificates (or itself). Once a certificate is signed, its contents cannot be changed anymore.

Signing CAs

The Internet is a big place, so how do we know whom to trust? To solve this issue, the concept of Certificate Authorities came up.

A Certificate Authority (commonly referred to as CA) is a central trusted source of certificates. They have a CA Certificate (also known as the „root“ certificate) that is well known and trusted. This certificate is only used to sign other certificates. By signing another certificate, the CA confirms „yes, I trust this certificate and the information in it is correct.“

A related concept is a Certificate revocation list, also known as „CRL“, which is a list of digital certificates that have been revoked by the CA before their scheduled expiration date, and should therefore no longer be trusted.

Now that we have explained what a certificate is, let’s talk about keys.

Keys

Each certificate has its own key. The key makes certificates actually useful; without them, they would not work.

Each key consists of two parts: a public key and a private key. While the public key is embedded as part of the certificate itself, the private key is stored in a different file altogether.

In order to sign another certificate, you need the Private key of the signing certificate (but not of the certificate you want to sign).

When you open a connection to a server, the server also needs the private key of the server certificate in order to authenticate itself and establish encrypted communication.

This whole concept is called Public-key cryptography.

Confidentiality

A very important thing to understand is that the key is the only confidential piece in the puzzle; needless to say, it is the most important piece! So please, keep this always in mind: do not ever exchange keys over unsecured channels, under any circumstances!

On the other hand, the certificate itself is not confidential. The CA certificate in particular must be provided to all clients and servers, in order to verify other certificates.

How can a client ask a CA to sign a certificate? Through a CSR (also known as Certificate Signing Request) which, as the name implies, performs exactly this task.

Coming Up

Speaking about verification and issuing new certificates, we are going to talk about these subjects in detail, respectively in the second and third parts of this series. Stay tuned!

I think it can be said that at VSHN we have a certain obsession with documentation. This goes beyond the requirements set by our customers, or by those imposed by certifications such as the ISO 27001 or ISAE-3402. We have found that as a team we can work better when we can refer to written documentation at all times.

In the past few years we have standardized our documentation toolkit: we have adopted Asciidoctor as the lingua franca for our documentation. We have put in production various documentation websites based on Antora: our Handbook, our Knowledge Base, and the Project Syn documentation are some examples.

That works great for text. But what about diagrams? Our documentation has lots of them, and although embedding PNG files works fine, it does not “scale” very well.

For that reason we have set up an instance of Kroki in production (in APPUiO, of course!), to enable the generation of SVG diagrams based on various formats: PlantUML for UML diagrams, Nwdiag for network diagrams, and Ditaa for simple box-and-arrow kind of diagrams, all produced and shown in a crisp and neat SVG format. We love Kroki! It is such an awesome idea, that it has even been integrated to GitLab as a supported diagramming tool. How cool is that? In general, the Asciidoctor ecosystem has very good integration of diagrams into workflows, and this extends to Antora as well.

I am not going to dive into the benefits of vector vs. raster images; I think the readers of this article are well aware of the bonuses the former has over the latter. SVG diagrams look great in both online and print, but they can be a bit complicated to draw by hand (duh!).

But here’s a confession: I’m not a big fan of editing text-based diagrams either. But that’s just a personal choice. And the truth is, many other non-technical VSHNeers find the whole “diagrams as text” thing a bit arcane.

So that means that we needed a more accessible tool for them. The ideal diagram drawing tool for VSHN must have the following requirements:

• Cross-platform: Most of us at VSHN use Linux, but a sizable number also use Macs and Windows laptops.
• Accessible to non-technical VSHNeers: Not everyone at VSHN is a DevOps engineer.
• Simple to use: If possible, using a point-and-click interface; for example, in our Confluence wiki we have enabled the Gliffy extension, which allows non-technical users to create stunning diagrams.

So we started our search. Leaving aside tools like Inkscape, that are too generic, like Asciiflow, that are too limited, or like Dia, that are too platform-specific, it took us a while to find a tool that would fit our requirements. But we found it!

Please welcome Diagrams.net (previously also known as Draw.io). It is a web application geared specifically to the generation of diagrams, very easy to use and ticking all the boxes that we needed.

And even better, there is a Visual Studio Code extension that allows to edit diagrams locally, directly on your laptop, in Linux, Mac and Windows.

How do we integrate this with Antora? Very simple. In the assets/images folder of our documentation components, create your diagrams using the *.drawio.svg extension. These are automatically associated by Visual Studio Code with the extension, and provides a live editor with all the bells and whistles you might expect.

And then, well, just image::diagram.drawio.svg[] in your documents, git commit and push.

This approach is definitely more accessible to non-technical VSHNeers, making it super easy to edit diagrams online, or locally in Visual Studio Code.

To finish, here’s a Pro Tip™®©: switch the Draw.io extension to the “Atlas” theme, since some lines in the extension lack contrast, and aren’t easily seen when using a dark theme. You can change the Draw.io extension theme with the selector at the bottom right of the screen.

PS: there is an open issue in Kroki to add support for Draw.io diagrams. Can’t wait to see it in action!

Docker Inc., das Unternehmen, welches hinter Docker Hub steht, hat vor kurzem eine Beschränkungen der Image-Pull-Rate für Benutzer von Docker Hub angekündigt. Diese Änderung betrifft alle Cloud Native Installationen, die so konfiguriert sind, dass sie Container Images verbrauchen, welche in Docker Hub gespeichert sind, einer der populärsten Container Registries. Diese Massnahme hat direkte Auswirkungen auf den Einsatz vieler Kundenanwendungen, die derzeit auf APPUiO Public und privaten Clustern laufen.

Wir verfolgen die Situation aufmerksam. Nach den jüngsten Ankündigungen beginnt der Docker Hub langsam damit, eine Begrenzung der Abrufrate auf 100 Abrufe pro 6 Stunden für anonyme (nicht authentifizierte) IP-Adressen und 200 Abrufe pro 6 Stunden für authentifizierte kostenlose Benutzer durchzusetzen. Dies bedeutet, dass ein gesamter Kubernetes- oder OpenShift-Cluster ohne authentifizierung für alle seine Benutzer nur 100 Container Images in 6 Stunden von Docker Hub abrufen kann. Während Wartungsperioden werden üblicherweise die meisten Container Images eines Clusters abgerufen. Eine Reduzierung der Limite für die Abrufrate kann aus diesem Grund zu Ausfallzeiten führen.

Diese Situation sollte das heutige Wartungsfenster nicht beeinträchtigen. Obwohl die Beschränkung der Abrufrate am Montag, dem 2. Oktober 2020 angekündigt wurde, zeigt eine Analyse der „Responses“ von Docker Hub, dass die neuen Begrenzungen noch nicht angewendet wurden. Diese werden nur während eines 3-Stunden-Fensters von 18:00 bis 21:00 Uhr (MEZ) morgen durchgesetzt . Leider wissen wir zu diesem Zeitpunkt noch nicht, wann die neuen Pull-Rate-Limits vollständig durchgesetzt werden.

Bemerkenswert ist auch, dass diese Einschränkungen weder für die interne OpenShift-Registry gelten die in APPUiO Public oder Private enthalten ist und die völlig unabhängig vom Docker Hub ist, noch für Docker-Benutzer mit Pro- oder Team-Konten. Authentifizierte Benutzer mit Pro- oder Team-Konten können unbegrenzt Daten von und zum Docker Hub übertragen.

VSHN evaluiert derzeit Massnahmen, um Ausfallzeiten zu verhindern und die Auswirkungen dieser Situation für unsere Kunden zu reduzieren. Die derzeit geeignetste Lösung besteht in der Umstellung auf die oben genannten Pro- oder Team-Docker-Kontoarten. Noch einfacher ist die Verwendung eines authentifizierten Benutzerkontos als Pull Secret anstelle eines anonymen Kontos, das die Pull-Rate-Grenze verdoppelt und das Risiko von Ausfallzeiten erheblich verringern könnte. Eine andere Möglichkeit besteht darin, Container Images in ein anderes öffentliches Register zu migrieren, wie z.B. Red Hat Quay. Eine andere Möglichkeit ist die Verwendung eines privaten Registers, wie AWS ECR, GitLab Container Registry, Harbor oder andere ähnliche Technologien. Insbesondere hat AWS kürzlich die zukünftige Verfügbarkeit („innerhalb von Wochen“) eines kostenlosen öffentlichen Registers angekündigt.

Bei Fragen dürfen Sie uns gerne kontaktieren.