Infrastructure as Code

Skillbyte Podcast #45: Das Spring Boot Framework

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

In diesem Podcast geht es um das Thema: Das Spring Boot Framework

// Inhalt //
02:35 – Was ist Spring Boot?
03:26 – Erfahrungsbericht: Spring Boot Anwendungsentwicklung
14:43 – Spring Boot Paradigma: Convention over Configuration
15:16 – Lohnt sich der Einsatz von Spring Boot? Lernkurve?
16:39 – Ein kleiner Vergleich mit der Pyhton Welt
18:16 – Features von Spring Boot
22:31 – Spring initilizr auf start.spring.io
23:45 – Spring Support von IntelliJ IDEA
26:41 – Spring Boot Banner
27:44 – Dokumentation der Spring Boot Anwendung
29:00 – Fallstricke & Tipps
33:02 – Fazit: Ist Spring Boot empfehlenswert?

Show Notes:

Podcast #29: Die Zwölf Faktoren des Cloud Native Development (Teil 1)
-> https://soundcloud.com/skillbyte/podcast-29-die-zwolf-faktoren-des-cloud-native-development-teil-1

Podcast #30: Die Zwölf Faktoren des Cloud Native Development (Teil 2)
-> https://soundcloud.com/skillbyte/podcast-30-die-zwolf-faktoren-des-cloud-native-development-teil-2

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Ich denke auch, dass sich das als Blaupause und Grundlage für die voll regelrecht für Java Anwendungsentwicklung nehmen würde, weil die meisten Anforderungen aus Umgebungen kommen, wo man das eben gut umsetzen kann. Ich meine missis in den letzten Jahren nichts untergekommen, wo man jetzt auf einen klassischen ein Maschienen Server oder einen großen Mainframe irgendwas hätte entwickeln müssen, sondern man kommt eben immer eigentlich gerade wenn es Java sein soll in diese Microservices Richtung bzw. kann seine Anwendung zum Lösen eines Problems so designen, dass sie auch sinnvoll so umzusetzen ist.

Und dann ist Spring Boot wirklich ein Top Tool.

Herzlich willkommen zu unserer Skill bei Podcast Episode Nummer fünfundvierzig Das Spring Boot Framework abonniert unseren Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn ihr die Entscheider oder die Fachkraft seid, wenn ihr eine höhrer Frage habt im Verlauf der Episode sendet uns gerne eine E-Mail an Podcast Skill Bild.de:. Wir freuen uns immer über Bewertungen und weitere Empfehlungen dieses Podcasts an eure Freunde und Kollegen, die sich ebenfalls für diese Themen interessieren.

Wenn ihr aktuell in der IT-Branche auf Jobsuche seid, schaut auch auf Skill weite Isles Jobs vorbei. Ich bin heute hier mit den beiden Skill BYD Data Ingenieurs Oliver und Andreas.

Hallo ihr zwei Callboys. Schön wieder dabei zu sein. Hallo Moritz Fela, endlich mal dabei zu sein.

Oli kennen ja schon einige Zuhörer, Andreas. Für dich ist es heute ein Novum. Aber ich freue mich wirklich, euch beide dabei zu haben, weil ihr euch sehr intensiv jetzt in dem letzten halben Jahr bzw. kann man so sagen die zweite Jahreshälfte 2000 und 20 mit dem Spring Boot Framework beschäftigt habt und auch eine recht komplexe Anwendung darauf entwickelt hat.

Genau. Wir haben als Projekt. Ich glaube, so ab August letzten Jahres bis Ende des Kalenderjahres genau haben wir eine Spring gut basierte Anwendung für den Kunden gebaut, was für uns ein völlig neuer Text steckt. Zu dem Zeitpunkt war uns aber die Möglichkeit gegeben hat, da sehr, sehr schnell production ready zu werden und eine Anwendung zu haben, mit der wir sehr schnell weiterentwickeln und testen können. Das war eine ziemlich coole Sache. Da kann Andreas aber auch noch was zu sagen, weil auch für den war das glaube ich ein neuer Einstieg.

Ja, genau. Also für mich war das eigentlich alles Komplettem, weil sowohl Java als auch Bimbos und bin tatsächlich erstaunlich schnell reingegangen. Das hat mich auch ein bisschen überrascht. Sobald man sich einmal an die Annotationen gewöhnt hat, ist man eigentlich sofort dran.

Genau das ist ja auch das Kernziel des Spring Boot Frameworks. Vielleicht kennt der ein oder andere Zuhörer ist noch nicht so oder kann auch nicht genau was damit anfangen. Deshalb würde ich kurz sagen, dass es sich um einen Quell offenes Framework für die Java Plattform handelt, welches meist genutzt wird, um eben Webanwendung zu implementieren, Microservices zu implementieren. Und das Ziel dieses Frameworks ist es eben möglichst schnell komplett Laufwege Anwendung erzeugen zu können, weil die default Einstellung der Konfiguration im Grunde sinnvoll sind.

Das ist der Anspruch, den dieses Projekt hat. Und wie das so ist z.B. beim Schachner im Menace to learn alive to Master, so ist das auch ein bisschen bei Spring Boot gestartet ist man sehr schnell, kann dann aber die Anwendung nach und nach um weitere Komponenten erweitern und eine sehr komplexe Anwendung bauen, was er ja auch gemacht hat.

Auf die genauen Inhalte müssen wir ja jetzt gar nicht eingehen, aber die Anwendung sollte als System von mehreren kleinen Microservices ineinander greifen. Wir brauchten unter anderem einen einfach zu nutzen. Das Web frommt und wir brauchten den eigentlichen Controller dahinter. Wir brauchten eine Datenbank Anbindung. Wir mussten die Möglichkeit haben, Daten im lokalen Dateisystem zu paar sistieren und und und. Das waren viele einzelne Komponenten, die wir dann entsprechend damit strukturieren konnten. Und das hat dem Ganzen wirklich einen hervorragenden Rahmen gegeben, wo man dann die Arbeit auch de facto gut aufteilen konnte, um eben das Ganze schön gekapselt zu haben.

Das hatte auch ganz viele Aspekte von der Pull-Faktor App, über die wir ja schon mal zusammen gesprochen haben, wie wir das dann Gebaute nachher auch die PEUT haben.

Andreas War das für dich? Hattest du das Gefühl, dass man es gut aufteilen kann und dass du dann so einzelne Häppchen abarbeiten konntest?

Ja, das ging eigentlich Duterte als ich zu dem Projekt dazugekommenen, was aber nur zwei Wochen war, nachdem Oliver auch damit angefangen hat, war quasi schon ein bisschen ein Grundgerüst da und werden dann aber recht schnell gemerkt. Wir brauchen jetzt noch zusätzliche Rest API Endpunkte von quasi zusätzliche Microservices. Und da hat es mich überrascht, wie einfach es war, da dann zusätzliche Sachen zu schreiben. Dann hat man einfach einen zusätzlichen Controller hochgefahren und dem Endpunkte gegeben und die konnten unabhängig voneinander dann bearbeiten.

Das hat einfach sofort funktioniert.

Das Gute ist halt bei dem Spring Framework und Spring Boot ist ja letztlich nur eine Geschmacksrichtung des großen vollumfänglichen Spring Frameworks, dass man diese Inversion of Control eben nutzen kann. Also Andreas hat es eben schon angesprochen per Annotation. Also Edin Denkakt oder Auto wiederholt sich dann die einzelnen Komponenten in die Klasse durch den Container oder durch das Framework Injektor lassen kann. Das deutsche Wort wäre glaub ich verdrahten lassen kann und dann eben diese Komponente vollumfänglich zu nutzen. Habt ihr das so Komponenten Weise aufgeteilt?

Die Arbeit oder jeder hat so ein bisschen Überblick über den gesamten Code gehabt.

Das werden glaub ich beide einen ganz guten Überblick über alles. Aber gut, wenn man zu zweit arbeitet, dann teilt man sich schon ein bisschen die Arbeit auf und Alianza ein bisschen mehr Erfahrung mit Docker Containern schon an denen, die. Deswegen hat er sich da mehr darum gekümmert und ein bisschen mehr um die Rest API selber, dann würde ich auch genau so unterschreiben und es war wirklich praktisch, dass man die ganzen Dependency es, die man ansonsten berücksichtigen müsste, dass man diese ganzen Weg gekapselt module dann sich einfach über dieses Auto via O-Ring direkter reinholen kann.

Da kann man vielleicht später nochmal kurz drüber sprechen, aber so angeteasert. Das hat es für uns dann eben auch super gemacht, das ganze mit Unit Test Abdeckung nachher zu versehen. Also diese modularer Bauweise, die hat uns da das Leben in vielerlei Hinsicht vereinfacht.

D. h. ihr habt dann wirklich Komponente für Komponente g Unit testet im Rahmen der Zeit, die wir zur Verfügung hatten.

Ja, also die war von Anfang an begrenzt. Das waren die letzten paar Wochen im Projekt Scope. Und wir haben mit den Kern Komponenten, die für den Betrieb nötig waren, entsprechend angefangen und haben entsprechend dann doch noch ein sehr akzeptables Level an Test Abdeckung für die ganze Applikation geschafft. Am Ende ja. Und das haben wir genauso gemacht.

Er war auch ein bisschen überrascht, dass wir dann doch noch so eine hohe Testa Abdeckung hingekriegt haben, weil dadurch das ganze zeitlich limitiert war. Haben wir jetzt nicht Testpiloten Development von Anfang an gemacht, da vor allem auch vieles zum Anfang noch nicht klar war, wie es am Ende aussehen würde, aber zumindest Järvi alle gesagt hat. Die Kernidee Teile der App und mit der nachträglich ziemlich einfach noch mit Tests versehen.

Das heißt, die Anwendung wurde zuerst entwickelt. Ich glaube, das kann man sagen. Es handelte sich um eine Brücke, einen Exporteur und einen Importeur von zwei verschiedenen Systemen, der einfach Daten transformiert hat zwischen diesen Systemen. So, und da waren wahrscheinlich die Schnittstellen nicht ganz klar und es hat sich erst im Verlaufe des Projektes herausgestellt und dann am Ende, als die Schnittstellen klar waren und die schon bespielt werden konnten. Habt ihr das dann nochmal getestet? Richtig. Also das Ganze war, wenn man es drastisch formuliert, wirklich als One-Shot Anwendung konzipiert.

Man hätte das natürlich dadurch, dass sowohl das Quelle als auch das Zielsystem weitverbreitet sind in der Branche, in der der aktuelle Kunde da unterwegs ist. Aber die Systeme waren jeweils so spezifiziert und an die Bedürfnisse des Kunden angepasst, dass es viel mehr Aufwand gewesen wäre, das deutlich generischer zu machen, um es als Produkt dann auszuarbeiten, sodass wir da wirklich eine maßgeschneiderte, schnell entwickelte Lösung gebaut haben.

K Perfekt. Jetzt habt ihr diese Anwendung gebaut. Wenn ich das richtig verstanden habe, Oliver, du hast dich so ein bisschen um die Pakete gekümmert. Docker Den Betrieb oder die DevOps Komponente. Andreas Du hast vielleicht etwas mehr an der Anwendungs Logik gearbeitet. Hattet ihr das Gefühl, dass euch springender Gut unterstützt, also dass ihr euch wirklich auf eure Kernthemen konzentrieren könnt Infrastruktur oder Anwendungs Logik? Oder hattet ihr oft das Gefühl oh ich schreib hier Boiler Pleite Code um die x te Datenbank Verbindung aufzumachen oder sowas?

Das muss doch einfacher gehen.

Er sei ein bisschen hatte ich schon den Eindruck, dass man ein bisschen Boiler Plaid Code schreibt. Gleichzeitig hatte ich aber auch den Eindruck, dass es weniger ist als meine Java sonst machen müsste. Da ich wohl noch nicht so Java Erfahrung hatte, war mir bewusst, dass ich da mehr bei der Palette Code schreiben muss, als z.B. ein Payton war. Das hat sich dadurch ein bisschen in Grenzen gehalten.

Hast du ein Beispiel für Boiler Plaid er gut alle Geta an CETA hat man einen Partner z.B. einfach nicht. In Ada kann man vieles umgehen in der Stelle.

Für mich hats massiv Code gespart. Du hast das Stichwort Datenbank Anbindung gerade genannt. Da ist durch JPY zu den technischen Feinheiten kannst du vielleicht gleich noch kurz etwas sagen ist uns extrem viel Arbeit abgenommen worden. Also da bringt Spring Boot von Hause aus die Möglichkeit mit, das sehr elegant zu nutzen, in dem nicht nur einfach die Gredenko sieals und die Konnektivität Informationen zu einer Datenbank übergeben werden, sondern man hat auch über vordefinierte Funktionen hat man die Möglichkeit, die Tabellen selber direkt anzulegen.

Also die Schemata. Das wird alles von Springflut über sehr viele einzelne Komponenten ermöglicht, ohne viel Aufwand an der Datenbank selber betreiben zu müssen. Das ist wirklich schön gemacht.

Ja, das stimmt. Also ein sehr komplexes Datenbank Schema, wie wir dann letztendlich doch eigentlich hatten, halte ich glaube ich hier. Wenn ich die hätte selber schreiben müssen ich in der Zeit hinbekommen. Auf jeden Fall.

Vor allem wenn man noch die SQL Schnittstelle selber in irgendeiner Form hätte bauen oder mit kleine SQL Code hätte bedienen müssen. Und da nimmt einem JPC dann eben schon extrem viel Arbeit ab. Und das hat dann auch def abseitig viel gespart, weil man einfach die Datenbank zur Verfügung gestellt hat, die Konfiguration in JPL mit ein paar Zeilen schnell gemacht hat und dann lief das. Das muss man einfach dazusagen. Das war wirklich einfach die JPL. Hier steht ja für die java persistent api die eben genau.

Für. Daten bank. anbindungen. Da ist. Oder persistenz. Schicht anbindungen da ist. Und das schöne hier ist. Dass man im grunde. Das es gerade gesagt. Diese tabellen relationen. Oder das datenbank schema. Das kann man einmal anlegen. Und jpl kümmert sich dann darum. Je nach dem ob du eine postgresql datenbank hast. Maisie. Soldaten. Bank. Oracle. Datenbank. Den. Richtigen exkl. Dialekt nenne ich es mal zu generieren, so dass das konkrete Backend dann eben unterstützt wird.

Und das macht natürlich auf Migration sehr einfacher. Der eine Kunde setzt die Datenbank Technologie ein, der andere Kunde setzt die Datenbank Technologie ein. Da möchte man kein Wenn du Login haben, sondern die JPL benutzt, läuft es überall oder auf allen Datenbank Plattform, die eben JPY Unterstützung erfahren, was die meisten sein dürfen.

Ja, das Thema Parketts hierum hast du eben angesprochen. Hass hat für mich auch nochmal leicht gemacht. Das war dann die Zusammenarbeit von Spring bzw. Spring gut und eben Maven als Paket Manager dies mir extrem leicht gemacht hat. Die Anwendung dann einfacher dem Docker Container zu betreiben, also sowohl schon für Entwicklungs Zwecke wirklich jeder auf seinem Entwickler Laptop was auch praktisch war war. In Docker waren wir dann eben auch völlig unabhängig davon, weil ich habe es offene Meek gemacht Andreas glaube ich auf einem Linux System.

Das lief dann alles sofort und auch der Roll outs beim Kunden war dadurch viel einfacher, weil der Ebene Container Umgebung zur Verfügung gestellt hat und wir dann nur noch da rein diplomen mussten und dann eben mit dessen, der vom Team geklärt wurde, wie dann der Betrieb abläuft. Aber dadurch, dass wir eben die Pakete hierum über Maven und Spring buht dann eben hatten und das ganze schon im Docker Container betriebsbereit zur Verfügung stellen konnten. Sehr einfach war das ein Kinderspiel und schnell gemacht.

Das war echt toll. Da habt ihr direkt eine Stärke von Spring Boot voll ausgespielt in Kombination mit Docker, weil ich sag euch das früher war das nicht so, dass man eine Java Anwendung direkt ausführen konnte oder es war ganz ungewöhnlich, sondern es gab einen sogenannten Application Server an Tomcat aus dem freien Bereich oder auch verschiedene proprietäre Produkte. Von RedHat hieß es z.B. J. Bors und das war ein sehr schwergewichtige Server, die also teilweise mehrere Minuten benötigt haben um zu starten.

Und da wurde dann die Anwendung alzu war fail oder eher fail wurde die Anwendung rein die bloed und rein geladen und die wurde dann auf diesem Server ausgeführt. Das ist natürlich heute in der kybernetisch Umgebung Microservices Umgebung ist das überhaupt nicht praktikabel, dass man da einen Server hat, der sehr viele Ressourcen braucht und der mehrere Minuten zum Starten braucht, sondern da möchte man eine kleine ausführbare Code Einheit haben, die ihre dedizierte Aufgabe übernimmt. Und da bietet sich natürlich das selbst laufende Spring Boot Programm an oder die selbst laufende Applikation ist es ja ein derFall was man direkt starten kann.

Wir haben in dem Zusammenhang genau das bekommen, nämlich ein Zerfall, was schon alle Dependency es enthielt. Man musste da keine Libraries mehr installieren und gar nichts. Man konnte mit einem minimalistischen Docker Image anfangen. Es musste nur Java installiert sein. Dann hat man das ja ausgeführt. Wenn man wollte noch ein paar Laufzeit Parameter mitgegeben und dann lief die Anwendung und die ethical schon eben diese Webserver Komponente. Zum Beispiel wenn ich mich erinnere an meiner Anfangszeit in dem Projekt, wo ich noch nicht so vertraut war.

Damit hab ich noch einen extra Docker Container hochgefahren, wo ich in Engine X Webserver drin betrieben habe, damit ich diese Rest API überhaupt irgendwie ansprechen konnte. Und irgendwann haben wir dann verstanden, dass Springflut das schon von Hause aus mitbringt. Aber da hat Andreas viel mehr mitarbeitet als ich.

Ja, da kam dann aber nochmal die zweite Erkenntnis. Also erstmal wie obligat gesagt hat, des Rest Framework selber. Aber man habe dann festgestellt, dass es ja wirklich war, seinen kompletten Webserver der auf Heilberufe mitliefert. Wir hatten dann nämlich doch nochmal eine Endings dazu, die Plots, um einfach statisch ein paar Fails für das Frontend können und das fand ein selber und dann feststellte Wir können das einfach direkt staatlich mit einbinden. Wir nennen einfach einen Ordner Public und dann passiert alles automatisch.

Das war dann nochmal so ein Aha-Erlebnis.

Das ist diese Opinio Nahtod Konfiguration. Also bring but leg dir schon so die Fold Ordner an oder bzw. die kannst du anlegen, wo dann Settings drin liegen können für die Anwendung oder eben statische HTML Falz, wo man sich dann nicht weiter kümmern muss, wenn man sich an diese die Fold Konfiguration hält. Man kann auch alles konfigurieren, aber das Ziel von Spring Boot ist es zu sagen Hammer, wir geben dir einen vernünftigen Grundstock auf dem kannst du aufsetzen und du kannst alles konfigurieren.

Aber so wie wir es dir liefern, ist es erst einmal in Ordnung für die meisten Anwendungen. Also könnt ihr bestätigen Spring Boot hat euch fÃr eure Entwicklung doch ordentlich unter die Arme gegriffen. Ihr seid schnell zu Rande gekommen, habt wenig kämpfen müssen. Leute, die um die Millennium Wende Java entwickelt haben, die kennen noch, wie schwerfällig das alles war. Habt euch gut in der STANDARD Konfiguration zurecht gefunden und wenn ihr Zusatz Komponenten eingebaut habt. Ich weiß jetzt nicht ob ihr den Spring Logger benutzt habt oder wahrscheinlich die Spring Datenbank Anbindung und so, dann war das wahrscheinlich mit 20.

Mal googeln. Bildung ist natürlich hier die Website, die sofort auf ploppt, war das relativ schnell eingebunden. Ja, würde ich genau so unterschreiben. Es war zunächst mal intuitiv ziemlich viel verständlich, muss ich sagen. Nun muss ich dazu gestehen, dass ich zumindest Java schon mal vorher gemacht hatte und auch Maven vorher schon mal gesehen hatte. Das hat mir die Grundlage ein bisschen bereitet, aber nachdem ich dann in die einzelnen Sachen besser reingekommen war, lief das sehr schnell.

Die Lernkurve war sehr steil und auch einfachste Internet-Recherche. Meistens kann man eben bei Bildung raus, hat da schon geholfen, weils eben auch so viel genutzt wird und so viele Leute sich damit beschäftigen und damit arbeiten.

Für mich war da die Lernkurve noch ein bisschen Tayler, weil ich hatte tatsächlich vorher noch keine einzige Zeile Java Code geschrieben. Aber selbst damit war das ohne Probleme machen. Also mit den Web Ressourcen kann man dann schnell zu Rande Andreas. Gibt es denn in der Python Welt ein mit Spring Boot vergleichbares Framework? Also was ähnliche Features anbietet oder was die vielleicht immer wieder aufgefallen ist, dass du gedacht hast oh stimmt, das ist so wie bei Falcon oder so.. Also mir geht es ganz häufig so Wenn ich mich in einer Welt relativ gut auskenne und dann mich in neue Themen einarbeitet, dann stelle ich fest Ah, okay.

Die NPD ist eine neue Form von Maven oder Gretl oder dass man quasi diese queer Referenzen herstellen kann.

Ich würde sagen, es gibt nicht so ein monolithischer Ding, was es alles kann. Ein bisschen. Also es gibt gute Respawn Frameworks, dem Rass ähnlich komfortabel auch eine Rest API aufziehen kann. Aber dann muss man halt nochmal einen Webserver dazu machen, was man zwar auch leicht geht, aber es halt erst ein anderes Projekt. Dependency Injection ist nochmal komplett anders. Man braucht es einmal in Payton nicht ganz so viel, da man in der Laufzeit natürlich viel austauschen kann.

Dynamisch auch, aber wenn man es wirklich vollständig benutzen will, dann muss man zu anderen Paketen gehen. Also es gibt nichts, was das alles miteinander verbindet und einem von Anfang an was funktionierendes gibt. Man muss das ein bisschen zusammensuchen, mehr und auch Entscheidungen treffen, welches man dann von mehreren Möglichkeiten wählt. Swing gibt’s ja auch Alternativen.

Genau, aber Spring Boot muss man schon sagen. Ich will nicht vom de facto STANDARD sprechen, aber das ist für Berat, also Rapid Application Development in der Java Welt so über die letzten Jahre ist das ein sehr, sehr großer Player geworden und man startet meistens damit, dass ganz viele große Applikationen, die man kennt, bestehen ja heutzutage aus vielen, vielen kleinen Microservices. Und diese Microservices, die die Arbeit im Hintergrund verrichten, die sind sehr oft mit Springflut geschrieben.

Welche Features von Spring Boot habt ihr denn verwendet? Also wir haben eben schon über ETT Auto Wired gesprochen. Andreas hatte die Notationen erwähnt. Das ist natürlich das Ding, oder? Diese Inversion of Control ist das Konzept, mit dem Spring damals bekannt wurde, Anfang der 2000er Jahre, dass man eben nicht mehr New Klassisch schreibt und damit eine harte Kopplung hat, sondern man sich über ET Auto Wired z.B. einen Logger in Jack tat, eine Datenbank in Jack That oder ein Transaction Manager in Jack That und dieser Transaktion Manager ist quasi entkoppelt davon, solang der ein gewisses Interface implementiert.

Bleiben wir mal beim Logger ist es egal, ob das ein Festplatten Logger ist, ein Screen Logger, ein Netzwerk Logger oder ein Logger auf einem ganz anderen Medium. Ein na Logger, der einfach nur alle Log Zeilen wegschmeißt oder ein Rauchzeichen lagert. Zur Not. Das Konzept ist ja ganz zentral und ich denke, das hat euch auch relativ früh. Habt ihr das bemerkt?

Ja also die Cernko Komponente für uns war, würde ich jetzt für mich sagen das Auto, wir O-Ring, dass man eben nicht jedes mal neue Instanzen von Klassen erzeugen muss, sondern wirklich diese Benes hat. Und wir haben die auch meistens eben als Singleton benutzt. Das war wirklich etwas, wo wir uns dann auch sukzessive beim Design der Anwendungen Gedanken drum gemacht haben. Also wir haben dann wirklich versucht, wo wir eigentlich zuerst intuitiv gesagt hätten Okay, wir brauchen mehrere Instanzen davon von der gleichen Klasse, dann haben wir trotzdem versucht, unser Design Pattern so umzubauen, auch gedanklich, dass wir eben diese Singleton Auto Viri Funktionalität benutzen können.

Und es hat uns halt auch beim Testing dann begleitet. Entsprechend ja eben das Logging. Andreas Was kann ich mir, wie haben wir das gemacht? Haben wir das von Spring genutzt?

Das Logging ist es auch per Annotation. Das war der SL vor J. Logger lassen hab der Franz Spring Boot selber ist oder?

Meistens sind das externe Libraries, die du einfach in Jackets. Beim Logging kippt es mehrere Standards. Es gibt Lock vor J, dann in CV. JJ Logger. Da gibt’s noch zwei, drei andere. Ich benutze den, der in der Anwendung schon drin ist, weil ich da kaum Unterschiede feststelle oder zumindest mit allen leben kann.

Sagen wir so. Was mir noch einfällt, das ist relativ gegen Ende gekommen, als es darum ging, die Anwendung beim Kunden in den Container Cluster. Zwar Masons zu Diplomen ging es darum, wie wir Health Checks unserer Anwendung im Betrieb machen können. Und weil das vom Dev OPs Team des Kunden angefragt wurde, wie man sicherstellen kann, dass die Anwendung auch vernünftig läuft und ich meine, da hättest bring uns die Funktionalität intrinsisch zur Verfügung gestellt. No Matrix Ja, genau, dass wir da nicht noch selber Health Brookes verschreiben mussten mit dedizierten Endpunkten in der API.

Genau. Wenn ihr das Micro Service Profil benutzt habt, haben wir glaube ich Letz endlich nämlich nicht.

Aber wir haben dann letztendlich die eigenen Endpunkte geschrieben gehabt und dann festgestellt, dass es bringt uns eigentlich frei Haus geliefert hätte. Aber da war es in dem Fall schon zu spät. Das lag dann eher daran, dass wir uns nicht genug damit auskannten. Okay, gut.

Aber das heißt im Grunde jetzt wisst ihr, dass es das gibt. Beim nächsten Service könnte man sich diese STANDARD Matrix also hier RAM verbraucht CPU Jukic, Disk Space könnte man sich auch sparen, sondern einfach die vordefinierten nutzen und die dann eben entsprechend erweitern. Wenn man das braucht.

Ja, was Oleh mir auch gesagt hat. Wir hatten dann ganz viele Klassen mit Autoritären, was am Ende darauf hinausgelaufen, dass wir ganz viele einzelne Klassen hatten, die quasi ein Objekt aus der einen Umgebung der neuen Umgebung übersetzen konnte. Und all diese Übersetzer waren dann letztendlich Singleton Wins, die dann an einer entsprechenden Stelle, wo sie benötigt wurden, einfach nur initiiert worden.

Genauso macht man es auch auch. Ich nehme an, als sie dann die einzelnen Komponenten getestet habt, dann injektor dir dann einfach Mock Objekte statt der realen Instanzen um dann die Kernfunktion einer Klasse zu testen. Richtig, genau so haben wir es dann gemacht.

Genau das war immer der Punkt. Wir haben versucht, das, was wir als Bian eben dann Jack Thot haben, vorher getestet zu haben, um es dann eben an einer anderen Stelle als fertigen Mock benutzen zu können.

Habt ihr bei Projektstart ich glaube es gab schon im Template Oleh Wanne. Ihr habt nicht den Spring Finisher Leisure, also auf Startpunkt Spring dort AIO gibt es den, den habt ihr nicht benutzen müssen, oder?

Nee, tatsächlich nicht. Da hatte ein Kollege schon was vorbereitet, um so eine grobe Projekt Struktur auch mal in Form von Place holder Klassen angelegt und eine grobe Funktionalität war auch schon gegeben. Also ich glaube man hat die Möglichkeit eine Liste zu migrieren oder Objekte einzulesen aus einem Testfall. Und es gab schon eine Anbindung an eine Postkarte oder Mail SQL Datenbank. Genau das war so unser Startpunkt zu dem Zeitpunkt und entsprechend gab es dann eben auch schon ein POM Fall mit dem ganzen Maven Setup A okay war.

Es gibt auch Startpunkt Spring Punkt Видео gibt es diesen Spring in leiser und da kann man dann sagen ich möchte eine Springflut Anwendung schreiben mit Datenbank Zugriff mit Maven oder Greendale Build System und man klickt so ein paar Sachen zusammen und am Ende fällt ein Zipfel raus, was quasi so die Basis Anwendung mit den getroffenen Einstellungen schon enthält. Quasi dieses schlachte schnell und kümmert sich um die Anwendungs Logik auf die Spitze getrieben. Jetzt habt ihr beide ja intelligent Diaa benutzt. Für das Projekt hat euch die Idee gut unterstützt.

Bei Spring Boot Anwendungen ist der Support dafür reif.

Der Support der war super. Tatsächlich. So war von den Socken. Wie einfach es doch ist, damit all die Sachen, die man sonst sehr manuell nachschauen muss in Variablennamen merken und dann ins Java natürlicher nach ner typisierte Sprache, d. h. das kommt noch dazu. All das. Da nimmt es einem ziemlich viel Arbeit ab.

Und auch die Kenntnis der Fidi über die Projekt Struktur. Also was kann ich überhaupt per Auto via O-Ring einbinden? Also was hab ich zur Verfügung? Oder wenn ich jetzt gerade nochmal an das Pom fail zurückdenke. Wenn ich da versuche in Versions takk von etwas einzubinden, was in der Form so nicht existiert, werde ich darauf hingewiesen oder dass ich das dann erst runterladen muss, damit es zur Verfügung steht. Für mich jetzt lokal all solche Sachen, um die man sich ansonsten zu einem späteren Zeitpunkt Gedanken machen müsste, um dann wieder zurückzugehen, um es zu fixen.

Das war schon klasse und natürlich die Möglichkeit, selbst in Module reinspringen zu können, die man nicht selber geschrieben hat, sondern die aus externen Libraries stammen und im Zweifelsfall dann eben de kompilierte Code vor sich zu haben. Was aber immer noch besser ist, als nicht zu wissen, was passiert.

Ja, das stimmt. Du hast Andreas hat eben auch gesagt die Gather und Zeta. Das stimmt, dass man die schreiben muss, das ist schon. Da entsteht diese riesen Text Tapete. Ich mache mal mit ALD einfügen generiere ich die einfach und habt ihr dann für alle Properties. Deshalb stört mich das gar nicht so sehr. Obwohl das eigentlich natürlich schöner geht, hat Andreas vollkommen recht. Was ich bei der Springflut Unterstützung ganz klasse finde ist Du kriegst ja dieses Blättchen, dieses Ahornblatt oder so wird dann angezeigt und dann siehst du die einzelnen Pins, dann kannst du bei den Autor via Pins kannst du so dadurch springen oder er schlägt dir dann schon die Methoden der Pins vor, wenn du da unten arbeitest.

Meistens läuft es da so hinaus. Du was hat deine Klasse, die die Anwendungs Logik enthält und du? Historiker Klassen, die dir halt zuarbeiten, also z.B. Du hast deine Anwendungs Logik und hast ein Database Worker, der Objekte aus der Datenbank holt, Objekte in die Datenbank speichert usw.. Kannst du die dann sehr einfach in deine aktuelle Klasse rein? Metten?

Ja, die Funktionalität hab ich zumindest auch hin und wieder mal benutzt. Was mir noch als Randnotiz positiv im Gedächtnis geblieben ist, ist die Tatsache, dass sehr intuitive Nomenklatur vorgeschlagen wird von der Idee. Also wenn ich das schreibe oder was haben möchte an möglicherweise vordefinierten Strukturen innerhalb meiner Klasse, dann ist die Nomenklatur entsprechend schon an das angepasst, was die tun soll. In dem Zusammenhang wies für mich jetzt gerade notwendig ist, auch wenn dann das schon mal sehr lange Methoden Namen bei rauskommen.

Aber es ist sehr gut. Human Redtube möchte ich mal sagen, was die Idee da einem vorschlägt. Also sie unterstützt da auch schon den menschlich intuitiven Zugang sehr.

Habt ihr eigentlich? Fällt mir gerade ein, bei Convention over Configuration habt ihr auch ein eigenes Banner erzeugt vor einer Anwendung.

Ja, ich hab das sogar in zwei erzeigt.

Wäre ja, ich hab zwischendurch mal gewechselt. Das ist richtig. Am Anfang habe ich ein Corporate Identity ähnliches Banner aus Asti Artzt da hinzugefügt. Genau Asgard Generatoren gibt’s ja genug online frei verfügbar und danach hab ich mir ein Zitat aus einem Musikstück, was ich sehr schätze da eingebaut, was in den Zusammenhang von dieser ganzen Worker Struktur ganz gut reinpasst. Richtig, das war so ein bisschen Selbstverwirklichung, muss ich zugeben. Aber ja. Haben wir gemacht.

Vielleicht für unsere Zuhörer. Kurz. Es gibt eine Band TX t, die kann man auch auf einem standardisierten Pfad ablegen. Und wenn die Anwendung gestartet wird, wird automatisch diese Textdatei quasi ins Lock Fail übertragen. Also normalerweise steht an Spring Boot Version 5.1 Delete, aber man kann das halt mit seiner eigenen SII Banner Punkt txt überschreiben. Was immer ganz interessant ist, was die Leute sich da ausdenken, weil das so ein Freitagnachmittag Task ist. Habt ihr denn auch die einzelnen Methoden dokumentieren müssen oder viel Dokumentation schreiben müssen?

Hat euch das bringt Boot irgendwie unterstützt?

Also da gibt es ja Bild Targets Chewie Java Doc die Dokumentation extrahieren. Da gibt es auch so Spring Boot Plug-Ins das ist alles ein bisschen schöner aussieht. Da purzelt dann diese Java STANDARD Dokumentation raus. Ich weiß nicht, ob das in dem Projekt gefordert war.

Das war nicht in Förderturm manuell dokumentiert, was zu dokumentieren war. Aber zwischendurch hatte ich mir tatsächlich auch diese automatischen Tools angeschaut. Die sind teils sehr umfangreich im Sinne von, dass sie natürlich automatisch alles dokumentieren, was in dem Fall einfach mehr war, als wir brauchten. Dann hätte man sich da dann nur die Teile rausziehen müssen, die man braucht. Von daher war es quasi. Es hat einem zu viel schon gegeben, mehr als von den Verbrauchter.

Zumindest war das mein Eindruck, was aber definitiv am Projekt Scope lag. Das war einfach nicht immer Anforderungsprofil der Aufgabe enthalten. Da ging es mehr um eine Übersicht Dokumentation und weniger in die Tiefe einzelner Methoden rein Dokumentation zu schreiben nach dem Festlegen vorgelegten Schema, sodass wir dann da eher eine Markdown Read Me geschrieben haben, die auch eher kurz ausgefallen ist und auf die Punkte eingegangen ist, die wirklich nötig waren. Deswegen konnten wir das Feature nicht nutzen. Sinnvoll.

Gab es denn bei dem Projekt irgendwie Fallstricke, die mit Spring Boot zusammenhängen, wo ihr sagen würdet Oh, wenn ich das nochmal machen würde, da hab ich viel Zeit gelassen, das würde ich anders machen. Also so Tipps, die im Grunde euch selber geben würdet, wenn ihr das Projekt nochmal durchführen würdet.

Ich weiß nicht, ob ich sie anders machen würde, aber auf jeden Fall Fallstricke, über die man wegkommen muss. Schon an seinem bisschen. Vor allem wann etwas ein Singleton Objekt ist und wann es kein Singleton Objekt mehr ist bzw. wenn du mal kein Singleton Objekt haben willst, musst du einfach ein bisschen mehr Arbeit machen oder muss überlegen ob du es wirklich nicht Singleton brauchst oder haben Singleton nicht auch ausreicht, weil einige Teile der Anwendung Wandern nachher ermutigt werdet. Da musste man dann ganz genau nachdenken, dass man da jetzt nicht dem Singleton irgendwie einen State verleiht, der dann von zwei setzt, sich gegenseitig überschreibt oder solche Dinge.

Da kann man perfekt wie Pattern einzelne Instanzen pro Thread Instance Ihren oder eben das ist ja fast schon dein generische Inversion of Control Anwendungs Design. Was du beschreibst.

Genau. Aber da fehlt ein bisschen die Zeit, dann auch für irgendwann. Aber ich würde sagen, dass das der wichtigste Punkt war, weil das einfach ein Konzept ist, was keiner von uns beiden zu dem Zeitpunkt wirklich angewandt hatte. Mal im Alltag, in der Programmierung und wenn man sich damit mal ein bisschen intensiver auseinandergesetzt hat, vielleicht auch auf einer theoretischen Ebene und an einfachen Beispielen angefangen, dann erleichtert das den Einstieg vor allem ins Design von so einer Anwendung, weil wenn man ständig wieder drei Schritte zurückgehen muss, um dann den Ansatz für eine Problemlösung doch nochmal komplett auf links zu drehen, weil man eben genau bei dieser Inversion of Control irgendwie das konzeptionell dann doch nicht richtig gemacht hat für den eigenen Anwendungsfall Gespartes schon.

Zeit, wenn man da einfach von vornherein das bei seinem Design Pattern berücksichtigt, als sie die Anwendung designt habt. Ich meine, wir haben eben schon kurz drüber gesprochen, habt ihr genug Beispiele für Spring gut Problem im Internet gefunden, also Bildung. Die Seite haben wir erwähnt und auch sonst bei Stack Overflow hattet ihr Immi Probleme für euern Fall was zu finden oder war das eigentlich immer gut? Wie würdet ihr die Dokumentation Situation einschätzen?

Ich würde sagen, Bildung war da sehr umfangreich. Es kam ein paar Mal vor, dass ich nach dem hin. Das reicht mir jetzt nicht nochmal einen halben Tag auf die Suche im Internet gegangen, nur um dann am Ende beim gleichen Bildung Artikel wieder zu landen und zu sehen. Okay, eigentlich stimmt es ja doch, was hier steht. Und wenn man es richtig liest und einen mit ein bisschen Abstand nochmal liest, dann steht da eigentlich alles drin.

Ich glaube, bei sehr spezifischen Problemen kommt es dann wie eigentlich immer ein bisschen aufwändiger werden zu recherchieren. So grundsätzlich war das Vorhandensein von Documentation ja schon gut ausgeprägt, aber ich erinnere mich, dass wir bei dem Thema Parallelisierung und dann eben Multi Reading unserer Anwendung doch die eine oder andere technische Hürde hatten, die ein bisschen schwieriger zu überwinden war, sowohl vom Design als auch von der technischen Umsetzung nachher, was dann auch ein bisschen mehr Recherche und Refactoring bei uns dann eben auch nötig gemacht hat.

Aber das sind dann schon sehr spezifisch die Themen der parallele Entwicklung oder?

Neben läufige Entwicklung ist natürlich immer noch ein Komplexität Stufe höher, einfach weil man eine ganze Menge bedenken muss, damit das auch funktioniert.

Ich hatte noch einen zweiten Fallstrick. Vielleicht hat mir eben am Anfang schon über das dpa gesprochen und wie Einfaches zu sagen gemacht hat, die Datenbank aufzubauen. Man hat dann aber am Ende schon gemerkt, wenn man relativ komplexe Abhängigkeiten mit mehreren von Civey, Strands und auch Manitoba Bennie Relationships. Irgendwann kommt man dann halt auch da ans Ende dieses Modells und kommt dann halt an Stellen, wo es dann noch mal her sich herausstellt. Okay, wenn ich das jetzt aber von der Seite aufziehe, funktioniert es perfekt und von der anderen Seite generiert es mir dann halt ganz ineffizienten ASCII Code.

Da muss man dann halt ein bisschen aufpassen, wenn man da angelangt ist.

Also einfach ein bisschen Augen offenhalten und vielleicht nicht nur eine Doku Stelle im Internet aufsuchen, sondern 2 3, um dann eben das für sich passende da rauszusuchen.

Genau da braucht ein bisschen mehr Recherche und muss sagen ein bisschen auch selber mehr ausprobieren, was dann da der beste Ansatzes würde.

Dir den Spring Boot als Plattform weiter empfehlen oder nochmal verwenden, wenn ihr eine weitere Java Anwendung in sagen wir mal im Kybernetisch Cluster betreiben wollen würdet oder auch einfach so auf dem Server betreiben wollen würdet.

Auf jeden Fall. Also ich würd mit nichts anderem anfangen wollen in Java.

Ich denke auch, dass sich das als Blaupause und Grundlage für, ja als die Fall regelrecht für Java Anwendungsentwicklung nehmen würde, weil die meisten Anforderungen aus Umgebungen kommen, wo man das eben gut umsetzen kann. Ich meine missis in den letzten Jahren nichts untergekommen, wo man jetzt auf einen klassischen ein Maschienen Server oder einen großen Mainframe irgendwas hätte entwickeln müssen, sondern man kommt eben immer eigentlich gerade wenn es Java sein soll in diese Microservices Richtung bzw. kann seine Anwendung zum Lösen eines Problems so Design, dass sie auch sinnvoll so umzusetzen ist.

Und dann ist Spring Boot wirklich ein Top Tool würde ich jetzt sagen. Und das ist doch glaube ich für den Einstieg gut. Also wenn man sagt, man kann bisschen programmieren, man kann objektorientierte programmieren, dann steigt man in Java ein, dann kann man mit Spring Boot auch sehr zufriedenstellend schnell ein Ergebnis erzielen, was wirklich Produktions reif. Innerhalb kurzer Zeit ist das eine tolle Sache.

Da kommt glaube ich dieses Opinio Native was du meintest Magix gut durch es. Es hat halt an vielen Stellen einfach sinnvoller die Falz und außer wenn du weißt, dass das unbedingt anders haben willst, ist halt anders. Aber der Default ist erstmal sinnvoll.

Ja genau. Also diese Opinio native Settings spielen eine Rolle. Deshalb läuft die Anwendung sofort, weil man im Grunde alles hat, was eine Anwendung benötigt. Der Webserver oder der Tomcat in dem Fall ist eingebaut, Matrix sind eingebaut, Health Checks sind eingebaut. Externe Konfiguration, also das Laden von Settings aus Properties. Falls wenn man zum Beispiel einen Dart Mac anbinden möchte und da ein Username Passwort und Connection String hinterlegen muss, ist dabei. Also ja, es funktioniert direkt und man kann dann anpassen, was man braucht.

Ich fand euer Beispiel sehr schön, weil ihr eigentlich ein Micros Service der Daten Transformationen hauptsächlich Macht implementiert habe, dann aber gesehen hat. Oh wir müssen noch irgendwie eine Web Komponente nachrüsten, weil wir statische Dateien aus liefern möchten oder Web Dateien ausliefern möchten. Ist das wirklich für eine Web Oberfläche gedacht gewesen, als wo jemand auf diesen Service springt und im Browser etwas machen kann? Oder war das einfach nur um Dateien auszulagern, die für diese Transformation notwendig sind?

Das war tatsächlich dann eine Oberfläche. Einfach weil sonst der Zustand der App ein bisschen schwierig zu monitoren waren. Brauchten wir da etwas, um den Überblick der dem Garzón in dem Fall zu behalten? Einfach weil ja da mehrere Zehntausend. Datenpunkte migriert werden mussten und das durch verschiedene Snakes durch. Erstmal exportiert werden musste, im neuen System importiert. Nebenbei noch Sachen hochgeladen werden mussten und da den Überblick zu behalten. Damals hat man ja im Frontend für gebastelt. Okay.

Und das Frontend ist nur für euch gewesen. Oder guckt der Kunde das auch an, wenn er diese Software einsetzt?

Das war jetzt in dem Fall für uns mehr als die Person, die dann die eigentliche Migration macht. Was in dem Fall ein Kollege von uns ist. Also nicht ganz für uns selber, aber der Kunde benutzt es in dem Fall nicht.

Er könnte es aber benutzen, wenn er wollte. Wenn die Anwendung in unserem Fall, auf dem wir entwickelt haben und er unser Benchmark Punkt war Björn ist gerade gesagt, ein paar 10 000 Datenpunkte, um die es ging, da war die Laufzeit für den kompletten Migrations Prozess im Bereich von Stunden. Das ist was, was man theoretisch morgens starten. Und wenn man es Büro verlässt, ist die Anwendung fertig betreiben kann.

Nicht nur theoretisch, sondern praktisch, ja sogar richtig.

Das wird sich dann hoffentlich bald zeigen. Aber es gab auch den Use Case. Ein bisschen mehr in der Zukunft, dass wir über mehrere 100 000 Datenpunkte vergleichbare Einzel Größe reden. Und dann würde die Anwendung halt schon deutlich länger laufen und man möchte vielleicht aktives Monitoring davon haben. Und das wäre eben darüber möglich gewesen, dass man dann eben mal reinschaut, wie es gerade der Stand der Dinge.

Und insbesondere hat dieses Webforen dann letztendlich nichts anderes getan, als gewisse Endpunkte unserer App anzusprechen. Und mit diesen Endpunkten hätte man dann auch ein beliebiges anderes Monitoring aufziehen können.

Na okay, ater sind die nachgerüstet von Matrix, die ihr eingebaut hat.

Unter anderem genau Azawad. Einige Standards, Sachen wie ihr Herzschlag und Memory Konsumption. Aber dann halt auch einfach wie viele sind schon prozessiert?

Wie viele sind in den unterschiedlichen Stages der Migration solche Sachen? Den letzten Fallstrick hatte ich noch als beiten Entwickler. Man muss sich an die Annotationen gewöhnen, dass sie einfach was ganz anderes sind als Payton Annotationen. Wenn man damit dem momentanen Modell sich einmal umgedacht hat, dann funktioniert es. Also das ist halt wirklich nur Annotation. Sind also zusätzliche Informationen, die dann irgendwie interpretiert wird, nicht Code, der ausgeführt wird.

Die Annotationen gibt es auch in neueren Pfeifen Versionen, zum Beispiel bei den Data Classes und ich hatte das so verstanden, dass die was ähnliches machen wie auch in der Java Welt oder ich hab sie so benutzt.

Sie sehen ähnlich aus, aber letztendlich sind sie nichts anderes als Haja oder Functions. Also die Funktionen als Argumente nehmen und dir deine modifizierte Funktion zurückgeben. Während Java Annotationen ja eigentlich nur ein Hinweis an ein Paket sind, jetzt irgend eine Magie zu verführen, aber nicht an den Annotation selber gekoppelt ist. Klar, man kann Annotation auch selber schreiben, aber es ist schon so, dass die Annotation so eine Art Auszeichnung sind, um die nachfolgende Funktion oder so eben zu Parameter visieren oder das nachfolgende Objekt genau innehabe.

Das eigentlich paar Interesieren passiert in Java soweit ich es verstanden hab, ja nochmal einfach anders. Also irgendetwas anderes nimmt dir Annotation und macht dann etwas damit Sphären in Python. Es ist die Annotation selber, die etwas macht.

Genau das Spring Framework werte die Annotationen aus und sagt Ach guck mal, hier ist ein Auto Wired, da muss ich ja diese Biene reinstecken, die ich hier initialisiert hab. Also das kann man vielleicht noch sagen, das Spring Framework geht hin, wenn die Anwendung gestartet wird, guckt das alle Bins also also eine Java Klassen hier als Service definiert habt oder als Controller definiert habt, guckt es an, instanziiert diese Klassen und dann erst guckt es in die einzelnen Klassen rein.

Wo steht dein Auto Wired und stöpseln jetzt diese initialisiert Klassen eben zusammen, damit die Anwendung loslaufen kann? Das passiert sozusagen alles im Vorfeld von dem Framework selber. Wenn ihr Fragen habt oder Feedback, sendet uns gerne eine E-Mail an Podcast Skill bei Tee. Wir freuen uns immer über Bewertungen und wenn ihr den Podcast an Freunde und Kollegen weiterempfehlen, die sich für ähnliche Themen interessieren. Wenn ihr aktuell im IT-Bereich auf Jobsuche seid, schaut gerne auf das G.H. Die Slash Job Seite vorbei.

Weitere spannende Technologien Themen findet ihr auch im Skill Bait Blog. Oli Andreas, ich danke euch ganz herzlich, dass ihr heute Abend meine Gäste wart.

Danke Maurice. Es war mir eine Freude. Ich wünsche euch beiden noch einen schönen Abend. Danke dir auch.

Maurice KnoppSkillbyte Podcast #45: Das Spring Boot Framework
Mehr

Skillbyte Podcast #43: Helm – Der Kubernetes Paketmanager

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

In diesem Podcast geht es um das Thema: Helm – Der Kubernetes Paketmanager

// Inhalt //
01:23 – Definition: Was ist Helm und wie wird es eingesetzt?
04:14 – Einsatzszenarien für Helm Charts
08:03 – Warum benötigt man Helm Charts ?
09:13 – Vorteile von Helm Charts und deren Einsatz
14:32 – Zusammenfassung Vorteile Helm Charts
16:12 – Von Terraform über Kubernetes zu Helm
22:18 – Beispiele: Betrieb hoch-skalierbarer Anwendungen
26:09 – Neue Anwendungen werden Cloud-native entwickelt; selten Migrationen von Bestandssystemen
29:18 – Bestandteile und Funktionen eines Helm Charts
34:25 – Handhabung von Helm auf der Kommandozeile
36:23 – Helm 2 vs Helm 3
37:35 – Flux – CI/CD in Perfektion
41:53 – Fortgeschrittene Deployments: Canary und Blue Green Deployments; Istio

Show notes:

Podcast #25: Kubernetes: Flexibles und leistungsfähiges Rechenzentrum für Unternehmen
https://soundcloud.com/skillbyte/podcast-25-kubernetes-flexibles-und-leistungsfahiges-rechenzentrum-fur-unternehmen

Podcast #36: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service Werkzeug
https://soundcloud.com/skillbyte/podcast-36-terraform-virtuelles-rechenzentrum-mit-dem-infrastructure-as-a-service-werkzeug

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Das Wichtigste zu verstehen ist, dass man mit Helm eigentlich nur kybernetisch Ressourcen verwaltet. D.h. Anstatt dass ich jetzt mit meiner Cubes Btl hingehe und sage create deployment create secret create config map, sag ich einfach nur Haman Stall und im Hintergrund läuft halt genau das. Aber das Schöne an der ganzen Sache ist, dass das alles kybernetisch Native ist. Also im Prinzip kann ich es nicht best practice, aber im Nachhinein kann ich beliebig auch die Ressourcen per Hand wieder editieren.

Ist natürlich nicht empfohlen, weil dazu gibt’s ja Helm. Herzlich Willkommen zum Skill bald Podcast Nr. dreiundvierzig Helm Der Kybernetisch Paket Manager abonniert unseren Podcast für mehr spannende Technologien aus dem Technologie Umfeld, wenn er IT Entscheider oder ity Fachkraft seid. Wenn ihr eine Frage habt im Verlauf der Episode sendet uns gerne eine E-Mail an Podcasts Skill BYD Punkt D Wir freuen uns auch immer über Bewertungen und ganz besonders wichtig für uns sind Weiterempfehlung an eure Freunde und Kollegen, die sich auch für Technologie Themen interessieren.

Wenn ihr aktuell ity Jobs sucht, schaut gerne auch auf das Gebiet Jopp Seite vorbei. Ich bin heute hier mit Julius, einem DevOps Ingenieur von Skill bald und ich freue mich super auf dich. Hallo Julius, hi Maurice. Ja und heute sprechen wir über Helm und das Thema kybernetisch bzw. was Helm genau ist. Und Helm ist eine Technologie. A kann man sagen, die in den letzten 2 3 Jahren doch deutlich an Verbreitung zugenommen hat und ja auch so ein bisschen gehypt es, oder?

Ja, auf jeden Fall. Also das Tool ist ja schon ein bisschen älter. Aber wie du gesagt hast, es ist jetzt in den letzten Jahren hat das enorm zugenommen. Auch. Vor allem wird das viel verwendet. Also eingebettet in andere Systeme, wie z.B. Rangiere oder so. Also das ist auf jeden Fall sehr populär zurzeit genauso.

Entwicklungsgeschichtlich kann man ja sagen, diese Kuba Metis Infrastruktur ist entstanden und die Leute haben begonnen eben ihre Anwendungen in kombiniertes Cluster zu Diplomen, die zu managen und haben dann aber festgestellt okay, so eine Anwendung aus mehreren Microservices im Kybernetisch Cluster, das ist relativ viel Handarbeit, diese zu warten und die einzelnen Komponenten zu aktualisieren. Es wäre doch schön, wenn man so eine Art Paket Manager hätte, wie man das aus z.B. Linux-Distributionen kennt wie APT, get oder Pacman und dieses Konzept auch für kybernetisch Anwendungen, die wie gesagt aus mehreren Microservices bestehen können, verwenden kann.

Das Ziel ist es eben kybernetisch Anwendungen möglichst einfach zu managen, also wie man bei abgeht install Paket Name sagt und Linux Pakete installieren kann. Genauso möchte man das auch in der Kybernetisch Welt haben und natürlich auch genau so einfach mit einem an install. Wofür hast du denn Helm bisher benutzt?

Ja, im Prinzip genau wie du jetzt gerade erwähnt hast. Also der Zustand, dass man eben irgendein fertiges Tool schnell installieren will, gerade auch zu Demo Zwecken oder um mal so ein kleines Proof of Concept zu machen. Wenn man zu einem Kunden fährt, den einfach zeigen will, was möglich ist und wie schnell das alles geht. Da benutzt man gern Helme, weil wie du schon gesagt hast im Linux Umfeld ist das ja auch sehr gängig, dass man da einfach schnell was installiert um es auszuprobieren, weil man sich eben nicht durch irgendeinen Install Wizard durchklicken muss und auch eben nicht viel konfigurieren muss, sondern das eigentlich out of the Box funktioniert.

Also Helm ist wie kybernetisch selbst auch OpenSource richtig. Genau. Ja, das ist ein Open-Source-Projekt, was von der Cloud Native Computing Foundation betreut wird. Und so kann auch jeder im Prinzip da dran mit basteln.

Contribution Ja, das machen ja die großen Cloud Provider. Alle oder die großen alten Namen bringen sich dann natürlich ein, weil sie auch gesehen haben der Trend geht ganz klar eben zum Paket Manager auf Kuba net des Container Anwendungen. Wenn unsere Zuhörer noch mehr zu kybernetisch wissen möchten, empfehlen wir auch gerne unsere Folge Nr. 25 Da geht es intensiv um das Thema Kybernetisch, um komplexe kombiniertes Anwendungen eben betreiben zu können oder installieren, deinstallieren, abzugrasen zu können. Wie genau macht man das denn mit Helm?

Stell dir einfach mal vor, wir haben entweder Ein und Promos Rechenzentrum oder ein Cloud kybernetisch Cluster hochgefahren. Ist ja egal, ob der jetzt bei einem der großen Cloud Provider läuft oder im eigenen Rechenzentrum. Und ich möchte die Helm Technologie einsetzen. Wie würde ich da denn jetzt dran gehen?

Ja. Also grundsätzlich gibt’s ja dann erstmal die Frage Möchte ich das jetzt für meine spezielle Anwendung, die ich zum vielleicht auch selbst entwickel machen oder für eine Anwendung, die eben noch nicht im Heim Repository mit drin ist? Oder eben so eine typische STANDARD Anwendung? Das weiß ich an Engine X Server oder typisch sind auch ein Monitoring primitives oder sonst was mit allen möglichen Abhängigkeiten. Im letzteren Fall würde man dann halt wirklich gucken, in welchem Repository das drin ist. Meistens sind die auch in den STANDARD Repositories drinnen.

Da gab’s jetzt plötzlich viel Umstrukturierung. Aber die großen Sachen, die sind eigentlich immer zu finden. Und dann würde man ähnlich wie beim Paket Manager tatsächlich einfach sagen Heim ins Daul den Release Namen. Also da kann ich selbst an einen Namen vergeben, der dann unique in meinem Cluster halt erscheint und dann eben der Name des Pakets. Im Prinzip also im Heim Umfeld nennt man das Helmut Shard. Und ja, man kann da beliebig dann auch Variablen in dem Shard verändern und anpassen.

Aber im. SIB reicht ein einfaches Heim in Stall, den Release Namen und das Shard, was ich installieren will und dann läuft das eigentlich schon von selbst alles an, mit allen Abhängigkeiten und einem möglichen.

Das heißt, ich konfigurierte Helm benutze ich von der Kommandozeile Karl gegen den kubanisches Cluster, gegen den ich es benutzen möchte. Ob on primus oder in der Cloud.

Richtig, genau genauso siehts aus. Und es gibt schon Repositories an die Helm Charts enthalten für STANDARD Komponenten wie z.B. Webserver, Engine X oder Datenbanken. Wobei Datenbanken in kubanisches Clustern ist immer so eine Sache, aber für fertige Komponenten und da kann ich meine eigene Software, die vielleicht ein Webserver braucht ne, wenn es Microservices ist, kann ich sozusagen darauf basieren lassen, oder?

Ja, das ist eben der Vorteil. Ähnlich wie beim Paket Manager wieder, dass sich eben Abhängigkeiten auch in meiner eigenen Anwendung einfach reinziehen kann. Und wie du schon gesagt hast, das ganze Management von Abhängigkeiten. Das passiert alles klein seitig und im Prinzip werden dann einfach ganz normal die Sachen nach und nach in kybernetisch Cluster installiert von Hän und ich muss mir da gar nicht viel Gedanken machen.

Also Helm geht dann hin, lädt die einzelnen @Helmut Charts die ich als Abhängigkeiten markierter. Bleiben wir mal beim Webserver runter, lädt die Docker Images runter Diplome die dem kybernetisch Cluster und sieh zu, dass alle Komponenten ordentlich starten. Und ja, die beschriebenen Wolli ums gemault teeth werden die Ports die angegeben werden freigeschaltet sind verschiedene krit. Dunkels gesetzt werden. Also als variablen Beispiel, sodass nach und nach die Anwendungen wirklich wie ausgepackt aus einem Paket in dem kybernetisch Cluster lauffähig gemacht wird.

Genau ungefähr so ist es natürlich schon noch so, dass Kuba Annettes sich um Sachen kümmert, wie jetzt die Container runterzuladen und so weiter. Das wichtigste zu verstehen ist, dass man mit Helm eigentlich nur kybernetisch Ressourcen verwaltet. D.h. Anstatt dass ich jetzt mit meiner Cubes Ctrl hingehe und sage create deployment create secret create config map, sag ich einfach nur ha’m. Im Stall und im Hintergrund läuft halt genau das. Aber das Schöne an der ganzen Sache ist, dass das alles kybernetisch Native ist.

Also im Prinzip kann ich es nicht best practice. Aber im Nachhinein kann ich beliebig auch die Ressourcen per Hand wieder editieren. Ist natürlich nicht empfohlen, weil dazu gibt’s ja Helm.

Das ist ja genau der Punkt, dass man eben nicht Anwendungen händisch installieren möchte. Das würde ja auch funktionieren. Und dass man dann hinterher sagt Okay, die Anwendung läuft. Ich habe drei Tage dafür gebraucht. Welche Befehle hab ich denn sozusagen abgesetzt, um die Anwendung zu installieren und daraus mir ein Script mache, sondern das genau soll ja Helm machen. Man beschreibt in diesem Helm schade, dass es eine Jamel Datei beschreibt man quasi die Abhängigkeiten und den Zustand der App und Helm sieht einfach zu, dass dieser Zustand hergestellt wird und führt die dazu notwendigen Kommandos aus.

Genau, ja.

Also das ist wie du schon gesagt hast, in DE klarer, tiefer Ansatz, typischer Orchestrierung. Use case also ich sag halt was ich haben will und Heyl guckt was hab ich und was muss ich tun, damit ich den Zustand erreiche? Also da haben wir noch gar nicht drüber gesprochen. Auch Sachen wie Updates und so weiter können von Heyme auch direkt behandelt werden. Und PAME vergleicht halt einfach nur Ist und soll und guckt dann, dass die Aktion ausgeführt werden, die nötig sind.

Ja, das ist ja auch wie bei einem Linux Paket Manager. Na da kann man ja auch die Updates direkt über dem Paket Manager machen und die werden dann eben eingespielt entsprechend.

Genau, ja. Also die Vorteile von HAMCHA sind ganz klar. Wir haben schon von der Jamel Datei gesprochen, dass man diesen Infrastructure Ascot Ansatz noch weiter treibt. Die Jamel Datei ist natürlich einfach eine flache Datei, die man in git Versionierung kann. Man sieht wer welche Änderungen gemacht hat, man hat reproduzierbare Installationen. Ich könnte ja jetzt auch sagen wir ich habe drei kybernetisch cluster test Akzeptanz Umgebung und Produktions Umgebung und könnte dann in schneller Folge ein komplexes Helmi Chat mit vielen Komponenten in allen drei Umgebungen installieren.

Das wäre überhaupt kein Problem. Richtig.

Genau das ist eben auch der Vorteil. Ich hab’s eben schon ein bisschen angerissen. Man kann diese Hemme Charts, die bestehen auch aus Templates. Also diese ganzen kubanisches Ressourcen werden getrampt rated und dazu wird go template im Englischen benutzt. Das heißt, dass ich dann auch abhängig von dem Environment, wo ich mein Deployment mache, auch Variablen setzen kann. Das heißt in Produktion kann ich z.B. sagen, die Praktikas von dem Container, also wie viele Container gleichzeitig für meine Anwendung laufen, ist höher als jetzt in einem Test in Valmont, wo ich halt eben nur kurz Funktionalität durch testen will.

Okay. Das heißt, die Ausfallsicherheit ist dann quasi noch die Umgebung anpassbar, sodass ich pro Umgebung das festlegen kann. Genau.

Also es kommt natürlich aufs hammerhart an. Wenn ich jetzt was vorge Bauteils nehme. Irgendein offiziös. Dann muss ich halt gucken, was ist da g Templates. Also was kann ich durch Variablen ändern? Aber wenn ich jetzt ein eigenes Chart Bauer z.B. für meine Anwendung, die ich jetzt selber entwickelt hab mit allen Abhängigkeiten kann ich beliebig in diesen kybernetisch Ressourcen wie jetzt bei eben schon erwähnt mittels den go templates kann ich dann einfach jeden beliebigen Punkt also ob es jetzt in der Environment variabel ist, obs Memory Limits oder sonst was sind, kann ich alles beliebig als variabel definieren.

Im Template und dann eben in einem separaten Pfeil kann ich dann sagen okay, das sind meine Values, die eben für Produktion sind. Das sind meine Waldis, die für die Testumgebung sind. Und so lässt sich das dann beliebig anpassen auf die Infrastruktur im Beispiel jetzt auch wenn man ein fertiges Chart hat. Das macht das Ganze auch so mächtig. Nicht jeder will sein Monitoring gleich aufsetzen. Der eine hat eben andere Ansprüche, auch an Verfügbarkeit oder auch die viele Daten überhaupt gespeichert werden.

Wenn es jetzt Richtung Valium Claims und so geht und das lässt sich dann halt eben beliebig konfigurieren und das macht das Ganze auch so mächtig. Ja, verstehe.

z.B. in meinem Alltag ist es total sinnvoll, dass man sagt in der Produktions Umgebung hab ich z.B. 50 Ports um die ganze Last abzuwickeln. Also dieser Produktions Anwendungen. Aber in meiner Testumgebung, der teste ja nur ich. Da brauche ich viel weniger Disk Space, kann die kleinen Cloud Instanzen nehmen, das kostet dann weniger Geld wenn man will ja nicht. Vielleicht zum ganzen Cluster nur für die Entwicklung dann Überstunden betreiben und kann das dann eben so konfigurieren, dass das passt.

Und das ist auf der einen Seite viel Last bewältigen kann, im Produktionsbetrieb aber im Development Betrieb dann sehr kostengünstig ist, dass man theoretisch ein paar Dollar am Tag jeder Entwickler seine eigene Umgebung hoch und runterfahren kann mit nur wenigen Maschinen aus dem gleichen Hemsworth heraus.

Genau das kann man auf jeden Fall machen. Wie gesagt, es kommt da immer auf das Template an, was genau jetzt konfigurierbar ist und was nicht. Aber das ist auch das Schöne an diesem ha’m Ansatz, wenn ich jetzt selber einen Chart entwickel. Wir hatten ja schon angesprochen, die Struktur ist so, ich hab da mal einen Chart dort Jamel mein Haupt Jamel Fall, was halt so einen Namen vergibt Version Abhängigkeiten und dann kommt halt ein Template Ordner, indem eben diese ganzen Ressourcen liegen.

Und im Prinzip kann ich erstmal von alleine kybernetisch Ressource ausgehen. Also wenn ich jetzt mir einen Cube Citi alte Skripte mache auf eine Ressource im Jamil Format, dann kriege ich im Prinzip schon die Datei, die kann ich in dem Template Ordner ablegen und dann ist das Ding erstmal gelaufen. Ich kann dann eben im Nachhinein sagen okay, hier steht jetzt Reply CAS 3 drin. Ich möchte das jetzt konfigurierbar machen und dann kann ich eben da ganz einfach das mit dem GO Template in Format teilt.

Ja, Template draus machen und da gibt’s natürlich ganz viel Advanced darf das man halt auch anfangen kann Funktionen zu bauen, die dann von bestimmten Sachen wie jetzt welchen Get Lab Branch ich das jetzt baue und so weiter die Variablen anpassen. Aber das ist alles advanced. Das Schöne ist, dass man halt wirklich so step by step das Ganze aufbauen kann.

Das heißt, man kann sehr schnell starten, weil man es einfach verstehen kann. Aber die Erweiterungen Möglichkeiten sind mannigfaltig, sodass man auch komplexe Enterprise Anwendungen im @Helmut Charts verpacken kann.

Genau hier also für jeden der kybernetisch benutzt, ist das eigentlich überhaupt kein Problem Helmuts zu bauen, weil man eben immer bei den Intels Ressourcen anfängt und dann eben bestimmte Sachen konfigurierbar macht.

Das heißt mit Helm Charts sind im Grunde diese Dateien gemeint, die eben diese Orchestrierung beschreiben.

Ja, also das ist ein bisschen verwirrend, weil das Startort Jamel ist ein Fail, was zu einem Heyme Chart gehört. Aber genau wie du sagst das ganze Paket. Also die Templates, das Valerius Free und das Chart dort Jamel, also die Beschreibung von dem ganzen Chart, das ganze Paket, das Wandel, das nennt man eben Chart.

Okay, verstehe. Das heißt, wenn wir nochmal die Vorteile von Helmi Charts zusammenfassen, was bringt mir deren Verwendung? Dann kann man schon sagen erstmal bündelt es die Anwendungs Informationen. Also welche Dienste brauche ich, welche Williams brauche ich, welche Ports brauche ich? Die sind da ja alle beschrieben und einfach erweiterbar. Also wenn man ein weiteres Molden brauch, kann ich das einfach da eintragen und es würde dann hinzugefügt. Änderungen durch die Git Versionierung keit können einfach nachverfolgt werden und es gibt bereits eine große Bibliothek von vorhandenen Pane Charts, die ich entweder inkludieren kann oder als Basis für eigene Entwicklung nutzen kann.

Ja genau. Was vielleicht noch ganz interessant zu wissen ist. Wir haben ja schon gesagt, Heyme macht eben diesen ist Säufer gleich und das gantzer Kommando. In diesem Fall wäre das dann Häme Upgrade. Das ist eidam potent, also idR impotent im Deutschen. Das bedeutet, ich kann das Kommando so oft ich will absetzen und es ändert eigentlich nichts, außer dass jetzt die Release Noma hoch gezählt wird im Cluster. Aber abgesehen davon läuft meine Applikation. Ohne angefasst weiter.

Wenn ich jetzt keine Änderungen gemacht habe und das ist natürlich eine super Grundlage für Scripting, dann also, wenn ich das jetzt in der Pipeline packe oder so, kann das halt dann super einfach immer abgesetzt werden, weil das sich eben selbst darum kümmert, die nötigen Schritte durchzuführen.

Naja, okay, verstehe. Das heißt, wenn zwei Maschinen fehlen und du setzt Upgrade ab, dann Start. Der hat die zwei Maschinen. Und wenn das gleiche Kommando eine Minute später nochmal abgesetzt würde, würde einfach gar nichts passieren, weil er erkennt Ah, der Zustand, wie ich ihn beschrieben habe im HAMCHA. Das ist der Zustand, der auch im Cluster vorliegt. Das heißt, ich muss nichts machen. Genau. Wir haben in Episode Nr. sechsunddreißig über Terraforming gesprochen.

Das nutzt ganz ähnliche Mechanismen, um die Basis Infrastruktur, also z.B. diesen Kybernetisch Cluster aus der Taufe zu heben. Auf einer Cloud Lösung oder einer vorhandenen Infrastruktur und das ist natürlich in Kombination mit Kobanê des und Helmut Scharz kann man sozusagen von den Maschinen über den Cluster bis hin zur Anwendung eine komplette Basis Infrastruktur aus der Taufe heben mit dem Infrastructure as a Service Ansatz.

Das ist vielleicht noch ganz interessant, wo du jetzt Terraforming erwähnst. Viele Leute bringen das ja durcheinander. Terraforming hän Antriebe. Wo ist jetzt hier die Abgrenzung eigentlich? Und wie du schon gesagt hast, Terraforming ist halt eher Infrastructure Xcode. Also da hole ich mir dann irgendwie einen Cluster aus dem stampfe ich mir aus dem Boden und im hellen Bereich. Da ist man dann halt eher so bei den Applikationen, Middleware und sowas wie du gesagt hast. Terraforming hält ja auch für Zustand.

Bei Terraforming ist es so, dass der Kleinen seitig gehalten wird in dem Pfeil. Dieses Fall kann ich auch angucken und bearbeiten. Bei Helm ist es so, dass sich das ist auch abhängig von der Version. Da hat sich auch viel getan von der Version 2 zu 3, aber im Prinzip werden die ganzen Informationen im Cluster gehalten. Bei der neuen Version Version 3, da werden die Informationen in dem Namespace gehalten, wo auch mein Release läuft, also die Applikation, die ich installiert hab.

Und das hat eben den Vorteil, dass dann auch so Sachen wie jetzt Rol based Access Control von kybernetisch aus direkt umgesetzt werden. Also dass der Benutzer, der dazu berechtigt ist, das Deployment zu ändern oder überhaupt was zu Diplomen die Möglichkeit kriegt, wobei jemand anders, der dann eben nicht die Rolle hat, diese Möglichkeit unterbunden ist.

Also so eine Art Zugriffs Beschränkung mit Hilfe der Aarburg Policy genau Vorjahr bei Hellem 2 war das nicht ganz so einfach.

Das hat super funktioniert, wo Kybernetisch Arbat noch nicht implementiert hat. Weida hatte noch einen Server im Kybernetisch Cluster der laufen musste. Der sogenannte Tilla Server oder Tilla wird er auch einfach nur genannt. Und dieser Tilla hat halt als Server funktioniert für das Ziel n Tool vom Client aus und der hat halt seine ganzen Ressourcen innerhalb seines Namens Spaces abgelegt. Also enorm viel war das in dem Cubes System namespace. Da lief halt der Tilla und der hat dann Config Maps erstellt oben eben seine Ressourcen und seinen Zustand zu halten.

Und jetzt? Neu ist eben bei Hemme 3, dass die Ressourcen in dem Target namens Bake, also da wo ich meine Deployment wirklich mache, abgelegt werden, was eben diesen Vorteil hat, dass man die Arak Funktion von Kybernetisch direkt mit einbindet. Na weil wenn ich jetzt mit meinem Kleintieren gehe und keine Rechte hab, dann kann ich natürlich auch diese config maps gar nicht lesen oder bearbeiten.

Ja, das ist auch Tilla. War ja auch so ein Sicherheitsproblem, weil halt alle Leute, die sozusagen mit dem Tiller sprechen können, auf alle verwalteten Ressourcen Zugriff haben. Und jetzt über die Arbaces kann man das etwas feien Granulat wa steuern? Also man sollte auch für unsere Zuhörer, wenn man heute anfängt, auf jeden Fall mit der Version 3 von Helm beginnen. Genau hier. Ja, das ist vielleicht nochmal, um diesen Zweck klarzumachen. Ich finde das ganz interessant.

Du musst dir einfach vorstellen, oder? Unsere Zuhörer können sich einfach vorstellen, man hat diese laufenden Server einfach im Rechenzentrum, also hunderte oder tausende davon. Mittels Terraforming bündelte ich einige dieser Server zusammen zu einem Kybernetisch Cluster. So und der Cubaner? Das Cluster ist sozusagen ein STANDARD, der ob er jetzt bei Escher läuft, bei Google in der Cloud läuft oder bei AWS Amazon in der Cloud läuft oder irgendwo anders auch im eigenen Rechenzentrum sich mehr oder weniger gleich verhält.

Und auf diesem kybernetisch Cluster oder in diesen kybernetisch Cluster kann ich jetzt mittels Helm meine kybernetisch Anwendungen diplomen. Und wenn man diese drei Werkzeuge zusammennimmt also Terraforming Kybernetisch Helm komme ich relativ weit weg von diesem Vendor Lock in genau.

Ja wie du schon sagst. Also ich meine Kuba Annettes generell ist schon ein richtiger Schritt in die Richtung, dass man halt einfach eine Basis schafft und dann eben man nimmt ja gerne den Begriff Cloud Agnostikern in den Mund, also dass man eigentlich sich nicht wirklich drum kümmern muss, was unterhalb von Kybernetisch läuft, weil man da eben diese fest definierten Standards von Kybernetisch hat, also die Ressourcen und so weiter. Und klar, wenn ich dann ein. Dann bin ich da flexibel.

Also wenn du Helm benutzt, bist du da flexibel und hast quasi den ganzen Steg aus dem Vendor Lock in herausgezogen. Genau hier. Das heißt also, das ist ja wirklich toll, diese drei Komponenten oder softer Komponenten, die auch frei verfügbar sind in Kombination binnen Minuten hab ich quasi aus STANDARD Servern hab ich ein komplettes System aufgesetzt. Ich hab meine Infrastruktur pro Visionär. Ich hab mein kybernetisch klasse laufen plus ich habe meine kubanisches Anwendungen laufen und kann zu Testzwecken ja ganz beliebig diese Infrastruktur binnen Minuten hoch und runter fahren.

Kann Updates einspielen, kann Roll backs durchführen. Das hast du eben schon angesprochen, dass Helmut Shard selber dient. Natürlich auch. Jetzt muss man sagen für Entwickler auch als eine Art Dokumentation der Anwendung, weil ja genau beschrieben ist, was hängt von welchen Komponenten ab, welche Ports kommunizieren miteinander. Alleine das hat ja schon ein Wert, dass man sozusagen eine Anwendungs Dependency Graw generieren kann. Aus dem Hemd Shard. Ich weiß nicht. Gibt es da ein Kommando, dass man es irgendwie visualisieren kann?

Deshalb gute Frage. Das weiß ich tatsächlich gar nicht. Aber wie du schon sagst, das ist ein enormer Vorteil, den ich auch immer wieder gerne kommuniziere. Dass man eben durch das Coden von Schritten, die man durchführen muss, im Prinzip die Dokumentation überflüssig macht und auch damit eigentlich Fehler beseitigt. Wenn jetzt Sachen manuell durchgeführt werden, dann können immer Fehler entstehen. Man muss jemanden da haben, der aktiv zur Seite steht, mit dem Kopf da ist und wenn man das eben einfach automatisiert hat, sowohl mit Tera Form an.

Simple aber auch eben helfen könne einen dieser Fehler nicht so schnell unterlaufen.

Um ein plastisches Beispiel zu geben Stell dir mal vor, du bist verantwortlich für den sagen wir mal für den Server oder für die Helm Anwendung, die hier die Server betreibt, wo jeden Tag 20 Millionen Leute die Liste der Coruña infizierten runterlädt. Also das Beckhams sozusagen verdienender Corona Server. Und du würdest jetzt feststellen oh, die Anwendung wird sehr oft aus den App-Stores geladen. Ich muss irgendwie hoch skalieren. Das wäre eine relativ einfache Änderung. Würdest du das dann im @Helmut Chat mittels Reply CAS ändern oder was genau würdest du da einstellen?

Lustigerweise ist das Coruña App oder Coruña Waren App Server Beispiel eigentlich ziemlich gut, weil man da mehrere Komponenten drin hat. Zum einen Documentation. Wenn ich jetzt meine Heimat Charts publiziere einem Ghetto Chopra Satori Open Source, dann kann jeder sehen was läuft da eigentlich? Wie ist die Infrastruktur aufgesetzt? Wo läuft das Ganze? Und das hilft halt wirklich dann auch bei der Dokumentation, dass der Punkt 1, wie du sagst. Dadurch, dass ich dann mit meinen Templates eben diesen Replika Faktor einfach schnell hochsetzen kann, kann ich dann auch super schnell reagieren auf irgendwelche Anfragen.

Der Anstieg von Anfragen gut kybernetisch macht das natürlich auch schon mittels Autos Gayle. Aber wenn man jetzt in die Richtung geht, dass man mehrere Standorte hat, also eine globale Applikation hat, dann kann ich halt auch wirklich sagen Hey, wir haben jetzt einen neuen Markt irgendwo in Asian Pacific Area, dann kann ich einfach sagen So, da fangen wir jetzt an und da brauche ich jetzt ein Rechenzentrum und da hilft mir halt sowohl Theaterformen für die Infrastruktur, aber auch ha’m, vor allem, weil ich eben meine Applikationen in Minuten ausrollen kann oder eher Sekunden.

Ja, ich glaube auch an ein anderes gutes Beispiel ist, wenn ein ganz verbreiteter Messenger für Mobilfunk, Geräte oder für Smartphones seine Policy, seine Daten Policy ändert und auf einmal die anderen Messenger einen immensen Nutzer Ansturm zu verzeichnen haben. Das wäre auch so eine Situation, die in klassischen Server Umgebungen oh Gott, jetzt muss ich Server bestellen und die Immi mieten. Okay, ich bin in der Cloud, das heißt, ich kann in ein paar Klicks hinzufügen, aber das möchte man eigentlich auch nicht.

Man möchte im Grunde eine Anwendung so resilient implementiert haben, dass sie von selber, wenn sie wächst mehr Server Kapazitäten WIP mit kybernetisch mit Autos galligen automatisch sich beschafft bis zu einem gewissen Schwellwert.

Naja, das ist definitiv ein Vorteil. Ja und das ist dann eben ne kybernetisch Funktion bzw. in Helm selber kann man ja auch darauf Einfluss nehmen. Ja also wenn man zwei Beispiele genannt der Coruña ERP Listen Server und die anmeldest Server für Smartphone Messenger. Das ist natürlich auch eine Unternehmenskunden, die uns zuhören. Interessant wenn sie Nutzer Ansturm haben bei gewissen ich sag mal Black Friday Verkäufen oder Medienberichterstattung zu einem Unternehmen oder wenn Marketingkampagne laufen, wo halt in kurzer Zeit viele Kunden die Angebote nutzen.

Oder ein jüngstes Beispiel aus der vergangenen Woche, wo teilweise Server von Brokern Probleme hatten, weil eben ganz viele Aktien gehandelt werden auf einen Schlag. Da kann man dann gegenhalten.

Auf jeden Fall. Das hilft halt einfach schnell zu reagieren, weil ich eben dann nicht manuell. Irgendwelche Schritte einleiten muss, meinen Experten, der dann vielleicht im Urlaub ist, irgendwie ans Telefon kriegen muss. Sondern ich habe eben einfach die Dokumentation mehr oder weniger da und eben kann ich auch einfach Änderungen vornehmen direkt im Code, muss nicht mal irgendwo groß rum klicken, sondern ich mach das halt wirklich genau an der Stelle, wo ich brauch. Und da es so einfach ist, kann das natürlich auch automatisiert passieren, also direkt vom Computer.

Bevor wir jetzt noch auf weitere Details von Helmut Charts eingehen, würde ich dich noch fragen. Gerne zu deinem Erfahrungsschatz. Und zwar ist es deiner Erfahrung nach so, dass Firmen eher anfangen, neue Anwendungen auf Kuba nettes zu entwickeln und dann auch direkt zu @Helmut Charts zu erstellen? Oder werden auch viele Bestands Anwendungen also vielleicht alte Monolithen, die jetzt noch nicht so dem Mikroskops Paradigma folgen auch in Kuba Annettes Pakete verpackt und dann auch mit Helm Charts ausgerollt? Wie ist da deine Praxiserfahrung?

Also meine Praxiserfahrung ist eigentlich fast immer das gleiche und zwar dieses ganze Klout Thema kommt ja auf die Firmen zu und die wissen auch, dass die da was tun müssen. Die meisten haben kurz vor 12, also da ist das wirklich ein heißes Thema. Und da dann meistens auch relativ viel Funding in der Region dann zur Verfügung gestellt wird, passiert das doch meistens, dass Anwendungen grundsätzlich nochmal neu überdacht werden und dann auch eben der Microservices Ansatz umgesetzt wird, weil man eben, wenn man sowieso alles umzieht.

In diesem alten monolithischen Umfeld hat man natürlich seine großen Anwendungen irgendwo auf dem Server, der von irgendwem mit Hand konfiguriert wurde und wahrscheinlich irgendwo ne ganz dicke Dokumentation auf dem Schreibtisch liegt. Und da jetzt zu sagen Okay, ich hole das jetzt alles in die Cloud, das ist sowieso Arbeit. Und dann überlegen sich die Unternehmen meistens, dass es dann sinnvoller ist, das Ganze sowieso direkt schon um zu design, weil diese großen monolithischen Anwendungen haben ja auch was Skalierung betrifft Probleme.

Die sind meistens auch überhaupt nicht dafür gebaut, Verteil zu laufen. Und diese ganzen Cloud Native Komponenten API, Gate, Boyce und allen möglichen Sachen wären da gar nicht wirklich gut eingebunden. Wobei, wenn man dann nochmal wirklich sich anguckt, was gibt’s heutzutage für Frameworks, was ist der Stand der Dinge, dann kann man da seine Applikationen schön direkt Cloud Native neu designen. Und das ist auch das, was ich zurzeit hauptsächlich beobachte dass der Schritt eben auch direkt gemacht wird und die Applikation neu Design wird.

Man hat ja auch aus seinen Fehlern gelernt. Man weiß, wo sind die Schwachpunkte und manchmal sind das ja wirklich grundlegende Sachen, wo halt die Struktur von dem alten System einfach nicht so richtig passt.

Ja, genau, also das ist auch meine Erfahrung. Die alten Systeme funktionieren ja irgendwie, sonst wären sie ja nicht mehr da. Die lässt man vielleicht noch einfach weiterlaufen und steckt da gar nicht so viel Liebe rein. Aber wenn zukünftige Anwendungen entwickelt werden, benutzt man natürlich die neuen Technologien oder erweitert die alten Technologien um eine Komponente, die dann eben schon in der Cloud läuft. So ist auch meine Erfahrung. Also ich habe auch noch nicht gesehen, dass man Monolithen eins zu eins einpackt und dann in Kybernetisch betreibt.

Das wäre sicher auch dann ungünstig.

Ja, da hat sich einfach sehr viel getan, jetzt auch in der letzten Zeit. Wie einfach Applikationen strukturiert werden und implementiert werden, also gerade Sachen Richtung Datenspeicher und so in der Cloud geht man halt nicht davon aus, dass man immer so lokal seinen Speicher direkt bei der Anwendungs Logik hat, sondern geht da dann eher hin und benutzt externe Komponenten. Es kann ja auch eine skalierbare Datenbank sein, die auch im Cluster läuft. Aber eben dadurch, dass alles fein Granularität strukturiert ist, kann ich eben auch beliebig hoch und runter skalieren, so eben wie die Funktion benutzt werden von der Anwendung.

Lass uns doch nochmal etwas ins Detail gehen und nochmal genau besprechen, wie ein Helm Shard genau zusammengebaut wird oder wie das funktioniert. Möchte uns da kurz mit an die Hand nehmen, um das einfach mal strukturiert nochmal von Anfang bis Ende kurz zusammenzufassen, weil wir haben ja jetzt schon hier und da das Thema mal angeschnitten.

Ja, also das Hemd Shard ist eigentlich ein Wandel aus verschiedenen Dateien. Und die Haupt Datei ist eben dieser Chat dort Jamel, die eben dann einfach nur grunt information über das Chat enthält wie jetzt den Namen Version Abhängigkeiten. Und weiter gehts dann eben mit dem Templates Folder. Das ist so standardisiert der Ordner, der eben diese ganzen kybernetisch Ressourcen beinhaltet. PM nimmt dann einfach alles in dem Ordner und Diplomat das ins Cluster. Das heißt, wenn ich ein Pfeil da drin habe was überhaupt nicht ein Template ist, was einfach nur eine kybernetisch Ressource ist, dann wird hier auch genauso im Cluster ausgerollt.

Dann kann ich natürlich keine Konfiguration Änderungen machen mittels variabel, aber manchmal ist das ja auch gewollt. Dann die des Template Ding selbst. Das funktioniert eben mit diesen Gol Templates und alle goh lang internen Funktionen Template Funktionen sind abgebildet. Also wenn man da in der Sprache schon ein bisschen Erfahrung hat, hilft das natürlich immens. Aber Heimat auch noch weitere. Funktion hinzugefügt, dies dann leicht machen eigentlich alles mögliche zu Templeton, was Person nur Beispiel Funktionen, die man nutzt.

Also ich hab jetzt noch nicht viel mit Go lang gemacht, aber gibt es vielleicht eine funktionierende häufiger nutzt und die dir hierzu direkt einfällt?

Ja, also es gibt verschiedene Möglichkeiten, aber es gibt ja auch bestimmte Anwendungen. Wollen ja auch irgendeinen random character String haben, z.B. um krypto grafische Strukturen zu initialisieren.

Und da könnte man dann jetzt einfach in dem hammerhart sagen Gib mir random alpha numerische Ziffern generieren er ID oder sowas und das ist mein zaehlt für irgendwie eine Verschlüsselung Funktion, oder?

Genau das wäre jetzt ein Beispiel. Ich meine, ähnlich würde es oft auch mit Passwörtern gemacht, die eben nur Admin Passwörter für irgendwelche Datenbanken, die nur innerhalb des Clusters einem Sekrete sein sollen. Und da will man das Passwort ja explizit auch randomisiert haben. Das heißt, dass man halt gar nicht erst irgendwie eine Schwachstelle hat, wo irgendwer das Passwort kennt zu irgendeiner Datenbank, sondern das wird einfach direkt alles innerhalb des Clusters abgespeichert und keiner braucht da Zugang zu genau bei den Templates.

Ist vielleicht noch interessant für die, die da jetzt noch nicht so mächtig sind. Mit der Jamel Syntax ist natürlich empfohlen, das in Jamel zu machen. Das wird ja in vielen anderen Bereichen auch verwendet, weil das eben so schön lesbar ist. Aber für die, die’s Probleme macht Jamil ist ja eine obere Menge von Jason, also jede valide Jason Struktur ist natürlich gleichzeitig eine valide Jamel Struktur. Das erlaubt mir dann auch Jamil zu schreiben und wenn ich mal nicht weiterkommen.

Kurz die Ressource oder die Struktur eben in Jason darzustellen. Das wird ganz normal dann verwendet von Ham wie jedes andere Jamil und ja, funktioniert auch so was dann vielleicht noch interessant ist, ist das Beliefs. Das hatten wir schon ein paarmal ein bisschen angerissen. Hier nochmal explizit das ist eben ein Fall, was einfach Variablen definiert. Alles, was ich in dem Chart konfigurieren kann, kann ich in diesem Various Fall anpassen. Das heißt, ich kann dann eben, wie wir schon vorher gesagt haben, die Replika aus einer Anwendung anpassen und ich kann eben auch verschiedene Valerius Fails für verschiedene in Wassermanns benutzen.

Das heißt, wenn ich jetzt z.B. einen Gegenpol Süd-Korea kann ich auf jedem Bronstein auch ein unterschiedliches Belgiers Fall ablegen. Wenn es jetzt Development ist, was dann in die Test in Valmont geprobt wird, will ich da vielleicht andere Werte, andere Hoch Verfügbarkeit Werte haben als jetzt bei Produktion in Wahrnehmens.

Ich könnte auch Suchtest Nutzernamen da unterbringen. Dann heißt der User auf Test heißt der User minus test und auf in der Produktion wird er ganz weggelassen.

Wo solche Geschichten dafür wäre das welches Faltern da genau das Beliefs Fall ist natürlich auch wenn ich mir jetzt irgendwie von extern eine Ressource rein hole. Wenn ich jetzt z.B. einen Promi fürs Monitoring aufsetze, dann ist das Fall eigentlich die einzige Komponente, die ich mir dann auch selber privat abspeichern muss in meinem Git Repository, wo ich meine Changes Tracker, weil ich im Prinzip mit dem Chat dann direkt gar nichts zu tun habe. Ich passe nur dann Sachen an wie jetzt wie viel Speicher klemme ich, damit eben bestimmte Metriken abgespeichert werden und so weiter.

Und das ist alles was, was ich einfach bei mir in dem Delius enda aber grundsätzlich die Templates des Shard, das fasse ich gar nicht an, weil wenn da dann Änderungen Fixes eingespielt werden, dann werden die halt auch eben mit jedem Upgrade dann automatisch ausgerollt.

Das heißt, ich hab jetzt das Hemd Shard zusammengebaut mit Radius Jamil Templates, TV-Gelder, Charts, Jamil hab das auf der Festplatte oder es ist ne sollte ich lieber sagen. Und wie installiere ich das jetzt? Also ich hab die Anwendung da orchestriert in dem Helm Chart. Und wie schafft die Anwendung es jetzt in den Kybernetisch Cluster?

Also ganz konkret passiert das eigentlich mit Helm in Stowe und dann kann ich dem eben mit Minus ein Wadephul geben und dann gebe ich dem ganzen noch einen Release Namen. Den kann ich mir eigentlich mehr oder weniger aussuchen und dann bestimme ich halt noch welches Chart das ist. Das kann natürlich ein externes sein. Da sage ich dann bei einem Engine X z.B. Vietnam Nami Schrägstrich Engine X, also aus dem Vietnam Repository, dass Engine X Chart und dann wird das direkt installiert.

Also dann werden die Schritte eingeleitet, dass im Prinzip alle Abhängigkeiten und alles installiert werden in dem Cluster. Wenn ich jetzt natürlich das Ganze schon am Laufen hab, dann würde ich nicht mehr ins Stäube nutzen, weil Naniten. Steul schlägt fehl. Ein Stall ist nicht wieder impotent, sondern das Install ist ein mehr oder weniger imperatives Kommando, was halt einfach die Installation vornimmt. Normalerweise benutzt man tatsächlich Helme Upgrade und ich benutze eigentlich am liebsten Helme Upgrade minus AI, was soviel heißt wie machen Upgrade und wenn nichts da ist installierst.

Also dieses Kommando ist sozusagen alles in allem. Das Shard wird installiert, wenn es nicht da ist. Und ja, das ist auch das, was man dann eigentlich in Çiçek Scripte oder. Wo bei Automation einbaut, weil das eben diese idem Potenz hat. Okay, verstehe. Das heißt, man braucht sich im Grunde nur ein Kommando zu merken Upgrade minus ai oder minus y und Trends nicht installiert. Es wird die Anwendung installiert in der Version und wenn sie bereits installiert ist in der gleichen Version wird nichts gemacht, außer das Toyo Release Nummer instrumentiert wird und wenn die Anwendung installiert ist in einer vorherigen Version wird auf die aktuelle Version gab geredet.

Genau. Also es gibt natürlich dann auch Advanced Sachen, also haben unterstützt auch Semantic Versionen. Aber also da kann man dann die Release Nummer entsprechend anpassen. Aber das sind dann Sachen, die relativ Fettwanst sind.

Für jeden der jetzt kurz nach einer Anwendung erstmal die Pointe reicht das auch erstmal so dann die Unterschiede zwischen der Helm Version 2 mit dem Tilla Server, der sozusagen im Kybernetisch Cluster läuft und alle Aktionen durchführt und der Version 3, die mittels Airbag auf die ihr zugewiesenen rechte Bereiche zugreifen kann, um die Aktionen durchzuführen. Da bist du ja schon drauf eingegangen. Wie verbreitet ist Helm denn und lohnt es sich das genauer unter die Lupe zu nehmen? Ich glaube da haben wir fast schon eine Antwort gegeben im Verlaufe des Podcast.

Aber vielleicht fassen das nochmal zusammen.

Ja klar. Also das ist auch wirklich haben wir die Sache ganz am Anfang ja angerissen, dass Helme einfach extrem an Popularität zugenommen hat. Also es ist einfach inzwischen auch Grundlage für viele andere Systeme. Also im Ranga Rangiere ist ein Overlay über ein kybernetisch Cluster und das vereinfacht einfach die Verwaltung von kybernetisch Clustern. Da gibt’s ne schicke Joi, wo man das alles verwalten kann und da gibt’s eben auch einen Katalog.

Also das ist im Prinzip wie so eine App Store voll Kybernetiker und der basiert natürlich auf Helme und andere Bonnard sozusagen unter der Motorhaube im Hintergrund.

Genau da läuft dann natürlich Helm ganz normal und da sind auch die offiziellen Helme Repositories. Dann weiter geht’s ja dann noch, das geht ob’s Tool Flachs, Version 2 und das benutzt auch Helm Charts für Deployment. Also das Richtige ist hier natürlich die Version 2, weil da hat sich ja viel geändert zur Version 1, aber das ist so ein Get up Stuhl, wo man eben seine ganze Infrastruktur und Deployment alles entgeht, Repositories hat und Flachs bildet. Die Brücke zwischen den Geth Repositories und der Infrastruktur also ist guckt einfach aktiv.

Hab ich Änderungen in den Geth Repositories? Wenn ja, dann führt das eben die nötigen Kommandos aus. Also sozusagen das Scripten von Ham Upgrade.

Das finde ich richtig cool, muss ich mal sagen. An der Stelle du hast Watcher auf dein Git Repository yum, der bei Änderungen losgeht und dein kybernetisch cluster Status aktualisiert oder updated. Also das ist schon SII ICD auf höchstem Niveau finde ich persönlich es auf jeden Fall.

Das ist für mich auch so der letzte Schritt, der eigentlich alles zusammen packt. Dann war man hat natürlich das Problem, dass die Akzeptanz von Infrastructure oder auch Konfiguration oder sonst was. Ascot halt immer ein bisschen unterschiedlich ist. Es gibt ja auch gewisse Kollegen, die dann auch doch Änderungen manuell vornehmen. Wenn dann wirklich die Hütte brennt, dann hat man manchmal auch das Gefühl, jetzt hier in den Code zu gehen, das zu ändern, das zu Kometen Commit Message zu schreiben, zu pushen, dann wieder nicht woanders einzuloggen, eine Pipeline zu triggern oder sonst was.

Da haben viele dann irgendwie das Gefühl, wenn dann wirklich mal was los ist, dass das zu lange dauert. Und dann kann es schnell passieren, dass der Zustand, in dem geht Repository und in der Infrastruktur divergieren. Und soweit ich da bin, wird’s wirklich kompliziert. Das Schöne ist beim flachst, dass ich den Benutzern gar nicht mehr die Möglichkeit geben muss, manuell Sachen zu ändern. Bei jeder oder jeder. Der muss hat Zugang zu den Repositories und kann da einfach seine Änderungen machen.

Und das wird dann einfach im Hintergrund automatisch auf die Infrastruktur ausgerollt.

Ich sehe da noch einen ganz anderen Vorteil und zwar bis flux. Ja, so eine Art erweiterter Commit Hook. Das heißt, ich weiß, wenn ich mein Kotaku Mitte und auf Master Merge oder auf einen Release Branch merge, der wird dann automatisch Diplomat. So und das auf Entwickler Seite erzeugt dann eine Art erhöhtes Qualitäts Gefühl. Lass mich das nochmal sagen. Ich glaube auch, dass Flags und die Konsequenz daraus, dass wenn ich etwas Kommittee und auf den Master Branch merge, dass das automatisch Diplomat wird.

Das führt dazu, dass man das Testing noch ernster nimmt und noch mehr Tests schreibt, um einfach zu sagen Okay, wenn ich das jetzt hier committee, kontrolliert das kein Mensch mehr, sondern es wird wirklich produktiv ausgerollt. Wenn man das möchte und so einstellt. Und ja, das ist eigentlich eine gute Sache, dass man im Prinzip dann noch mehr Tests schreibt oder die Tests nochmal gründlicher checkt. Manuel checkt, um zu sagen Das muss ja alles Test Bar sein, sonst kann es sein, dass sich vorne was kaputt mache.

Das hilft auf jeden Fall dabei. Und das hilft natürlich auch der. Die Akzeptanz, also, dass Änderungen dann auch wirklich zur Infrastruktur kommen. Die Zeit ist einfach geringer, weil ich weiß, sobald ich was da rein packe, ich muss niemand Bescheid sagen, ich muss keinem sagen Hey, ich hab hier wieder eine Änderung. Roll das doch mal bitte auf die Infrastruktur aus, sondern das passiert dann einfach. Und das ermöglicht natürlich auch wiederum ganz andere Reaktionen bei den Entwicklern, weil die natürlich ihre Changes instant auf der Infrastruktur haben und einfach die Anwender profitieren ja auch ganz deutlich.

Da ein fertig gestelltes Feature ja schneller ist, in die Produktion schafft und schneller dann auch aktiv genutzt werden kann, von den entweder ein Nutzer da draußen oder den Unternehmens Benutzern. Das möchte man ja auch, dass man die Time to Market würde man im BWL Kontext sagen ich sag mal code to user time möglichst gering hält. Auch als Entwickler ist es ja möglichst erstrebenswert, dass wenn doch noch Probleme oder Rückfragen kommen, dass man die möglichst zeitlich nahe zur Implementierung dann erhält und nicht Monate später, wenn man sich dann nochmal eindecken muss.

Unser Muss. Okay, was war denn jetzt nochmal genau Sachstand da?

Okay Julius, vielen, vielen Dank für die intensiven Einblicke in das Ökosystem von Helm Kybernetisch Terraforming. Es hat mich super gefreut.

Sehr gerne, ja. Mich hat es auch gefreut, dabei zu sein. Vielleicht nochmal einen kleinen TISA am Ende. Was natürlich möglich macht, es in Verbindung mit anderen Tools auch komplexe Deployment Strategien umzusetzen, also z.B. Canary Deployment oder Blue Green Deployment. Bei Canary Deployment würde ich halten Feature erstmal an eine kleine Gruppe von Leuten ausrollen und dann testen wie reagieren die da drauf? Ist die Responses Zeit von dem User? Also wie lange braucht der User durch die Seite zu browsen?

Ist die schneller? Ist die langsamer? Wird das UI plötzlich verwirrend oder wird das eindeutiger für den Benutzer? Und dann kann ich Stück für Stück das halt als Produktions STANDARD haben. Und bei Blue Green ist eben dieser Situation, dass ich im Prinzip meinen Production impliziere und meine neue Version in ein zweites Produktion in Valmont, die Pleuger und dann eben einfach den Traffic komplett von dem einen Production in das andere Router und so halt dann auch ohne irgendeine Art Downtime halt einfach um switchen kann auf eine andere Version und Tools wie jetzt zum Beispiel ist Théo, die helfen mit Helm zusammen ebenso Sachen automatisiert umzusetzen und sowas ist natürlich Next Level.

Also das ist wirklich advanced. Aber das ist auch das, was man wirklich braucht, wenn man Ansprüche an Verfügbarkeit hat und Automatisierungsgrad.

Wenn unsere Zohra eine Frage haben oder Feedback zur aktuellen Episode, freuen wir uns über eine E-Mail an Podcast Skill bei Gilbert. Wir freuen uns immer über Bewertungen des Podcasts und natürlich Weiterempfehlung an eure Freunde und Kollegen. Das ist ganz ganz wichtig, wenn ihr die Podcast Episoden und die Inhalte als wertvoll erachtet. Empfehlt den Podcast gerne an Freunde und Kollegen. Weiter schaut Rolfs Gilbert de Slash Blog vorbei für weitere spannende Technologie Themen. Vielen Dank Julius für die Einblicke in Helm.

Und bis bald.

Bis bald.

Maurice KnoppSkillbyte Podcast #43: Helm – Der Kubernetes Paketmanager
Mehr

Skillbyte Podcast #42: IT-Aufgaben richtig outsourcen (Design, Entwicklung, Support)

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

In diesem Podcast geht es um das Thema: IT-Aufgaben richtig outsourcen (Design, Entwicklung, Support)

// Inhalt //
01:14 – Definition: IT-Outsourcing
03:06 – Typische IT-Outsourcing Aufgaben
03:54 – Vorteile von IT-Outsourcing
04:26 – Warum ist IT-Outsourcing relevant? – Erfahrungsberichte aus der Praxis
10:23 – Saubere Kommunikation ist der Schlüssel für erfolgreiches Outsourcing
14:30 – Vorgehen für erfolgreiches IT-Outsourcing
15:17 – IT-Outsourcing Schnittstelle schwierig zu besetzen
16:18 – Erfahrungsberichte & Vorgehen für erfolgreiches Outsourcing
22:30 – Systembetrieb erfolgreich outsourcen
28:11 – Welche Plattformen gibt es?
30:09 – IT-Outsourcing Fails
37:09 – IT-Outsourcing Success Stories
41:06 – IT-Outsourcing is here to stay

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

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #42: IT-Aufgaben richtig outsourcen (Design, Entwicklung, Support)
Mehr

Skillbyte Podcast #36: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service (IaaS) Werkzeug

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

In diesem Podcast geht es um das Thema: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service (IaaS) Werkzeug

// Inhalt //
01:10 – Definition: Was ist Terraform? Was leistet die Software?
06:23 – Software eats Hardware -> Infrastructure as a Service
07:42 – Welches Problem löst Terraform und wie erfolgt der Einsatz?
08:40 – So sieht ein typisches Terraform Projekt aus
11:53 – Der Terraform State – am besten remote in der Cloud
16:18 – Vorteile von Terraform
16:28 – Vorteil: Infrastructure as Code / Versionierbar in GIT
16:48 – Vorteil: Infrastrukturänderungen können sofort getestet werden
17:12 – Vorteil: Integration in CI/CD Pipeline
17:50 – Vorteil: Zentrale Infrastrukturpakete /-module
20:11 – Vorteil: Buildserver kann Terraform ausführen
20:44 – Vorteil: Portierbarkeit zwischen Cloudplattformen
23:22 – Nachteile von Terraform (Funktionsgrenzen, Cloud Limits)
23:30 – Nachteil: keine Einheitliche Benamung bei unterschiedlichen Providern; unvollständige Dokumentation
26:20 – Detaileinrichtung von VMs benötigt weitere Werkezuge (Ansible, Puppet, Chef)
27:48 – Vorteil: Kubernetes Umgebungen können mit Terraform provisioniert werden
28:35 – Nachteil: Proprietäre Cloud Features via Terraform nicht oder später verfügbar
31:48 – Nachteil: Abstraktionsschichten erhöhen immer die Komplexität
32:47 – Vorteile: Infrastruktur versionierbar, kurzfristige Wartezeit auf Ressourcen, Rückgabe nicht verwendeter Ressourcen, große Community
34:17 – Variablen in Terraform Templates für unterschiedliche Umgebungen
35:54 – Terraform Graph: stets aktuelle Dokumentation der Infrastruktur

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

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #36: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service (IaaS) Werkzeug
Mehr