Podcast #8: Must-have Skills, Technologien und Weiterbildung für DevOps

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

In diesem Podcast geht es um das Thema: Must-have Skills, Technologien und Weiterbildung für DevOps

// Inhalt //

1. Was ist ein DevOps Engineer?
2. Welche Skills hat ein DevOps Engineer?
3. Welche Technologien setzen DevOps Engineers ein?
4. Welche Erfahrungen hat Skillbyte mit DevOps / Kubernetes gemacht?

Link zum Podcast: Devops - Was ist DevOps und das DevOps Mindest?
https://soundcloud.com/skillbyte/skillbyte-podcast-2-devops

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 zum Skillbyte Podcast Nr. 8 Matthew Skills Technologien und Weiterbildung für Deep Jobs Mein Name ist Maurice und ich freue mich ganz besonders, euch heute bei dem Podcast begrüßen zu dürfen. Abonniert den Podcast gerne, wenn euch die Inhalte interessieren und euch technologische Bildung wichtig ist. Und wenn ihr Fragen im Nachgang habt oder was spezieller wissen möchtet, schreibt uns gerne eine Mail an Podcast skillbyte. Ansonsten würden wir uns über Feedback und positive Bewertungen freuen, weil uns das motiviert, weiter an dem Podcast zu arbeiten.

Mein Gast heute ist Masiar, der Geschäftsführer von Skillbyte Helm.

Es freut mich sehr, da zu sein.

Du bist ein alter Hase und wir sprechen heute über das Thema Devotees oder Skills, Technologien und Weiterbildung für UPS. Und da freue ich mich ganz besonders, dass wir heute sprechen können, weil du der Experte bist in dem Bereich.

Danke! Ich hoffe mal, jetzt habe ich natürlich die Erwartungshaltung sind riesig von meiner Seite. Vielleicht fangen wir einfach mal an, wenn du uns erklären könntest was genau ist denn ein Dev OPs Engineer? Steve Jobs Engineer würde man doch sagen, oder? Oder einfach Devotees? Ja, genauso wie bei der beim Software-Entwickler da auch verschiedene Spielformen gibt. Ja, es gibt ja auch den Software Engineer und den Software Developer in Nuancen, die eine Unterscheidung sind wirklich in den Nuancen.

Es gibt keine keinen großen Unterschied zwischen der Bobs Ingenieur der Bobs. Das ist ein zusammengesetztes Wort, eigentlich zwischen Developer und Operations. Historisch gesehen gibt es den Entwickler und den Administrator. Das heißt, und der Begriff ist noch mal, wir haben da zwar in einer anderen Podcastfolge drüber gesprochen, aber für diejenigen, die das noch nicht gehört haben Früher war das so. Der Softwareentwickler hat sein sein Artefakt gebaut, da purzelte ich jetzt als Entwickler. Kann das niemals als Beispiel Java nennen.

Purzelt eine Datei oder eine Datei heraus, das hat man dann irgendwo in einem Übergabe Ordner abgelegt. Ob das jetzt Jenkins automatisiert gemacht hat, damals noch Hudson oder man das PDF PCP auch immer irgendwohin geschoben hat, hat ab dort ein Systemadministrator oder die Kollegen vom Operations diese Datei genommen und dann verteilt auf verschiedene Application Server. Ob das jetzt im Web Logic war, Animate Bos oder Plain Tomcat hat dann die Dateien dort Ausführung gebracht und die Schnittstelle war relativ klar. Der Entwickler entwickelt das Artefakt im Warp und der Admin Diplomat ist dann.

Und das hat sich jetzt geändert oder ist dabei sich zu ändern. Und aus dieser Rolle heraus oder aus diesen beiden Rollen ist eine Rolle entstanden, nämlich die Rolle des Sterbeort. Natürlich gibt es die anderen Rollen nach wie vor. Du brauchst natürlich Entwickler, du brauchst natürlich Administratoren, aber die Zuständigkeiten haben sich ein bisschen verschoben und diese neue Rolle geschaffen.

Wenn man sich das bildlich vorstellt, ist es quasi so. Früher waren es zwei getrennte Abteilungen und jetzt sitzt quasi jemand genau dazwischen, der beide Kompetenzen mitbringt.

Ganz genau. Genauso sieht es so aus. Es begab sich so, dass der erste Entwickler immer mehr Operations Aufgaben übernommen hat, wie zum Beispiel Jenkins konfigurieren oder auch Peschel irgendwas irgendwohin zu schieben. Also es gab immer so eine Rolle, die aber doch sehr, sehr sehr seinen Schwerpunkt hatte. Aber inzwischen ist das tatsächlich echt so eine, so eine so eine Zwitter Rolle. Meistens entstanden aus Entwicklern, die mehr Operations machen, aber genauso gut gibt es von der anderen Seite einen Admin, der jetzt auch sich mit der Entwicklungsgeschichte auskennt.

Also du wirst immer einen treffen, der seinen Schwerpunkt irgendwo hatte und jetzt das verschoben hat in die andere Richtung. So wie bei mir auch. Ich bin irgendwie. Seit 20 Jahren habe ich Software entwickelt, Java Enterprise Application und habe dann irgendwo vor sechs Jahren meine meine Passion entdeckt für für dieses Thema also Content Regierung Cluster und habe mich mehr und mehr zu dem Thema hingezogen gefühlt, zumal ich die ersten zwei Jahre noch vor der Softwareentwicklung tatsächlich Linux Administrator war. Also die ganzen Shel Sachen Linux und so waren mir schon geläufig.

Ich habe dann Softwareentwicklung gemacht, sehr lange das Wissen um Linux und Shell und Wikipedia und so hat mir natürlich sehr sehr sehr geholfen bei der Entwicklung. Und jetzt mache ich den Switch zu dem seit sechs Jahren und beschäftige mich halt mit diesem Thema Content, Content, Cluster, Lösungen und so weiter.

Und das ist das eigentlich, was die Rolle erst so salonfähig gemacht hat, weil man durch durch Einsatz von Container Technologien ergibt sich die Frage wo laufen diese Container denn, wenn ich als Entwickler erst einmal eine Java Applikation habe und das generiert mir lass uns sagen Spring Boot, das erzeugt mir so eine Zahl und aus dieser dann baue ich ein Image schreiben Docker Fall wo wandert das denn hin? Also wer baut das denn dann? Und wenn ich ein Microservices denke, was?

Ich sage mal. Umsetzung von mehreren Diensten innerhalb von von als Container Diplomat werden wir kommunizieren diese Container miteinander, wo werden Sie Diplomat und und in welcher Umgebung und wer Diplomat Diplomatie und daraus ist dann wiederum die Cluster Technologie entstanden, die Kubernetes Open Shift und und Meadows Marathon. Und es hat halt immer mehr dazu geführt, dass gerade diese Cluster Technologien lassen sich alle PPI bedienen. Das heißt, du kannst Jenkins laufen lassen, der nach dem Bauen des Images ein Deployment anspricht und in Kubernetes irgendwas Diplomat und Büchele vor Administrator hat ein Kubernetes Server aufgesetzt.

Ab dann kannst du als Entwickler quasi alles andere beeinflussen. Du kannst die Images bauen, dort die verschiedene Quality Stages durch verschiedene Stages promoten, die Images und und und Cloud-native, sogar Firewalls, die sich heutzutage PPI bedienen lassen. Früher musstest du einen Port oder eine IP freischalten. Muss es, musstest du ein Ticket erstellen, ein paar Tage warten und heutzutage lässt sich alles über Automatisierung und so weiter erreichen, so dass der Entwickler immer mehr Verantwortlichkeiten rund um das Thema Betrieb übernommen hat.

Und darum geht es bei dieser Rolle der VIPs. Also einer, der sich in beiden Welten wohlfühlt.

Das ist ja quasi oder wenn ich mir das jetzt mal so vorstelle, schon die Idee. Die zweite Iteration der Automatisierung früher der klassische Admin, hat halt diese Systeme gewartet, Systeme gepatzt hatte so ein Monitor vielleicht an der Wand im Administration Büro, wo verschiedene Metriken einliefen für verschiedene Anwendungen. Also so kenne ich das noch, dass da drauf steht Oh jetzt oh, irgendein Eintrag bedroht jetzt geschäftiges Treiben im Admin Büro. Dann wurden dann Gegenmaßnahmen ergriffen, um zu sagen Okay, was ist da jetzt passiert?

Wie kriegen wir die Anwendung wieder funktionsfähig? Und diese ganzen Überprüfungen, die früher manuell gemacht wurden. Also ich gucke Monitor an der Wand oder ich prüfe verschiedene Systeme nach. Die werden heute komplett von diesem Dev OPs Framework übernommen. Genau. Also die gucken von selber nach. Ist ein Dienst ausgefallen, dann starte ich den neu. Und das diese Regeln oder diese Erfahrung, die die Admins früher hatten, so nach dem Motto dieser eine Prozess zickt immer und die beiden, wenn die sich nicht verstehen, muss ich das Netzwerk Interface mal neu starten, dann geht es schon wieder.

Das liegt heute halt als Code vor, damit Kubernetes oder verschiedene Tools dann eben entsprechend agieren können.

Ja genau. Also wenn man, wenn man mal zurückdenkt, was ein Admin alles machen musste, um zum Beispiel Nehme an, dein dein Service ist von außen über einen speziellen Einstiegspunkt erreichbar, also über deines Namens IP Adresse. Wenn der Dienst dann weg war musste haben die Admin sehr viele ich sag mal Linux Tools benutzt, um zum Beispiel die IP die das war eine virtuelle IP um das auszutauschen und das woanders hin zeigen zu lassen. Per Peacemaker wurde zum Beispiel geguckt ist der Dienst da?

Man hat sehr viel auf IP Ebene selber gemacht und jetzt wird es interessant. Im Grunde ist Kubernetes nutzt einige Linux primitiveren nennt man nennt man so wie zum Beispiel Linux Namespace Groups IP Tables und hat wenn man es mal sehr abstrakt sagen smarten Wrapper drum herum gebaut, so dass du keinen Admin mehr braucht, der diese Dinge tut, sondern man hat so ein Layer da vorgeschaltet. Denn jeder der eine API lesen kann oder eine Kommandozeile, einen Befehl absetzen kann sehr einfach all diese komplizierten Sachen unten drunter bewerkstelligen kann.

Okay, also man hat die Linux System Tools Perl Rest API an steuerbar gemacht und wahrscheinlich noch vereinfacht oder die Ansteuerung vereinfacht.

Wenn du so willst. Ja, Narayen und Kubernetes macht natürlich noch ein bisschen mehr neben diesen ganzen IP technischen Sachen. Nun und ich sage mal diese primitive, weil ich eben genannt habe, kann es natürlich Container zum Laufen bringen. Wobei es inzwischen schon Kubernetes Distributionen gibt, die jetzt gar nichts mehr so viel mit Containern zu tun haben, weil klassischerweise verbindet man einen Container mit Kubernetes, sondern es gibt auch Kubernetes, wo man rein Linux administrieren kann. Aber entstanden ist es ja von Google.

Also Google hat dort Kubernetes quasi gebaut. Das ist anders. Vorher hieß Back und ist dann der Open Source Community übergeben worden als Kubernetes. Und das ist sozusagen der de facto STANDARD Cluster für lokal betriebene Landschaften. Wobei es inzwischen auch wieder Bewegungen gibt, das Docker als einzige Runtime abgelöst wird oder parallel Runtime entstehen, namentlich ACT und andere, die zum Beispiel auch dieman less sind, wo du gar kein Docker, die man mehr braucht, sondern es wandelt sich sehr viel.

Und das ist auch ein Thema bei Obst. Er muss sehr in dieser schnelllebigen Welt sich sehr schnell zurechtfinden können. Entstehen ohne Ende Tools. Verschwinden auch wieder. Man muss sehr am Ball bleiben.

Cool, jetzt hast du quasi ein gutes Bild gezeichnet. Was ist es und was macht ein Depp Engineer und wie ist das historisch einzuordnen? Welche Skills muss denn ein Ingenieur haben? Also Weiterbildung ist essenziell, das würde ich ja fast sagen. Das ist generisch in der IT so. Aber im TV-Bereich und im Frontend Bereich wahrscheinlich noch, muss man da noch ein kleines Ausrufezeichen dahinter setzen. Es gibt also Def OPs Engineers heute so wie du. Die kommen aus der Softwareentwicklung, ham aber administratives Hintergrundwissen oder Administration Hintergrundwissen und sagen okay, Softwareentwicklung kann ich.

Ich weiß wie die wie ein Linux System funktioniert, da verbinde ich das doch einfach mal zusammen. Das ist glaube ich relativ häufig. Gibt es denn auch zum Beispiel Administratoren, die sagen ok, ich würde jetzt auch gerne mal mehr entwickeln oder ist da wirklich Coding notwendig um Kubernetes zu steuern? Oder reicht auch da Scripting? Im Prinzip, was ja viele Admins schon gewöhnt sein dürften?

Also zum einen muss ich noch einen Schritt zurückgehen. Du hattest vorhin, bevor ich das beantwortet. Du hattest erwähnt, dass das früher im Prinzip man diese Monitore hatte, wo die Admins draufgucken und so. Das gibt es nach wie vor. Also du kommst ja meistens nicht in so grüne Wiese Projekte rein, sondern schon in der Landschaft, wo es gewisse Tools und zentrale Software, Monitoring und so weiter existiert. Das heißt, diese sogenannten Leitstellen, da wo du, wo du auf große Monitoren oder Monitoren siehst, was passiert, wenn solche Applikationen down ist, die gibt es nach wie vor und du kannst das in Kubernetes anbinden, also Tools wie z.B. X oder Ich singe.

Du kannst sie dazu bringen, englische End Points im Cluster zu monitoren. Die sind natürlich nicht so cloud-native. Das heißt, die Tools verändern sich. Cloud-native zum Beispiel sowas wie Prometheus, wo du Prometheus innerhalb des Clusters laufen hast und du zum Beispiel einen Container einfach mit einer bestimmten Annotation versieht und schon weiß das Cluster oder Prometheus. Hey, das ist ein neuer Endpunkt, den ich quasi schreiben muss. Und schon wann packe deine Applikation mit in dieses Monitoring rein und das ist der Punkt dieses Wasser super komfortabel.

Genau darum geht's. Und das machen Entwickler. Das ist das Allerbeste. Das, was der Entwickler schreibt. Artefakte für seine Applikation, die er benötigt, macht nur noch eine Portion dran. Und schwupps, bist du mit dem Monitoring drin.

Ja, perfekt. Ja, so will man das als Entwickler. Genau. Es ist schon klar, dass diese alten Leitstellen noch gibt es. Ich meine, du kannst aber nicht alles bei Kubernetes abfragen. Es gibt ja immer noch Memory fällt aus oder Festplatten fallen aus, wo dann wirklich physikalisch ausgetauscht werden muss. Das ist natürlich nach wie vor auf dem alten Wege. Wird das überwacht?

Richtig, muss es ja auch nicht. Das ist ja. Also du kannst nicht alles von innerhalb des Clusters irgendwie monitoren. Was ist, wenn das selber ein Problem dann hat? Also genau so jetzt aber zu der zu der anderen Frage. Also ideal ist also bei mir war es ideal, weil ich schon Systemadministratoren Erfahrung hatte in die Entwicklung und jetzt wieder Richtung der Warp. So versichert quasi beide Welten oder alle drei Welten irgendwie mitgekriegt. Es ist vielfältig. Du, also ich als ich sage jetzt mit der Dermot Rolle entwickelt selber jetzt nicht mehr, aber ich weiß sehr genau, wie eine Java Applikation zum Beispiel gestrickt sein muss, damit sie als Container im Cluster läuft.

Und ich kann auch die Fehlermeldungen lesen und weiß was damit zu tun ist. Ich kann die Applikation auch sehr gut troubles, aber du musst dich entwickeln können. Das heißt, wenn du von der Admin Seite kommst, reicht es bis zu einem gewissen Level in die Entwicklung einzutauchen, dass du weißt, zum Beispiel im Falle von Java, wie du liest, was die wichtigsten Sakrales bedeuten, wie eine JVM sich verhält oder wie du mit JVM tunen kannst mit gewissen Parametern und wie dieser Parameter wie zum Beispiel hier und so weiter im Container Umfeld, im Cluster sich verhalten.

Und so zum Beispiel weiß ich, dass Java 8. Wenn du da die Settings setzt. Die DWM weiß zum Beispiel nicht, dass sie in einer Container Umgebung läuft. Okay, sie sieht die Memory Grenzen nicht und ab Java 11 ist das mit drin. Bei Java 8 kannst du irgendwie so ein Experimental Feature aktivieren, was es dann wiederum weißt du, das weiß ich ja Java Entwickler und kann das sehr gut zuordnen. Das heißt, wenn du mich jetzt fragst, würde ich sagen ich muss jetzt nicht wissen wie ob es objektorientierte Programmierung ist oder oder solche Dinge.

Aber wie sich die JDM verhält, was die wichtigsten Parameter sind und wie gesagt die Fehlermeldungen deuten können und und und. Das reicht dann schon.

Ich denke das ist auch realistisch, dass das viele Admins hier heute schon tun. Also die sehen irgendwie einen Crash in Dienst, kommt nicht mehr hoch. Dann wenden sie sich an den Entwickler und sagen Guck mal hier, das ist das Log, weil ich habe neu starten probiert und dies und das, aber jetzt bist du dran oder so und genau so war das früher. Das hat sich vom Admin die Lotsen geschickt, da geht das nicht und das wurde dann immer hin und her geschoben und der Vopos kann das halt lesen.

Okay so und skripten als. Sollte man auf jeden Fall können. Aber so Beschmutzung Ketten Du musst idealerweise Jamel lesen können und schreiben können, weil alles in dieser Welt ist, entweder in Jamil oder ein Jason, aber ich würde sagen, 80 90 prozent werden in Jamel Dateien abgelegt, wie zum Beispiel Deployment, Konfigurationen und andere sämtliche Konfigurationen. Elemente sind in Jamel geschrieben.

Ich habe in der Markup Language ist glaube ich der Fachbegriff, wenn jemand nachgucken möchte, der Jamel noch nicht gehört hat.

Und du solltest natürlich dich komplett mit dieser Container Welt auskennen. Wie das funktioniert? Docker als Hauptgrund seien noch STANDARD Randthemen, Kubernetes, aber auch mit allen neuen Entwicklungen die auf uns zukommen. Ich hatte einige erwähnt wie aktiv oder dieses OKI weiß was an einem STANDARD Interface einer Gemeinschaft ist. Und jeder OC konforme oder kompatible Runtime kann in Kubernetes laufen. Das hat mit diesen eine sollte man sich auskennen, idealerweise noch eine Automatisierungstechnik angeben oder Terraforming machen. Sie ist für für Applications Konfiguration, Positionierung von Applications Artefakten, Konfiguration auf diverse Maschinen und Terraforming mehr für Infrastruktur Positionierung.

Das heißt, du kannst mit einem Knopfdruck kannst du in APS komplette Landschaften oder On Prem oder sonst wo hochfahren oder noch hinzufügen zum Cluster. Solche solcherlei Dinge machen mit Terraforming oder andere, weil das, was in einem der beiden sollte man sich auskennen, idealerweise sogar beide, je nachdem, was der Kunde oder der, was in dem Unternehmen eingesetzt wird, wahrscheinlicher. Genau was ich denke, was auch noch wichtig ist, ist dieses diese CCD, die Pipeline, also Continuous Integration zu kennen.

Früher, du hast es eben angesprochen, da wurde wurde der Code in Subversion committed noch oder ist schon ins git repository um dann hat Jenkins den gebaut und das Artefakt war dann war oder naja was dann irgendwo hin geschoben wurde und heute geht es ja weiter. Also dann wird Jenkins baut es immer noch, baut aber vielleicht direkten Container, Image oder Image, was dann nach und nach so Rolling Release mäßig ausgerollt wird. Über die einzelnen Ports, über die über die einzelnen Maschinen im Kubernetes Cluster, so dass man wirklich ein komplettes Release durchführen kann und der Endkunde oder der Business Kunde je nach Anwendung keinerlei Ausfallerscheinungen bemerkt, sondern direkt die neue Version dann nach einer gewissen Zeit ausgerollt ist.

Das denke ich, ist ja auch noch weiter gesponnene Gedanke über siegt, der ja perfekt durch Kubernetes Cluster unterstützt wird.

Ja genau. Also wenn meistens kommt immer noch ein Jenkins zum Einsatz. Aber es gibt inzwischen andere gute Pipelines, wie zum Beispiel gibt Lab Little Kagome etwas mehr Container oder Kubernetes, native ist sie usw. Es gibt inzwischen eine Handvoll von diesen Systemen. Es ist die Aufgabe des Steve Jobs, ein System aufzusetzen, zu konfigurieren, mit den Benutzern, mit den notwendigen Plugins zu versehen. Aber es ist dann so, dass meistens das Ganze, der Prozess in Stages ausgeführt wird.

Und dieses Tages sind wiederum in Dateien abzulegen im Fall von Jenkins. Jenkins Fail und das liegt im Code Repository. Das heißt, die Systeme sind so ausgelegt. Wenn Sie Code auschecken und unseren Jenkins Fail finden, dann wissen Sie Oh, okay, ich muss aktiv werden und fang an zu bauen. Das hast du konfiguriert. Jenkins Job, so dass du sagst, da ist man Repo und man Jenkins viel und schon läuft Jenkins los und fängt an diese Datei abzuarbeiten, hat gewisse Befehle, beinhaltet das im Falle von Jenkins ist es groovy, wobei wir beim Scripting werden, wobei du kein groovy Programmierer sein muss, um so eine Helm, so eine Pipeline oder so Stages zu definieren, sondern Programmierkenntnisse reichen.

Die Syntax ist sehr einfach. Das was du sagst, pass auf. Als ersten Schritt fangen wir den Code an zu bauen und zwar mit May. Dann nimm das Java daraus gepurzelt ist und hat das Image wir das Image so und so, schieb das Image da und dahin und dann die Probleme. Das mit den Dänen, den Kubernetes Cluster, all das kannst du dort definieren. Üblicherweise macht das der Boobs zum Ersten Mal für die für die Entwickler. Und ab dann können die Entwickler quasi das selber beeinflussen.

Aber die Programmierer und das bisschen groovy können sie auch lesen und können dann, wenn sie gewisse Änderungen haben, das dann selber machen und so, dass der der Mob sich dann wieder mit anderen Dingen beschäftigen kann.

Also technisch als Skills noch mal zusammenfassend Bash, Jamil, Jason Git Lab oder git allgemein und Kubernetes natürlich. Das sind so die großen Themen und dann alles was an Entwicklung Software seitig hinzukommt oder an Linux Basiswissen. Das hilft natürlich auch ungemein bei der Erstellung dieser Skripte. Ist eigentlich auch als Dev OPs. Nützt es mir was wenn ich Windows Server Kenntnisse habe oder ist das. Komplett außen vor in der Windows Welt definitiv, sie ist auch ein ganz wichtiger Part, das gehört dazu.

Orchestral ist zu dieser Liste, was du aufgezählt hast. Ne, Windows ist definitiv auch ein Thema. Ich selber hatte mit Windows Containern nichts zu tun oder mit dieser dieser Welt nichts zu tun. Ich bin auf der Linux Seite, aber du kannst auch Windows Container bauen, die auch mit einem Windows ausgestattet sind. Aber da kann ich jetzt nicht so viel zu sagen. Weil das einfach nicht mein Universum ist, kenne ich auch keinen Kunden bisher der das einsetzt.

Mehr also mehr. Wäre mal ganz interessant zu sehen wie das geht.

Zum Thema Sicilien Wir haben es jetzt sehr schnell durchgezählt, aber das Thema Deployment ist die heiße Continuous Integration. Das heißt, dass werden, wenn die Developer das auf verschiedenen Branches einchecken. Das soll ja helfen, dass Code relativ oft gebaut wird und ein Feature was Committee, das irgendwie gebaut wird oder gemacht wird in den Developer oder Master oder was auch immer und man sehen kann, dass die Software immer noch baut. Auch wenn ich jetzt dann entwickelt habe oder hundert andere Entwickler gebaut haben, um dieses permanente Bauen und Integrieren in in den Branch ist Continuous Integration.

Der nächste Schritt ist ja Continuous Delivery. Das bedeutet, ich baue ständig. Das heißt, den Code, den ich jetzt integriert habe und gebaut habe, will ich, den liefer ich ständig.

Genau das ist noch was anderes als Deployment. Das Ausliefern heißt das Artefakt bauen und irgendwo hinschieben. Dass ich auch weiß, dass ich nicht nur bauen kann, also den Code kompilieren kann, sondern auch das gewünschte End Artefakt bauen kann, wie zum Beispiel Image oder eine Datei oder was auch immer.

Der nächste Schritt wird dann Continuous Deployment, so dass du wirklich Code angefangen beim Commit automatisiert in Produktion bringen kannst. Meinetwegen noch mit dem Quality dazwischen, wo einer händisch noch eine Freigabe machen muss, damit es auch wirklich in Produktion läuft und wie das Projekt wird. Da geht es zum Beispiel bei Kubernetes verschiedene Strategien. Standardmäßig ist das Rolling Update, das heißt, wenn du Code in Produktion bringst, eine neue neue Version deines seines Images, dann fährt Kubernetes dieses diesen Container hoch.

Der alte Container mit der alten Version läuft aber immer noch. Und erst wenn der neue Container sagt Hey, ich bin da und es gibt einen Helm Signal, dann Switch Kubernetes ersetzt Traffic auf den neuen Container um.

Das heißt, du hast keinen Ausfall gehabt deiner Software Applikation. Es gibt aber auch andere Strategien, wie zum Beispiel Canary Releases, wo du auch im Container hochfährt mit der neuen Version und nur ein Prozent Teil deines Traffic, wie zum Beispiel 3 prozent 5 prozent ein prozent auf diese neue Version leitest, so dass du gucken kannst. Funktioniert die Software noch, ohne dass jetzt alle deine Kunden das sehen, sondern nur ein geringer Teil. Und wenn du sicher bist, dass das funktioniert und keine Fehler, wie kannst du dann umsetzen?

Ist das nicht ein bisschen komplizierter? Geht natürlich nur, wenn du keine Datenbank und so weiter hast. Aber von diesen verschiedenen Strategien gibt es zwei oder drei. Und dann muss man auch den Kunden, also in unserem Fall auch beraten können Hey, was willst du und wie kann so ein Prozess oder so eine Umgebung aussehen?

Also es geht schon ins Detail dann auch.

Wahrscheinlich hängt das auch stark von der Anwendung ab. Welches ist das beste Diploms Vorgehen für diese jeweilige Anwendung und was ist da verkraftbar? Oder wie schafft man den meisten Nutzen?

Ja ja, stell dir vor du hast Instanzen von einer Software mit 100 Containern die balanced werden. So, wenn du jetzt aber sagen wir diese Blue Green Deployment, was bedeutet die Farbe hundert neue Instanzen, um von der neuen Version. Und wenn das funktioniert, dann wird es um das Wort in einem gewissen Zeitraum doppelte Ressourcen und man muss sich da schon sehr viel je nach Umgebung Gedanken machen, wie so eine sinnvolle Strategie aussehen kann.

Verstehe. Klar, sehr viele Technologien für Devotees Engineers. Ansonsten Admin Seite haben wir besprochen. Die Coding oder Scripting Seite haben wir angesprochen. Auch oder? Meiner Erfahrung nach müssen Steve Jobs auch gut kommunizieren können, also eben in beide Richtungen, dadurch, dass sie mit beiden Gewerken zu tun haben oder aus einem Gewerk stammen und diese Aufgaben nach und nach übernommen haben, auch gut kommunizieren, um dann eben auf der einen Seite zu verstehen Okay, was braucht die Anwendung wirklich?

Also sonst aber natürlich okay, gib mir 100 Container, dann läuft meine Anwendung immer um. Ich sage mal mit Augenmaß die Anwendung zu positionieren und dann eben auch auszurollen. Verantwortungsgefühl ist natürlich auch wichtig, weil als Dev OPs oder als wenn man Operations macht, ist natürlich der Fokus auf Stabilität. Als Developer will man natürlich neue Features entwickeln. Das in der Vergangenheit sind diese beiden Richtungen ja oft diametral aufeinander gestoßen und es kam eben zu Verwerfungen zwischen den Developer und Operations, weil die an unterschiedlichen Kriterien gemessen werden.

Operations wird an Abteilungen gemessen und Developer an neuen. Features oder Bugfixes pro Zeiteinheit, so der Dev OPs muss natürlich jetzt beide Anforderungen in einer Person unter einen Hut bringen, was aber schon dazu führt, dass man schon bei der Entwicklung der Software ein Auge auf den Betrieb hat. Was ja nicht schlecht ist. Auf jeden Fall.

Ich war bei Kubernetes, bei Kubernetes oder diesen Plustern ist Stabilität bei Design. Das das System merkt, dass dein Java Applikationen was im Container läuft gerade abgeschmiert ist und fährt dann woanders einen hoch. Oder du kannst sehr schnell auf einem Helm mit einem Befehl, ob jetzt per Kommandozeile oder automatisiert. BDKJ wie auch immer, kannst du zurückrollen auf die alte Version. Du kannst sehr schnell agieren. Was früher? Ich kann mich erinnern. Früher haben wir so Ordner unsere Dateien irgendwo in Systemebene abgelegt, dann mit dem Datum als Ordner Namen und haben dann die produktive Version per Link auf diese Ordner switchen konnten auch so zurückrollen, dass all diese Hacks, die man sich hat einfallen lassen.

Wir sind halt unter Kubernetes standardisiert.

Das war schon ziemlich cooles Vorgehen, dachte ich. Aber natürlich ist es ein bisschen hemdsärmelig in einem Profi Umfeld als weiteren Skill. Tiefgreifendes Verständnis für Anwendungs Architektur, also TCP Ports nat. Grundlegende Themen wie Zertifikate und Verschlüsselung. Das ist ja auch super wichtig. Also da stelle ich ich habe auch Linux System Administration beruflich einige Zeit gemacht. Stelle ich auch wieder fest. Bei vielen Leuten, die direkt als Entwickler eingestiegen sind oder in der Data Ecke eingestiegen sind, die wissen gar nicht so unbedingt was Sport ist oder was für eine Beschränkung bei den Ports herrscht.

Nur unter 1024 sind System Ports 2004 oder 2025 bis 50000, 535 sind dann zur freien Verfügung. Und das muss man natürlich wissen, wenn man tief in diese Infrastruktur Themen drinsteckt.

Absolut absolut. Ich meine Du hast mit sehr schnell bei solchen Umgebungen mit Security zu tun, weil Kubernetes per Default ist unsicher. Du musst viele Dinge dort absichern. Jeder kann irgendeinen Container duplizieren, der aus dem Internet gegen ein Image sie zum laufen bringt, was mit dem User gut läuft. So im Prinzip ist es das gleiche, als wenn du irgendeinem User Zugang gibst. Okay, wow. Also es ist super super gefährlich. Man muss für Security Echtzeit einplanen und dann musst du als der Mob es dann auch wissen.

Was bedeutet denn ein User ID? Wie kann ich forcieren, dass kein Container mit dem User läuft? Oder per Default ist Kubernetes so gestrickt, dass jeder Namespace, also alle Container, die in einem namens Space Case ungefähr so als Gruppe oder Kunde oder Mandant vorstellen, wo eine zusammengehörige Anzahl von Containern läuft? So per se ist das aber so stell dir vor, da gibt es ein Mensch des Maurice, nämlich des Masiar du Diploms. Was ist die Bläue, was in unseren Namespace ist?

Man kann per Default kann meine meine Container auf deine Container zugreifen.

Netzwerktechnik a per default Zugriff okay, ja genau so, du musst dann Network Policies einführen, um diese Dinge zu verhindern. Aber manchmal willst du das auch. Dass gewisse Dienste aber erreichbar sind, das du musst dich mit Netzwerk Grundlagen auskennen, also zusätzlich zu den Kubernetes, spezifischen Objekten und so weiter musst du dich natürlich auch auf Netzwerk Seite auskennen. Du musst die IP Notation, die Seite Notation Cider kennen und ja Netzwerk Primitive. Aber wie du sagtest IP Ports und Netzwerk Routing und solche Dinge.

Also wirklich tiefgreifendes Administration zu wissen haben, um dann in den Kubernetes Files eben dann die richtigen Ports oder diese diese Strecken anzulegen, die kommunizieren können. Also ich denke ja, der ein oder andere Zuhörer hat vielleicht schon mal mit einer virtuellen Maschine auf seinem eigenen Entwicklungs PC gearbeitet und auch festgestellt oh, wenn ich mit S-H von meinem Host Betriebssysteme in meine virtuelle Maschine möchte, dann muss ich einen Port öffnen und hatte damit dann Kontakt. Eben genau mit dieser Netzwerk Topologie Sachen.

Also superspannend kannst du uns denn mal. Ich denke das es auch sehr sehr interessant für Leute, die vielleicht noch nicht direkt mit Kubernetes gearbeitet haben, so ganz kurz skizzieren wie so ein Grund Kubernetes Cluster aussieht. Also welche Bestandteile hat er und was braucht man um überhaupt? Ich sage mal eine kleine Anwendung, vielleicht eine Webanwendung darin, die planen zu können.

Ja, also Kubernetes ist besteht aus mehreren Komponenten. Das eine ist der Master Node und der Worker, die zwei Hauptkomponenten.

Okay, der Masiar Master ist, wie der Name schon sagt, dafür da alles zu managen und der Worker ist da, wo eigentlich mein Workload läuft. In diesem Master gibt es da nun wiederum verschiedene Systeme, die zusammenspielen und den Master ausmachen. Das ist einmal der API Server, das ist der Server, der quasi alle Anfragen entgegennimmt per API die Fernsteuerung, die wenn du zum Beispiel auf deinem Mac oder auf deiner Windows Maschine das Cupcake, also quasi WL installiert hast Kommandozeile und dann unterhält.

Sich der mit dem Epiker. Okay, dann gibt es den sogenannten Skillbyte, der quasi dafür verantwortlich ist, die über die Balkanroute auszusuchen, wo der Container deponiert werden soll. Da gibt es wiederum verschiedene Strategien. Per Default ist es so, dass das Kubernetes versucht, alle Nodes oder den Workload über alle Worker gleichmäßig zu verteilen. Das macht es. Dann gibt es desweiteren noch die dritte Komponente. Das ist der Controller Manager. Der ist dafür verantwortlich. Die beherbergten die eigentliche Logik, wie zum Beispiel mit einem Deployment umzugehen ist wie mit einem Replikation, ActionScript, Replikation, Controller und eigene Controller, die man schreiben kann.

Und die beinhalten die eigentliche Logik, um diese API Request auszuwerten und entsprechend zu handeln. Der APIs aber selber nimmt im Prinzip das Ding nur entgegen, wie wir die Anfrage guckt, ob das schematisch und syntaktisch richtig ist und leitet es dann irgendwie weiter hinter dem Master. Also es gibt nur eine vierte Komponente, wo quasi der Status des Clusters gespeichert wird. Das ist das Etikett. Das ist eine verteilte KI Value Story und grundsätzlich ist es so, dass dieser diese Management oder Control Plan, bestehend aus diesen Episode als Guerilla Controller, John etc.

, die auch verfügbar ausgelegt sein soll. Okay, und zwar auf verschiedenen Nodes. Auf einem Node bin ich in einem nicht ausführlicheren System und mit drei Nodes bin ich in einem sicheren System, wobei hierbei Node ausfallen kann und das Cluster immer noch operabel bleibt. Es gibt immer eine ungereimt. Ich kann auch mit fünf oder sieben Maßnahmen betreiben. Das System hat immer mit einer ungeraden Zahl zu tun, um Split Brain zu vermeiden.

Ja, also das ganze basiert auf dem RAFT Protokoll. Es geht CD, weil damit der Status festgehalten und das braucht. Consensus Konsens bedeutet, dass sich eine Mehrheit an Nodes auf den Status einigen muss, damit es quasi die Wahrheit wird fürs Cluster. Und die Mathematik dahinter ist relativ einfach eine halbe +1. Dass das Anzahl der Not durch zwei +1 brauchst du, damit du noch operabel bist. Genau das sind die. Aber ohne jetzt auf diesen komplizierten Mechanismus genau einzugehen.

Das sind die Komponenten, die den Master ausmachen. Auf der Gorka Seite ist eigentlich läuft nur eine kleine Komponente. Das nennt sich Couplets und der ist für die Kommunikation mit den Massen verantwortlich und der steuert quasi dein als Beispiel deine Docker Runtime oder Container oder Time Beispiel Docker, die und sagt Hey, bitte, jetzt den und den und das und das Image hoch. Okay, es gibt noch eine zweite Komponente, um das vollständig zu haben auf dem Worker Nodes, der sogenannte Proxy, der steuert im Prinzip, wenn du später Services in Kubernetes anlegt, ist quasi dafür da, um Abstraktion auf IP Ebene einzubauen, damit du, wenn es mehrere Instanzen eines Ports laufen hast, du das verteilen kannst.

Das steuert im Prinzip IP Tables.

Okay, und jetzt um auf das Beispiel der Webanwendung zurückzukommen jetzt müsste ich ja einen Port haben, wo ich die Webanwendung hin diplomen kann, oder?

Also genau das handle. Wenn du das alles aufgesetzt hast, dann hast du lokal meinetwegen das Cupcake installiert, das Kommando Tool. Jetzt kannst du anfangen, Kubernetes Objekte anzulegen, was in ein Objekt zum Beispiel ist ein Port, ein Objekt. Du kannst also direkt sagen Hier, kreiere mir mit deinem Port. Das machst du immer über. Entweder über Jamil Dateien, die du auf Datei Ebene idealerweise natürlich git ablegst. Das ist. Das nennt man Deklaration. Sprich du hast den Zustand von dem, was du haben möchtest.

In der Datei manifestiert diese Datei Business Units und kannst jederzeit diesen Zustand wiederherstellen. Du kannst aber auch mit Cupcake direkt per Kommandozeile diese Objekte erstellen. Nur weiß keiner mehr, was du gemacht hast. Das heißt, ein Kollege, der nicht da ist, der sieht nicht was du gemacht hast und Maurice, das ist halt nicht Deklaration. Das wenn man OPs macht, sollte man immer darauf achten, dass man deklariert arbeitet. Und das bedeutet immer Dateien anlegen für Objekte und zum Beispiel nicht Cupcake Create Secrets oder so machen, sondern eher eine Datei anlegen.

Und das wäre so jetzt kann ich also einen Pfad anlegen, eine Datei und sagen Sie mir bitte das Image da und daher zum Beispiel daher, wo Jenkins vorher das Image gebaut und ihn gepusht hat. Und dann kann ich dann noch ein paar Konfiguration mitgeben, wie zum Beispiel Umgebungsvariablen oder Passwörter oder sonstiges, was ich brauche. Und dieses Epi Objekt erstelle ich dann zum Beispiel mit Kupka, Creed oder Minus F und dann den Dateinamen. Und dann fängt der Server an, das das auszuwerten und die entsprechenden Befehle loszutreten, damit dann am Ende doch kein Limit auf dem Worker, den der Skillbyte ausgesucht hat, sich das Animate sieht und zum Laufen bringt.

So alles was du dazu brauchst, wie zum Beispiel. Du sagst im Portal, du läufst bitte auf Port 88 oder whatever. Alles was dazu notwendig ist, damit der Port hinterher auch erreichbar ist, macht das Kubernetes System für dich. Wie ich am Anfang sagte, er fängt an mit PTBS Regeln anzulegen. Der fängt an, je nachdem wie du dein Ding deinen Port konfiguriert hast. Gewisse Sachen am Linux System zu drehen, wie z.B. der Port braucht viel Gigabyte, dann Kubernetes dafür über sie groups.

Das auf dem Berg kann diese vier Gigawatt, die auch zur Verfügung stehen. Und solltest du ein Nod haben, was keine 4 Gigabyte Platz hat, dann sorgt das Geld dafür, dass ein Port auf eine Maschine landet, was soviel RAM hat.

Der verteilt also die Workload dahin, wo auch die Ressourcen sind, genau um die vor konfigurierten Ressourcen bereitzustellen.

Du kannst also der Skillbyte ist eine Wissenschaft für sich. Du kannst zum Beispiel sagen Hey, ich habe zwei Maschinen in meinem Cluster, die haben die POS und die brauche ich um um englische Rechenleistung um um Machine Learning Modelle zu berechnen. Dann kannst du auch die Ports dazu bringen und uns dazu bringen, diese diese Berechnung Ports auch genau auf die Maschinen zu verteilen. Auf keine anderen oder über Datacenter Grenzen. Und wenn du in einem Du kannst auch Cluster haben, was sich über mehrere Data Center spannt, kannst du zum Beispiel einen Pott näher an deine Kunden platzieren.

Hmm, okay, das ist ja jetzt ganz interessant. Würdest du denn sagen, dass diese Kubernetes Umgebungen eher ohne Prämisse aufgesetzt werden, weil du ja dadurch eine große Effizienzsteigerung in deinem vorhandenen Rechenzentrum als Unternehmen hast? Oder dass man damit eher in der Cloud hantiert, dass man sagt Okay, Cloud Technologie ist sowieso ein Thema, mit dem wir uns beschäftigen wollen. Dann starten wir diese Kubernetes Project oder diesen Kubernetes Cluster direkt in der Cloud Umgebung.

Du sowohl als auch. Also es gibt viele Kunden, die das schon haben und auch haben wollen, weil sie in der Cloud nicht vertrauen oder weil sie gewisse Daten haben oder Policies, die keine Cloud. Es gibt aber auch Unternehmen, die sagen Cloud first, wo eigentlich Rechenzentrum gekündigt werden und sagen so wie geht es mit allem in die Cloud? Es gibt auch Hybrid Lösungen, weil dem Kubernetes Cluster ist es völlig Wurst wo deine Workarounds laufen, ob das jetzt in einem Data Center in einem Keller ist oder oder.

Halt in der Cloud Worker, da ein Worker da platzieren und die Kommunikation dieser einzelnen Container, die einen auf den Blockchain laufen, die kommunizieren über sogenannte Overlay Netzwerken. Das heißt Kubernetes bringen eigenes Networking mit, was sich über der Bea ihr legt. Und da gibt's wiederum viele verschiedene Installationen oder sogenannte Netzwerke Plugins, die das unterschiedlich handeln händeln. Zum Beispiel Calico. Also das ganze ist über ein Interface gesteuert, das Container Network Interface. Das ist standardisiert und es gibt verschiedene Firmen, die dieses dieses Interface implementieren.

Und jeder kann unterschiedlich mit dem Networking umgehen. Wie zum Beispiel hat ein Plugin, was den Datenverkehr asymmetrisch verschlüsselt, automatisch dann Calico arbeitet über PGP und kann Netzwerk Policies unterstützen. Standardmäßig kommt das ganze mit Flanell, was eigentlich die vollgültig ganz gut ist, aber eben keine Network Policies unterstützt. Also es gibt irgendwie 15 verschiedene Network Plugins und jeder hat irgendwie sein Für und Wider. Das ist auch das gehört dazu, dass man solche Dinge kennt und weiß, wann man welches einsetzt.

Aber worauf ich hinaus wollte alle haben die Gemeinsamkeit, dass die quasi IP Message Reading alles an IP Tables vornehmen, um über Netzwerk Grenzen hinweg miteinander kommunizieren zu können. Das ist ja super charmant, wenn du du hast deine Prämisse Anwendungen und du hast jetzt eine Last Spitze und kannst halt dann die Webserver oder die Webserver Ports in der Cloud mit dazunehmen und du könntest, wenn du jetzt ein Landspitze hast. Na also ich denke zum Beispiel an eine Versicherung. Bei der Autoversicherung ist glaube ich Kündigung immer der letzte Tag im September oder so was.

Und da werden natürlich tendenziell viele Leute die Versicherung wechseln und es ist wichtig, dass man als Versicherungsunternehmen dann verfügbar ist, um eben möglichst viele Neukunden gewinnen zu können. Oder auch ich kann es ja auch so machen, dass ich Ich habe meine Webserver in meinem Land, aber habe dann auch in den verschiedenen Rechenzentren um den Globus eigene Webserver, um die Kunden aus den jeweiligen Ländern direkt schnell bedienen zu können. Habe aber meine Haupt Infrastruktur bei mir zu Hause im Unternehmens Rechenzentrum oder so!

Ja immer spannend. Spannend wird es natürlich. Sage mal so, wenn du, solange du genug Maschinen irgendwo stehen hast, ist es ja schön und gut. Das heißt, du kannst ja einfach mit als Node ins Cluster hängen und das System fährt automatisch mehrere Ports hoch. So interessant wird es aber, wenn du nicht genug Maschinen hast und hast dir zum Beispiel eine Werbung geschaltet, die Marketingaktion gestartet, wo auf einmal am nächsten Tag die Kunde die Bude einrennen. So, und da gibt es wiederum Mechanismen, Autos, Geiling, wo das System merkt Hey, da ist was.

Ich bekommen die Last nicht mehr hin. Es sind Schwellwert, die man eintragen kann und wenn du in der Cloud Umgebung bist, dann das nennt sich horizontal Postauto Skala. Das heißt das System geht dann Boot und dann eine neue Not. Also bei Abwesenheit die 2. Instanz und hängt das mit ins Cluster. Das hast du innerhalb von ein paar Minuten neu dem Cluster, der dann auf einmal die Last aufnehmen kann und nicht die Last. Wechselt sie einen gewissen Schwellwert, dann baut sich das Ding wieder ab.

Es ist fantastisch, dem zuzugucken.

Dann nicht mehr gerade Begeisterung, das heißt es quasi so ein elastisches Gummiband in die Cloud hinaus. Wenn dein eigenes Rechenzentrum zu klein ist und du fängst diese Last Spitze erst mal ab und kannst sie dann in Ruhe überlegen. Okay, es kommen noch ein paar Marketingaktionen. Ich möchte meinen Cluster aufrüsten oder okay, ich skalieren einfach immer über die Cloud, also je nachdem, was dann mehr Sinn macht für das jeweilige Unternehmen. Aber man merkt schon, jetzt haben wir, ob es ein Stück weit verlassen oder uns auf eine die die Spezial Technologie Kubernetes gestürzt, wo du ja extrem viel Expertise hast.

Man sollte, wenn man so ein Projekt angeht, entweder frisch aufsetzt oder weiterentwickelt. Du hast eben von 15 verschiedenen Plug in Anbietern im Netzwerk Bereich gesprochen. Da macht das extrem viel Sinn mit jemandem zu sprechen, der sich damit auskennt oder der da Expertise hat wie wie mit dir oder mit der Dev OPs Säule von Skillbyte, damit man halt Fehlentscheidungen vermeidet bzw. viel rumprobieren abkürzen kann.

Tatsächlich fragen Kunden auch oft nachher, welche Skills brauchen wie den führt der? Also genau das, worüber wir gesprochen haben. Und wie kann man diesen Mainz überhaupt etablieren? Bei uns im Unternehmen also auch so mehr von der organisatorischen Seite Narayen, wie zum Beispiel einen Plan zu machen. Welche Skills brauchen wir, ein Assessment zu machen? Welche Skills sind da und wie muss man wen weiterbilden, damit man in diese Richtung kommt?

Ja, das ist natürlich jetzt auch. Also da gibt es ein paar Generika, die haben wir eben angesprochen. Aber es kommt da natürlich darauf an, auf diese Special Plugins oder die Spezial Use Case ist jedes Unternehmen dann letztlich im eigenen Kubernetes Cluster abdecken möchte.

Und oft ist auch vielleicht nicht Kubernetes selber direkt die Wahl. Also wenn ich zum Beispiel wenig Ressourcen ab, weil Kubernetes ist halt nicht trivial. Ich sage mal aus dem Netz nur drei Befehle aus dem Tutorial lesen installieren. Schön und gut, aber was danach kommt Backup Recovery Konzept Disaster Recovery Security alles Riesenthema Themen Monitoring Es gibt zum Beispiel Ranger was was? Ich sage mal das Aufsetzen, das Betreiben etwas vereinfacht, bringt seine eigenen Geschichten mit, die man wie man wissen muss.

Es gibt das eine riesige Tool Landschaft und da erst mal durch den Dschungel zu blicken, was macht für mich Sinn? Da kann ich nur empfehlen, man soll sich einen Berater holen, der einem wenigstens für ein, zwei Tage so ein bisschen den Dschungel lichtet und sagt Das ist ein Weg, den könnt ihr gehen. Und dann kann der Kunde dann selber den Weg gehen. Aber gerade am Anfang kann man halt viele Fehler machen.

Und ist es so aus deiner bisherigen Erfahrung heraus, dass Kunden EDV einsetzen, um den eigenen Service der System Administration oder der der IT-Abteilung zu verbessern? Also dass man schnellere Releases fahren kann, dass man robusten robust das System hat? Oder stehen Kosteneinsparungen bei der IT-Infrastruktur da im Vordergrund? Also man kann ja auch sagen, wenn ich 100 STANDARD Server habe, die jetzt alle Workload abfangen können, ist das billiger, weil das ist immer der gleiche Dell Server anstelle wenn ich hier einen ganzen Zoo von über 15 Jahre gewachsenen System Betrieb weiter betreue.

Also der Hauptgrund die Hauptmotivation ist Geschwindigkeit Entwicklungsgeschwindigkeit meinst du Entwicklungsniveau und nicht nur Entwicklern? Wie schnell die Entwickler entwickeln ist immer eine Sache, aber bis der Code in Produktion wandert bis Releases ausgerollt werden, weil guck mal, der Markt ist heutzutage extrem schnelllebig. Wenn du in releasen Jahr lang brauchst, dann bist du fast weg vom Fenster. Du musst schnell reagieren können. Du musst Dinge ausprobieren können, um aus dem, was du probiert hast, Erkenntnisse zu gewinnen, sagen immer, das ist gut oder schlecht, um dich dann kontinuierlich zu verbessern.

Und das kannst du nur, wenn dein Release Prozess automatisiert ist und nicht wenn du Codein Checks alles zusammenbricht und kein Entwickler sich traut einzuchecken und wochenlang sein Commit zurückhält und monolithische Software Applikation. Also wo ist Big Bang Releases, wo du drei Kreuze machst oder die Finger gekreuzt? Es ist alles gut geht? Nein, das muss kontinuierlich gehen. Und erst wenn du diese Kontinuität reingebracht, das kriegst du Geschwindigkeit und Automatisierung rein verstehe. Also darum geht es, dass man diese Iteration Zyklen von Software möglichst verkürzt, um schneller reagieren zu können und Feature to market sozusagen.

Oder vom Plan von der Tafel bis hin in die Welt hinaus die Zeit mit. Kurz zu halten. Das verstehe ich. Und vielleicht hast du noch mal zusammen, wo skillbyte, als ob es Experten besonders viel Wert schaffen können. Also in welchen Fällen können wir Kunden helfen?

Das ist echt unterschiedlich. Ich habe jetzt einen Kunden, wo ich denen helfe überhaupt in diese Welt einzutauchen. Also wirklich was im Container. Was ist diese Technologie, was im Microservices? Was ist Kubernetes? Welche Vorteile hat das? Und begleite den Kunden quasi auf dieser Reise zu diesem Stadium auf der grünen Wiese kannst du also beginnen, wenn man so schön.

Genau, genau, genau das ist sehr abwechslungsreich. Das ist teilweise halt Beratung, teilweise how Konzept bis hin zur Auswahl von Ressourcen oder Empfehlungen, wie es dann weitergeht. Der andere Part ist, wenn halt auch oft dazu geholt werden, ist die Krise, die Kette nicht richtig funktioniert sehr langsam ist, Fehler trächtig ist, man diese Iteration nicht wirklich verkürzt kriegt. Und da gucken wir zum Beispiel Prozesse an, was läuft schief? So ist das. Technisch ist das organisatorisch bis hin zu wirklich komplett Cluster Aufbau Open Shift Kubernetes, wo der Kunde schon mal diese Vorteile kennt und weiß und einfach jetzt Unterstützung braucht.

Sagt Ich brauche jemanden, der mir das Cluster mal entweder aufsetzt, auf Vordermann bringt oder auch wirklich nur Komponenten daraus. Ja, ich möchte meine Klasse gesichert haben. Welche Komponenten gibt es? Da kommen dann wiederum das Thema, zum Beispiel Df6 OPs ins Spiel, wo du versuchst, Security so weit wie möglich nach vorne zu verlagern. Üblicherweise geht man hin, macht Penetration Testing. Da die Applikation Exploit kauft sich eine Hacker Bude unser Partner von außen drauf. Bei Df6 geht es darum, dass man diese Analyse, diese Security Check so weit wie möglich nach vorne verlagert.

Schon beim Bauen des Codes, wie zum Beispiel durch staatliche Code Analyse und und und was es da alles für Tools gibt, also auch danach werden wir gefragt. Also für einzelne Bereiche, Komponenten, Monitoring Security, was für einen bestehenden Cluster verbessern oder neu aufsetzen.

Okay, also sehr viel, sehr divers, sehr diverse Anfragen und unterschiedliche Anforderungen. Was natürlich auch daran liegt, dass es noch ein relativ junges Feld in der IT und ein stark Bewegungen unterworfen ist. Feld in der IT is ja cool. Also wir haben gelernt was ist ein DVP Engineer oder noch mal ein kurzes Recep gemacht. Wir hatten ja schon mal eine Podcast Episode dazu. Die verlinke ich auch zu diesem Podcast. Dass interessierte Hörer sich die auch noch anhören können, haben gelernt, welche Skills ein Engineer mitbringen muss, um welche Technologien eingesetzt werden.

Eine ganze ganze Menge, wie ein Kubernetes Cluster aussieht und was für aktuelle Problemstellungen Kunden große Konzerne oft damit haben. Ich denke das ist eine ganze Menge und ich möchte mich an dieser Stelle ganz herzlich bei dir bedanken. Masiar für den ganzen Input sehr gerne. Und wenn die Zuhörer Fragen haben, können Sie gerne eine E-Mail an Podcast Skillbyte senden. Und wenn die Podcast Episode gefallen hat, freuen wir uns natürlich auch immer über eine gute Bewertung und der Podcast kann auch abonniert werden bzw.

auf Skillbyte Blog erscheinen. Weitere Artikel zum Thema, die von Interesse sind Masiar Möchtest du noch etwas sagen, um das abzuschließen? Ja, und zwar ich möchte nochmal darauf hinweisen. Ich bin gerade dabei Webinar Reihe zu machen. Zu dem Thema Kubernetes einmal eine Einführung, was so ein bisschen mehr auf der Managementebene ist. Das Kubernetes ist, welche Vorteile es bringt und dann wird es spezialisierte Webinare geben zu einzelnen Themen wie Security Monitoring und ja, die Zeit ist öfters mal auf die skillbyte Seite schauen, da werde ich sie bekannt geben.

Okay, das heißt ein Management Overview Webinar und ein oder schon eher technische Seminare.

Dann genau danach, dann zweiten und dritten Teil. Ja, exakt. Okay, perfekt. Da ist ja für jeden was dabei. Ja, alles klar.

Vielen Dank Masiar. Danke dir Maurice gerne.

Danke! Schönen Abend auch. Tschüss.