Skillbyte Podcast #2: Devops - Was ist DevOps und das DevOps Mindest?

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Devops - Was ist DevOps und das DevOps Mindest?

// Inhalt //
01:10 -> Definition: Was ist DevOps und das DevOps Mindest?
06:17 -> Wie kam es zum DevOps Gedanken und was leistet DevOps?
11:11 -> Vorteile von "Infrastruktur als Code"
11:52 -> Vorteile von Continuous Integration und Continuous Delivery
17:50 -> Kubernetes und OpenShift wird mit DevOps in einem Atemzug genannt, was ist das und welche Vorteile haben wir dadurch?
21:03 -> Detailerklärung zu Kubernetes und OpenShift
27:45 -> Anwendungsbeispiel: AWS, Terraform und CoreMedia
34:15 -> Was ist GitOps und DevSecOps?

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Herzlich willkommen bei unserem Skillbyte Podcast! Wir freuen uns, dass ihr heute wieder zuhört. Und ja, heute ist die zweite Ausgabe und ich sitze auch heute hier wieder mit Masiar. Wir sprechen über das Thema Dev OPs. Und wenn euch der letzte Podcast gefallen hat, dann das ist ganz wichtig für uns. Gebt uns gerne dort eine positive Bewertung. Also bei dieser iTunes, Soundcloud oder wo auch immer ihr den Podcast hört, weil dann wissen wir, welche Themen euch interessieren und welche Themen wir noch genauer besprechen können.

Wenn ihr Leser Fragen habt, schreibt uns gerne eure Frage per E-Mail an Podcasts skillbyte D Und die Leser fragen die zu den Themen oder die spannendsten dieser Fragen zu den Themen. Die beantworten wir dann jeweils im nächsten Podcast. Wie gesagt, heute wird das Thema der sein und ich bin wieder hier mit Masiar. Hallo Masiar, wunderbar, dass Tilo Maurice, dass du wieder Zeit gefunden hast und dass wir über das Thema sprechen können. Du hast ja dich in den letzten Jahren intensiv damit befasst.

Und auch wie im letzten Podcast würde ich gerne damit beginnen, dass wir kurz definieren, was Steve Jobs aus deiner Sicht bedeutet, weil es auch eine hohe Buzzword Dichte was und in diesem Kontext bewegt.

Ja, ja, im Grunde. Der Name sagt eigentlich schon sehr eindeutig. Der OB setzt sich zusammen aus den Begriffen Developer und Operations. Klassischerweise hast du in der Softwareentwicklung eine Software entwickelt und es später betreiben bist hast du zwei Rollen in diesem System. Das eine ist der, die eine Rolle ist, der Entwickler oder die Entwickler, die Software erstellen. Und die zweite Rolle ist das Operations, was dafür sorgt, dass die Software auch läuft. Das heißt Server aufsetzen, also eigentlich noch vorher.

Es fängt bei der Kapazität Planung an. Man setzt sich zusammen und überlegt Okay, wie viele User wollen wir damit handeln? Welche Anforderungen haben wir an die Software Richtung Hardware und Betrieb? Und dann fängt man an auszurechnen, welcher Server man bestellen muss. Dann geht das los. Geht es in die Bestellung rein und dauert Wochen, bis die Maschinen da sind, dann müssen die Administratoren sich hinsetzen, da entsprechende Pakete drauf installieren und dann die Software darauf zu installieren, bis so was wie eine Software laufen kann.

Meistens wie schon gesagt, zwischen Wochen und Monaten. Und es ist im Prinzip so eine Gewitterwolke, das heißt einer, der sich in beiden Welten zurechtfindet. Und es ist aber nicht nur sich mit Software-Entwicklung und Operations auskennen. Der Begriff an sich beinhaltet eigentlich noch viel mehr. Da sprechen wir über Docker Technologien, über Cluster, Technologien, Sie Idee und so weiter, was diese Rolle alles beinhaltet. Da können wir aber gleich drüber sprechen. Aber grundsätzlich die Definition der Erwerbs und Operations, das ist ja ist eine ganz spannende Entwicklung hin, dass man diese klassische Trennung zwischen Softwareentwicklung und System betrieb oder Systemadministratoren, die es ja seit ich weiß nicht in den 80ern 70ern gibt, dass man die quasi zusammenführt und sagt Okay, im Praxis Betrieb haben wir festgestellt, es gibt Probleme, wenn zwei unterschiedliche Personen oder zwei unterschiedliche Gewerke sich um diese Themen kümmern, also die Entwickler entwickeln und die Systemadministratoren betreiben.

Da gibt es ja dann klassischerweise Reibungspunkte, weil jeder jede Gruppe nur ihr eigenes Ziel absolut in den Augen hat. Also ich könnte mir vorstellen, der Entwickler möchte natürlich neue Funktionen entwickeln, die Software verbessern und hat natürlich auch den Druck seitens des Kunden hier in der Bringschuld, neue Features zu liefern. Und der Systemadministrator sagt Eigentlich würde ich das am liebsten so stabil wie möglich halten und jedes neue Feature bedroht mein bisher stabiles System sozusagen.

Und genauso ist es. Ein weiteres Problem ist zum Beispiel, wenn wenn mal Fehler auftreten und der der Admin sagt hier die Software läuft nicht. Naja, da gibt es Probleme, sagt der Entwickler klassischerweise. Bei mir läuft's diese Parität der Umgebungen, angefangen von der Entwickler Maschine über ich sage mal Testumgebung, Umgebungen, Staging Umgebungen, Abnahme, Umgebung und Produktion sind so unterschiedlich, wie die sich mit der Zeit auch auseinanderentwickelt. Zum Beispiel früher, also nicht nur früher, auch heute.

Ich erlebe es oft genug, dass das Software Pakete erstellt werden und man braucht einfach mal weitere Bibliotheken, die auf dem Server vorhanden sein müssen, damit die Software zum Beispiel laufen kann. Und die Administratoren müssen dann hingehen. Diese Dinge. Installieren und denk weiter an Patches, Betriebssystem, Patches und so weiter. Ein Admin hat heute so viele Aufgaben und so viel zu tun, dass er meistens nicht hinterher kommt, all diese Maschinen Umgebungen synchron zu halten. Und das ist das das bekannte Problem oder Phänomen der Snowflake Server, sprich die die Maschinen entwickeln ein Eigenleben und laufen auseinander.

Das hat bei dem einen statischen Patch einen, bei dem anderen nicht. Und ja, das sind halt all diese Probleme, die so eine Skulptur versucht einzufangen.

Jetzt haben wir dieses diese beiden Problemfelder angesprochen Softwareentwicklung und System Administration. Jetzt hat man gesagt Okay, der Entwickler, der sagt läuft aber bei mir in A Works an meinen Maschinen, der hat ja unter Umständen auf seiner Maschine gar nicht, wenn er Enterprise Software entwickelt. Das Gleiche die gleichen Anforderungen, die eine Anwendung hat im produktiven Betrieb. Der Entwickler ist als Single User auf seinem Rechner unterwegs und die Anwendung im System Betrieb hat ja unter Umständen hunderte gleichzeitige Benutzer, die man lokal so gar nicht, die alle unterschiedliche Dinge tun.

Und das kann man lokal ja gar nicht so schön simulieren. Ja und jetzt ist der Bedarf dahin gegangen, dass man gesagt hat Okay, diese Entwickler und diese Systemadministratoren Rolle, die möchte man zusammenfassen, also die Developer und die Operations Rolle zu den OPs. Und das bedingt ja eine ganze Reihe von Paradigmen Änderungen. Du einige hast du eben schon angesprochen. Aber was ist denn so für dich das das maßgebliche oder die der große Unterschied zwischen einem Betrieb und einem klassischen Betrieb?

Also dass das man ist nicht hingegangen und hat gesagt, wir brauchen diese Rolle und schneiden die Tools drumherum, die wir dazu brauchen, sondern es ist genau andersherum passiert Es entstanden neue Technologien, die überhaupt so eine Rolle möglich oder sogar notwendig gemacht haben, ganz vorne dabei die wichtigste Technologie ist. Doch da ist im Prinzip eine Technologie, die hilft, Prozesse auf Unix Maschinen zu isolieren. Du kannst Software nun mit dieser Technologie so patentieren, dass du nicht nur deine eigenen an Anwendungs Artefakte wie zum Beispiel dein kompilierte Code oder oder Java Bytecode hast, sondern du hast auch alle damit zusammenhängenden Abhängigkeiten in einem Paket inklusive des Betriebssystems.

Das heißt, du kannst dein Paket komplett schnüren und dieses Docker Image ist lauffähig, du kannst es installieren und zum Laufen bringen und dann spielt es überhaupt keine Rolle wo dieses Image läuft. Ob es bei dir auf dem Rechner läuft, in der Produktions Umgebung, in der Steigung Umgebung läuft, weil es ja die kompletten Abhängigkeiten, Third Party Libraries und und und drin schon hat. Deswegen verhält es sich überall gleich. Das ist dir. Diese Parität ist jetzt aufgehoben zwischen Entwicklungsumgebung und Produktion.

Das heißt, entweder kann ich mir sagen bei mir läuft und in der Produktion nicht, weil es ist immer das gleiche Image oder dieselben Abhängigkeiten und dieselbe Instanz. Das hast du patentiert, wenn du es anders ausgedrückt so kleine Server, die für sich lauffähig sind und das wird nur noch hin und her geschoben.

Prinzip und ist das dieses? Sorry, wenn ich dich unterbreche, aber im Prinzip ist da dieses Modell der virtuellen Maschine oder der VM auf Anwendungs Ebene heruntergebrochen. Du hast nicht meine eigene virtuelle Maschine, sondern du hast eine virtuelle Anwendung, die mit allen Abhängigkeiten sicher neben anderen Anwendungen auf der gleichen Maschine betrieben werden kann.

Wobei jetzt keine Virtualisierung ist, Technologie ist, sondern Isolation Technologie. Das heißt, diese Anwendungen, die nebeneinander und mit verschiedenen Versionen einer Bibliothek jeweils arbeiten, können ganz safe auf einer Maschine zusammenlaufen, weil sie so voneinander isoliert sind. Und es passiert dann auch nicht mehr sein. Ein Paradigma bei Docker zum Beispiel ist auch, dass keiner mehr das kennt, jeder von uns in der Softwareentwicklung drin ist oder ist jetzt ein Problem. Ich fix das mal schnell auf dem Server.

Lieber Admin, spielt das mal bitte schnell auf den Server ein, damit das wieder laufen kann. Also dieses Paradigma gibt es bei Docker nicht mehr. Diese Images sind diese Kleinen, wie du es so schön genannt hast. Virtual Machine sind im YouTube, das nicht veränderbar ist. Wenn ich ein Fix einspielen will, dann schmeiße ich dieses ganze mit Zweckbau Neues und dieses Neue. Das heißt, ich hab gar nicht das Problem, dass die Server auseinander laufen können, dass ich auf der Produktion was anderes eingespielt habe als zum Beispiel den Staging.

Und das ist ein Riesenvorteil.

Und du hast auch, du hast dadurch ja eine erzwungene Versionierung, sag ich mal, wenn das neue Image dann nicht funktioniert oder sich. Nicht bewährt, dann kann ich notfalls auf das alte Image vom Vortag zurückgreifen und sagen Oh, da muss man noch mal ran.

Ja, und der Vorteil dieses diese, diese kleinen, diese kleinen Paradigmenwechsel hat eine Lawine losgetreten, weil plötzlich kannst du das Ding auch komplett automatisieren, das heißt den Bau von Images. Also ich habe mir deine Java Applikation zu bauen. Animate zu packen lässt sich plötzlich automatisieren, weil die ganze Konfiguration und das Bauen diese Instruktionen. Dafür werden Dateien abgelegt. Und das ist auch ein ganz wichtiges Paradigma bei Devotees, das sämtliche Funktionen in Dateien abgelegt werden, also Konfiguration und diese können exekutiert werden auf der Kommandozeile.

Damit lassen sich natürlich viele Dinge automatisieren und automatisieren bedeutet weniger fehleranfällig. Automatisieren bedeutet Skalierbarkeit. Es spielt überhaupt keine Rolle, ob das Image auf einem, zwei, drei oder 500 Servern ausgerollt wird. Ja, das verhält sich überall gleich und ich kann es auch automatisieren. Und das ist der große Vorteil, dass man im Prinzip die die Positionierung der Maschine beschreibt. Man oder der Anwendung beschreibt man ja in diesem Fall selber drin. Also was sind die Abhängigkeiten? Und dadurch, dass man es beschreibt, was der System Admin vielleicht vorher wusste und sagt Okay, ich installiere mal Linux Masiar war ich installiert mal die Cerberus Bibliothek so und dann läuft das und das wird alles sozusagen in Textdateien, also in diesen Jamel Files festgehalten und ist dann nicht ist anstatt implizit im Wissen ist das dann explizit verfügbar in diesen Dateien.

Und diese Dateien können natürlich wieder designiert werden oder eben beliebig herum gruppiert werden.

Ja genau. Und das Docker hat aber noch etwas anderes losgetreten, dem ich sagte, dass es wie eine Lawine ähm, man hat bei der Softwareentwicklung bis jetzt immer das große Problem gehabt. Gerade bei komplexen Installationen und Software Systemen, dass man einen großen Monolithen gebaut hat. Das heißt ein großes Stück Software, wo Teams von 20 30 Mann daran gearbeitet haben. Und das macht die Sache sehr schwierig zu. Als Beispiel zu integrieren. Sprich wenn wir ein kleines Team an einem bestimmten Feature baut, dann haben die einen eigenen Branch, also im Prinzip eine eigene Version der Software, an der sie gerade arbeiten und andere Teams arbeiten bei anderen Stellen.

Dieses diesen Code wieder zusammenzuführen, das hat immer zu Problemen geführt, gerade wenn neue Releases anstanden. In großen Unternehmen kennt man das heute noch. Es gibt Release Zyklen von bis zu einem Jahr. Das heißt, bevor die neue Version, ein neues Feature live geht, dauert es bis zu einem Jahr. Das muss alles vorher geplant werden, um das Ganze. Dieses ganze Movement sagt Hey, wir wollen weg von diesen Big Bang Releases, wo man die Finger gekreuzt hat, wenn die Software live gegangen ist, damit bloß keine Fehler auftreten.

Das wohl mal runterbrechen auf mehrmals am Tag. Das ist die Königsdisziplin. Das hilft, dass die Entwickler Vertrauen in die Software gewinnen, in ihren eigenen Code gewinnen, weil es mehrmals am Tag gebaut wird, getestet wird. Und somit ist es dann auch kein Problem, mehrmals am Tag live zu gehen. Das heißt, ich bin viel flexibler. Ich kenne kleine kleinere Features einbauen, die ich auch für testen kann mit dem Kunden. Ich kann sehen, habe das Feature Board angenommen oder nicht.

Wenn nicht, schmeiß es weg, indem ich einfach ein neues Image, die Bläue und die Kunden merken noch nicht mal, dass eine neue Software eingespielt wurde. Jetzt kann man wiederum zu dem nächsten Schritt der Lawine, nämlich die Orchestrierung, das in Produktion bringen dieser Images. Da kann ich in einem Atemzug das Thema Kubernetes oder Open Shift nennen, was nichts anderes ist, als so ein Image, das ich irgendwo gebaut habe, in Produktion zu bringen und zu betreiben.

Diese Automatismen, die du hast, ist eben sehr schön gesagt. Ich versuche das implizite Wissen von verschiedenen Admins in Dateien zu packen, so dass es explizit habe Versionen repliziert habe. Das hilft mir durch so einen Automatismus wie wie Kubernetes, Klasse oder Open Shift, da diese Software zu betreiben, zu skalieren. Wenn ich zum Beispiel merke Hey, die Software kommt gut an von 1000 Usern am Tag habe ich jetzt 10000 User am Tag. Was wäre früher passiert?

Okay, wir brauchen neue Server, bestell die mal wieder und stell dir mal live. Das ist heute passé. Du kannst. Auf Knopfdruck kannst du diese Images von drei auf 100 Instanzen hochschrauben, wenn du willst und somit viel mehr User abhandeln als gestern. Das geht instant, wenn du so willst. Gerade im Zusammenspiel mit mit Cloud-Lösungen wie jetzt AWS oder oder ok.

Ich sehe, das heißt, um noch mal so den großen Bogen zu zeichnen durch diese Verschiebung der Verantwortlichkeiten von dem Entwickler etwas mehr in. Man sagt nicht nur Okay, du entwickelst die Software, sondern du baust quasi kleine Pakete, die dann auch genauso betrieben werden können. Ist ist ja diese ganze Software Landschaft erst entstanden, dass man gesagt hat okay jetzt das heißt die ganze Maschinen Positionierung wird auch entwickelt und in Docker ausgelagert. Und du hast es eben schon angesprochen mit den Monolithen.

Diese Monolithen werden ja oder dieser Trend lässt sich ja etwa seit den 2000er Jahren erkennen. In viele kleine Anwendung zerlegt, also in die sogenannten Microservices. Und jetzt kommt sozusagen alles zusammen und geht auf, dass man sagt Okay, ich kann einerseits diese kleinen Microservices supergut in einzelne Container verpacken, die sind sicher voneinander getrennt, die können über das Netzwerk miteinander kommunizieren. Die können auf meinem lokalen Developer Rechner gestartet werden, können auf einem Server im Rechenzentrum gestartet werden, können auf einem Cloud Server gestartet werden.

Das ist eigentlich auch egal, ob das Amazon oder Ezzor oder ein anderer Hersteller ist. Das heißt, ich habe auch hier Laufe nicht Gefahr in ein Window Login zu laufen, sondern kann es quasi überall betreiben, was natürlich aus Firmen Sicht sehr schön ist. Und. Zusätzlich, weil ich jetzt so kleinschrittig iterativ vorgehe, habe ich noch die Möglichkeit, diese ich nenne es mal Features to market oder Code to market Zeit drastisch zu reduzieren, weil ich sage jetzt habe ich eh die ganze Strecke durch automatisiert und ob ich jetzt ein Release mache am Tag oder 20.

Das kann quasi die Software selber entscheiden. Wichtig ist nur, dass ich überall diese Barrieren einziehe, diese Qualitätskontrolle, die das der neue Code der täglichen zugeht. Hinzu kommt eben entsprechend kontrolliert und auf Läufigkeit getestet wird und dann sich am nächsten Tag auch direkt im Einsatz bewähren kann. Dass man die Features von der Planung bis hin zum Ausrollen, dass der Endkunde, der draußen diese Anwendung nutzt, dass dieser Zeitraum deutlich deutlich reduziert wird.

Genau genau darum geht es. Es geht nicht mehr. Ich kann mir das heute als Unternehmen nicht mehr leisten, ein Jahr lang auf neue Features zu warten. Der Markt ist so schnelllebig, ich muss Dinge schnell ausprobieren können. Ich kann mich. Früher haben sich die Unternehmen eingeschlossen, haben sich Features ausgedacht, monatelang und geplant und Excel-Tabellen. Powerpoint. Da spielt alles keine Rolle, weil der Kunde entscheidet. Am Ende ist das ein Feature, was ich will oder nicht.

Und das kann ich nur herausfinden, wenn ich das schnell testen kann. Und das wird mit dieser Technologie Docker, Microservices, Kubernetes Schnittstelle Open Shift erst möglich. Und das ist der ganze Zauber daran im Enterprise Kontext sicher möglich. Das ist ja das ganz Wichtige, dass man ermöglicht, dass man sofort zurück rollen kann auf alte Versionen und nicht ich sage mal händisch der Administrator hektische ist zwei Dateien wieder zurück kopiert, oder? Ja, das ist er ist ja in vielen Unternehmen gang und gäbe, dass das so gemacht wird noch, das ist noch viel smarter.

Also wenn du, wenn du so ein so ein ist, aber nimm als Beispiel Kubernetes. Das gleiche gilt für Open Shift. Wenn ich ein Kubernetes Cluster laufen habe, dann kann ich unterschiedliche Strategien verfolgen. Ich kann sagen Pass auf, ich habe einen neuen Release und fahre mir bitte dieses neue Release im Cluster hoch. Lass aber das alte Release bitte noch weiterlaufen und route den Traffic. Immer noch auf das alte Release und erst wenn die neue Software quasi am Start ist und ich getestet habe mit bestimmten Helm Checks und sage das neue Release ist das Fusion funktionierend, dann kann der Traffic umgeschaltet werden auf das neue Release.

Sprich ich habe keine Downtime. Keiner muss sich mal am Wochenende hinsetzen. Zwischen 3 und 4 Uhr morgens die Releases machen. Habe ich alles schon miterlebt. Die nächste neckischen Blue Green Deployment. Es gibt noch eine andere Strategie Strategie, wie zum Beispiel Canary Deployment, wo ein bestimmter Prozentsatz des Traffics, man nehme an, 10 prozent oder 5 genau oder 2 prozent nur auf das neue Release gehen. Das heißt, ich kann mit einigen wenigen Usern checken und testen.

Hey, verhält sich die Software so wie es soll? Und erst wenn ich sicher bin, dass es auch so funktioniert, weil ein gewisser Anteil des Traffics da draufgeht geht, kann ich sagen Okay, jetzt schalte ich den Rest darauf und wenn nicht, dann schalte ich die 2 prozent wieder zurück auf das alte Release. Also all diese Möglichkeiten sind dann halt in so einem Cluster gegeben.

Helm stimmt, weil die vier Anwendungs Komponenten sind ja beschrieben und man kann dann einfach via Kubernetes sorgt einfach selber mit bestimmten Mechanismen dafür, dass der Traffic auf bestimmte Docker Instanzen läuft. Was das auch noch mit sich bringt ist im Prinzip ist gibt es einen ein diese ganzen Fehler Mechanismen was ich vorher in der alten Welt gebaut habe mit Heartbeat und virtueller IP, Umzüge und und und. Das passiert heute alles automatisch im Cluster. Sobald das Cluster merkt, dass die Software nicht läuft, weil ein Image an einen Docker Container nicht so funktioniert, dann fährt er den auf dem auf einer anderen Instanz wieder hoch.

Das System heilt sich von alleine.

Das heißt, diese Technologien wie Kubernetes und Open Shift, die sind sozusagen der Herr über diese Container Landschaft und ziehen kontinuierlich Messdaten ab oder Metriken ab und gucken wie exakt, wie geht es jedem einzelnen Container? Hier ist die Antwortzeit relativ hoch. Oder wenn eine Maschine komplett ausfällt, dass man sagt Okay, hier die Port 31 antwortet nicht mehr, was ist da drin los? Ich starte ihn einfach mal neu auf einer anderen Maschine. Vielleicht gibt es da ein Problem und Kubernetes und Open Shift sind ja also ich kann die gar nicht so klar voneinander abgrenzen.

Vielleicht kannst du mir da helfen. Kubernetes steuert ja die Dienste sozusagen auf so einer eher niedrigen technischen Ebene. Und Open Shift ist von ehemals rated jetzt IBM das Produkt um diese ganze OPs Architektur aufzusetzen im Unternehmens Kontext. Vielleicht kannst du da noch mal genauer sagen, was die einzelnen Komponenten für Aufgaben übernehmen können.

Also Kubernetes selber besteht aus mehreren einzelnen Komponenten, die das System erst ermöglichen. Ich will jetzt gar nicht so auf diese einzelnen Komponenten eingehen, weil es vielleicht zu technisch wird. Aber Open Shift ist also Open Kubernetes ist ein Open-Source-Projekt und Open Shift ist ein Projekt von von Rettet. Aber Open Shift ist Kubernetes, dass heißt Open Shift oder Rettet hat Kubernetes genommen mit einer bestimmten Version und baut da drum herum Enterprise Features. Zum Beispiel hat Kubernetes kein eigenes User Management, das hat Open Shift eingebaut.

Das ist ein Feature. Es hat ein paar Sicherheitsmerkmale. Mehr als als Kubernetes des Images funktionieren da auch ein bisschen anders. Es gibt die Arbeiten in operativ nicht direkt mit Images, sondern mit sogenannten Images Streams. Deshalb ein paar Vorteile. Aber alles, was Open Schiff baut oder das meiste wandert auch wieder zurück. Irgendwann in der späteren Version in Kubernetes. Also die geben auch Code wieder einen Upstream an das Upstream Projekt ab. Aber es ist ein Kubernetes, was unter Open Shift werkelt.

Wenn einer sich mit Kubernetes auskennt, kann er mit ein, zwei Wochen Ausbildung kennt er sich auch ein Open Shift aus, weil es halt eine GUI hat, die sehr gut funktioniert. Open Kubernetes hat zwar auch ein Dashboard, aber das ist bei weitem nicht so ausgefeilt wie das Open Shift. Die Open UI Methode bezeichnet sich selber als das Enterprise Community. Okay. Genau.

Also Kubernetes ist ja Open Source und ich glaube ursprünglich von Google freigegeben. Die als Kern Komponente und Rettet hat dann quasi daraus eine komplette Pipe oder ein komplettes Produkt gemacht, mit all den Anforderungen, die eben im Unternehmens Kontext auf so eine Lösung dann ankommen darauf zu kommen.

Ja richtig. Bedeutet aber nicht im Umkehrschluss, dass ich ein Kubernetes alleine auch nicht im unterbreite Kontext laufen lassen kann. So viele Unternehmen tun das. Es ist halt nur ein bisschen mehr Aufwand, Konfiguration und so weiter. Aber natürlich kann ich auch Kubernetes so betreiben, dass es im Enterprise konnte funktioniert so genau ist dann. Wahrscheinlich muss man dieses Services, also muss man entweder darauf verzichten, hier das User Management oder man muss eben wieder mehr Manpower dagegen setzen, weil mehr Schritte händisch jetzt erfolgen müssen.

Ja, richtig, genau. Genau. Und um das und das das initiale Thema überhaupt zurückzukommen man merkt schon, dieses ganze Cluster Management betreiben der Container innerhalb des Clusters. Da merkt man schon, wie sich die Rollen anfangen zu vermischen. Weil nämlich zum Beispiel Infrastuktur, was früher der Operations man gemacht hat, jetzt auf einmal als Code vorliegt, nämlich in Jamel Dateien. Das heißt, ich kann Infrastruktur jetzt im Code ausdrücken. Stichwort Infrastruktur, Infrastruktur S Code IAS wird es plötzlich eine Entwickler Sache, weil der Entwickler kann diese Dateien erstellen und zur Ausführung bringen und schon hat die.

Selber sich eine Infrastruktur gebastelt und das ist jetzt genau dieser Mischvolk, nämlich der Boobs, einer der quasi sowohl entwickeln kann als auch sich Infrastruktur aufbauen kann und die Admins die Rolle der klassischen Administratoren ist es mehr ich sage mal dieses Cluster am Laufen zu halten, weil die werden natürlich auch auf bestimmten Hardware Maschinen laufen, ist das Thema Backup, was passiert, wenn der Node ausfällt und so weiter. Also die Aufgabenbereiche, die Verantwortlichkeiten verschieben sich. Ich merke das im Unternehmen viele Admins oder klassische Admin so ein bisschen ich sage mal dem ganzen dieser ganzen Technologie negativ gegenüber eingestellt sind, weil sie meinen, dass das ihnen Aufgaben abnimmt, dass sie plötzlich nichts mehr zu tun haben.

Im Gegenteil, es nimmt einfach wiederkehrende Aufgaben ab, so dass sich die Admins dann mehr Gedanken um andere Dinge machen können, die vielleicht wichtiger für das Business sind, als permanent zu gucken. Läuft es nicht?

Ja wahrscheinlich auch die. Die Admins kümmern sich dann von der Hardware Seite wirklich mehr um die Metall Infrastruktur, also wirklich um die Server selber. Auf der anderen Seite, das ist so meine Erfahrung, bekommen sie natürlich dadurch, dass diese Docker Container auch sehr viele Daten über sich selber preisgeben, wie ich meine Antwortzeit. Wie viel Speicherbedarf habe ich? Wie groß sind meine Williams? Bekommen Sie sehr viele Metriken zur bereitgestellt zur Kontrolle? Die Anwendungs Gesundheit möchte ich mal sagen.

Also so eine Art Health Check, dass man immer sehen kann okay, wie geht es meiner Anwendung eigentlich? Sie läuft normalerweise auf 20 Knoten, heute läuft sie auf 60, was ist denn da los? Oh, wir haben einen besonderen Ansturm, weil ein neues Produkt hat gelauncht oder so was. Und sich dann darauf eben zu konzentrieren. Derweil machen wir uns nichts vor. Die natürlich können Notes automatisch gestartet und gestoppt werden und die Infrastruktur skaliert. Aber so ganz 100 prozent vollautomatisch ist das nicht.

Also da muss immer noch mal ein Mensch draufgucken, um zu sehen Oh, hier läuft was aus dem Ruder oder man, man, das ist ja auch alles immer in so einen Apparat eingebettet. Man kauft dann Storage oder Festplatten für ein gewisses Szenario und irgendwann stellt man fest Oh, wir verbrauchen viel mehr Speicherplatz, als wir das eigentlich einkalkuliert haben. Da müssen wir mal neue Williams beschaffen. Also ohne menschliche Intelligenz geht es da nicht.

Geht es natürlich nicht. Immer noch nicht. Wie. Man muss auch bedenken Diese Landschaft ist extrem schnelllebig. Es entstehen tagtäglich neue Tools, verschiedene Frameworks, die alles immer einen Ticken leichter machen und so weiter und so fort. Also SFOR ist doch auch eine Herausforderung für die Firmen, sich in diese Landschaften, diese verschiedenen Wust an Tools einzuarbeiten, auszukennen. Wie kombiniere ich was, um mein Ziel zu erreichen? Ich will hier ein Beispiel nennen Wir haben früher, als ich in der Softwareentwicklung war, haben wir mit einem Enterprise Content Management System gearbeitet.

Comedia Sehr großes, komplexes, mächtiges System, viele, viele, viele einzelne Komponenten, die jeweils einen eigenen Server brauchten oder brauchen. Und das Aufsetzen eines solchen Systems für eine einzige Umgebung wie Entwicklungsumgebung oder oder sagen Umgebung hat Wochen gedauert. Und wir haben das jetzt so umgebaut mit zum Beispiel Terraforming, Terraforming, ein Tool, um Infrastruktur automatisiert zu Provisionen. Damit kann man als Beispiel auf der Cloud Umgebung AWS Server Infrastrukturen aufbauen, sie miteinander vernetzen, Firewalls vorbei und alles per Code.

Und mit so einem Script, was wir geschrieben haben, waren wir in der Lage binnen einer Minute so eine Infrastruktur aufzubauen, damit das Comedia überhaupt in der Lage ist, darauf zu laufen, dass das alle Notwendigen sauber isoliert, miteinander vernetzt und so weiter. Ein weiteres Script angebl. Und und Docker, Falz und Kubernetes falls um die Comedia kommt einzelne Comedia Komponenten zu, die Leute auf dieser Infrastruktur und sie miteinander zu koppeln, so dass sie miteinander reden können funktionieren können.

Das heißt also eine komplette Umgebung binnen fünf Minuten aufgebaut im Vergleich zu Wochen vorher. Das ist gigantisch und das kann jedes Unternehmen schaffen. Vorausgesetzt Sie wissen, welche Tools Sie einsetzen, um was zu erreichen.

Das heißt auch für die Entwickler ist das super praktisch, wenn man sagen muss Da Oh, ich möchte jetzt hier mal was ausprobieren. Wie verhält sich das denn in der Medienlandschaft oder in dieser Infrastruktur Landschaft und fährt sich dann schnell selber einen eigenen Cluster hoch? Der kann auch ohne Prämisse sein, also im Unternehmen selber, wenn man da vielleicht sensible Daten hat, Daten hat oder auch in irgendwelchen Cloud Computing Instanzen um. Man kann halt nur. Ich sehe das bei uns oft, dass die Data Engineers dann Maschinen hochfahren, Modelle auf CPUs auf GPU berechnen und dann wird die Maschine einfach wieder in den Winterschlaf.

Genau, weil nur das Teure oder das Aufwendige sind eben nur die Berechnung, die auf den GPU sehr schnell durchgeführt werden können. Und das ist viel praktischer, als wenn man sich da immer die Maschinen kauft und dann sich um die Treiber, Verwaltung usw. alles selber kümmern muss.

Ja, ich meine, das hilft ja auch ohne Geld zu sparen. Es gibt jetzt ein Projekt Jenkins X, das ist eine Erweiterung von Ying und Yang. Werden die meisten kennen. Das ist ein Sicilia Tool um Software zu bauen und zu duplizieren. Und das Jenkins X ist komplett gebaut für die Docker Kubernetes Cloud Welt. Als Beispiel, wenn bin ich ein Entwickler ein Public feststellt auf ein Feature Branch, was er gerade offen hat, dann wird automatisch Jenkins X aktiv.

Das instanziiert die eine neue Jenkins Instanz innerhalb eines Kubernetes Clusters baut die Software schmeißt Jack in die Instanz wieder weg. Die Plot die Instanz, die die Software Release in einem Feature Branch in einen neuen Port auf dem Kubernetes Cluster. Das heißt, du kannst. Wenn du das Feature Bratschen und Request stellst, dann kannst du 5 Minuten später kann der die Fachabteilung es wieder testen in einer separaten abgeschotteten Umgebung. Alles automatisiert und überleg mal, was das für ein Aufwand ist, war und ist so was nicht zu tun.

Naja, es wird einfach nicht gemacht oder oder. Du hast halt diese Monster Releases, die alle drei Monate alle 6 Monate alle 12 Monate anstehen und wo vorher oft an Crunch Time durchgeführt wird und alle den Atem anhalten, wenn es wirklich released wird. Und das ist ziemlich unangenehm und das möchte keiner und das möchte schon gar kein Unternehmen, was irgendwie einen planbaren Release Zyklus haben möchte. Das ist glaube ich gut nachvollziehbar ist.

Man muss dazu sagen, es ist keine unkomplizierte Landschaft. Also auch die Entwickler stehen vor einem Paradigmenwechsel, weil du kannst deine Software nicht mehr so schreiben, wie du es gewohnt bist. Es gibt eine sogenannte, eine sogenannte Methodik. Das nennt sich die 12 Factor Methodik. Also man kann das googeln, das sehr genau beschrieben, wie eine Software beschaffen sein muss, best Practices, damit es in so einer Umgebung laufen kann. Die ist einmal flüchtig ist, weil ein Pott oder einer Instanz in einem Kubernetes Cluster ist flüchtig, es kann der Cluster kann entscheiden Hey, dieser dieser Not hat so viel, so viel Kapazität Engpässe.

Ich muss den jetzt woanders hinziehen. Die Software, damit es wieder vernünftig laufen kann. Das heißt, die Software wird auf der einen Seite abgeschaltet, auf der anderen Seite wieder hoch geschaltet und der Entwickler muss wissen, was das bedeutet für seine Software. Und zum Beispiel darf er keine Session vorhalten und er muss dann halt anders programmieren. Das heißt auch der Entwickler steht vor neuen Herausforderungen. Aber wenn das gemeinsam sowohl von der Entwicklung als auch von der von der Operation Seite gemeistert wird, eröffnen sich dem Unternehmen völlig neue Möglichkeiten, also völlig neue Möglichkeiten in Bezug auf Geschwindigkeit der Entwicklung, Geschwindigkeit, Sicherheit und auch Kosteneinsparungen.

Weil du das Du hast es schon gesagt ja, man muss es lernen. Also eine Weiterbildung ist sowohl von den Entwicklern erforderlich als auch von den Systemadministratoren. Wenn man es aber kann, kann man natürlich mit so einem Cluster sehr viele unterschiedliche Geschäftsfelder abdecken oder sehr viele Anwendungen darin betreiben und die Cluster Ressourcen sehr flexibel einsetzen, die man jetzt bei starren Maschinen vielleicht nicht so einfach nicht hat oder auch wenn man also viele Anwendungen haben ja auch zyklische Last Spitzen, wenn da ein Sonderangebot vorherrscht oder sonst was.

Und dann muss ich immer so viel Infrastruktur vorhalten, um die komplette Last Spitze abfangen zu können. Und innerhalb des Clusters weiß ich Okay, die eine Anwendung hat montags eine Landspitze, die andere vielleicht freitags. Dann kann ich die Cluster Ressourcen so verwenden, dass die beiden Anwendungen zugutekommen. Ja, du hast noch. Du wolltest noch über Git OPs und Df6 sprechen.

Genau. Ja, das sind ein paar Neuerungen oder Erweiterungen dieses Delvaux Paradigmas, was der OPs bedeutet. Dass man also Security ist ein ganz wichtiges Thema, gerade im Enterprise Kontext. Meistens ist es aber so, dass die Anwendung die Pflicht wird und von außen Penetration Testing betrieben wird, um um Schwachstellen zu finden. Das heißt, wenn man mal sich so eine Continuous Integration Continuous Development Kette anguckt, die von links nach rechts wandert. Links ist im Prinzip der Code, der wird im nächsten Schritt gebaut, wird im nächsten Schritt getestet und irgendwann geht es in die Produktion, läuft also von links nach rechts.

Und der Sexshops bedeutet, dass man versucht, Security schon ganz weit links in der Kette zu integrieren, so dass du bei jedem Schritt Security checks. Das bedeutet als Beispiel Du kannst Tools einbinden in diese Pipeline, die statische Code Analyse betreibt, also quasi dein Java Code. Ich bin dabei Entwickler, deswegen nehme ich Beispiele dein Code analysieren, auf Patterns untersuchen, die zum Beispiel auf Funktion hindeuten könnten oder potenzielle Gesetzestextes ermöglichen könnten und so weiter. Und da kriegst du so ein Scoring, der die wichtigsten Bedrohungen, Helm, Attacken, Bedrohungen klassifiziert und sagt Okay, hier ist ein Score grün oder rot, da sollst du nochmal ran.

Damit fängt es an bis hin zu Wenn du Docker Images gebaut hast, gibt es Tools, zum Beispiel von Oberst Web Application Security, die die wichtigsten Web Attacken durchführt auf dein Image, der dann guckt. Also der liefert eine Instanz hoch für die Tags drauf durch und kommt dann durch oder nicht. Also du kannst diese Dinge automatisieren. Da haben wir drüber gesprochen. Das ist das ganze Sinn und Zweck Automatisierung. Wenn man schon mal automatisieren kann, dann will man auch Security so gut wie möglich automatisieren.

Und das ist halt okay.

Ja, ich kenne auch sowas. Da gibt es auch für Java über Java gesprochen. Das gibt es auch ein Maven Plugin. Dann bindest du quasi diese Library ein und dann guckt er beim Bild. Oder immer wenn Maven ausgeführt ist, guck dir eine Online-Datenbank nach, verwendet deine Applikation vor. Bekannte oder haben die Versionsnummer, die die Versionen, die du benutzt, die haben deine Abhängigkeiten, haben die bekannte Schwachstellen oder Sicherheitslücken, dann musst du die Version upgraden. Also du benutzt, sagen wir mal einen FTP-Server Bibliothek in deiner Anwendung.

Und da wird jetzt eine Sicherheitslücke erkannt in der Version 2.0, die du verwendest. Dann sagt dir das Tool Ich bau das nicht. Du musst Version 2 1 benutzen für den FTP-Server, damit du damit ich dir das durchgehen lassen, weil sonst baust du eine Version mit einer Sicherheitslücke.

Nicht nur nicht nur Sicherheit, sondern auch Compliance. Also vielleicht darf darfst. Weil du in einem bestimmten Land bist bestimmte Version einer Library und man denkt du LIBREAS, die vielleicht nicht irgendwohin Diplomat werden dürfen oder herausgegeben werden dürfen. Und die Software checkt, was du da gerade einsetzt, ist diese lange Version, die du einsetzt. Kompliment zu deinen Unternehmens Policies und schlägt dann Alarm und führt darüber Buch und Auditing usw. Das spielt im Unternehmens Kontext kann Unternehmen die international operieren.

Shantanu habe ich gar nicht gedacht, dass der gewisse Kodex oder so nicht überall verwendet werden können.

Zum Beispiel genau genau. Und das andere Thema, das geht auch. Das sagt lediglich aus, dass es also im Prinzip eine Version Kontrollsystem dein Source of Trust ist. Das heißt dort steht wie ein Server auszusehen hat und dort steht, für welche Umgebung du welche Version der Software, die bloed haben willst. Und sobald Änderungen passieren, reagiert das System, also das Kubernetes Cluster, darauf und führt Dinge aus. Als Beispiel Wenn du ein Branch mit einem bestimmten Tag versüßt, zum Beispiel Production oder Staging, dann wird das System aktiv.

Die Leute diese Version mit diesem Tag genau in dieser Umgebung, damit du das testen kannst und git ops, weil halt dies, dass die Quelle okay, das heißt, der Entwickler würde jetzt, der sagt Oh, ich habe lokal getestet, es funktioniert soweit, ich würde es auf dem Testsystem haben wollen, dann merkt er seinen Branch oder? Oder nach dem Code Review March der Verantwortliche den Branch auf den Testing Branch und dann würde automatisch würden die Events getriggert, die notwendig sind, um diese neue Version auf der Test Infrastruktur bereitzustellen und.

Genau, also Teil des Masiar hatte ich vorhin erwähnte Pull Request, das auf einen bestimmten Pull Request, eine Version gebaut wird und im Kubernetes das Zitat mir gibt, aber man diese Richtlinien hat, mit denen man arbeitet, betreibt man okay.

Das ist doch sehr interessant und auch sehr nützlich aus Entwicklungsperspektive, dass man da den Workflow ein bisschen abkürzen kann.

Ja, definitiv der super!

Vielen Dank für die ausführliche Informationen Masiar. Wie gesagt, unsere Zuhörer Fragen haben, dann können Sie gerne eine E-Mail an Podcasts Skillbyte senden. Wenn der Podcast gefallen hat, dann gerne abonnieren und gerne eine Bewertung abgeben. Das hilft uns immer sehr, um den weiter zu verbessern. Und eine weitere Informationsquelle für technische Informationen ist der Skillbyte Blog. Also einfach auf www. Skillbyte nachsehen. Da gibt es oben in dem Menü den Punkt Blog oder Skillbyte ist das Blog. Kann man auch direkt eingeben und da haben wir auch sehr viele Informationen zu dem Thema.

Ja, vielen Dank. Wunderbar.

Hat mich sehr gefreut. Wunderbar. Masiar bis zum nächsten Mal. Bis dann. Ciao. Tschüss.