CI/CD

Skillbyte Podcast #48: Grundkenntnisse und Skills für ALLE IT-Fachkräfte

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

In diesem Podcast geht es um das Thema: Grundkenntnisse und Skills für ALLE IT-Fachkräfte

// Inhalt //
01:29 – Was euch die Hochschule NICHT beibringt…

02:59 – Themenkomplex: Datenhaltung und -verwaltung
03:34 – SQL – Structured Query Language bei relationalen Datenbanken
05:53 – NoSQL – Not only SQL bei schemafreien Datenbanken
07:02 – Hashtabelle / HashMap
08:23 – häufige Datenvormate: JSON, YAML, CSV
10:37 – Zusammenfassung: Datenhaltung und -verwaltung

10:49 – Themenkomplex: Netze und Protokolle
11:13 – IP Adressen und -netze, Ports, NAT, Router, Gateway, TCP/UDP, Routing, Datenpakete, Firewalls
14:20 – HTTP Protokoll inkl. Status Codes und Zertifikaten für HTTPS
15:19 – REST APIs

16:13 – Themenkomplex: Systeme und Plattformen
16:25 – Linux, Kommandozeile / CLI (Bash), vi, nano, SSH, scp
18:46 – Docker, virtuelle Maschinen
19:35 – Cloud computing, Dienste und Orchestrierung dieser
21:06 – Cloud Native Software Development

23:00 – Themenkomplex: Arbeit mit Sourcode
23:09 – Code Versioning: GIT (branching, merging, rebasing), github.com, gitlab.com
25:17 – Integration von CI/CD Pipelines, GitHub Actions, Gitlab CI/CD (gitlab-ci-yml)

26:14 – Themenkomplex: Debugging
26:19 – Logdateien lesen
27:48 – Debugger konfigurieren und einsetzen

30:06 – Themenkomplex: Produktivität & Zielorientierung

32:45 – Zusammenfassung aller Themengebiete
34:21 – Podcastempfehlungen zur Vertiefung

// Weiterführende Episoden je nach Schwerpunkt //

Podcast #9: Bull’s Eye Software Development – Einfach und fokussiert auf Unternehmensziele
https://soundcloud.com/skillbyte/podcast-9-bulls-eye-software-development-einfach-und-fokussiert-auf-
unternehmensziele

Podcast #8: Must-have Skills, Technologien und Weiterbildung für DevOps
https://soundcloud.com/skillbyte/podcast-8-must-have-skills-technologien-und-weiterbildung-fur-devops

Podcast #7: Must-have Skills, Technologien und Weiterbildung für Data Engineers und Data Scientists
https://soundcloud.com/skillbyte/skillbyte-podcast-7-must-have-skills-technologien-und-weiterbildung-
3fur-data-engineers-und-data-scientists

Podcast #6: Must-have Skills, Technologien und Weiterbildung für Full-Stack Entwickler
https://soundcloud.com/skillbyte/skillbyte-podcast-6-must-have-skills-technologien-und-weiterbildung-
fur-full-stack-entwickler

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

// Weiterführende Blogposts mit mehr Informationen //

Tutorial: IT-Basiswissen für DevOps, Big Data, Developer
https://www.skillbyte.de/tutorial-it-basiswissen-fuer-devops-big-data-developer/

Onboarding neuer IT-Mitarbeiter (DevOps, Big Data, Developer)
https://www.skillbyte.de/onboarding-neuer-it-mitarbeiter-devops-big-data-developer/

Must-have Ressourcen, Skills und Techniken für Data Engineers und Data Scientists
https://www.skillbyte.de/must-have-ressourcen-skills-und-techniken-fuer-data-engineers-und-data-scientists/

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Okay, ich habe jetzt meine Hochschule oder meine Ausbildung abgeschlossen. Was wird denn jetzt tatsächlich von Firmen im Alltag gefordert? Diese Skills werden oft an den Unis vernachlässigt, sind aber ganz relevant für den Berufsalltag, für die Berufspraxis. Wenn ihr mit Kollegen zusammenarbeitet.

Herzlich Willkommen zur Gewalt Podcast Episode Nr. Achtundvierzig Grundkenntnisse und Skills für alle IT-Fachkräfte Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld, wenn er IT Entscheider oder die Fachkraft seid. Wenn ihr eine Frage habt, sendet uns gerne eine E-Mail an Podcast Amtsgewalt D Wir freuen uns immer über Bewertungen und ganz besonders an Weiterempfehlung dieses Podcasts, an Freunde und Kollegen, die sich ebenfalls für diese Themen interessieren. Das ist uns ganz wichtig.

Und heute möchte ich darüber sprechen, welche Grundkenntnisse und Grundfähigkeiten denn für alle IT-Fachkräfte wichtig sind. Gerade wenn ihr vor dem Berufseinstieg steht und euch fragt Okay, ich habe jetzt meine Hochschule oder meine Ausbildung abgeschlossen, was wird denn jetzt tatsächlich von Firmen im Alltag gefordert? Und hier ist mir ganz wichtig, dass ich Themen anspreche, diese Wohlfühl Softwareentwickler, Admins, DevOps, Data Engineers von Belang sind und die für alle diese Berufsgruppen wichtig sind. Diese Skills werden oft an den Unis vernachlässigt, sind aber ganz relevant für den Berufsalltag, für die Berufspraxis.

Wenn ihr mit Kollegen zusammenarbeitet und häufig ist es so, dass das so Grundfähigkeiten sind, die euch dann auch niemand mehr so richtig erklären möchte, weil das einfach so ein Brot und Butter Geschäft ist, dass ihr das am besten dann zuhause nachliest oder die Kollegen schon mit den Augenrollen, wenn so eine Frage gestellt wird. Davor möchte ich euch bewahren und einfach ein paar Denkanstöße geben, paar Themen geben, die ja durcharbeiten könnt, wo ihr euch mit beschäftigen könnt und dann voll in den Berufseinstieg glänzen könnt und dadurch starten könnt.

Was befähigt mich dazu? Ich bin seit über 16 Jahren Softwareentwickler und seit über acht Jahren in der IT Beratung tätig, habe also schon viele Unternehmen gesehen und viele Projekte durchgeführt und habe dadurch einen breiten Erfahrungsschatz aufgebaut und sehe dann immer das neue Ankömmlinge Junior Entwickler Junior Dev Orbs Junior Atmens oft die gleichen Fragen haben, die mit einer Woche oder zwei Wochen Vorbereitung zu klären wären und wo man dann einen viel besseren Einstieg ins Berufsleben finden würde. Also vielleicht wenn ihr Einsteiger seid, sendet ihr euren Kommilitonen auch diese Podcast Episode und macht es euch sehr viel einfacher direkt erfolgreich ins Berufsleben einzusteigen.

Ich freue mich auf jeden Fall und wenn ihr Fragen habt. Wie eingangs erwähnt, schick mir gerne eine E-Mail, wenn ich ein Thema vergessen habe. Eurer Meinung nach sendet meine E-Mail an Podcast beide Punkte. Das erste Thema, wobei ich heute sprechen möchte, beschäftigt sich mit der Datenhaltung und Verwaltung. Ihr könnt euch ein Computersystem so vorstellen, dass es sich im Grunde um einen Datentyp handelt oder um mehrere Daten Zöpfe, um die drumherum Code gebaut wird. Also Decode nimmt die Daten, die in einer Eingangs Struktur vorliegen.

Das kann ein Bild sein und konvertiert diese Daten in ein anderes Format, ein Video, ein Bilder, Album usw.. Also im Grunde ist es immer so ihr habt Daten und der Computer Code macht etwas mit diesen Daten, transformiert diese Daten und gerade wenn es um das Thema Datenhaltung geht auch heute noch spielen relationale Datenbanken. Das sind Datenbanken wie Maria DB, My, SQL PostgreSQL, auch Oracle oder MS SQL eine große Rolle. Und alle diese Datenbanken werden über die STANDARD Abfrage Sprache SQL abgefragt.

Und egal in welchen Projekten, dieser SQL STANDARD wird euch immer wieder über den Weg laufen. Das ist auf jeden Fall eine Fähigkeit, die ihr brauchen werdet. In eurem Berufsalltag und die an der mannigfaltigen Stellen einsetzbar ist, ist es sogar so, dass neue Technologien, die hinzukommen z.B. wenn man an die Haddock Daten Platform denkt, die es jetzt auch gar nicht mehr so neu. Dann werden Werkzeuge extra so konzipiert, dass sie auf den vorhandenen SQL Standards aufsetzen können.

Also dass man mit der SQL Sprache, die sehr viele Entwickler bereits können, dann eben auch neue Anwendungsfälle abdecken kann. Also SQL absolut wichtig, um ein paar Beispiele zu geben. Ein paar Select Abfragen auf Tabellen Jeunes sind ganz wichtig. B. Jeune ich Daten zwischen zwei Tabellen Was ist eine Relation? Relation ist im Grunde genommen eine Tabelle. Was ist ein Primärschlüssel? Wie setze ich in die CS? Was für Vorteile haben in die CS? Welche Nachteile haben sie?

Schaut euch mal ihr Diagramme an. Also Entity Relationship Diagramme. Die habt ihr wahrscheinlich im Studium schon gesehen. Die werden auch in der Praxis eingesetzt und letztlich bilden die einfach nur Datenbank Schemas ab. Also an der Stelle nochmal wichtig die SQL Abfrage Sprache ist super wichtig. Schaut euch das an. Macht einfache Kluth abfragen also create read update Lettner fügt was ein, selektiert Ergebnisse, löscht meine Zeile. Update Meine Zeile so als Fingerübung. Da seid ihr auf jeden Fall schon mal gut gewappnet, weil SQL wird ihn mit an Sicherheit grenzender Wahrscheinlichkeit in eurem Berufsleben wieder auftreten.

Hier noch als Erweiterung. Die optionales Wenn ihr das Thema vertiefen wollt, könnt ihr euch auch Objekt relationale Mapper anschauen, sogenannte Ockhams. Hier geht es darum. Programmiersprachen sind häufig objektorientierte und ihr arbeitet mit Objekten. Daten werden aber immer, wenn sie in relationalen Datenbanken liegen, auf Tabellen abgebildet. Das heißt, es sind im Grunde zwei Welten und diese Object relationalen Mapper verbinden diese beiden Welten ist nicht unbedingt Voraussetzung, aber als Erweiterung. Wenn euch das Thema interessiert, würde ich das empfehlen, mal anzuschauen.

Kommt auch sehr häufig vor. Wir befinden uns immer noch in dem Blog Datenhaltung und Verwaltung. Und das zweite Thema, was sehr wichtig ist und was euch im Berufsleben auf jeden Fall über den Weg laufen wird, sind die sogenannten No ASCII Datenbanken wie beispielsweise Mongo DB, No SQL steht hier aber nicht für kein SQL, sondern für Not only SQL und es handelt sich um so genannte Schema freie Datenbanken. Was bedeutet das? Bei den relationalen Datenbanken haben wir schon festgestellt Es gibt Tabellen.

Diese Tabellen haben ein festes Format und alle Daten müssen in diese Tabellen hineinpassen. Bei den Schema freien Datenbanken ist das nicht der Fall. Da könnt euch vorstellen einen Such Index wird häufig mit Schema freien Datenbanken abgebildet und mit Dokumenten, die sich nach und nach erweitern. Also wenn man z.B. ein Dokument hat, das nennt sich Person, dann hat die Person vielleicht Vorname Nachname. Irgendwann kommt ein Führerschein hinzu, irgendwann kommt ein Schulabschluss hinzu, irgendwann heiratet die Person vielleicht und es kommt mir ein Link zu einer anderen Person hinzu.

Und das weiß man vorher alles nicht. Deshalb können die Dokumente in der Datenbank Personen nach und nach erweitert werden. Ohne Schema. Also SQL haben wir, No SQL haben wir, da gehen wir gleich noch genauer drauf ein. Ein weiterer Punkt zur Datenhaltung und Verwaltung, der euch auf jeden Fall begegnen wird, ist die sogenannte Hascht Tabelle oder auf Englisch Hash Map. Schaut euch bitte an, wie funktioniert eine Hash Map? Was für Vorteile habe ich bei der Hash Map?

Was? Eine Hash Map ist einfach eine Datenstruktur, die einen Schlüssel zu einem Wert abbildet. Im Grunde genommen könnt ihr euch vorstellen, ein Schlüssel muss eineindeutig sein wie eine Telefonnummer und der Wert könnte z.B. die Person sein, die hinter der Telefonnummer steckt. Wenn ich jetzt einen neuen Wert mit der gleichen Telefonnummer einfüge in diese Hash Tabelle, dann fällt der alte Wert raus und die neue Referenz. Also sagen wir mal die gleiche Telefonnummer gehört jetzt einer neuen Person, wird dann dort gespeichert.

Der Vorteil von einer hascht Tabelle ist, dass ein sehr schneller Zugriff ermöglicht werden kann, wenn man den Key errät. Wenn man die Telefonnummer weiß, kann man sofort den Namen der Person nachgucken in der O Notation, während er die Zugriffs Zeit würde sich als O von 1 darstellen, was der beste Fall ist und die Hash Tabelle läuft euch sehr sehr häufig über den Weg. Diese Datenstruktur beim Thema Caching, wenn ihr schnellen Zugriff auf Elemente benötigt bei Key Value Stores.

Ein unbekanntes Produkt aus diesem Bereich wäre z.B. Readers. Also schaut euch wirklich an, was ist eine Hash Tabelle? Wie funktioniert die? Gibt’s in allen Programmiersprachen. Macht euch mit dem Konzept vertraut. Das ist ganz wichtig. Als letzten Punkt bei Datenhaltung und Verwaltung möchte ich auf häufige Datenformate eingehen. Also ein häufiges Datenformat ist z.B. Jason Java Skript, Objekt Notation. Das habt ihr bestimmt schon mal gesehen. Das sind einfach abgerollt. Schlüssel, Werte, Kombinationen. Wenn man so möchte, also sucht nach Jason Fall, dann sieht er sofort, was ich meine.

Dieses Dateiformat kommt sehr sehr häufig vor. Und das wird zum Brot und Butter Geschäft während eurer täglichen Arbeitszeit werden bin ich ganz sicher. Ist auch sehr ähnlich beim Zugriff auf Novell SQL Datenbanken. Werdet die Abfragen an diese Datenbanken stellen. Da kommen dann Jason Dokumente zurück, also Jason Objekte zurück, wenn ihr auf irgendwelche Rest APIs zugreift. Da kommen wir gleich noch zu. Wird ebenfalls wie mit Jason Objekten gearbeitet und also an Datenformat. Jason kommt da nicht vorbei.

Wenn ihr nicht wisst was das ist. Schaut es euch an. Macht euch damit vertraut und es ist sehr, sehr wichtig. Ein zweites Datenformat, insbesondere für Konfigurationsdateien ist das sogenannte Jamel Dateiformate.

Jamel und Jason sind austauschbar. Also man kann Jason Datei als Jamil Datei schreiben und eine Jamel Datei als Jason Datei ist ein bisschen der Geschmacksfrage. Jason Dateien werden häufig zur Verwendung von Daten zum Austausch von Daten Objekten verwendet. Jamil Dateien sind oft Konfigurationsdateien, also Latin oder Markup. Länge ist die geschriebene Abkürzung und die neuen Technologien nutzen alle diese Sprache zur Konfiguration. Ein drittes sehr häufig anzutreffen das Dateiformat ist das sogenannte CSV Dateiformat. Häufig liegen Daten Exporte in dem CSV &comma.

Seppl rated beliefs vor. Das könnt euch so vorstellen, dass im Grunde einfach eine Tabelle abgerollt wird und alle Daten mit Kommas getrennt hintereinander geschrieben werden. Und das ermöglicht es auch Systemen, die keine Kenntnis voneinander haben, mit diesen Daten zu arbeiten. Also irgendein System, was mal erstellt wurde, kann Daten in CSV exportieren, z.B. eine Telefonrechnungen und ein anderes System. Was? Einige Jahre später erst danach erzeugt wurde, kann man diese Daten eben wieder einladen. Weil sich beide sind CSV STANDARD halten.

Das wären meine 4 Tipps zum Thema Datenhaltung und Verwaltung. Ich fasse nochmal zusammen SQL Abfrage Sprache superwichtig Der Umgang mit No SQL Datenbanken ist sehr wichtig. Die Funktionsweise einer hascht Tabelle sollte dir kennen und die geläufigsten Datenformate. Mit denen sollte dir auch was anfangen können. Okay, nach Datenhaltung UN-Verwaltung kommen wir jetzt zu dem Block Netze und Protokolle. Das wird einige von euch langweilen, andere von euch, wenn ihr großen Nachholbedarf haben. Das stelle ich immer wieder fest.

Und zwar geht es um nichts weniger als das Verständnis, wie das Internet funktioniert oder spezieller wie TCP IP Netzwerke funktionieren. Was ist eine IP-Adresse? Also ganz genau. Was ist das? Was ist eine IP V4 Adresse? Was ist eine IP V6 Adresse? Warum ist diese Adresse wichtig? Was bezeichnet diese Adresse? Ist diese Adresse änderbar? Wer teilt diese Adressen zu? Wer verwaltet diese Adressen? DHCP In diesem Kontext ist auch wichtig. Alles Stichworte, die er nachgucken könnt und die wichtig sind Ports.

Was ist ein Port? Von einem Service, der auf meinem Rechner läuft. Wie viele Ports gibt es? Welche Ports sind bereits belegt? Gibt Welche Konventionen existieren zu Ports? Hier insbesondere Ports unterhalb der Nummer 1024 dürfen eigentlich nur von Services verwendet werden. Die erhöhte Rechte haben und so weiter und so fort. Das sollte durch angucken gerne auch Wikipedia bietet exzellente Dokumentation zum Thema IP Netze an. Schaut euch das an! Also was sind IP Adressen? Was hat es mit den Ports auf sich?

Was ist ein Router bzw ein Gateway? Ein Router bootet innerhalb von Netzen. Ein Gateway verbindet zwei Netze. Wir sagen zwar im Sprachgebrauch häufig DSL Router, aber streng genommen ist es ein DSL Gateway, denn es verbindet das private Heim Netz mit dem Internet. Was bedeutet Network Address Translation kommt so häufig vor in Kunden Projekten. Bei Network Address Translation geht es einfach darum, dass die IP-Adresse im Internet, die euer Gateway im Internet hat, auf eure lokalen Geräte zuhause beispielsweise abgebildet werden muss.

Das heißt, euer Handy, euer PC, eurer Spielkonsole, euer Fernseher. Die haben alle die gleiche IP V4 Adresse im Internet. Aber trotzdem muss natürlich das Gateway Player DSL Gateway entscheiden. Wo schicke ich denn welche Daten hin und muss die Geräte auseinanderhalten? Wie funktioniert das genau? Ein weiteres Stichwort hier wäre Port vor Wording. Das solltet ihr auch wissen. An das habt ihr aber wahrscheinlich im Studium gelernt. TCP und UDP was ist der Unterschied zwischen TCP Verbindungen und UDP Verbindungen?

Ganz einfach kann man sagen bei TCP Verbindungen fallen Verbindungs Fehler auf und werden behoben. Also verlorene Datenpakete werden an Nacht gesendet. Bei UDP ist das nicht der Fall. Dafür ist UDP schlanker und hat weniger Management Overhead, was die Paket Verwaltung angeht. Das ist manchmal von Vorteil, wenn man einfach möglichst hohe Datenrate erzielen möchte oder wenn verlorene Pakete nicht wichtig sind z.B. bei Skype Verbindung. Wenn da ein Wort fehlt, dann nützt das nichts, das wenige Sekunden nach und später nach zu senden, sondern dann lässt man Safa weg und macht weiter.

Generell Wie funktioniert Routing? Was sind Datenpakete? Wie funktionieren Firewalls? Das ist Grundlagenwissen, aber immer wichtig in Firmen, weil Unternehmen oft sehr komplexe Systeme im Einsatz haben, die eben mit dem Netz verbunden sind. Und oftmals, wenn es Probleme gibt, liegt das an Komponenten in dem Netz, die eben diese Einzelkomponenten verbinden. Und wenn man nicht versteht, wie Alpines zu funktionieren, dann kann man den Fehler nicht entdecken und beheben. Es ist der einfache Grund.

Der zweite Punkt bei Netzen und Protokollen. Neben der Funktionsweise des Internets sein grundlegendes Verständnis des http Protokolls. Also was gibt es für Methoden geth post put die z.B.. Und was gibt es für http status codes? Viele kennen bestimmt den Status Code 404. Das ist wenden eine Ressource eine Webseite in dem Fall nicht gefunden wurde. Gibt auch den Status Quo 200, wenn der Request erfolgreich verarbeitet wurde. Es gibt noch viele, viele weitere Status Codes, die alle eine andere semantische Bedeutung haben.

Da sollte man sich mal die Tabelle anschauen, um einfach einen Überblick zu bekommen, was es alles gibt. Die muss man nicht auswendig können, aber man muss z.B. Klassen von Status Code sollte man wissen. Also die fünf Hunderter Codes bezeichnen Server Fehler als bei vier Hunderter Codes ist häufig eine Ressource einfach nicht gefunden worden. Bei 200 Codes ist der Request erfolgreich durchgeführt worden. Aber es gibt halt verschiedene Rückmeldungen, dass man einfach diese Klassen kennt. Das ist sehr wichtig und hochgradig Praxis irrelevant.

Ein dritter Punkt bei Netzen und Protokollen, der sehr wichtig und in den letzten Jahren noch an Wichtigkeit. Sind die sogenannten Rest APIs als Schnittstelle zwischen Microservices oder zwischen zwei Systemen, die miteinander sprechen, meistens über Jason? Geht es darum, System A ruft z.B. bei System B ein Login auf, System B sendet System A zurück. Okay, erfolgreich eingeloggt. Daraufhin kann System A System B sagen wieder ein Request schicken. Ok. Dann bitte möchte ich die und die Daten abrufen.

Dann weiß System B anhand von Informationen, die gesendet werden. System AS autorisiert und kann dann die entsprechenden Informationen zurück liefern. Immer wenn ihr euch irgendwo auf einer Website einloggt, wird im Hintergrund genau dieser Datenaustausch durchgeführt. Also Rest APIs in Verbindung mit dem HTTP Protokoll und der Funktionsweise des Internets. Also es sind absolute Basis Baustein und die braucht ihr mit Sicherheit grenzender Wahrscheinlichkeit auf jeden Fall in meinem Berufsleben. Kommen wir nach der Datenhaltung und Verwaltung über das Thema Netze und Protokolle.

Nun zum dritten Thema Systeme und Plattformen. Hier ist es wichtig zu wissen, wie das System Linux aufgebaut ist. Linux wird nach wie vor auf den meisten Servern eingesetzt. Auch die ganz Docke isierung und die ganzen Cloud Umgebungen basieren zum größten Teil auf Linux und sehr, sehr häufig. Wenn ihr Software entwickelt, die irgendwo ausgerollt werden soll, passiert das auf Linux Systemen. Und da sollte dir einfach ein grundlegendes Verständnis davon haben, wie das System aufgebaut ist. Da gibt es tolle Youtube-Videos zu, die das in der Kürze erklären.

Also was ist der Kernel, was ist der User Space? Was sind die häufigsten Verzeichnisse bei einer Linux Installation oder auch im Docker Container? Ist es oft so ähnlich? Was sind Konfigurationsdateien also häufig unter Slash etc., die wichtig sind, wo ich dein Haus eintragen kann oder irgendwelche anderen Systemeinstellungen verändern kann? Das lohnt sich immer. Also generell Linux System Aufbau verstehen und die häufigsten Verzeichnisse kennen. Das führt mich direkt zum nächsten Punkt dem Umgang mit der Linux Kommandozeile.

Ob das jetzt das Basch Terminal ist oder TCS h WGT, da Entwickler durch seine eigene Vorliebe. Es ist aber wichtig hier, dass ihr euch für einen Terminal entscheidet, dass ihr das so konfiguriert, dass er damit auch umgehen könnt und euch dann eben auf der Kommandozeile wegen könnt. Ob das jetzt Linux ist oder MacOS, das ist erst mal nicht so wichtig, aber dass ihr in Verzeichnissen navigieren könnt. Also mit CD in ein Verzeichnis reinspringen oder wieder rausspringen, das Sie mit lässt euch das Verzeichnis Inhalt anzeigen lassen können, dass ihr Dateien editieren könnt entweder mit den Editoren wie ein Nano oder euer Lieblings Editor, dass ihr per 6h auf einen Server zugreifen könnt.

CH Leerzeichen Server Namen entspringt er auf den Host, dass ihr z.B. mit SCP Daten zwischen Servern hin und her kopieren könnt oder von einem Server auf eurem Rechner kopieren könnt. Das wird häufig benutzt bei Log Dateien. Wenn man da etwas nachschauen möchte, das man erstmal vom Server auf den eigenen Rechner kopiert, dass man Dienste stoppen kann und neustarten kann und dass man sich einfach sicher auf der Kommandozeile bewegt. Das ist sehr, sehr sehr wichtig und das ist absolutes Grundlagenwissen.

Hab ich häufiger schon in meinem berufst Kontext gesehen, dass das nicht beherrscht wurde. Und dann entsteht im Team sehr, sehr oft Frustration, weil das eine Grundkenntnisse ist, die vorausgesetzt wird. Also wer mit dem System Ausbau von Linux besprochen und die Navigation auf Linux Kommandozeile auch die Verwendung von Docker und virtuellen Maschinen wie VirtualBox sind sehr, sehr wichtig zu wissen, wie man damit umgeht, weil die Entwicklung doch mehr und mehr in Docker Containern vollzogen wird oder auch in virtuellen Maschinen statt auf der eigenen lokalen Hardware.

Das hat einfach den Vorteil, dass man, wenn man einen Docker Container baut oder Diplomat, dass er sich überall gleich verhält und man nicht mehr das Problem hat, dass eine Software auf dem lokalen Rechner anders funktioniert als dann später in der Produktion auf dem Server, weil man das vermeiden möchte. Also schaut euch an, wie Docker funktioniert, wie man Docker Container runterlädt, wie das langjÃhrigen der Falz Systeme der Docker Images funktioniert und wie der Docker Dienst generell funktioniert auf der Linux Infrastruktur.

Ich denke ah es ist sehr interessant und b ist es auch hochgradig Praxis relevant. Ein weiterer Punkt bei System und Plattform ist natürlich, dass in den letzten Jahren immer stärker in den Vordergrund tretende Cloud-Computing auf der einen Seite versus der On Priamos Rechenzentren, die auf der anderen Seite noch laufen bei vielen Unternehmen und ich denke, es wird dahin gehen, dass bis auf sehr, sehr wenige Ausnahmen fast alle Anwendungen in der Cloud betrieben werden. Heute sind wir in einem Zwischenzustand, dass noch viele alte Anwendungen, die seit Jahren bestehen, im eigenen Rechenzentrum laufen und nicht in die Cloud wandern.

Aber Anwendungen, die neu entwickelt werden eben schon auf der Cloud Infrastruktur angelegt werden. Und da muss man sich dann einfach auskennen. Also auch mit der Terminologie Wie heißt eine virtuelle Maschine in der Amazon Cloud oder in der Cloud oder in der Google Cloud, je nachdem, welchen Cloud Provider man da verwendet?

Da ist es auch wieder wichtig. Ich die Netze und Protokolle zu verstehen. Wie können die Maschinen untereinander kommunizieren? Welche Cloud Tools gibt es? Wie heißt jetzt zum Beispiel DNS namens Auflösung jetzt bei dem Cloud Provider und so weiter und so fort. Also hier am besten wie kommt ihr da rein? Die meisten Club Weida bieten ja so ein Free Plan an, dass man sich da einfach anmelden kann und dann eine einfache Website auf diesem Cloud Host installieren. Ich glaube, da kann man sehr schnell Erfolge erzielen und sich sehr schnell in diese Infrastruktur als Dienst oder Infrastruktur as a Service Umgebungen einarbeiten.

Oft ist es auch so, dass Unternehmen schon eine Cloud Infrastruktur hab und wir die nicht von Null aufbauen müssen, sondern eben erweitert. Aber da muss man sich dann auch auskennen, welche Werkzeuge es da alles gibt. Wenn man schon bei Cloud Computing ist, muss man auch meiner Ansicht nach das Cloud Native Software Bell abmahnt ansprechen. Da haben wir bei Skill BYD 2 Podcast Episoden zu gemacht, die Episode Nummer neun und zwanzig und dreißig. Denn Anwendungs Software, die für Cloud Umgebungen entwickelt wird, die wird etwas anders entwickelt als man das vielleicht bei Legacy Anwendungen früher gemacht hat, wo alles auf einem Server ausgeführt wurde.

Heute ist es so, dass das Thema State zentral gehalten wird, dann Cloud Datenbanken oder Cloud Now, SQL Datenbanken und die Microservices drumherum. Diese Daten transformieren sehr schön. Da sind wir wieder bei dem Bild, was ich eingangs gezeichnet habe, dass man im Grunde sich einen Computer Computersystem als Datentyp vorstellen kann mit Code drumherum. Genauso ist es in der Cloud auch. Aber es gibt ja ein paar Besonderheiten, auf die man achten sollte bei der Anwendungsentwicklung, die eben unter Cloud Native Development zusammengefasst sind, damit man auch alle Vorteile der Cloud nutzen kann.

Also damit man so super breit skalieren kann, damit man sich Maschinenhaus fahren kann und im Grunde eine Milliarde User App frühstücken kann, muss man die Anwendungen in einer bestimmten Art und Weise entwickeln. Und das ist das Cloud Native Development, würd ich auch sagen. Schaut euch das mal an, müsste euch nicht so tief anschauen, aber ist auf jeden Fall wichtig. Und in dem Zuge Cloud Entwicklung macht euch mit so Schlagwörtern vertraut wie CDN konnte Delivery Network Was bedeutet AWS?

Was bedeutet CCP? Was bedeutet esgab? Wie gehe ich mit der neuen Infrastruktur aus der Cloud um statt echter Hardware im Server? Vielleicht steigt er auch direkt auf Cloud Services ein und kennt gar nicht mehr echte Server. Das ist auch okay, aber der Umgang mit den Cloud Diensten, das halte ich für sehr, sehr wichtig und hochgradig Praxisräume und auf jeden Fall. Und auch die meisten Cloud-Anbieter bieten Kommandozeile Tools. Als wenn man sich auf der Kommandozeile bewegen kann, kann man auch die Tools der Cloud-Anbieter verwenden.

Nach System und Plattform wäre der vierte Punkt von mir nun das Arbeiten mit Source Code. Wie geht man damit um? Und hier ist ein ganz, ganz grundlegendes System, was man auf jeden Fall beherrschen sollte und sich anschauen sollte. Das Git Code Version im System von Linus Torvalds himself, gegründet vor einem Jahr. Was heißt ersetz? Installiert euch Git schaut an, wie man einen Branch macht, wie man Branches wieder merkt, wie Rhee Basinger funktioniert, welche Vorgehensweise es gibt, Feature Entwicklung auf sogenannten Branches durchzuführen.

Dann, wenn das Feature entwickelt ist, muss der Branche wieder in den Master Branch zurückgemeldet werden. Da gibt es verschiedene Vorgehensweisen. Also ich sage nicht, dass man sich das alles anschauen muss, aber man muss Git so benutzen können, dass man Code einchecken kann, Code Versionierung kann, die geläufigsten Kommandos kennt, also mit blame schaut wer hat diese Code Datei geschrieben und wen kann ich da fragen z.b. Und wo kommt diese Änderung her, dass man einen Branch ziehen kann, dass man ein Branch wieder marjan kann?

Das ist super wichtig und habt ihr vielleicht schon im Studium benutzt. Wenn nicht, schaut euch bei Jude Ami oder bei YouTube an Git Kurs an, der euch die Basics vermittelt und wirklich die Basics Bronchien Marching Rebalancing. Damit seid ihr schon gut aufgestellt. Da gibt es noch sehr fortgeschrittene Themen, die wenn euer Unternehmen das einsetzt, werden sie euch das zeigen. Aber zumindest die Basis Sachen solltet ihr kennen, um damit umzugehen, dass es immer wieder ein Knackpunkt.

Und da solltet ihr zumindest Grunderfahrungen haben, um da nicht direkt anzuecken bei eurer neuen Stelle. Wenn ihr wollt, macht euch ein Account bei GitHub und komm oder Güttler Punkt kommen. Erstellt euch dort euer eigenes Repository zum Ladet mal Dateien hoch, ladet das runter. Fragt einen Freund, die Dateien zu ändern und die wieder hochzuladen, sodass er euch einfach. Ja, vielleicht nutzt er im Studium schon vor eurer Abschlussarbeit oder irgendein Text. Könnt ihr mal Git benutzen, um gemeinsam an einem Werk zu arbeiten und dann kriegt er schon Erfahrung, was für Probleme es gibt und was auch Git leistet.

Und das ist sehr sehr wichtig. Es gibt noch andere Wirsching Systeme außer Git z.B. SVR oder CVS, aber Git hat im Grunde genommen alle verdrängt. Und wenn ihr Git verstanden habt, dann könnt ihr auch mit allen anderen umgehen. Deshalb halte ich es für das Allerwichtigste. Ein weiterer Punkt Wenn ihr das Codewort Oenning mit Git beherrscht, ist die Integration von Kaikki. Die Pipeline, also Continuous Integration Continuous Delivery haben nämlich meistens in Unternehmen hört man ja nicht auf, wenn man denkt Sourcecode eingecheckt hat, sondern jetzt muss der Source Code ja in ein Programm überführt werden oder in einen Container überführt werden.

Und dieser Container wird dann ausgerollt auf dem Testsystem, auf dem Produktionssystem, je nachdem, was man gerade macht. Da gibt es bei GitHub die sogenannten GitHub Actions, die es machen können. Bei Gelabt gibt es die Key ICD Pipeline über die Gitter i-Punkt Jamel Datei lässt sich das steuern. Also schaut euch die Integration dieser Sie als Hedy Pipelines an ist ein etwas fortgeschrittenes Thema, wird aber auch hochgradig Praxis relevant. Hab ich in jedem Projekt bisher gehabt. Was man da zumindest verstehen muss.

Was da vor sich geht und gegebenenfalls auch Anpassungen durchführen können muss, würde ich empfehlen, sich auf jeden Fall da mal ein Youtube-Video zu anzugucken. Okay. Soviel zur Arbeit mit Sourcecode. Mein fünfter Punkt, der absolut wichtig ist, heißt Debugging. Womit die Bar gegen meine ich erstmal, dass ihr Log falls lesen könnt Dienste Linux Dienste System Dienste auch Windows System Dienste schreiben Ereignisse in Log Dateien Diese Log Dateien sind die erste Anlaufstelle, wenn es zu Fehlern kommt, wenn es zu Problemen kommt, wenn man irgendwie schauen muss, wie verhält sich der Dienst.

Und das ist tägliches Brot und Butter Geschäft, das man in Lokführers schauen kann. Also entweder springt man auf der Kommandozeile per Asha direkt auf die Maschine oder in den Docker Container und betrachtet dann eben die Lock falls mit den gebräuchlichen Editoren wie wie nano less more. Dies sind keine Editoren, aber Betrachter um dann die Log Dateien anzeigen zu können. Ihr könnt jeden Editor benutzen, der für euch passt. Wichtig ist, dass ihr wisst, wo sind Lokführers zu finden unter war oder jeweils an der konfigurierten Stelle im Container und dass ihr dort reinschauen könnt.

Superwichtig gibt auch so Log Aggregation Dienste wie e.K. Zum Beispiel oder Cubaner die Log Falls sammeln gerade in verteilten Umgebungen und die dann an zentraler Stelle aggregieren. Ihr könnt euch vorstellen, wenn ihr 20 Container habt, dann möchtet ihr nicht 20 Container abklappern per Kommandozeile, sondern möchtet die Log falls zentral an einer Stelle einsehen können. Dann habt ihr schon einen Dienst, der euch das abnimmt, die Lock Fields zu sammeln. Aber das Sorgfalt selber betrachten müsst ihr dann immer noch eben auf einer Web Oberfläche und vielleicht nicht in der Kommandozeile.

Aber Log falls lesen will gelernt sein kommt aber auch jeden Tag vor. Ein ganz ganz großes Thema. Was mir am Herzen liegt beim Thema Debugging ist das Richtige die Backen. Ich halte das für extrem wichtig für effektive Arbeit zu machen. Also stellt euch vor. Ihr baut eine Website und jedes Mal, wenn ihr eine Änderung gemacht hat, müsst ihr den Webserver neu starten, um zu gucken, welche Änderungen hat meine Änderungen denn jetzt bewirkt? Wie sieht die Webseite jetzt aus?

Wie sieht die Webseite jetzt aus? Jetzt würdet ihr so ein Plugin verwenden wie z.B. Hoth Reload, was einfach, wenn ihr die Datei speichert, die Webseite neu lädt und ihr sofort seht, was eure Änderung bewirkt hat. Und das ist jetzt nur Webentwicklung. Das kann man für alle möglichen Technologien gibt es einen dieBürger. Ob das im Browser ist, eine JavaScript Code schreibt, ob das auf JVM Sprachen ist wie Java oder Scala, da gibt es die Bagger.

Ob das bei iOS ist? Wenn ihr Apps entwickelt oder bei PHP. Überall gibt es die Braga, welche die Entwicklung und das Bugfixes extrem vereinfachen. Ihr könnt Breakpoint setzen, also an bestimmten Stellen im Programm stehen bleiben. Dann könnt ihr euch angucken, welche Werte alle Variablen haben. Ihr könnt oft auch die variablen Werte an dieser Stelle ändern. Teilweise könnt ihr das Programm zurückspulen, eine Änderung machen und dann nochmal vorwärts über diese Änderungen drüber gehen und gucken, ob eure Änderungen den gewünschten Effekt hat.

Ihr könnt variablen Werte ansehen und editieren. Ihr könnt OT Reload benutzen. Das heißt, dass ihr die geänderte Datei direkt kompilieren und wieder einladen könnt und direkt den geänderten Code testen könnt. Vorwärts rückwärts über eine Stelle gehen und kommt so viel schneller einem Back auf die Schliche. Oder wenn ihr auch Software entwickelt, als wenn ihr immer wieder den Server neu startet oder den Dienst neu startet und euch bis an diese Stelle durchklicken. Also nutzt ein Debugger. Das ist mein Appell.

Das ist auch ein riesen Hebel. Ich bin immer wieder überrascht. Auch fortgeschrittene Entwickler benutzen nicht immer einen Debugger, sondern erarbeiten erst einmal relativ lange ohne, bis sie dann die Bagger abklemmen. Und die Bagger ist für mich eins der Nummer eins Produktivitäts Werkzeuge überhaupt, um Softwareentwicklung zu betreiben oder Bugfix sing. durchzuführen. Also investiert wirklich die Zeit in die Bagger kennenzulernen und einzurichten. Das ist eine etwas größere Hürde. Oftmals muss man ihn konfigurieren und muss erst mal ein paar Settings gerade ziehen, bis man ihn auch nutzen kann.

Das sollte aber auf jeden Fall machen, auch wenn es etwas lästig ist, weil die Zeit holt er hinterher immer wieder raus. Nach dem Thema Diba gegen was ich abschließen möchte, komme ich zu dem sechsten Punkt und der sechste Punkt ist im Grunde genommen keine Werkzeug Empfehlung wie vorhin, sondern eine Empfehlung zu eurer generellen Einstellung. Der sechste Punkt heißt Produktivität und Zielorientierung und das ist ein ganz wesentlicher Punkt. Die Herangehensweise an ein IT bzw. Software Problem ist ganz wesentlich für euern Erfolg und ich sehe es sehr sehr oft, dass das ein Haupt Unterscheidungsmerkmal ist zwischen einem Entwickler, der vielleicht weniger Erfahrung hat und einem Entwickler, der sehr viel Erfahrung hat.

Die Entwickler mit sehr viel Erfahrung, die überlegen erst auf dem Papier, die planen eine Funktion, die schauen sich an, die lesen sehr viel. Was ist denn schon da? Was kann ich wiederverwenden? Gibt es eine Open Source Library, die ich benutzen kann, die mir schon sehr viel Arbeit abnimmt? Was ist denn schon da? Also wie ist genau mein Weg zum Ziel? Und sehr, sehr viel Zeit wird für die Planung aufgewendet, wohingegen eher Junior Entwickler meistens direkt anfangen Code zu tippen.

Ah hier, da weiß ich, da kann ich etwas implementieren und hier machen wir die Suchfunktion und so. Also die springen direkt ins Thema rein, statt erst mal zu planen. Und da ist mein Erbteil an euch. Überlegt erst einmal genau, was erreicht werden muss, was die Anforderungen sind und dann überlegt euch einen minimalen Weg, wie ihr genau diese Anforderungen auch umsetzen könnt. Nicht zu viel implementieren und gerne needed genau gucken. Okay, wie ist ein effektiver Weg von meiner Anforderung hin zur Implementierung?

Viel Zeit in das Verstehen des Problems zu investieren und auch viel Zeit in die gedankliche Entwicklung der Lösung zu investieren und dann erst mit dem Cone anzufangen und die einzelnen Blöcke zusammenzuziehen. Also desto Me im Vorfeld überlegt und plant, desto weniger Code schreibt ihr am Ende. Weniger Code heißt weniger Fehler, teils besseres Programm, bessere Software. Wichtig wäre bei dem Punkt auch noch daran zu appellieren, dass ihr, bevor er eine Änderung durchführt, überlegt Welchen Impact hat diese Änderung denn für das Business?

Und ist das wirklich wichtig? Sehr oft beobachte ich, dass Entwickler dann diese Technologie und jene Technologie und dies noch verwenden wollen. Aber das löst überhaupt nicht das Ziel Problem. Also man muss sich wirklich jeden Morgen deshalb ist das Daily bei Scrum auch so wichtig nochmal zentrieren und sagen Okay, was sind denn die wichtigsten Themen, die ich erledigen muss, damit die Anforderung umgesetzt wird, um nicht vom Weg abzukommen? Eine Podcast Episode, die genau das Thema aufgreift, ist die Episode Nummer 9 Bulls als Software Development.

Da geht es darum, wie man fokussiert auf die Unternehmensziele hin entwickelt und möglichst genau den Kurs hält. Ich fasse nochmal zusammen als der erste Themenblock Datenhaltung und Verwaltung. Da geht es darum, SKL solltet ihr beherrschen no SQL Datenbanken sollte die verwenden können und beherrschen, was eine hascht Tabelle ist Wissen und die häufigsten Datenformate Jason, Jamel und CSV verwenden können. Bei Thema 2 in Netzen und Protokollen sollte die Funktionsweise des Internets verstehen. Was sind IP Adressen usw.. Das HTTP bzw.

https Protokoll verstehen auch. Was hat es mit der Verschlüsselung auf sich und wie werden Zertifikate eingesetzt? Und ihr solltet Rest APIs ansprechen können und verwenden können. Bei Systeme und Plattformen den Linux System Aufbau verstehen, euch auf der Linux Kommandozeile sicher bewegen können. Docker und virtuelle Maschinen einsetzen können. Den Unterschied zwischen Cloud-Computing und Prims Rechenzentrums Anwendungen verstehen vielleicht die Faktoren des Cloud Native Development mal anschauen im Podcast Episode Nr. neun und zwanzig und dreißig und die geläufigsten Cloud Services habe ich mal angeschaut haben.

Also Google, Microsoft und Amazon sind hier zu nennen. Bei der Arbeit mit dem Sourcecode solltet ihr mit Geld umgehen können und die Integration von KI, als sie die Pipelines verstehen. Warum macht man das und wie geht das prinzipiell? Beim Thema Debugging Lock Falls lesen können und den Debugger einrichten. Das ist ganz wichtig, damit ihr produktiv arbeiten könnt und beim Thema Produktivität und Zielorientierung euch immer wieder daran erinnern. Planen. Problem verstehen. Möglichst viel über das Problem wissen und dann erst eine Lösung entwickeln.

Weil desto mehr man über das Problem weiß, desto einfacher ist die Lösung hinterher. Für weitere Podcast Episoden zu den Themen die packe ich euch in die Shownotes. Aber den Podcast Nr. neuen Bullshit Software Development einfach und fokussiert auf Unternehmensziele in entwickeln Must-Have Skills und Technologien für DevOps findet ihr in der Podcast Episode Nr. 8 für Data Ingenieurs und Data Scientists in der Podcast Episode Nr. 7 für Faulstich Entwickler. In der Podcast Episode Nr. 6 und die 12 Faktoren des Cloud Native Development findet ihr in der Episode 29.

und 30.. Nochmal wichtig zu sagen all die angesprochenen Themen haben eine sehr hohe Praxis Relevanz, das kann ich euch sagen aus 16 Jahren IT Erfahrung und über acht Jahren I Beratungs Erfahrung. Wenn ihr Fragen habt oder Feedback zu der Episode, weil ihr glaubt, dass ich ein wichtiges Thema vergessen habt, sendet uns gerne eine E-Mail an Podcasts. Gilbert D. Wenn euch die Podcast Episode gefallen hat, abonniert unseren Podcast und lass deine 5-Sterne Bewertung. Wir freuen uns auch immer über Weiterempfehlung an Freunde und Kollegen, die sich ebenfalls für Technologie Themen interessieren.

Ansonsten freuen wir uns noch, wenn ihr uns Gilbert D. Slash Blog vorbeischaut. Vielen Dank fürs Zuhören und bis zum nächsten Mal.

Maurice KnoppSkillbyte Podcast #48: Grundkenntnisse und Skills für ALLE IT-Fachkräfte
Mehr

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 #38: Darum müssen IT-Manager programmieren können!

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

In diesem Podcast geht es um das Thema: Darum müssen IT-Manager programmieren können!

// Inhalt //
01:20 – Was ist das Problem?
03:35 – Nur general Management Skills reichen nicht für IT-Projekte
06:29 – IT-Management braucht zwigend technischen Sachverstand
07:40 – Kardinalfehler: Aufgrund mangelnden IT-Verständnisses werden fachliche Anfoderungen sehr ungenau spezifiziert
09:14 – Technischer Sachverstand und Coding Skills helfen extrem bei der Anforderungermittlung mit der Fachseite
12:02 – Technischer Sachverstand ist nötig um vom Team respektiert zu werden
13:05 – So schaffen IT-Manager den Programmier-Einstieg (Bugfix, Unittest, Hello-world, neue Technologien sichten)
17:07 – IT-Zeitabschätzungen validieren
21:36 – Technologiekenntnisse boosten die Anforderungsanalyse und die Ergebnisspräsentation
27:42 – Wo können IT-Manager coden im Projekt lernen?
31:02 – Workaround wenn keine Technikskills vorhanden sind
31:44 – Gegenfrage: Darum sollten Entwickler auch Management-Aufgaben übernehmen!

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

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #38: Darum müssen IT-Manager programmieren können!
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

Skillbyte Podcast #35: Moderne Microservice Architekturen – Die Zukunft der Softwareentwicklung als Servicenetz

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

In diesem Podcast geht es um das Thema: Moderne Microservice Architekturen – Die Zukunft der Softwareentwicklung als Servicenetz

// Inhalt //
01:30 – Definition: Microservice Architekturen (Masiar)
04:07 – Exkurs: Enterprise Service Bus
05:03 – Definition: Microservice Architekturen (Maurice)
10:39 – Die Historie hinter dem Microservice Trend
13:29 – Flexibilität vs Komplexität
16:57 – Betrachtungen der Paradigmen Monolith vs Microservice
20:47 – Vorteile von Microservices
20:51 – Modularität
21:33 – flexible Integration
23:33 – Skalierbarkeit (Cloud native Paradigma)
25:30 – Verteilte Entwicklung / Best of Breed Ansatz
25:49 – mehr (API Schnittstellen-) Dokumentation
26:46 – Robustere Systeme
29:55 – Nachteile von Microservices
29:57 – Netzwerkkommunikationsoverhead entfällt beim Monolithen
31:15 – Höhere Komplexität
32:25 – HTTP-Protokoll (overhead, stateless)
33:43 – Microservice Beispiele aus der skillbyte Praxis

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

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #35: Moderne Microservice Architekturen – Die Zukunft der Softwareentwicklung als Servicenetz
Mehr

Skillbyte Podcast #34: Serverless Computing – Hype oder Chance? AWS Lambda, Azure Functions, Google Cloud Functions richtig verwenden

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

In diesem Podcast geht es um das Thema: Serverless Computing – Hype oder Chance? AWS Lambda, Azure Functions,
Google Cloud Functions richtig verwenden

// Inhalt //
01:04 – Was ist Serverless Computing?
03:15 – FaaS – Functions as a Service
06:43 – Cloud Anbieter für Serverless Computing
07:52 – Abrechnung von Serverless Computing Ressourcen
09:25 – AWS Lambda am Beispiel von Amazon Alexa
11:56 – Vorteil: Zeiteinsparung bei der Administration ist signifikant
14:25 – Vorteil: Abrechnung nur verbrauchter Ressourcen
15:16 – Vorteil: Kosten werden Transparent
17:09 – Vorteil: Kleine Teams können Anwendungen Millionen von Menschen zur Verfügung stellen
18:10 – Nachteil: Vendor Lock-in
20:04 – Nachteil: Keine Performance-Garantie
23:43 – Nachteil: Ressourcenbeschränkungen (CPU Zeit, RAM, Laufzeit, etc.)
25:34 – Nachteil: unflexible Laufzeitumgebungen mit fixen Softwareversionen
28:35 – Debugging bei der Entiwcklung von Functions
30:30 – In diese Szenarien ist Serverless Computing besonders sinnvoll…
35:34 – …und in diesen sind sie nicht besonders sinnvoll

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Herzlich Willkommen zum Skill bald Podcast Episode Nr. 34 Servile Computing Hype oder Chance Apps, Landa, Escher Functions, Google Cloud Functions und so weiter richtig verwenden abonniert unseren Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn die Entscheider oder IT Fachkraft seid, lasse auch gerne eine 5-Sterne Bewertung da oder sendet uns eine E-Mail mit euren Fragen an Podcast Skill bei. Wir freuen uns auch immer, wenn ihr den Podcast an eure Freunde und Kollegen weiter empfehlt.

Ich bin heute hier mit Max von Skill bald Hallo Max, Hallo Moritz, es freut mich ganz besonders, da wir ja schon wirklich über ein Jahr zusammen arbeiten, dass wir heute diese Episode zusammen machen können.

Freue mich auch dabei sein zu können. Es hat mich immer gereizt, jetzt immer auch mein Thema gefunden und einen Zeitpunkt wo verpasst.

Ja und was für ein Themas ist auf der einen Seite ein hoch spannendes Thema Server es Computing. Auf der anderen Seite hab ich den Eindruck, dass es aktuell auch etwas gehypt wird. Wir können ja mal darauf eingehen, was servile Computing eigentlich ist. Was verstehst du denn darunter?

Ich verstehe zwei Sachen Wissen. Lattmann da sei einmal Server, alles im reinen Sinne oder so wie es jetzt im Moment und den Cloud Providern beworben wird. Bedeutet zwar aber, dass er erstmal, dass man sich selber nicht um die Hardware kümmern muss. Das heißt, dass man im Endeffekt den Cloud, wobei der dafür bezahlt, dass sie die Infrastruktur bereitstellen, wo man dann nur noch seine Anwendungen drauf ausrollen muss. Und das ist eben für mich erst mal der grundlegende Server des Computing an der Stelle.

Aber natürlich gibt es auch die engere Definition, die dann vor allen Dingen auch heute im Podcast eher die größere Rolle spielt. Bowls dann eher in Richtung Funktion Access Service geht, wo dann eben auch der ausführende Layer sozusagen nochmal abstrahiert ist, sodass man wirklich nur sehr wenig Aufwand selber hat, was man sozusagen bereitstellen muss. Genau, also die Wartung der Plattform.

Du hast eben gesagt Server lässt, man muss sich nicht mehr um die Hardware kümmern. Genau genommen muss man sich ja auch um einige Ebenen der Software nicht mehr kümmern. Also kümmern im Sinne von installieren, warten, Updates einspielen, den Server tauschen, wenn er mal alt ist. All diese Dinge also ganz klar sollten wir vielleicht sagen Server List Code läuft natürlich nach wie vor auf Servern, nur man hat keinen direkten Kontakt mehr dazu, weil eben diese Schicht weg abstrahiert ist.

Ich denke, das spannendste Thema für unsere Zuhörer ist die Abstraktionsebene Functions, also Service oder App. Faas.

Das ist auch die geschichtlich neueste Stufe der Server alles Ebene. Da geht es darum der Anbieter stellt eine Laufzeit Umgebung zur Verfügung. Also das kann eine Python Runtime sein. Das kann eine Java Run Time sein, eine dort net run time. Alle möglichen Plattformen sind hier denkbar. Und auf dieser Plattform werden dann eben einzelne Funktionen oder Programmteile ausgeführt und diese werden dynamisch gestartet anhand von bestimmten Triggern und auch skaliert. Also ob ich ein Bild konvertiere beispielsweise oder tausend Bilder konvertiere parallel.

Das ist damit dann möglich. Rampen für Cloud Provider eben dafür zuständig €000 Laufzeit Umgebung bereitzustellen, die dann parallel den Job abarbeiten können. Hast du in letzter Zeit selber schon Functions, also Service Funktionen entwickelt?

Hab ich in der Tat. Das war bei zwei verschiedenen Projekten jeweils verschiedene Anwendungsfälle. Einmal haben wir das genutzt, um Web Application also an der Stelle einer Westlake JAL bereitzustellen, die eben von außen aufgehoben wird. Dann Processing mach. Und je nach bestimmte Antwort zurückgibt. Der andere ist mehr asynchronen Fal, wo sozusagen durch Daten Anlieferung Funktion getriggert wird, die dann eben Daten einliest, transformiert und dann wieder raus schreibt. Und dann kann auch in einer Kaskade dahinter eben neue Fangzähne getriggert werden, sodass dann sozusagen dieser übliche Ettl Job durch mehrere verschiedene Functions abgebildet wird, wobei jede Funktion immer nur eine Transformation ausführt und dann Pappi Events wie Datei wurde geschrieben oder neue Datei existiert.

Angetriggert werden und dann entsprechend ihre eigene Verarbeitung an der Stelle fortsetzen. Das heißt, die Verkettung der Trigger ist quasi ein Stück weit der neue Programmcode. Wieso?

Bei einer Dominostein Reihe genommen würde ich sogar vielleicht noch einen Schritt weiter gehen und sagen, dass wenn man mit Pantheons arbeitet und da komplexere Logik umsetzen will, ist man eigentlich gezwungen Microservices mehr oder weniger in Reinform zu denken und umzusetzen, weil dazu, wenn er später noch kommen Franzens bestimmte Limitationen haben, was vor allen Dingen Performance angeht, also CPU Rechenzeit. Und dann ist so eine Funktion tatsächlich auch nur gedacht als einen logischen Schritt, sodass man, wenn man verschiedene Schritte in seiner Ausführung hat, hat man sozusagen immer wieder einen neuen Micros Service, der gekrault wird oder durch ein Event ausgeführt wird, einfach um ein plastisches Beispiel zu.

Geben Wir sind ja noch bei der Definition, was Server des Computing ist. Früher hätte man so eine klassische Webanwendung oder ein Webshop hätte eine Anwendung beinhaltet, wo dann die Bestellung ausgelöst wird, das Etikett ausgedruckt wird für den Karton, der später versendet wird. Plus die Zahlung von der Kreditkarte, mit der der Kunde bezahlt hat. Eingezogen wird und im letzten Schritt wird der Warenbestand um 1 Dex demontiert, um eben diese Bestellung dann darzustellen. Und im Server ist reich, während das einzelne Funktionen, die sich nacheinander aufrufen oder das kann er teilweise sogar auch parallel geschehen.

Aber Microservices in Reinform. Diese kleinen Funktions Blöcke, die sich dann eben nacheinander aufrufen, was man vielleicht noch sagen sollte, weil das Wort oder der Begriff Server des Computing oft marketingtechnisch ausgeschlachtet wird meinen kann, sind auch so Docker Container Round Times also die bezeichnen sich auch als Server. Alles das ist hier im Kontext dieser Podcast Episode nicht gemeint. Mir meinen wirklich nur einzelne Funktionen, die miteinander verzahnt werden können und nicht ganze Programme, Bausteine oder ganze Programm Plattformen die eben hochgefahren werden, wo man dann auf einer niedrigeren Abstraktionsebene einsteigen würde.

Im Grunde, wenn man die Geschichte der Applications Entwicklung sieht, sind Server lässt die neueste Stufe, denn es wird auch. Ich habe in einem Artikel gelesen DevOps als DevOps auf Steroiden bezeichnet. Man kümmert sich im Grunde nur noch um die Programm Logik, also die einzelnen Funktionen und die Verschaltung dieser Funktion von Deist als das Beispiel, was du gegeben hast. Max, dass die Funktion über eine API aufgerufen werden und dann eben weitere Schritte wieder über Abis anstoßen. Schon wahrscheinlich das Paradebeispiel im Server des Computing Bereich.

Mit welchen Anbietern hast du denn? Und Laufzeit Umgebung? Hast du denn jetzt schon Erfahrung gesammelt?

Persönlich hab ich schon so gut wie in den drei größten Cloud Anbietern gearbeitet. Also Amazon habe erst an der Stelle Track Software an Google Cloud Computing allerdings lediglich in Apps und den Ärger mit den befangene Pandoras gearbeitet. Das wäre an der Stelle daneben Landa Funktionen bei Apps und einmal ja Funkens, dann bei Microsoft.

Ich glaube bei Google heißt es Cloud Functions und bei IBM heißt es auch Cloud Functions. Aber das unter dem Begriff Lambada und dem jeweiligen Provider wird man ganz sicher den Produktnamen ausgraben können. Okay, ich glaube, da haben wir schon mal ein gutes Grundverständnis gegeben, was Server Computing ist. Also vielleicht noch ganz kurz Welche Laufzeit Umgebung hast du eingesetzt? Ich nehme an Python, oder?

Genau. Bei mir war es jedesmal Theißen. Allerdings wenn die relativ die Wert mittlerweile aufgestellt. JavaScript funktioniert und auch jede andere große Programmiersprache wird mittlerweile auch an der Stelle unterstützt. Vielleicht noch ein Wort zur Abrechnung.

Also klassische Server bezahlt man ja, indem man einfach die Server mietet oder? Beim Cloud Server wird ja auch pro Minute abgerechnet. Beim Server Computing ist das so ein Mix aus verbrauchten CPU Ressourcen. Remme Ressourcen und Durchsatz. Das unterscheidet sich glaube ich auch bei jedem Anbietern. Bisschen gab es unterscheidet sich auch dann nochmal zusätzlich, in welchem Kontext du sie verwendet. Also ich weiß, dass man bei Apps verschiedene Modi haben kann. Man kann die typische Lambda Funktion haben.

Man kann auch Lambda haben. Man kann die Landa Funktionen mehr oder weniger direkt dem Internet preisgeben oder ein API Gateway benutzen und je nachdem welches Modul man dann je nach Funktionsweise benutzt. Damit wird es auch nochmal ein bisschen anders abgerechnet. Beim Großen und ganzen kann man eben sagen, man bezahlt für die Ressourcen, die man auch tatsächlich einsetzt. Lambada bedeutet, dass die Funktions Ausführung möglichst nahe an den Endkunden herangeführt wird, oder?

Genau das hat. Ich glaube in dem Kontext zwei Bedeutungen. Einmal wird eben z.B. das API Gateway nicht benutzt, was dann eben auch nochmal zusätzlich ein Netzwerk Delay verursachen würde. Und wie du richtig gesagt hast, werden dafür auch Server benutzt, die eben sehr nahe beim Kunden stehen. Das wirkt dann, wenn man das so möchte und bucht quasi und auch bezahlt weltweit auf die verschiedenen Server verteilt, sodass dann je nachdem von wo der Kunde das aufruft, das dann an den nächst gelegenen Server geht.

An der Stelle noch ein Beispiel Bevor wir zu den Vor und Nachteilen von Server des Computing kommen, ist Amazon Alexa also der Sprachassistenten von Amazon selber. Jedesmal wenn man mit Alexa spricht, ruft man im Hintergrund quasi eine Lambda Funktion auf, die dann antwortet. Das fand ich ganz interessant, dass Amazon die eigene Technologie für ja doch dieses Blockbuster Produkt verwendet, was natürlich dann auch Signalwirkung haben soll. Seht her, das ist stabil genug, darauf kann man sich verlassen.

Okay, jetzt haben wir schon einige Vorteile. Implizit angesprochen. Lass uns doch nochmal durchgehen, ob wir nicht was vergessen haben. Skalierbarkeit hatten wir eben schon angesprochen. Amazon Alexa kann man sich z.B. vorstellen, dass am Anfang gab es vielleicht einige tausend Nutzer, die regelmäßig mit ihrer Alexa gesprochen haben. Mittlerweile dürfen das einige Millionen sein. Und diese ganzen Anfragen können eben parallel durchgeführt werden, ohne dass man sich darum kümmern müsste, die Infrastruktur entsprechend zu skalieren.

Das macht der Cloud Provider und auch das Konzept für die Fans sind, denen ausgelegt sind, wo man quasi nur eine Funktion vom Code her bereitstellt, mit vordefinierten Inputs und definierten Outputs. Diese Art der Programmierung dadurch ist trivial möglich, dass auch tatsächlich die Anwendung eben skaliert. Weil n klassischen Anwendungen muss man potentiell eben auch nochmal Gedancken reinstecken, ob die Anwendung überhaupt staatlich ist, ob sie skalieren kann und so weiter. Und diese Sachen sind implizit automatisch gegeben, wenn man entsprechend diese Umgebung nutzen will, weil dann muss man sich diese Gedanken alle vorher machen.

Angekommen vom Cloud Provider sozusagen ein vordefinierte Event eingereicht, mit dem man arbeiten kann. Mehr hat man nicht. Man kann natürlich auch externe Systeme noch anfragen, aber erstmal hat man nur dieses Event und tut dann eben mit diesem Event was. Und dass es in sich allein von den logischen Gedanken beliebig skalierbar, sodass allein die Herangehensweise an die Programmierung so einer Funktion eben an der Stelle das Skalieren quasi gratis mitliefern.

Ich hab bei der Recherche so einen schönen Satz gefunden. Ich glaube es von Google. Das heißt from prototype to production to planet scale, also dass im Prinzip der parallelisiert Kargheit dieser Service Funktion keine Grenzen gesetzt sind. Physikalische Grenzen sind natürlich schon durch den Cloud Provider gesetzt, aber die liegen so hoch, dass man dort erst einmal keine Probleme haben sollte.

Okay, dass man sich nicht mehr um die Beschaffung von Hardware, die Installation des Betriebssystems, die Wartung und das Update des Betriebssystems und etwaiger anderer Software Komponenten kümmern muss. Das hatten wir eingangs schon erwähnt. Ist aber ein wichtiger Punkt, denn ich wette in vielen vielen Admin Teams wird signifikant viel Zeit für diese Tätigkeiten aufgewendet. Soviel zu meiner Erfahrung. Ich weiß nicht, welche du da gesammelt hast, doch das ist ja identisch.

Muss man sich ja nur einmal in der Fachliteratur ein bisschen umschauen. Es tauchen gefühlt jede Woche mindestens eine Sicherheitslücke auf, wo man dann das Team eigentlich überprüfen muss. Okay, der Server, auf denen unsere Anwendung läuft, ist da die Open Access Bibliothek jetzt drauf, die betroffen ist oder nicht? Wenn ja, wie? Installieren wir das? Können wir das im laufenden Betrieb machen und so weiter. Und all das entfällt eben, wenn man in diesem Server lebt, Kontext unterwegs ist.

Dafür bezahlt man am Ende dann den Cloud Provider, dass die sich dann eben um Wartung, Update und so weiter kümmern. Und man selber bekommt von der Situation überhaupt nichts mehr mit. Und dann muss sich auch keine Gedanken machen, was an der Stelle eben irgendein Produktionsausfall oder sowas ist. Oder dass die Funktion erstmal nicht mehr erreichbar. 2 Grad der Hauptsatz aber ja, updatet oder sonst was.

Das hat man eben an der Stelle überhaupt nicht, da auch das Thema, was oft unter den Tisch fällt Hardware Ausfall. Vielleicht erinnerst du dich an ein Projekt, wo wir beide waren, was noch nicht so lange her ist, dass eine fehlerhafte Netzwerkkarte also wirklich wochenlang Haare raufen gesorgt hat, bis sie im gefunden und deaktiviert wurde und ab dann konnte normal weitergearbeitet werden. Das sind auch Sachen. Also nicht, dass es die defekte Netzwerkkarte in einer Cloud Umgebung nicht geben kann.

Aber ich denke die STANDARD Hardware dort ist so gut Monitor, dass das relativ schnell auffällt. Genau. Und soweit ich das weiß, haben sie ja auch nochmal spezielle Software laufen, die Unstimmigkeiten im Netzwerk aufspürt oder insgesamt Unstimmigkeiten in der Hardware. Und dann wird mal einfach ein kompletter Server Schrank aus der aktiven Hardware rausgenommen, falls nur die Ahnung ist, dass da mit dem Server schon was nicht in Ordnung ist, weil Cloud Provider haben natürlich so viel Ressourcen oder so viele Backups auch, dass das einfach mal möglich ist.

Was natürlich für ein normales durchschnittlichen Unternehmen nicht einfach mal möglich ist. So viel über pro. resümierte Hardware dazu haben, dass man meinen gesamten Server Schank aus dem Rechner Cluster rausnehmen kann.

Und wer eine Woche mit Debugging von Hardware Problemen verbracht hat, der wünscht sich, dass er damit nichts zu tun haben möge.

Preis ist auch ein Vorteil. Wir haben es unter Vorteil gelistet, aber ich würde sagen, da muss man etwas aufpassen, denn es gibt durchaus auch Szenarien, wo es günstiger ist, wenn man einen eigenen Server mietet, der z.B. kontinuierlich unter Hoch Last steht oder der sehr spezielle Anforderungen erfüllen muss, also sei es Spezial Hardware oder sehr viel Arbeitsspeicher aufweisen muss, dann sind Server alles Funktionen leider keine Option.

Genau, also das muss man je nach Anwendungsfall immer evaluieren. Es gibt eben meistens bei der Cloud nicht die STANDARD Aussage. Ja, das ist günstiger als alles andere, weil dann gäbe es das andere auch nicht. Mehr dementsprechend. Wie du richtig gesagt hast, mein Server ständig ausgelastet wäre, dann ist der häufig günstiger, als wenn man die gleichen Neuyork laut über Funktionen an der Stelle Fahndungen.

Ein weiterer positiver Punkt, der in vielerlei Hinsicht positiv ist, ist die Abrechnung für verbrauchte Ressourcen, also CPU Zeit, RAM Io. Und nicht nur, weil man tendenziell, wenn man ein System, das man nur für die Last starken Zeiten im Prinzip bezahlt, sondern es wird auch sehr deutlich im Projekt oder bei mehreren Projekten, welche Projekte wie viele Kosten verursachen und wo genau bei welchem Arbeitsschritt und welchem CPU Dienst oder bei welchem Programmteil die höchsten Kosten anfallen und die meiste Berechnung anfällt und man kann dort gezielt optimieren.

Das finde ich auch sehr schön eigentlich. Früher hat man gesagt, die Datenbank läuft 24 Stunden am Tag. Dann können wir auch hier alles rein und rausrechnen und Backup machen. Jeden Abend 100 Gigabyte übers Netzwerk schieben, das ist ja eh da und jetzt muss man sich das schon genauer überlegen. Also kann natürlich auch negativer Punkt sein, weil man sich jetzt damit beschäftigen muss. Aber generell halte ich das für eine gute Sache, dass man weiß, wo welche Aufwände erzeugt werden und man einfach so nochmal einen Überblick bekommt.

Genau.

Also vielleicht auch das Beispiel, das sein Wickler ein bisschen anders entwickelt kann. Ich habe selber gemerkt, dass wenn man sich jetzt eben genau an diese neue Serviceleistung Banken mit arbeitet, dann denkt man auch mal zwei oder drei mal mehr nach, um zu überlegen Okay, brauche ich jetzt diese Datenbank Anfrage oder nicht? Wie du eben so schön gesagt hast wenns im normalen System läuft und die Datenbank Ishtar, dann macht man im Saft. Hab eine Anfrage Mehrheit dahin, obwohl es natürlich auch Bermann Snack optimieren würde.

An der Stelle bringt das natürlich auch Vorteile in jeder anderen Umgebung. Aber gerade in diesem Klout Umgebung hat man sowieso nochmal einen monetären Vorteil dadurch, sodass man dann auch als Entwickler gleich Kaymer überlegt, ob man das nicht wieder schöner oder performant an der Stelle schreiben kann.

Also es wird einfach transparent und man kann sich gezielt darum kümmern oder sich gezielt dafür entscheiden, sich nicht darum zu kümmern. Was ich noch als gigantischen Vorteil seh ist, dass dieses Wissen für die Administration, was ja in jedem Unternehmen aktuell vorhanden ist und auch früher für die Produktentwicklung unabdingbar war, nicht mehr unbedingt notwendig ist. Und auch kleine Entwicklerteams, die vielleicht nur aus Entwicklern und einem 2 DevOps Menschen bestehen, dass sie Anwendungen entwickeln und betreiben können, die von Millionen von Nutzern genutzt werden können da draußen und das ohne eigenes Infrastruktur Team.

Wenn man sich auf Zerfalle Computing konzentriert, also das entbindet einen nicht von allen administrativen Aufgaben. Man muss sich natürlich auskennen und dieses DevOps wissen sich auf schlauen was ist eine IP Adresse? Wie funktionieren Netze, wie sicher ich das ab und so weiter. Und wie Provision niedrig die Infrastruktur auf meinem gewählten Cloud Provider. Also diese klassische Rolle zwischen Entwickler und Betrieb dann aufnehmen. Aber ist es wirklich kein Admin im engeren Sinne mehr notwendig für eine Anwendung, die Millionen von Leute nutzen?

Das ist ja auch schon mal was. Also Apps zum Beispiel. Aber wie das so ist, auch wenn es wunderbar klingt und wer jetzt die Vorteile aufgezählt haben, da gibt es natürlich auch ein paar Nachteile, die wir schon gestrichen haben.

Ich glaube, der größte Nachteil, wo man sich immer bewusst sein muss, sobald man in der Cloud unterwegs ist und vor allen Dingen bei den sogenannten Managed Service. Was Fangnetze Service an der Stelle ist, ist, dass wir ein Vendor Login haben. Das heißt, wenn wir uns jetzt entscheiden, bei Apps in der Landa Funktion was zu tun, dann können wir das nicht eins zu eins so auch danach bei Google z.B. laufen lassen, falls das wichtig ist. Allerdings, das muss man natürlich auch zugeben ist, dass dadurch das Konzept hinter den Fangzähne bei den meisten festgeschrieben ist, muss man natürlich nicht die komplette Funktion neu schreiben, sondern an der Stelle eher den Input und Output so neu formatieren, dass er auch die neue Cloud passt.

Allerdings kannst du dann auch nochmal sein, dass er nach anderen Cloud ein bestimmtes Paket nicht verfügbar als Voda. Man kann es nicht nach installieren oder lohnt was. Also man legt sich erst mal auf eine Cloud fest, wenn man eben eine bestimmte Funktion Umgebung auswählt. Am Ende dessen muss man sich bewusst sein, was natürlich auch am Ende der Tweet of ist. Zwischen dem Komfort, den wir eben erwähnt haben, bezahlt man einer gewissen Stelle dann natürlich damit, dass man den Cloud-Anbieter treu sein muss.

Es hat sich noch keine Open Source Server alles Computing Platform herauskristallisiert, so z.B. kybernetisch. Es ist ja das DevOps Rechenzentrum oder der STANDARD für Container Computing kann man sagen, der von allen Cloud Anbietern angeboten werden muss, weil er einfach so omnipräsent ist. Und für Server des Computing gibt es so einen verbreiteten offenen STANDARD eben noch nicht, der ja vielleicht noch kommen kann. Es wäre zu wünschen, dass man dann zwischen den Anbietern eben auch wechseln kann.

Ich glaube, da besteht ein hohes Bedürfnis, gerade von großen Unternehmen. Aber wer weiß, was die Zukunft bringt. Einen weiteren Nachteil sehe ich im ansprecht Verhalten einer Sour, weil es Funktion. Es gibt keine Garantie, dass diese sofort eine Antwort liefert. Manchmal ist so eine gewisse Ramp up Periode notwendig von wenigen Sekunden, bis dann die Funktion eben ausgeführt werden kann. Das ist insbesondere dann kritisch, wenn ich eine interaktive Anwendung habe, also wo der Nutzer Eingaben tätigt und er dann auf die Rückantwort wartet.

Muss aber gestehen, ich habe hier noch keine Hands on Erfahrung. Ob das wirklich so ein großes Problem ist? Wir haben tatsächlich an der Stelle einmal die Erfahrung gemacht also diese Vampir Periode ist tatsächlich nur am Anfang oder wenn die Funktion eben noch länger nicht ausgeführt wurde oder immer nur sehr sporadisch ausgeübt. Dann hat man eben dieses von dir erwähnte Problem und wir hatten tatsächlich den Fall, als wir eben die erwähnte Vest API bloed haben bzw. Konsequenz von unseren Websiten aus gekrault haben.

Da ist der Traffic schlagartig angestiegen und an der Stelle das Skalieren fand nicht schnell genug statt. Auch wegen dieser WMP Zeit. Und da hat es dann eben die ersten 5 bis 10 Minuten sehr viele Bettwil Requests Server, Time Outs und so weiter gegeben. Was an der Stelle jetzt nicht so kritisch war, weil das keine Daten waren, die das Nutzerverhalten zu sehr beeinflusst hätten. Aber je nachdem in welcher Situation man ist, kann man sich das eben nicht erlauben an der Stelle.

Wir sind danach auch etwas schlauer geworden, dass wir dann eben entsprechend, bevor wir ein anderes neues Deployment oder ein neue Landa Funktion woanders eingebaut haben. Kann man das eben auch einmal händisch selber vorheizen in Anführungsstrichen, wo man dann eben entsprechenden Traffic simuliert, dass eben vorhanden ist. Und ich glaube, mittlerweile gibt es auch seit längerem eine Checkbox, die man in den entsprechenden Oberfläche setzen kann, wo dann eben die Funktionen auf Standby gehalten wird, sodass dann eben diese Scale out oder das Skalieren sehr viel schneller geht.

Allerdings muss man den eben einmal setzen und ich glaube, es kostet auch was eine gewisse Betrag, sodass man da nämlich ständig setzen sollte. Aber es ist gut zu wissen, wenn der Cloud Provider das nicht hat, dann sollte man eben einmal quasi händisch vorheizen, sodass dann bei dem produktiv ausrollen. Wenn man nicht die Möglichkeit hat, prozentual über mehr Traffic abzugeben, dann muss man eben einmal händisch das sicherstellen, dass der Traffic erarbeitet werden kann. Händisch vorheizen.

Das hört sich ja an wie bei einer alten Dampflokomotive her.

Ich war auch amüsiert, als ich das erste Mal den Vorhalt Begriff in diesem Kontext gehört habe. Aber am Ende ist es genau das.

Das ist einfach eine technische Notwendigkeit. Die Cloud Provider haben natürlich tausende oder Millionen Funktionen registriert von all ihren Kunden auf diesen Laufzeit Umgebungen und da wird wahrscheinlich nur ein Bruchteil konstant genutzt und alle anderen werden schlafen gelegt, damit es bei diesen geringen Kosten bleiben kann. Und wenn eine Funktion angefordert wird, dann muss erst einmal eine Laufzeit Umgebung Provision tiert werden oder diese Funktion dort zur Ausführung gebracht werden. Und das kann dann eben diese berühmt berüchtigten ein, zwei, drei, vier Sekunden dauern.

In der Zeit hat man keine Antwort oder die Anwendung kann ich weitermachen? Ja genau.

Und nach dieser Vampir Periode ist das eigentlich kein Problem mehr, weil die meisten glaubt wieder an der Stelle im hingehen und diese entweihen, wo die Funktion ausgeführt wird eben sozusagen Kelchen. Das erst mal nachdem die hochgefahren wurde. Diesen sauberen State sozusagen wird dann mehr oder weniger als Abbild für alle anderen Funktionen der Nacht genommen, sodass dann eben nicht mehr die gesamte Umgebung hochgefahren werden muss, sondern nur noch dupliziert werden muss, was an der Stelle sehr viel schneller geht.

Ein weiterer Nachteil und da sind wir selber, das weiß ich aus erster Hand schon häufiger dran gestoßen und haben da Lösungen für entwickelt. Ist die Ressourcen Beschränkung innerhalb einer Server Ulis Funktion? Das ist wahrscheinlich auch oder es macht einen Unterschied. Je nach Anbieter gibt es da unterschiedliche Ressourcen Beschränkungen. Aber generell kann man glaube ich festhalten, dass man in einem sehr, sehr engen Korsett steht, also beispielsweise, dass eine Funktion maximal 40 Sekunden Laufzeit aufweisen darf. Danach wird sie zwangs beendet oder dass sie nur ein Speicherbedarf von ein Gigabyte RAM konsumieren darf und kann dann nicht weiter wachsen.

Und diese Beschränkungen sorgen zum einen dafür, dass man sich natürlich sehr kurz fasst und die Funktion wirklich nur einen sehr kleinen Teil des Programms dann eben übernimmt. Auf der anderen Seite kann es ja vielleicht doch nötig sein, eine große Anzahl an Bildern zu konvertieren und dann müsste man das irgendwie anders lösen. Genau.

Also das ist so ein bisschen dem Anwendungsfall geschuldet. Ich glaube, das liegt in der Konzeption begründet, dass eben Bankwesens kleine logische Einheiten sind, die häufig wenig Ressourcen Anspruch haben und schnell antworten. Aber das dann in millionenfach sozusagen. Wie du richtig erwähnt, das haben wir auch schon häufiger Probleme gehabt mit diesem Kontext, einfach weil sich dann am Ende das Anwendung. Szenario doch anders entpuppt hat, als es ursprünglich erdacht war, sodass man dann am Ende dann doch auf eine andere Technologie ausweichen musste.

Und man muss sich wirklich vor Augen halten. Also nach diesen 40 Sekunden als Beispiel Wert wird die Funktion Ehard beendet, also mit einem Kill abgeschossen. Wenn man da noch offene Datenbank Transaktionen hat, werden die nicht abgeschlossen oder verbleiben dann in diesem Schwebezustand. Also das muss man wirklich bedenken, wenn man da eine Anwendung, die Zeit, einen weiteren Nachteil.

Wobei ich sagen muss, ich seh das gar nicht als so großen Nachteil, weil die Cloud Provider sich ja doch sehr viel Mühe geben, sind die unflexible Provisionszahlungen der Laufzeit Umgebung. Also ja, wir haben eben schon gesagt Java wird angeboten, Pfeifen wird angeboten, sie Charb wird angeboten. Alles was Rang und Namen hat, JavaScript wird angeboten, aber dennoch muss man sich Vereine dieser FOR konfektioniert Laufzeit Umgebungen entscheiden und kann nicht frei seinen eigenen Sophistik dort aufbauen.

Genau das ist auch je nach Cloud Provider ein bisschen anders gelöst und das von dir angesprochene Korsett einmal enger geschnürt als bei anderen, sodass man da eben Dependency es zum Teil können eben relativ leicht nache installiert werden. Gemeint sind Pulsen Umfeld ist ein Python Paket kann man eigentlich in allen Umgebungen nochmal nach installieren, weil das eben einfach der normale Weg ist. An der Stelle aber zum Beispiel System Bibliotheken, auf die zum Teil bestimmte Pakete angewiesen sind, weil das eben nicht nochmal neu implementiert wird in der entsprechenden Programmiersprache, sondern eben auf normalerweise vorhandenen System Bibliotheken zurückgegriffen wird.

Die können zum Teil Probleme bereiten, wenn eben entsprechend in der Laufzeit Umgebung das einfach nicht vorinstalliert ist.

Hast du da ein Beispiel? Also Verschlüsselung oder Open CSL? Würde mir direkt einfallen, dass man vielleicht nicht jedes Cypher Sued hat.

Genau an der Stelle ist es ein relativ spezielles Beispiel, also das Knuff PGP quasi. Die asymmetrische Verschlüsselung ist an der Stelle nicht installiert in den Äther Pantheons. Zumindestens hab ich das an der Stelle nicht rausgefunden, wie ich es laden könnte. Und so gut wie alle landesüblichen heißen Pakete, die eine einfache Interaktion mit nur P&G verschlüsselten Dateien ermöglichen, setzen eben darauf, dass entsprechend die Bibliothek dafür vorinstalliert ist, was an der Stelle daneben dann nicht der Fall war und was daneben zu sehr viel Rechercheaufwand geführt hat.

Am Ende mussten wir uns auch an der Stelle aus anderen Gründen auch für eine andere Umgebung entscheiden, einfach weil sich herausgestellt hat, dass die Daten am Ende zu groß waren für die Funktion.

Da kann man mehrere beschränkende Faktoren zusammen, also Software Estag und diese Ressourcen Beschränkungen, sodass man sich dann dort von der andere nicht zur weiles Computing Lösung entscheiden musste.

Ein anderes Beispiel, was ich auch noch nennen kann es QT benutzt, was Leuten, die mit einer Maschine noch nicht vertraut sind, wahrscheinlich was sagen wird. Es ist nicht mit dem STANDARD C Compiler kompiliert, zumindest standardmäßig nicht meine ich, dass das zumindest das zugrundeliegende Problem war. Auf jeden Fall ist es nur sehr schwierig möglich, das in z.B. PKW’s zum Laufen zu bekommen. Es funktioniert, aber man muss dann doch wieder mehr Aufwand da reinstecken, dass man das eben selber kompiliert, weil die Laufzeit Umgebung sich eben leicht unterscheidet zu dem, was man normalerweise vorfindet, wo das Paket normalerweise ausgeführt wird.

Naja, und das sind dann genau diese Details Probleme, die dann doch wieder Zeit kosten. Was ich noch als Nachteil sehe.

Wobei da muss ich auch sagen, dass es bei manchen Cloud Providern doch relativ gut gelöst ist, das Debugging, während man diese Funktion entwickelt als man brauche so eine Art Remote Debugger, der dann in diese Server alles Computing Environment den dieBürger dort andockt und dass man die Funktion dann eben Schritt für Schritt durchlaufen kann. Da gibt es auch ganz gute Lösung, aber man hat halt all die Probleme, die man mit Remote Backing hat. Die Ports müssen offen sein, man muss die Funktion registrieren, es klappt nicht immer und man sieht nur die Funktion oder kann halt dadurch steppen.

Dadurch, dass man den Ausführung Stack nicht kennt, weiß man nicht. Okay, hab ich vielleicht einen Speicher Problem oder man sieht einfach nicht so viel wie wenn man das auf einer nativen Maschine macht. Genau.

Es gibt an der Schalotten unseren Ansatz. Zumindestens kenne ich den bei Apps so, dass sie tatsächlich einen lokalen Emulator für die Landa Funktionen bereitstellen. Der läuft dann meistens in Docker. Ich glaube es gibt auch alternative Installations Möglichkeiten, aber da hab ich mich dann für Docker entschieden. Und da wird dann quasi ein Docker Image Gisborne, wo dann deine Funktion Godwein kopiert wird und darum herum wird eben dann diese Funktion Logic simuliert. Funktioniert auch ganz gut, wenn man eben sozusagen die Events gucken will, ob die übereinstimmen, ob der Programmcode überhaupt ausführbar ist.

Was allerdings nicht ein Porst wird, zumindest zu dem Zeitpunkt wo ich es genutzt sind genau die angesprochenen CPU Limits MMW Limit. Execute belämmert in der Größe und so weiter, das wird an der Stelle dann eben nicht geprüft, sodass selbst wenn es dann eben lokal ausgeführt werden kann, man trotzdem in der Cloud noch auf Probleme stoßen.

In der Podcast Episode mit Olli haben wir ja über diese zwei Faktoren gesprochen, dass die Ausführung Umgebung möglichst der Entwicklungsumgebung entsprechen sollte. Und durch diesen Bruch hier kann man sich dann eben neue Probleme einfangen. Hier ist das dann nicht gegeben. Jetzt haben wir die Vor und Nachteile besprochen und ich glaube, jetzt kann man ganz gut ein Bild zeichnen, in welchen Szenarien servil es Computing denn besonders sinnvoll oder eben nicht sinnvoll eingesetzt werden kann. Alexas Gilt’s hatten wir schon als Beispiel.

Du hast gesagt, Dienste, die Überrest APIs miteinander sprechen, eignen sich auch sehr gut, weil das einfach die natürliche Sprache der servile Funktionen ist. Wir haben gesagt, es gibt verschiedene Trigger, mit denen die Funktion gestartet werden kann. Also neue Datei in einem Cloud Folder hochgeladen. In einer Message Cue steht ein neues Objekt an. Ein Rest API Call ist auch ein Trigger Import. Daten sind vorhanden, klopfen irgendwo an, in einer Datenbank entsteht ein Eintrag. Wenn die Anwendung sich darauf stützt, kann man das auch sehr einfach abbilden und bei hoch parallelisiert Baan Anwendungen also zum Beispiel könnte man sich vorstellen einen Web Dienst wo Leute ihre Audiodateien hochladen können im Wave Format und bekommen einen komprimiertes MP3 zurück.

Das wäre ja perfekt. Parallelisiert war eben pro User oder sogar pro User Datei. Das wäre so ein Anwendungsfall wo man sehr gut dann eben sovieles Computing Funktionen einsetzen könnte.

Genau. Wobei man natürlich auch an der Stelle nochmal anmerken muss, dass man sich im Vorhinein überlegen muss, ob man entsprechend Größen Beschränkungen z.B. im Mäzenen, den Kommentierungen Beispiel zu bleiben größten Beschränkungen für die Josa auferlegt, damit das eben garantiert ist, dass in der benötigten Zeit abgearbeitet werden kann. Apropos benötigte Zeit ich bin auch über einen Artikel gestolpert, wo eine Architektur vorgeschlagen wurde, dass eben die sovieles Funktionen möglichst über Message KÜS miteinander verbunden werden sollen. Das Problem liegt darin, wenn man die Server Funktionen miteinander verknüpft und eine Funktion auf die Antwort einer zweiten Funktion wartet, dann wird das berechnet, weil die erste Funktion aktiv auf den Rückgabewert der zweiten Funktion wartet.

Und der Vorteil bei Message Cues ist, dass die erste Funktion ihren Job abschließt, in die Message Kyu ein Objekt anhängt. Die zweite Funktion läuft los, führt ihren Arbeitsschritt durch. Das Ergebnis wird wieder in die Message Kyu eingehängt und jetzt startet die erste Funktion wieder mit dem Ergebnis der zweiten Funktion und kann damit weiterarbeiten. Und das das kann man sich leicht vorstellen. Bei vielen, vielen 000. Funktionen, die vielleicht parallel ablaufen, doch sehr viel Zeit sparen kann und unterm Strich natürlich auch Kostenvorteile bringt.

Wobei an der Stelle würde sehr wahrscheinlich eher so laufen, dass du insgesamt drei Funktionen und zwei Medikus hast. Hast du sozusagen die erste Funktion in die erste mildtätigen schreibt, dann die zweite Funktion aus der ersten liest und in die zweite mit Süd-Korea einschreibt und dann die dritte Funktion darauf wieder reagiert. Dann hast du eben die Trennung der Microservices noch klarer, weil sonst hast du in der ersten Funktion zwei Logiken drin einmal den externen Trigger sozusagen und dann nochmal Handfeger.

Wenn, wie deine Antwort in die Meterdicken geschrieben wird an der Stelle genau serverseitig macht es natürlich Sinn, das auch noch aufzuteilen. Mir war jetzt eigentlich nur wichtig zu zeigen, dieses aktive Warten einer sovieles Funktion. Das sollte man vermeiden, eben aus Kosten, Gesichtspunkten.

Und ein anderer Vorteil natürlich bei diesem asynchronen ist, dass dann, wenn eine davon Ressourcen intensiver als einfach durch die Hörer Verarbeitungs Zeit, dann ist das eben auch an der Stelle abstrahiert. Ich glaube es ist insgesamt ein guter esein Hinweis für die Microservices Architektur, dass du die Kommunikation möglichst asynchron machst an der Stelle, wo du es kannst, dass man die Message Cues das machen lässt, wofür sie gedacht sind, eben per Sistieren von Objekten und die Koppelung der Funktionen.

Dann eben im Grunde wie bei einer Fabrik mit ganz vielen Fließbändern. An die Fließbänder sind da die Message QoS, dass man das dann so aufbaut. Mach doch das Recovery einfacher. Wenn einzelne Dienste streiken oder es zu Problemen kommt, dann sind die Nutzdaten weiterhin in den Message cuius vorhanden, in der Mehrzahl der Fälle aber sinnig verloren. Die Prozessors führen kann ein resoniert werden. Ich denke generell, dass sovieles Computing bei der Neukonzeption von Anwendungen, insbesondere Webanwendungen die Stärken ausspielen kann, wenn klar ist, dass die Anwendung in der Cloud betrieben werden soll, wenn klar ist, welche Funktionen dort umgesetzt werden können, auch mit Nutzer Interaction oder Import-Export Jobs.

Im Grunde so eine klassische Webanwendung kann schon oder weitestgehend Services umgebaut werden. Glaube ich schon. Im Grunde hat man mit der Services Computing Technologie oder Funktion, also Service. Ziel wie mit den Container Technologien nur auf der Abstraktionsebene höher. Man möchte Ressourcen schonen, wenn eine Funktion nicht laufen muss. Möchte man sich nicht darum kümmern und keine Hardware vorhalten oder die Hardware, kann man für andere Funktionen benutzt werden. Und nur die Funktionen, die jetzt gerade laufen müssen, sollen dann eben auch Hardware in Beschlag nehmen.

Genau wie bei Container Technologien auch plus Skalierung plus Ausfallsicherheit. Diese ganzen Benefiz, die man dazu bekommt bei der Container isierung, bekommt man natürlich auch beim Server des Computing dazu. Dennoch gibt es auch einige Szenarien, wo Functions A Service nicht sinnvoll sind.

Genau, also zwei prominente Beispiele. An der Stelle einmal das von uns bereits angesprochene Sache, dass wenn ein Server zum Beispiel 24 Stunden am Tag sieben Tage die Woche komplett ausgelastet ist, dann kann das potenziell günstiger sein, sich tatsächlich dann den virtuellen Server dahin zu stellen oder auch zwei oder drei je nach Last Verteilung an der Stelle. Was aber für mich der wichtigere Punkt ist, ist, dass man eben auch Limitationen hat. Man hat Lais Herz die Ressourcen, die man benutzen darf CPU, RAM und vor allen Dingen Dauer der Funktion, aber auch die Limitationen im deiner Umgebung.

Das heißt, wenn du Ebene Software Komponente hast, die bestimmte Bibliotheken benötigt, die man nicht ohne weiteres nach installieren kann, dann ist das eben definitiv ein Fall, den man nicht in den Fanzines umsetzen kann. Zumindestens aktuell nicht. Es kann natürlich sein, dass sich das in Zukunft ändert, aber nackte entstand hat man da einfach zu wenig Freiheiten, als dass man jede Anwendungs Situation da komplett abbilden kann?

Ich denke auch, es gibt ja durchaus Szenarien, wo man die volle Kontrolle über die Software Komponenten die man einsetzt haben möchte. Einfach weil man eine Anwendung betreibt, die zertifiziert ist mit einer bestimmten Version einer Datenbank. Und dann ist zwar weiles Computing auch nicht geeignet, einfach weil man alle Variablen kontrollieren muss, um die Anwendung konform zu betreiben, eben mit diesen zertifizierten Komponenten und der Cloud Provider, sogar wenn er die Anwendung anbietet. Es kann immer sein, dass es nächste Woche ein Update gibt und dann die nächste Version benutzt wird ungefragt und man dann quasi nicht mehr zertifizierte Software einsetzt.

Genau. Und noch ein anderer Punkt, der je nach Unternehmen weniger wichtig oder wichtiger ist, ist die Portabilität. Weil wir haben an der Stelle ja schon hervorgehoben, dass je nach Cloud Anbieter sich eben die Pantheons leicht unterscheiden und man dann eben die Anforderungen hat, das sehr leicht sehr schnell zwischen verschiedenen Clouds hin und her gewechselt werden kann. Dann empfangt uns an der Stelle nicht das Richtige, sondern dann muss man sich zum Beispiel mit Containern und der Cuba net selbst Bentheim angucken, die so standardisiert eigentlich in jeder Cloud auch als Managed Service angeboten werden.

Die Limits einer Server Umgebung als Nachteil. Also wenn man die nicht halten kann. Das haben wir schon angesprochen, dass das problematisch ist. Also wenn man sehr viel Memory braucht oder kontinuierlich CPU braucht einen Punkt, den man noch gar nicht angesprochen haben und der auf jeden Fall ein Nachteil ist. Denn der Server des Computing Welt ist das Thema Security, denn man muss sich eben vor Augen führen. Der eigene Code wird parallel mit Code von ganz vielen anderen Unternehmen ausgeführt.

Generell ist das schon gegeneinander abgeschirmt, aber wenn man jetzt an die Prozessor Fehler der großen 86 Hersteller denkt, ist das natürlich ein Thema. Also man läuft mit Code von anderen Unternehmen, mit Daten von anderen Unternehmen Memory parallel und es gibt einfach Anwendungsfälle, wo man das rechtlich nicht darf oder wo man das einfach nicht möchte. Und in diesen Fällen ist Server des Computing oder generell Cloud Computing ist auch schon schwierig. Dann vielleicht nichts für ein naja. Also in den Fällen muss man wie du schon sagst, generell bieten Cloud Provider Möglichkeiten, dass man eben exklusiv auf Service läuft, also auf tatsächlich Hardware Maschinen.

Ich bin mir nicht sicher, ob das in den Pantheons vorgesehen ist. Wenn ja, bezahlt man da deutlich mehr, weil dann natürlich die gesamte Hardware bezahlt werden muss, auch wenn man sie nicht nutzt. Das heißt, da sind dann potenziell andere Services durchaus besser geeignet, wenn man eben diese Bedenken berechtigterweise dann hat.

Das muss man dann abwägen, je nach Anwendung, die da ausgeführt wird und natürlich auch, welche Arten man am Ende verarbeitet.

Herr Server, weil Computing eignet sich insbesondere dann, wenn man dieses Microservices Service Masch eben hochfahren kann oder die Anwendung sich darauf abbilden lässt. Und man kann glaub ich sagen in anderen Szenarien opfert man den einen oder anderen Vorteil. Dieser SVR Wallis Umgebung dann schon eben zugunsten von mehr Kontrolle. Kann auch Szenarien geben, wo man z.B. Abhängigkeiten zu externen Diensten hat. Also bei meinem aktuellen Projekt gibt es z.B. viele Stammdaten liegen einem SAP System, was mehrere Sekunden benötigt, um komplexe Anfragen zu beantworten und hier Ergebnisse zu liefern.

Und da würde ich mich auch schwertun direkt Server Funktionen anzudocken, ohne. Ein Caching ler dazwischen. Weil ich sonst nicht sicherstellen kann, dass ich diese 40 Sekunden Marke oder diese Zeit SchrÃnke der Server alles Funktionen nicht irgendwann mal reiße und dann abgebrochen wird und in undefinierten Zustand habe. Genau. Häufig ist es eben, solange man sich in der Cloud selber bewegt. Vor allen Dingen beim gleichen Anbieter ist man relativ sicher, was diese Timelords angeht. Hat natürlich niemals davor gewappnet.

Es gibt auch da Systeme, die einfach nicht auf zeitige Antworten ausgelegt sind. Aber wie du richtig sagst, sobald man externe Systeme noch dazukommen, hast du einfach da nicht zwangsweise die Kontrolle drüber. Zumal man, wenn man jetzt nochmal sagt externe Systeme, die man selber gar nicht kontrolliert, weil es nochmal von einem anderen Anbieter kommt, dann muss man eben schon auch gucken, ob da die Anforderungen eingehalten werden können.

Ja, wenn das GAP zwischen alter Technologie und servile Computing oder funktionelles as a Service, die ja wirklich ganz neu und an vorderster Front der Entwicklung stehen, wenn Scepter dazwischen zu groß ist, dann muss man schauen, wie man das minimiert, damit man nicht zu viele Abstriche machen muss in beiden Welten. Ja, vielen, vielen Dank, Max, dass du heute da warst. Wenn unsere Zuhörer Fragen haben oder Feedback senden möchten, können sie das gerne tun unter der E-Mail-Adresse, Podcast etc.

. Gilbert E. Lasst uns gerne eine Bewertung dar und abonniert unseren Podcast. Und wir freuen uns immer, wenn ihr diesen auch an Freunde und Kollegen weiterleitet. Für mehr spannende Technologie. Tim schaut auch gerne auf Skill bei TE Slash Blog vorbei. Max, ich bedanke mich ganz herzlich bei dir für dieses wahnsinnig interessante Gespräche rund um Server des Computing und das Thema Functions Service. Es hat einen Riesenspaß gemacht. Danke Meads, auch Spaß gemacht, dabei zu sein.

Wunderbar! Ich wünsche dir noch einen schönen Abend.

Danke. Gleichfalls.

Maurice KnoppSkillbyte Podcast #34: Serverless Computing – Hype oder Chance? AWS Lambda, Azure Functions, Google Cloud Functions richtig verwenden
Mehr

Skillbyte Podcast #30: Die Zwölf Faktoren des Cloud Native Development (Teil 2)

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

In diesem Podcast geht es um das Thema: Die Zwölf Faktoren des Cloud Native Development (Teil 2)

// Inhalt //
01:16 – Faktor 7: Bindung an Ports / Port binding
06:36 – Faktor 8: Nebenläufigkeit / Concurrency
14:31 – Faktor 9: Einweggebrauch / Disposability
19:34 – Faktor 10: Dev&Prod Vergleichbarkeit / Dev&prod parity
25:05 – Faktor 11: Logs
29:37 – Faktor 12: Administrationsprozesse / Admin processes

Twelve Factor App: https://12factor.net/

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

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #30: Die Zwölf Faktoren des Cloud Native Development (Teil 2)
Mehr

Skillbyte Podcast #29: Die Zwölf Faktoren des Cloud Native Development (Teil 1)

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

In diesem Podcast geht es um das Thema: Die Zwölf Faktoren des Cloud Native Development (Teil 1)

// Inhalt //
06:34 – 5 Leistungsversprechen von 12 Factor Apps
06:44 – Generelles Ziel: Verwednung deklarativer Formate
08:12 – Generelles Ziel: saubere Abgrenzung
08:43 – Generelles Ziel: Gleichartige Umgebungen (Dev, Stage, Prod)
08:55 – Generelles Ziel: Cloud-Deployments
09:00 – Generelles Ziel: Skalierbarkeit
10:56 – Faktor 1: Codebasis / Codebase
15:32 – Faktor 2: Abhängigkeiten / Dependencies
21:03 – Faktor 3: Konfiguration / Configuration
25:47 – Faktor 4: Unterstützende Dienste / Backing Services
29:59 – Faktor 5: Build, release, run
35:47 – Faktor 6: Prozesse / Processes

Twelve Factor App: https://12factor.net/

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

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #29: Die Zwölf Faktoren des Cloud Native Development (Teil 1)
Mehr