Industrielle IT/OT-Integration mit Kubernetes – ayedo zeigt wie

Viele Industrieunternehmen stehen heute unter massivem Druck. Ich glaube, ihr kennt das alle: Die IT/OT-Infrastruktur muss modernisiert werden – nicht nur aus Selbstzweck, sondern damit die Use Cases, die ihr umsetzt, auch wirklich skalierbar, sicher und wirtschaftlich betrieben werden können. Dafür müssen Maschinen, Sensorik und bestehende Hardware zuverlässig integriert und die Daten entsprechend nutzbar gemacht werden.
Ein entscheidender Baustein dabei ist Kubernetes. Der ein oder andere hat sicher schon davon gehört – ein Industriestandard zur Orchestrierung von Container-Anwendungen. Und wenn du jetzt denkst: „Ich bin kein DevOps-Nerd“ und abschalten willst, hör bitte erst recht weiter! Egal, ob du aus dem Shopfloor kommst, Architekturentscheidungen triffst oder neue Digitalisierungslösungen im Betrieb vorantreibst: Kubernetes ist längst kein reines IT-Thema mehr. Es ist der Schlüssel, um Use Cases von der Idee in den produktiven Rollout zu bringen.
Heute klären wir: Was ist Kubernetes im industriellen Kontext? Welche Use Cases lassen sich im Maschinenbau oder in der Energieversorgung damit umsetzen? Und welche Fehler kannst du dir bei der Umsetzung vielleicht direkt sparen?
Mein Gast ist Fabian Peter, CEO von ayedo, dem Anbieter in Europa für genau solche Container-Infrastrukturen auf Basis von Kubernetes. Sie betreiben diese nicht nur, sondern setzen sie auch auf – mit 24/7-Support. Alle Infos zur Implementierung findet ihr wie immer auf www.iotusecase.com und in den Show Notes. Und damit: Ab ins Podcaststudio.

Hi Fabian, schön, dass du da bist! Wie geht’s dir und wo erreiche ich dich gerade?

Fabian

Hallo! Ja, mir geht’s gut. Ich bin in der Nähe meines Zuhauses, sitze gerade im Office im Saarland, wo aktuell das schöne Wetter wohnt.

Das Saarland, fantastisch! Dann liebe Grüße in die Richtung. Vielleicht können wir zu Beginn das Thema ein bisschen einordnen. Ich denke, die meisten haben schon einmal von Kubernetes gehört, aber es wäre gut, das kurz zu erklären und in den Markt einzuordnen.

Docker installiere ich auf einem Gerät, zum Beispiel auf einem WAGO-Controller. Damit kann ich einzelne Container starten – kleine Software-Bausteine, die jeweils eine definierte Aufgabe übernehmen, wie etwa das Einsammeln von Daten über OPC UA. Um diese Container oder die Geräte, auf denen sie laufen, zu orchestrieren oder zu verwalten, braucht man Kubernetes. Es ist im Grunde ein zentrales System, das diese Geräte koordiniert. Ist das ungefähr richtig?

Fabian

Ja, das hast du gut beschrieben! Kubernetes kommt zwar nicht direkt aus der Welt der WAGO-Controller, sondern ursprünglich von den Facebooks und Googles dieser Welt. Diese Unternehmen merkten irgendwann: Ich brauche viele Geräte und muss darauf sogenannte „Workloads“ orchestrieren. Ein Container entspricht dabei einem Workload.
Wie du sagst, könnte dieser zum Beispiel OPC UA-Daten abgreifen und sie an einen Message Queue oder Broker wie HiveMQ oder RabbitMQ weiterleiten. Dahinter hängen dann wiederum Consumer – oft Softwarelösungen von Drittanbietern –, die eine bestimmte Aufgabe erfüllen. Kubernetes erlaubt es, solche Aufgaben in Container zu verpacken. Das Docker-Prinzip also – nur nicht auf einem einzelnen Gerät, sondern skaliert auf viele Nodes. Kubernetes übernimmt dann die Verteilung der Container im Cluster und sorgt dafür, dass sie am richtigen Ort laufen.

Cool! Weißt du noch, wann du Kubernetes das erste Mal in der Industrie gesehen hast? Es kommt ja, wie du sagst, aus einem ganz anderen Bereich. Das würde mich mal interessieren.

Fabian

Also, für mich war Daimler ein großer Vorreiter in Deutschland. Die machen seit Jahren viel mit Kubernetes. Ich glaube, ich habe auf der KubeCon letztes Jahr gesehen, dass sie mit etwa 9.000 Clustern arbeiten. Was genau sie damit machen, weiß ich nicht – ich kann mir vieles vorstellen, aber im Detail kenne ich es nicht.
Wir selbst hatten direkten Kontakt mit einem großen deutschen Automobilhersteller. Dort haben wir zunächst Docker bzw. Docker Swarm in einem Werk als Basisplattform installiert, um eine Fachanwendung zu betreiben, die mit dem Shopfloor interagiert. Das wurde später auf Kubernetes umgestellt. Für mich war das vor etwa drei bis vier Jahren das erste Mal, dass mir klar wurde: Kubernetes ist nicht nur ein Thema für die E-Commerce- oder Internet-Welt, sondern auch für andere Branchen relevant. Denn auch dort braucht man Skalierung und Kontrolle darüber, was wann wo läuft.

Stark. Wie viele Betriebe nutzen Kubernetes heute schon? Sind das eher die großen Player wie Daimler, oder auch kleinere, mittelständische Unternehmen? Würdest du sagen, 10 Prozent, 30 Prozent? Hast du da ein Gefühl?

Fabian

Ein genaues Gefühl habe ich nicht, aber ich würde schätzen: vielleicht 5 Prozent. Wenn ein mittelständischer Betrieb Kubernetes einsetzt, dann ist das meist ein Unternehmen, das Softwareentwicklung als zentrales Geschäftsmodell betreibt. In der klassischen Fertigung sehe ich es eher selten, vor allem bei Unternehmen, die nicht mit einer Vielzahl an Workloads oder Anwendungen zu tun haben. Das bedeutet nicht, dass es keine gute Idee wäre – aber der nötige IT-Horizont, um zu dem Schluss zu kommen, entwickelt sich meist erst ab einer bestimmten Größe, bzw. Menge an Problemen, die es zu lösen gilt.

Wann braucht man Kubernetes überhaupt, ganz einfach gefragt?
Ich hatte ja vorhin das Beispiel mit dem WAGO-Controller genannt, es gibt natürlich noch viele andere Hersteller. Ab wann macht so ein Setup Sinn? Etwa ab einer gewissen Anzahl an Geräten, wenn man etwas managen oder orchestrieren möchte?
Was ist das typische Problem-Statement – auch bei euren Kunden? Wann lohnt sich der Einsatz wirklich?

Fabian

Ich glaube, wir müssen den Industriekontext an der Stelle etwas verlassen, denn es geht bei Kubernetes nicht unbedingt um die Anzahl an Nodes, Geräten oder Servern, die man verwaltet. Man kann durchaus auch ein einzelnes Gerät effizient mit Kubernetes betreiben. Das ist dann per Definition zwar kein echtes Cluster, funktioniert aber trotzdem gut.
Vielleicht ein kurzer Exkurs: Was macht Kubernetes eigentlich? Du hast es vorhin richtig beschrieben, es orchestriert Container auf Maschinen. Das wirklich Interessante daran ist aber die klar definierte Schnittstelle nach vorne – für Entwickler, Operatoren oder Anwender. Wir sprechen hier von einer API. Und das ist in vielen industriellen Umgebungen tatsächlich etwas Neues.
Diese API erlaubt es, ganz präzise zu definieren: Ich habe eine Anwendung, die braucht zum Beispiel eine Datenbank, etwas Storage, vier Cores, drei Gigabyte RAM – und hier ist das Image, wo die Anwendung drin ist. Lass das bitte so laufen.
Diese Schnittstelle ist deshalb so spannend. Man hat die App in sehr klar abgegrenzte, standardisierbare Teile zerlegt. Und genau da wird Kubernetes interessant.
Ein Beispiel: Angenommen, ich habe einen WAGO-Controller – klassisch auf einer Hutschiene hinter einer Industriemaschine installiert – und will dort OPC UA-Daten erfassen. Wenn ich nun ein kleines Stück Software auf diesem Gerät zum Laufen bringen will, und das idealerweise in einem industrieweit akzeptierten Prozess, dann greift man auf Best Practices zurück. Das nennt sich Cloud Native Software Engineering.
Wenn man das einmal verstanden hat, kann man in einem großen Unternehmen an zentraler Stelle einen Change definieren, auf einen Knopf drücken, und dieser läuft automatisiert auf alle betroffenen Geräte aus. Nach einem kontrollierten Prozess.
Klar, bei einem einzigen Gerät kann ich das auch anders lösen. Aber wenn ich 50 oder 1000 Geräte im Feld habe und dort Software-Updates ausrollen möchte, wird es spannend. Vielleicht muss ich etwas ändern, weil ein Feature angepasst wurde, neue Ergebnisse gebraucht werden oder weil es um Compliance geht.
Dann ist Kubernetes enorm hilfreich. Ich muss nicht mehr per SSH auf jedes Gerät zugreifen oder komplizierte Ansible-Skripte schreiben. Stattdessen definiere ich zentral: Die Anwendung ist jetzt in Version 2 statt 1, und Kubernetes kümmert sich darum, dass das Update verteilt wird.
Idealerweise geschieht das sogar ohne Downtime. Das ist besonders bei Webservices interessant. Kubernetes bringt eine interne Logik mit, die sicherstellt, dass externe Zugriffe – etwa auf eine Datenbank oder einen Broker – nicht unterbrochen werden, nur weil gerade ein Update läuft.
Und genau das macht Kubernetes so attraktiv. Wenn jemand Docker auf einem Controller nutzt, dann gibt es dafür einen Grund – meist, um mit physischer Hardware zu interagieren. Und in solchen Setups wird man immer wieder Software-Updates ausrollen müssen.

Das ergibt Sinn.
Hast du ein Beispiel für einen typischen Use Case, vielleicht etwas in Richtung Predictive Maintenance? Was wären da die Anforderungen an so eine Anwendung?

Fabian

Einen konkreten Use Case haben wir ja eben schon angerissen: Du hast ein ganzes Werk voller Maschinen, die auf irgendeine Art und Weise Daten zur Verfügung stellen. Ich bin jetzt kein Spezialist für die klassische Automatisierungstechnik. also die Frage, wie man diese Daten bisher ausgewertet hat, um daraus Erkenntnisse zu gewinnen.
In der „neuen Welt“ würdest du z. B. eine Kubernetes-Anwendung entwickeln, die einen OPC UA-Poller enthält. Diese Software fragt bestimmte Daten von Maschine A ab und schreibt sie in eine Datenbank.
Das Ganze ist ein kollaborativer Prozess: Ein Business-Owner, Entwickler, Datenanalyst oder Ingenieur entscheidet, welche Daten von der Maschine erfasst werden sollen. Vielleicht wird auch der Bediener der Maschine gebeten, einen Schalter umzulegen, um andere Daten zu bekommen.
Daraufhin muss der Entwickler die Software, die in Kubernetes läuft, anpassen, sodass sie die neuen, gewünschten Datenpunkte in Echtzeit zur Verfügung stellt.
Der Anwendungsfall an sich ist nicht neu; früher wurde sowas mit Excel-Tabellen gemacht. Aber das Entscheidende ist: In dieser neuen Welt kann dieser Änderungsprozess, also was die Maschine liefern soll und was später im Dashboard oder Data Lake ankommt, innerhalb von Minuten umgesetzt werden.
Das heißt: Jemand entscheidet etwas „on the fly“, der Code wird geändert, gepusht, und die Änderung ist sofort live.
Der Data Engineer auf der Empfängerseite bekommt das Ergebnis ebenfalls in Echtzeit. Er muss also nicht mehr vier Wochen und sechs Tickets abwarten, bis jemand das Schema in Excel angepasst hat, damit er es mit Power BI visualisieren kann.
Stattdessen schreiben Entwickler ihre Anwendungen so, dass die Daten direkt in moderne ETL-Kanäle (Extract, Transform, Load) laufen – in eine Big-Data-Pipeline, die sie möglichst in Echtzeit bereitstellt.
Darauf kann man dann am anderen Ende Tools wie Power BI, Grafana o. Ä. aufsetzen, um sofort fundierte Entscheidungen zu treffen, z. B. in der Produktion.
Wenn du zum Beispiel feststellst, dass eine Maschine zu heiß wird, kannst du sie direkt abschalten. Früher dauerte es vielleicht fünf Minuten, bis man das bemerkt hat, heute nur noch 13 Sekunden. Und das kann bei Wartungskosten einen riesigen Unterschied machen.

Okay, cool. Mir fällt da gerade ein Projekt ein: Wir haben einen Partner, ALD Vacuum Technologies, ein klassischer Maschinen- und Anlagenbauer. Die stellen z. B. ihre Anlagen direkt beim Kunden im Werk auf.
Wenn ich also eine bestimmte Maschine dort stehen habe und die Schmelzparameter auswerten möchte, aber mein Hersteller kann das besser als ich selbst, dann teile ich meine Daten mit ihm über eine definierte Schnittstelle.
Das heißt, ich hätte lokal auf meinem Gerät eine Docker- bzw. Container-Instanz laufen, die mit Kubernetes verbunden ist. Über diese Struktur würde dann eine API bereitgestellt, über die mein Predictive-Maintenance-Use-Case umgesetzt werden kann, samt der entsprechenden Anwendungsanforderungen.
Macht das so Sinn in der Praxis?

Fabian

Ich würde sagen, Kubernetes ist gewissermaßen das trojanische Pferd für die Logik, die du eben beschrieben hast. Also für die Anwendung, die tatsächlich betrieben wird.
Das typische Szenario ist folgendes: Ein Maschinenbetreiber hat ein oder mehrere Werke mit entsprechenden Anlagen. Ist das Unternehmen groß genug, beauftragt es meist eine externe Firma, um eine passende Integrationssoftware oder Fachanwendung zu entwickeln. Diese Anwendung wird dann so gebaut, dass sie sich ideal in Kubernetes betreiben lässt. Man spricht davon, sie zu „deployen“.
Die eigentliche Logik für beispielsweise Predictive Maintenance steckt natürlich in der Anwendung selbst, also im Code, den der Softwareentwickler schreibt. Kubernetes übernimmt in dem Ganzen eher die Rolle des Transportmittels oder der Betriebsplattform. Du kannst deine Software dort „draufwerfen“, ein Ziel definieren – etwa dass sie 24/7 verfügbar sein soll – es ist leicht zu überwachen und es gibt Industriestandards, die sie auch mit klassischer Enterprise-IT kompatibel machen.
Die Businesslogik selbst entwickelt aber jemand anderes, typischerweise nach cloud-nativen Prinzipien, damit sie nahtlos auf Kubernetes läuft. Der Clou dabei ist: Wenn so eine Software einmal cloud-native entwickelt wurde, dann unterscheidet sich das Software-Artefakt nicht mehr durch die Art, wie es gebaut ist, sondern nur noch durch den Inhalt, also durch die Businesslogik.
Das heißt: Eine andere Firma, ein Partner oder auch ein internes Team kann die Anwendung übernehmen und weiterentwickeln, solange sie versteht, wie diese „Sprache“ funktioniert. Es gibt Best Practices, man kann nachlesen, wie man Anwendungen so baut, dass sie auf Kubernetes lauffähig sind.
Früher war das ganz anders. Da hat jede Firma Software auf ihre eigene Art ausgeliefert, und der Empfänger, also das Werk, musste sich individuell darauf einstellen. Heute gibt es mit Kubernetes diese eine gemeinsame Schnittstelle. Wenn du für Kubernetes entwickelst, kann ich deine Software einfach nutzen.

[13:52] Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus

Was spart mir Kubernetes im Vergleich zum klassischen Betrieb?
Du hast eben schon Dinge wie Skalierbarkeit und Update-Zyklen angesprochen. Gibt es auch etwas Greifbares, etwa zum Return on Investment?
Also: Wo verlieren Unternehmen heute wirklich Zeit und Geld, in ihren Werken oder in ihren Deployments?

Fabian

Ich bin leider kein großer Freund konkreter Zahlen, weil wir über diese Themen nicht in dieser Weise denken. Aber ich kann versuchen zu umreißen, wo hier das Potenzial liegt. Oder, wenn man so will, wo das „Gold vergraben“ ist.
Gerade in größeren Unternehmen mit hohen Compliance-Anforderungen, komplexen Prozessen und vielen Teamgrenzen spielt Kubernetes seine Stärken aus.
Mit Kubernetes und den zugehörigen Patterns holt man sich ein ganzes Ökosystem an Automatisierung ins Haus, das sich zudem auf Policys und Audits hin überprüfen lässt.
Nach einer gewissen Ramp-up-Zeit hat man für eine deployte Anwendung auch so etwas wie einen Prüfcode. Dieser kann Aufgaben automatisiert übernehmen, die heute oft noch manuell erledigt werden, mit Excel-Tabellen und Checklisten.
Ein weiterer großer Vorteil: Monitoring.
Wir erleben es oft in der Praxis: Wenn heute jemand in einem Enterprise-System eine neue VM braucht, müssen 12 Leute über 17 Tickets hinweg aktiv werden. Einer kümmert sich um die Firewall links, der andere rechts, der nächste macht das IP-Whitelisting, der vierte kümmert sich um den Proxy und so weiter.
Das sind alles Dinge, die sich über zentralisierte Services lösen lassen. Rund um Kubernetes gibt es dafür bereits einiges an Tooling, etwa für Secrets Management mit HashiCorp Vault und ähnliche Lösungen.
Wenn man diesen Ansatz grundsätzlich in seine Arbeitsabläufe integriert, entsteht ein sauberer Audit Trail, weil plötzlich alles nachvollziehbar und prüfbar wird. Gleichzeitig spart man enorm viel Zeit, weil man nicht mehr manuell Probleme behebt, sondern Logiken und Automatismen schreibt, die im Hintergrund zuverlässig arbeiten.
Ich könnte da noch lange weiterreden. Aber der Punkt ist: Mit Kubernetes öffnen sich neue Türen.
Ich hatte es vorhin schon erwähnt, das Anliefern von Software durch Drittanbieter wird deutlich einfacher. Heute bekommt man fast alles als Helm Chart, die Anbieter entwickeln ihre Lösungen bereits in dieser Form.
Stattdessen kann man die Software direkt übernehmen und einsetzen, ohne langwierige Anpassungen, weil sie standardisiert bereitgestellt wird und dadurch schneller und unkomplizierter funktioniert.

Also im Prinzip standardisierte, vorkonfigurierte Setups, richtig?
Vielleicht noch eine Nachfrage: Viele Betriebe müssen dieses Kubernetes-Know-how ja erst intern aufbauen. Du hattest vorhin von Teams gesprochen. Das spart doch auch Personalkosten oder zumindest Schulungsaufwand?
Oder ist das eher eine strategische Frage?
Ich könnte mir vorstellen, allein beim Thema Schulungen und „up to date bleiben“ in dieser Welt, in dieser Subkultur, geht sehr viel Zeit drauf.

Fabian

Ja, absolut. Gerade wenn man aus der IT/OT-Welt kommt, ist die Herausforderung besonders groß. Dort hat man zusätzlich zur klassischen IT auch noch die „alte Welt“ zu betreuen. Maschinen haben Betriebssysteme, die 30 Jahre laufen müssen, und entsprechend muss auch die Software für diese Maschinen jahrzehntelang funktionieren.
Das führt zu ganz anderen Denkmustern im Umgang mit Problemen.
Deshalb ist der Schritt hin zu Kubernetes ein echter Sprung, ein „Leap“. Und dafür braucht es immer ein paar Leute, die bereit sind, bestehende Denkmuster hinter sich zu lassen und durch neue zu ersetzen. Es bringt nichts, einfach jemanden in eine Kubernetes-Schulung zu schicken und zu erwarten, dass danach alles läuft. So funktioniert das nicht.
Das ist ein bisschen wie damals, als die Virtualisierung aufkam. Es hat Jahre gedauert, bis die Leute wirklich verstanden hatten, was sie damit alles tun können. Und selbst heute entdecken wir noch neue Möglichkeiten, die auf dem Prinzip des Hypervisors basieren.
Bei Kubernetes wird das ähnlich sein. Mit der Zeit öffnen sich neue Türen, neue Potenziale tun sich auf. Irgendwann muss man einfach anfangen, aber es ist und bleibt ein großer Wandel.

Bevor wir gleich über euch und eure Projekte sprechen:
Gibt es typische Fehler, die du bei der Einführung oder im laufenden Betrieb von Kubernetes immer wieder beobachtest?
Ihr habt ja schon viele große Kundenprojekte begleitet. Gibt es da Fallstricke, die regelmäßig auftauchen?

Fabian

Ein weit verbreiteter Irrglaube ist, dass Kubernetes einfach nur die „komplexere“ oder „schwierigere“ Version von Docker Swarm sei, und umgekehrt Docker Swarm die „leichtere“ Version von Kubernetes.
Das stimmt so nicht. Die beiden Systeme ähneln sich in einigen Versprechen, aber sie tun nicht das Gleiche.
Was wir häufig sehen: Das „Learning Delta“, also die Hürde beim Einstieg in Kubernetes, erscheint vielen zunächst zu groß. Deshalb sagen sie beim ersten Versuch: „Kubernetes machen wir nicht, wir setzen auf Docker Swarm.“
Und in 100 Prozent der Fälle ärgert man sich später, spätestens nach zwei Jahren, wenn man es doch neu aufsetzt.
Ein weiterer Fehler ist zu glauben, man könne mit den alten Denkmustern weiterarbeiten.
In der modernen Welt bedeutet Softwareentwicklung auch, seine Delivery-Prozesse so aufzustellen, dass man – theoretisch – mehrmals täglich neue Versionen ausrollen kann.
Das mag in der Industrie erst einmal gruselig klingen, aber in Bereichen wie dem Banking ist das längst Realität. Und dort ist die Kritikalität ähnlich hoch. Wenn plötzlich ein Gehaltslauf verschwindet, nur weil jemand ein Update deployt, ist das existenziell.
Der Punkt ist: Man darf nicht erwarten, dass Kubernetes sich „wie früher“ verhält.
Viele Unternehmen glauben, sie könnten einfach jemanden wie uns einkaufen, und dann läuft alles von allein. Klar, wir können viel übernehmen. Aber wenn man sich wirklich darauf einlassen will, wie man in Zukunft Software schreibt und IT-Probleme löst, muss man grundlegend umdenken. Und genau das machen viele nicht.

Ja, total.
Und falls ihr zuhört und sagt: „Hey, wir haben ähnliche Themen im Unternehmen“, dann vernetzt euch gerne mal.
Fabian, ich würde deinen LinkedIn-Link in die Show Notes packen, dann können sich die Hörer direkt mit dir verbinden. Oder einfach auf eurer Website vorbeischauen. Das war ayedo.de, oder?
Da findet man ja auch eine Community und Ansprechpartner für diese Themen.

[20:15] Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien

Was genau macht ihr eigentlich bei ayedo? Ich würde das gleich gern noch einordnen, auch im Vergleich zu anderen Marktteilnehmern oder Hyperscalern. Aber starten wir mal offen: Was bietet ihr konkret an?
Fabian

Okay, also ayedo bietet das an, was wir „Managed Software Delivery“ nennen. Wir helfen Unternehmen, die ihre Software mit Hilfe von Kubernetes entwickeln und betreiben wollen oder auch denen, die Kubernetes nur benötigen, um Drittanbietersoftware zuverlässig zu betreiben.
Unser Ansatz ist dabei flexibel. Wir stellen all das bereit, was man zum Entwickeln moderner Software braucht – also Hardware, virtuelle Maschinen, Netzwerk-Transit, S3-kompatiblen Storage und vieles mehr. Man kann sagen, wir funktionieren ein Stück weit wie ein Cloud Provider.
Aber anders als bei AWS, wo man sich alles einfach im User Interface zusammenklicken kann, läuft das bei uns über direkten Austausch. Unsere Kunden kommen mit ganz unterschiedlichen Anforderungen. Jede Software ist anders, hat eigene Eigenheiten, andere Bedürfnisse, andere Anforderungen an die Infrastruktur.
Wir führen viele Gespräche darüber, wie wir diese individuellen Setups compliant bekommen. Das ist auch einer der Gründe, warum wir derzeit stark nachgefragt sind. Die Welt bewegt sich in eine Richtung, in der Begriffe wie „Daten“ und „Amerika“ für viele in Europa nicht mehr ganz unproblematisch zusammen in einem Satz genannt werden. Genau da setzen wir an. Wir sind ein rein europäischer Anbieter mit Sitz in Deutschland und beherrschen die gesamte moderne Cloud-Welt, inklusive Kubernetes. Viele Unternehmen, darunter Agenturen, die Webshops entwickeln, oder Behörden, die im Rahmen des Onlinezugangsgesetzes Anwendungen für Bürger bereitstellen, interessieren sich deshalb für unsere Lösungen. Sie brauchen sichere, datenschutzkonforme Umgebungen und wir unterstützen sie dabei, von der Entwicklung bis hin zum Hosting.

Also ein vollständiger Compliance-Schutz mit einem europäischen Stack dahinter.
Und ich glaube, was vielen Kunden besonders wichtig ist, ist euer Service-Level-Agreement. Kannst du dazu noch etwas sagen? Wo liegt da der Vorteil, gerade auch im Hinblick auf die Frage, ob man das einkauft oder selbst aufbaut, was wir ja eben im Business Case thematisiert haben?

Fabian

Genau. Also wir bieten ein Service Level Agreement an, das aktuell standardmäßig auf 99 % ausgelegt ist. Wobei das ehrlich gesagt niemanden mehr beeindruckt. Inzwischen ist unser Standard-SLA bei 99,5 % bzw. 99,9 % angesiedelt, je nach Service. Das gilt sowohl für unsere eigene Cloud als auch für unterstützte Cloud-Provider oder beim Kunden selbst vor Ort, also auf deren Infrastruktur. Und natürlich kann man mit uns ins Gespräch gehen, wenn man mehr Neuner hinter dem Komma braucht.
Aber ich finde: Der wirklich relevante Aspekt beim SLA ist nicht nur die Zahl, für die es im Ernstfall Erstattungen gibt, sondern die Arbeit, die wir leisten, damit diese Zahlen auch dauerhaft eingehalten werden. Unsere Mission ist es, dass die Verfügbarkeit stabil hoch bleibt. Auch bei Szenarien, in denen andere Systeme vielleicht an ihre Grenzen stoßen würden.
Das heißt, wir bieten zusätzlich einen 24/7-Support an. Und wenn man bei uns anruft, landet man nicht in einem Callcenter am anderen Ende der Welt, sondern direkt bei Leuten wie mir, die die Systeme selbst bauen. Unser Support ist nicht ausgelagert, sondern besteht aus dem Team, das auch die Infrastruktur entwickelt. Wir kennen die Setups im Detail und können entsprechend konkrete Garantien geben, gerade auch für die komplexen Szenarien, die unsere Kunden mitbringen. Denn es ist ja nicht jeder gleich.

Stark. Und eure Kunden sind wirklich sehr unterschiedlich. Wenn man sich auf eurer Website umschaut, sieht man Namen wie Liebherr, HADES, T-Systems, Teltec und viele weitere große Unternehmen, die auf euch setzen.
Das ist schon beeindruckend. Auch wenn wir hier im Podcast nicht auf Details eingehen dürfen. Aber man bekommt einen ganz guten Eindruck, wer alles mit euch zusammenarbeitet.

Fabian

Ja, wir freuen uns wirklich sehr, mit diesen Unternehmen zusammenzuarbeiten. Hinter diesen Projekten stecken oft extrem spannende Aufgaben, gerade in den größeren Organisationen.

Was ist für dich das besonders Spannende daran? Sind es eher die Menschen oder die technischen Setups? Was begeistert dich an diesen Projekten am meisten?

Fabian

Also ganz klar: die Menschen. Das muss man wirklich sagen. Wir sind ja ein kleines Unternehmen. Man könnte sogar noch von einem Start-up sprechen. Wir haben eine sehr flexible, agile Kultur, wir geben richtig Gas. Und wenn man dann mit diesen großen Firmen zusammenarbeitet, spürt man oft einen ganz anderen Level an Loyalität, an Verbundenheit und an echter Leidenschaft für die Sache.
Viele unserer Kunden haben auch einen nationalen Auftrag. Und man merkt, wie ernst sie den nehmen. Das ist emotional schon etwas ganz anderes, als einfach nur einen Webshop hochzufahren. Klar, auch das machen wir gern, aber es gibt eben Projekte, die sind besonders. Man geht an Orte, im übertragenen Sinne, die haben etwas Magisches.
Und dann ist da natürlich auch der Business-Aspekt: Es ist für mich persönlich und für uns als Firma total spannend zu sehen, wie sich gerade wieder ein Wandel vollzieht. Weg von der Hyperscaler-Mentalität, weg vom kompletten Outsourcing, hin zu „Wir wollen wieder selbst bauen und selbst besitzen“.
Das finde ich großartig. Ich war immer jemand, der Software und Hardware lieber bei den Kunden in den Keller gestellt hat als in meinen eigenen. Es ist einfach schön, dafür Technologien entwickeln zu dürfen.
Und dieser Wandel macht unseren Business Case gerade so spannend, weil er für das Upper-Management wieder relevanter wird. Themen wie Open Source, digitale Souveränität und Lokalität stehen auf der Agenda. Es geht also um mehr als Technik. Es geht um Kontrolle und Vertrauen.
Es gibt nur eine Handvoll Anbieter, die das leisten können. Und wir hoffen, einer von denen zu sein, die diese Anforderungen für viele, auch sehr komplexe, Kunden erfüllen können.

Absolut. Und du hast eben „Lokalität“ angesprochen. Meinst du damit vor allem On-Premise-Installationen oder auch, dass ihr physisch vor Ort beim Kunden seid?

Fabian

Unbedingt. Aber sind wir ehrlich: Physisch sind wir heute selten direkt vor Ort, weil es die Infrastrukturen meist gar nicht mehr erfordern. Man kann sich remote aufschalten, man spricht übers Internet. Wenn wir vor Ort sind, dann für Workshops, Hackathons oder einfach, damit man sich mal persönlich kennengelernt hat.

Und echt cool, dass ihr euch bei diesen Kunden durchgesetzt habt. Das spricht absolut für euch. Ich muss ehrlich sagen, ich musste mich vor unserem Gespräch selbst erst mal orientieren, wer in diesem Markt eigentlich alles unterwegs ist. Man hört ja von AWS Compute-Angeboten, von IONOS, STACKIT und anderen, die ähnliche Themen bedienen. Das ist ein riesiger Markt. Aber es ist schön zu sehen, dass ihr da wirklich euren Platz gefunden habt.
Und noch eine letzte Frage:
Geht das Thema auch in Richtung Zertifizierungen, also zum Beispiel NIS-2? Ist das ein Treiber, der euch aktuell Rückenwind gibt und euch hilft zu skalieren? Siehst du da Bewegung?

Fabian

Ja, auf jeden Fall. NIS-2 war lange so ein „looming topic“, also so ein Thema, das ständig im Raum stand. Ich muss ehrlich sagen, ich bin kein großer Leser von Rechtstexten, daher weiß ich gar nicht hundertprozentig, ob es in Deutschland schon offiziell in Kraft ist oder ob es erst noch kommt. Aber wir haben uns natürlich schon vor Jahren Gedanken gemacht, welchen Einfluss das auf unsere Arbeit haben wird.
Und man merkt den Wandel deutlich, zum Beispiel in den Vendor-Audits, die wir erleben. Da werden heute ganz andere Fragen gestellt als noch vor ein oder zwei Jahren.
Wir versuchen, wie ich schon gesagt habe, genau diese komplexen Anforderungen ernst zu nehmen. Wir mögen es, mit Kubernetes und unseren Apps dahin zu gehen, wo der Standard nicht mehr funktioniert – an Orte mit besonderen Anforderungen, besonderen Setups.

[27:23] Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen

Was kommt in Zukunft noch? Was siehst du technologisch im Kubernetes-Umfeld – was entwickelt sich da aktuell weiter? Und was kommt bei euch an neuen Features oder Angeboten? Da bin ich noch neugierig.

Fabian

Also ich habe schon seit Jahren das Gefühl, dass wir in den kommenden Jahren eine Art Liberalisierung der Infrastruktur erleben werden. In Deutschland gibt es unglaublich viel Hardware, also echtes „Blech“, in den Kellern von Rechenzentrums- oder IT-Providern, groß wie klein.
Vor 10 oder 20 Jahren war es total angesagt, sich eigene Technik in den Keller zu stellen, IP-Netze zu kaufen, eigene Transitstrecken aufzubauen. Und viele dieser Strukturen existieren heute noch, auch wenn sie teilweise nicht mehr aktiv genutzt werden. Es gibt inzwischen einige Initiativen, die genau da ansetzen. Der Sovereign Cloud Stack ist ein gutes Beispiel. Ziel ist es, diese vorhandene Infrastruktur wieder verfügbar zu machen.
Also dass es in Zukunft möglich ist, zum Beispiel ein Kubernetes-Cluster bei einem lokalen IT-Provider bereitzustellen, der die passende Hardware besitzt, und dass das kein riesiger Aufwand mehr ist. Stattdessen soll es einen Plattformlayer geben, über den ich meine Hardware in einen zentralen Markt einbringen kann. Ich kann dann sagen: Die Maschinen stehen in Frankfurt, haben eine bestimmte Netzanbindung, das sind die technischen Spezifikationen. Und der Plattformlayer spielt mir darauf ein Kubernetes-Cluster auf, das dann nach außen angeboten werden kann.
Wie genau das am Ende laufen wird, weiß ich nicht. Aber ich bin überzeugt, dass wir eine Alternative zur heutigen Hyperscaler-Dominanz brauchen. Und in ein paar Jahren wird sich da eine Lösung auftun. Ob das dann OpenStack ist, SCS oder etwas anderes, muss man sehen. Aber für den europäischen Raum ist das technologisch ganz klar die Richtung, in die es gehen wird.

Ja, total spannend. Ich packe gern noch ein paar Infos dazu in die Show Notes. Wer sich für diese Initiativen interessiert, kann da gern mal reinschauen. Sorry, ich wollte dich nicht unterbrechen.

Fabian

Kein Problem! Vielleicht noch kurz zu uns bei ayedo: Wir arbeiten gerade aktiv daran, genau zu dieser Entwicklung beizutragen. Unsere Cloud-Plattform soll Nutzer befähigen, ihre eigene Cloud aufzubauen, auch On-Premise. Und zwar so, dass sich Entwickler und Anwender so fühlen, als würden sie mit AWS, Azure oder IONOS arbeiten, mit denselben Komfortfunktionen, Self-Service-Möglichkeiten, Roll-Based Access Control und vielem mehr.
Aktuell rollen wir neue Dienste aus wie einen Managed Identity Provider, Managed Object Storage, eine Managed Container Registry – alles als Teil unserer „Easy-to-Go“-Cloud-Lösung. Diese Services bieten wir sowohl in unserer Public Cloud an als auch als Private- oder Enterprise-Version für den On-Prem-Einsatz.
Und genau da wird in den nächsten Jahren noch viel passieren. Denn das sind die Herausforderungen, die in unserer Welt immer wieder gelöst werden müssen.

Stark! Gibt es denn für eure neue Lösung schon einen Produktnamen oder ist das noch nicht offiziell?

Fabian

Wir versuchen da einfach, die Dinge beim Namen zu nennen. Also zum Beispiel sagen wir ganz pragmatisch „Managed Identity Provider“. Ich bin da ein bisschen altmodisch. Warum sollte ich etwas, das ziemlich klar beschrieben ist, nochmal anders benennen, nur damit jemand extra drüber nachdenken muss, was es eigentlich ist?
Am Ende handelt es sich um einen gehosteten Keycloak, also um einen Identity Provider. Und mit diesen zwei Worten können die meisten Leute, die danach suchen, sofort etwas anfangen. Da braucht es keinen fantasievollen Namen.

Sehr schön!
Fabian, vielen Dank, dass du heute dabei warst – für all die spannenden Einblicke, auch aus euren Projekten. Ich fand’s richtig klasse, wie praxisnah du das Thema rübergebracht hast. Vielleicht hören wir uns ja nochmal für eine Nachfolgefolge, eventuell auch gemeinsam mit einem Partner oder Kunden.
Für heute auf jeden Fall: Vielen Dank dir! Und ich überlasse dir gern das letzte Wort.

Fabian

Danke, dass ich dabei sein durfte!
Ich würde gern mit einem Spruch enden, den wir auch gern mal auf T-Shirts drucken:
„Kein Backup – kein Mitleid.“

Das ist ein großartiger letzter Satz!
Aber eine allerletzte Frage fällt mir doch noch ein: Warum eigentlich die Aliens auf eurer Website? Vielleicht schauen jetzt einige Hörer:innen bei euch vorbei – und die werden sich das bestimmt fragen. Gibt’s da eine Hintergrundstory?

Fabian

Lass mich überlegen. Also: Was unser Branding betrifft, versuchen wir, die Leute auf einer emotionalen Ebene abzuholen.
Wenn man mir auf LinkedIn folgt, sieht man: Ich poste fast nur Memes. Wir wollen einfach mit einer positiven Note ansprechen – und dafür sind die Aliens ideal.
Die Aliens helfen uns, komplexe Dinge zu transportieren, die man in einem klassischen Diagramm nur schwer verständlich machen kann.
Unsere Mitarbeiter sind sogar in den Alien-Illustrationen verewigt – sie sind Teil des Storytellings. Wir sind da noch nicht ganz auf dem Level, wo wir hinwollen, aber es geht um Wiedererkennung, um Persönlichkeit und darum, nicht wie jede andere „langweilige IT-Bude“ zu wirken.

Ich kann nur sagen: Das funktioniert!
Also: Schaut euch auf ayedo.de mal die Aliens an – und Fabian, nochmal danke, dass du heute mit dabei warst. Mach’s gut, ciao!

Fabian

Danke dir – ciao!