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

AUTOMATISCH ERZEUGTES TRANSKRIPT

Oliver
Ich habe zwei Projekte in dem Rahmen gemacht beim gleichen Kunden und die wurden jeweils in einen on-premise Kubernetes Cluster deployed, den man auch so bei jedem Cloud Provider innerhalb kürzester Zeit provisionieren könnte. Man hätte diese gesamten Projekte auch innerhalb wirklich kurzer Zeit in jede Cloud Platform verschieben können.

Maurice
Herzlich willkommen zur Skillbyte Podcaste Episode Nr. 29: Die zwölf Faktoren des Cloud Native Development. Abonniert unseren Podcast, wenn ihr mehr spannende Themen aus dem Technologie-Umfeld hören möchtet und wenn ihr Hörer Fragen hat, sendet gerne gerne gerne eine E-Mail an podcast@skillbyte.de. Lasst uns gerne eine 5 Sterne Bewertung da, wenn ihr den Podcast gut findet und wie bereits gesagt: Wir freuen uns immer über Feedback. Ich freue mich ganz besonders heute über meinen Gast, der vor Urzeiten schon mal in einer Podcast Episode zum Thema Airflow dabei war. Hallo Oliver!

Oliver
Hallo Maurice. Freut mich wieder dabei sein zu können.

Maurice
Ich freue mich, mit dir heute über Cloud Native Development bzw. die Eigenschaften und Paradigmen dorthinter sprechen zu können. Das ist ja doch ein sehr heißes Thema, was viel nachgefragt wird zur Zeit.

Oliver
Ja, würde ich auch so sagen. Ich selber hatte damit bisher nur in on-premise Systemen Kontakt, also nicht in wirklichen Cloud Systemen, aber im unmittelbaren Umfeld von den Projekten wurde das Thema auch in der Google Cloud und bei AWS eingesetzt. Ja, ich kann bestätigen Ich kenne viele Leute, die sich damit beschäftigen und hatte da auch schon viele Diskussionen zu dem Thema.

Maurice
Jetzt kann man schon sagen, dass die Infrastruktur, die du benutzt hast. Die war schon Cloud Infrastruktur, allerdings in einem lokalen Rechenzentrum, weil das der Kunde so erfordert hat, ne?

Oliver
Richtig genau. Also, ich habe zwei Projekte in dem Rahmen gemacht, beim gleichen Kunden, und die wurden jeweils in einen U-Bahn-Netz Cluster Diplomat, den man auch so bei jedem Cloud Provider innerhalb kürzester Zeit Provision pieren könnte. Man hätte diese gesamten Projekte auch innerhalb kurzer Zeit in jede Cloud Platform verschieben können.

Das ist ja ein super Vorteil bei den Technologien. Das ist im Grunde man. Diese Abstraktion hat zwischen Ausführung, Umgebung und Software Schicht. Ob es in einer echten Cloud läuft, in einer Cloud oder auf dem lokalen Developer Notebook Kit ja für die Applikationen gleich aus?

Absolut.

Auf jeden Fall hat sich einer der frühen Cloud-Anbieter Hero Q, der eine oder andere wird in kennen. Gedanken gemacht. Was bedeutet denn eigentlich Cloud Native Software Development, also wenn man Applikationen schreibt, die hinterher in der Cloud ausgeführt werden sollen? Gibt es verschiedene Dinge zu beachten, um die Wartung zu vereinfachen? Die Entwicklungs Geschwindigkeit zu steigern und generell ein stabiles System und skalierbare System zu erstellen und hat dieses Manifest ins Leben gerufen der 12 Faktoren. Den Link dazu packe ich in die Notizen zu dieser Podcast Episode.

Im Grunde geht es ja darum, dass der Micro Service Trend weitergedacht wurde. Interessant sind diese 12 Faktoren des Cloud Native Development natürlich für die Zielgruppen der Softwareentwickler, die natürlich die Anwendungen bauen. Da zählen wir auch dazu. Auch der Oops Engineers, also Menschen, die die Anwendungen ausrollen und betreuen. Da kommen wir gleich noch dazu. Das ist oftmals im Cloud Native Development die gleiche Person, und es läuft immer mehr zusammen. Ich denke aber auch, dass diese Podcast Episode hier für Manager oder IT-Manager interessant ist, die wissen wollen, wie man heute professionell Software entwickelt, die eben die Möglichkeit hat, im Rechenzentrum wie auch in der Cloud mit minimalste Migrationsamt Aufwand zu funktionieren.

Absolut. Ich kann da insofern aus eigener Erfahrung sprechen, als das bei mir genau das eingetreten ist. Ich war in den Projekten tatsächlich in Personalunion der Entwickler der Software, also das, was wirklich Frontend und Backend microsd Service in einem Fall war und auch dafür zuständig, die Infrastruktur, Infrastruktur, Code in bester Manier zur Verfügung zu stellen und das Ganze eben auch auszurollen. Die Betreuung hab ich dann auch am Anfang übernommen, und mittlerweile ist das dann in die Hände von anderen Kollegen übergegangen.

Dieser Kunde hat ja eine umfangreiche Cloud Strategie oder Multi Cloud Strategie. Das heißt es sogar relativ wahrscheinlich, dass die Anwendung eines Tages auch mal dort betrieben wird.

Ja, das denke ich auch. Ich selber habe ja schon eingangs gesagt, dass ich bei den wirklichen Projekten damals nicht beteiligt war. Aber dass die Kollegen, die das gemacht haben, auch ihre Software ganz bewusst Cloud Eidgenössisch geschrieben haben und dann eben nur noch mit minimalen Konfigurationen änderungen, dann auch eben in jede Cloud Umgebung, die innerhalb kurzer Zeit, was auch ganz gezielt gewünscht war, weil der Kunde verschiedenste Cloud Provider im Portfolio hatte.

Früher waren es die Application Server. Heute sind die Cloud Provider die ziel. Deployment Plattformen, auf denen es funktionieren muss. Erinnert mich ein bisschen daran? Ja, und auch wenn die alle sehr ähnliche Möglichkeiten den den Entwicklern und den ingeniös zur Verfügung stellen, gibts halt doch dann gewisse Feinheiten. Ob das jetzt bestimmte Tools sind, dies z.B..

Google Cloud gibt oder bestimmte Datenbanken es nur bei RWE? Das muss man auch berücksichtigen. Also kleine Unterschiede gibt es schon.

Ich finde nicht nur kleine, sondern auch gerade im Bereich des Reifegrad der Lösungen gibt es noch sehr große Unterschiede. Finde ich persönlich. Was das Tuning angeht, hast du es schon angesprochen. Ich finde, da sind die Unterschiede nicht ganz so groß. Was man aber wiederum selber machen sollte, ist, dass man so einen Meter Layer verwendet wie zum Beispiel kybernetische. Um wieder diese Andersartigkeit der unterschiedlichen Cloud Provider noch ein weiteres Mal zu abstrahieren, um dann weitere Flexibilität gewinnen zu können in diesem Bereich macht es auf jeden Fall leichter.

Ich denke, dass es an der einen oder anderen Stelle schon hilfreich sein kann, wenn man cloud spezifische Produkte des Cloud Providers auch einsetzt, weil die einfach in dem Umfeld auch in Sachen Zuverlässigkeit und Performance herausstechen. Aber wenn man wirklich Cloud diagnostisch arbeiten will oder muss, dann ist dieser, zwischen der quasi Weg abstrahiert, auf jeden Fall nötig. Abstraktion ist schon das richtige Stichwort. Die 12 Faktoren sind ja quasi Methoden, um eine Software as a Service App zu bauen, die im Wesentlichen 5 Kern Leistungsversprechen liefert.

Zum einen sind da die Verwendung von Clara tiefen Formaten, um die situps zu automatisieren, also Hardware zu pro Visionären. Das ist einfach dem geschuldet, dass bei Deklarationen Formaten z.B. SQL ist eine sehr sprechende, deklarierter Sprache. Da kann man es vielleicht verstehen, dass diese Sprachen tendenziell sehr einfach zu verstehen sind, weil sie im Grunde den englischen Satz schon vorwegnehmen, was da eigentlich geschehen soll. Und die Einfachheit ist auch das Ziel dieser Formate, nämlich neue Mitarbeiter schnell ins Projekt zu holen.

Dass auch Leute, die sich mit einem Format, einem Tool noch nicht so beschäftigt haben, aber in sehr einfachen englischen Worten verstehen können, was hier eigentlich passiert. Also Deklarierter Formate ist ein Leistungsversprechen um kurz direkt Einzelmarkt.

Das macht es auch für die beiden Seiten Entwickler und DVB-S Engineer oder vielleicht sogar Systemadministrator leicht zusammenzuwachsen, weil wenn man in dem Zusammenhang bedenkt, dass die Infrastruktur, Service oder Infrastruktur Escalade, dass das jetzt auch theoretisch vom Softwareentwickler mitgemacht werden kann, was vorher überhaupt nicht auf seiner Liste hatte, dann macht es sowas natürlich leichter, da einzusteigen. Und genauso ist es für jemanden, der das nachher betreuen soll, im Betrieb und eventuell einspielen soll oder sowas leichter, damit klarzukommen.

Wenn das auf der anderen Seite auch die Clarity soll gelöst, Bergener, dann rückt man einfach näher zusammen.

Das sagst schon ein weiterer Punkt, der die System Administration betrifft, ist Teck Contract. Ich sage es mal auf Deutsch Saubere Abgrenzung. Da geht es einfach darum um der Portier bei der Ausführung Umgebungen. Es soll im Grunde keinen Unterschied machen, ob die Software auf meinem Laptop läuft oder in einer Cloud Umgebung oder auf einem Produktionsverfahren. Für die Anwendung soll das transparent sein, und die Anwendung soll immer im Grunde die gleichen verfügbaren Dienste sehen. Das wird auch von Faktoren abgedeckt.

Ein weiterer Punkt, der da direkt mit rein Spiel ist die einheitliche Umgebung also. Zwischen der Entwicklungsumgebung, der Testumgebung der Produktions Umgebung soll es möglichst wenig Unterschiede geben von den Software Komponenten her Cloud Deployment. Nach den DVB-S Prinzipien die erste schon angesprochen, sollen einfach möglich sein, und die Anwendung, die hinterher entsteht, ist Skalierung fähig. Also soll ohne umfangreiche änderungen an der Software sowohl auf einem Server als auch auf Hunderten Wölbern betrieben werden können und dadurch natürlich viel mehr Last verarbeiten können.

Für mich war das immer der Herausstechen neben der Portier und der sauber abgesteckten Umgebung etwas, was sehr, sehr eng zusammenhängt. Aber die Skalierung Fähigkeit ist wirklich das Kern Argument für mich hier an der Stelle, weil das ja sogar unter bestimmten Umständen möglich ist, dass das Deployment automatisch skaliert, bestimmte Grenzwerte überschritten werden, sei es CPU oder RAM, Verbrauch oder Anzahl der Requests pro Sekunde gegen den gleichen Webserver. Dann werden einfach innerhalb kürzester Zeit neue Instanzen von der Applikation hochgefahren.

Die Last wird wieder verteilt, und man kann weiter erreichbar sein. Und dann wird auch wieder runtergefahren. Weil in der Cloud kostet ja jede blockierte Ressource Geld, und wenn sie nicht gebraucht wird, kann man automatisch damit wieder runterfahren.

Das ist absolut großartig wie bei einem Gummiband Man dehnt den Server Park so weit aus, wie man das halt dann braucht für die jeweilige Situation? Ja, absolut. Was ich noch sagen möchte, ist, dass die 12 Faktoren explizit nicht an eine bestimmte Programmiersprache, die Zuschriften werden mir kommen, nicht an eine Programmiersprache oder an eine bestimmte Software ökosystem gebunden ist, sondern generell einsetzbar ist. Natürlich gibt es Programmiersprachen. Etwas moderneren ökosystemen, die das Tuning für die nun folgenden zwölf Faktoren mitbringt, denn die gehen wir gleich einzeln durch.

Das wird bei modernen Sprachen einfacher sein, als wenn ich jetzt Fortran in die Cloud bringen möchte, ohne das jetzt genau zu kennen. Wahrscheinlich bin ich schon niemandem auf den Schlips getreten. Aber generell gelten diese Paradigmen hier, nach denen man entwickeln sollte, natürlich generell für Cloud nette Apps, egal in welcher Sprache sie geschrieben sind oder welches welche Frameworks Sie benutzen. Dann können wir jetzt richtig vom Seitenrand des Schwimmbeckens eintauchen in das Cloud Native Development bzw. in die zwölf Faktoren.

Und ich würde einfach vorschlagen, dass wir mit dem ersten Faktor beginnen. Und das ist, wie sollte es bei Software anders sein? Die codebasis oder englisch codebasis. Was soll mit der codebasis geschehen? Wie soll die verwaltet werden? Das ist ganz wichtig, und das steht aus gutem Grund an erster Stelle. Software Code gehört in ein Wageningen System, git zum Beispiel oder alte Software, meinetwegen auch ein SVR. Wenn das noch im Betrieb eingesetzt wird. Aber es ist ganz wichtig, dass man Code, wer signiert und in einen Code Repository eincheckt.

Absolut. Das ist absolut Quinten essenziell. Nicht nur, wenn man alleine daran arbeitet und sich überlegt, ob die änderungen der letzten zwei Stunden nichts getaugt und dann, statt jetzt mit kontrollzentren alle einzeln rückgängig zu machen, rollig einfach zurück auf den letzten stabilen Release. Sei es, weil ich kollaborative arbeiten möchte und Aufgaben aufteilen oder einfach die Komponenten von verschiedenen Leuten zusammenführen möchte, uns vielleicht Konflikte im Code gibt. Das kann ich darüber alles viel, viel besser managen. Ein Punkt, auf dem wir bestimmte Lebenszusammenhang auch noch eingehen werden, ist kontinuierliche Entwicklung und kontinuierliches Deployment mit Pipelines, die dann auch schon meine Tests abdecken.

Also was? Im Fall von Git kann einem das alles aus einer Hand zur Verfügung gestellt werden.

Was ich hier nochmals meinen Favoriten an der Stelle hervorheben möchte git hat so ziemlich alle anderen Systeme substituiert. Du sagst es genau richtig und es bietet so viele Vorteile, sogar wenn man alleine entwickelt. Als einzelner Entwickler auf einem Projekt würde ich das empfehlen. Man hat Dimensionierung, das heißt, man kann immer gucken. Man kann mit der Version von letzter Woche vergleichen. Man kann eindeutige Texte für Releases vergeben. Meistens wird das Repository ja nicht auf dem eigenen Rechner betrieben, sondern es gibt nochmal ein SPIEGEL Server irgendwo.

Wenn man seine Arbeit pusht. Auf diesen Server hat man quasi eine implizite Datensicherung, die dann auch direkt wieder von anderen Leuten genutzt werden können, die vielleicht auch kurzfristig ins Projekt kommen. Also absolut essentiell.

Sourcecode gehört in ein Code Repository, und das ist für das Umfeld, über das wir hier jetzt reden. Cloud Application ist das nochmal besonders wichtig, weil die codebasis hier ja auch die Infrastruktur umfasst. Das darf man nicht vernachlässigen. Hier ist an der Stelle nicht nur der Code des eigentlichen Micro Services oder der Applikation, sondern wirklich auch hinterlegt. In welchem Umfeld und unter welchen Hardware nahen Bedingungen läuft die ganze Applikation hier und soll betrieben werden. Damit kontrolliert man auch wirklich seine Infrastruktur.

üBer die züll Faktoren gehen sogar soweit, dass sie sagen OK. Jede App also als App ist eine funktionseinheiten mit beschrieben hat ihre eigene Coat bake. Also wenn ich eine große Anwendung habe, sagen wir mal aus einem Bild abblockt und einem Bild Skalierung aus Systemen. Das sind jetzt zwei Services, die arbeiten zusammen. Dann hätten beide Apps, die zusammenarbeiten, ein eigenes Repository und würden sich dann, wenn sie sich gegenseitig bedingen, über ein Modul. Da kommen ja gleich noch zu inkludieren oder über einen Service ansprechen.

Aber jede App hat eine codebasis.

Genau das ist an der Stelle einfach eine Frage von Ich sag mal auch Code, Hygiene, wenn man so will. Man möchte das an der Stelle einfach so sinnvoll kapseln, wie es irgendwie möglich ist. Das ergibt an der Stelle einfach viel Sinn. Ich meine, jeder kennt Spaghetti Code, und das möchte man nicht auch noch auf seiner Infrastruktur und in seinem Gesamtprojekts. Da Teile Will zum Beispiel haben, geht es einfach auch ein bisschen ein bisschen Ordnung an der Stelle.

Plus auf diese codebasis kraft ja nicht nur der Entwickler zu, sondern es ist schon angesprochen Die sihlcity Strecke, also die Continuous Integration Strecke Continuous Deployment Strecke, die aus dieser Code Base den Source Code entnimmt und ihn dann in ein sogenanntes Pleuel umwandelt. Also paktiert, Abhängigkeiten mit hinzufügt, gegebenfalls Source Code kompiliert in ausführbaren Maschinencode und das Ganze dann auf eine Infrastruktur ausrollt. Und diese Schritte können ja eben nur erfolgen, wenn diese Instanz auch auf den Source Code, auf die letzte Version der Source Code Solow Version, die man lesen möchte, Zugriff hat.

Genau da bietet eben alles aus einer Hand um. An einer Stelle alles zu orchestrieren, das ist wirklich sehr, sehr angenehm und übersichtlich. Der zweite Faktor das Management der Abhängigkeiten bzw. englisch die CS. Die 12 Faktoren postulieren, dass eine Faktor App, also eine App, die diesen Regeln folgt, sich niemals auf externe Systeme Abhängigkeiten verlassen darf. Was heißt das konkret? Das heißt, dass die Anwendung nicht voraussetzen darf, dass auf dem Betriebssystem beispielsweise Image Magic installiert ist, um die Bild Konvertierung durchzuführen, oder das SMTP, da Mails verschickt werden können, wenn es Bilder konvertieren möchte und Mails verschicken, müssen diese Pencil explizit mit diesem Release verpackt sein.

Das ist ein Problem, was man vielleicht, wenn man mal auf der System Admin oder DVB-S Seite unterwegs war, kennt. Da treten Entwickler an einen heran oder Daten Analysten oder Data Scientists und sagen, sie hätten von einem bestimmten Stück Software gerne das abgestufte Ariely Stack installiert, und der nächste hätte gern was anderes. Und da ist man einfach mit unglaublich viel Arbeit konfrontiert, wenn man auf seinem mainframe auf jedem Einzelnen aus alles nachhallen will an Software, die installiert sein muss, wo gegenüber man eine Applikation so container arisiert, sag ich mal salopp ausgedrückt kann jeder Entwickler genau die Software auf die präziseste Versionsnummer spezifiziert die Pleuel, die er oder sie gerade braucht.

Der kann also seine App einfach akzeptieren und dann laufen lassen und muss sich nicht mehr darum kümmern, dass auf Server 123 Pfeiffen 307 installiert ist.

Docker ist hier das Stichwort. Man nimmt nicht mehr die Betriebsystem Komponenten, sondern mit Docker images rüstet man diese Funktionen in dedizierten Versionen danach Versionsnummer ein und kann dann so ein Steeg aufbauen, um die Funktionalität der Anwendung zu ermöglichen. Jede Software Entwicklungsumgebung hat ja auch ihre eigene oder die meisten ihrer Dependance, die Deklaration Manifest Moeglichkeit, also zum Beispiel das Pom smell bei Java, das Maven System Menschentypen SIS für Perl. Es ist, glaube ich, CPA, denn bei Ruby gibt es Ruby Gams.

PHP. Org verpfeifen oder kannst du nicht besser aus?

Ja, das validiert ist ein bisschen von Umgebung zu Umgebungen, was da im alten Umfeld möglich ist. Aber man kann zum Beispiel, wenn man jetzt konkret hier in dem Docker oder Obernitz Umfeld unterwegs ist, kann man die Datei einfach senden, sie Hegeler nennen, und dann werden die Pakete automatisch mit installiert. Das ist wirklich wirklich gut gelöst an der Stelle. Ich möchte hier noch ganz kurz einwerfen Docker bin ich auf jeden Fall. Bei dir ist das Tool der Wahl in den allermeisten Fällen.

Es gibt aber natürlich auch noch andere am Markt und sicherlich anderes beliebtes Tool, was auch seiner pro und contra Argumente gegenüber Docker hat. Wäre Singularity aber dem Ganzen, kann man wahrscheinlich eine eigene Podcast Episode widmen, wie man Container frisierte Applikationen baut. Deswegen möchte ich hier nicht ins Detail gehen. Aber es gibt Alternativen zu Docker.

Ja, doch, das hört sich doch gut. An Németh Singularity habe ich noch nicht gearbeitet. Docker hat bisher alles getan, was ich wollte. Muss ich wirklich sagen, das ist auch gleichzeitig? Wir haben gesagt, wir können die Dependance als erklärende Deklaration in diesem manifesten Maven Poems zum Beispiel mit Docker oder auch mit diesem virtuell. In Pfeiffen geht man sogar noch einen Schritt weiter und isoliert die Anwendung von den Systemen Bibliotheken, damit man quasi auch sicher geht, dass keine externen Abhängigkeiten sich einschleichen.

Es könnte ja sein, dass ein Tool, was sehr häufig oder sehr verbreitet ist, z.B. das die Anwendung sich darauf irgendwie verlässt, aber in und auf dem lokalen Entwicklungs Laptop ist es auch vorhanden und meinetwegen auch auf dem Testsystem vorhanden, aber auf dem berühmten Server 123 ist es noch nicht installiert worden oder ist es nie installiert worden? Und wenn ich ein Virtual emv benutze oder Docker Layer benutze, gehe ich halt sicher, dass ich explizit nicht auf die System Liberias zugreifen und mir dieses Problem dann nicht einfangen kann.

Also es würde vorher auffallen, wenn eine Komponente fehlt, und zwar konsistent in allen Umgebungen, richtig. Und wenn man einfach überall das gleiche Image, sei es jetzt Docker oder was anderes benutzt, dann ist eben auch überall das Gleiche drin. Das macht es an der Stelle schon wirklich übersichtlich. Und dazu muss man halt auch noch sagen, dass am Docker extrem leichtgewichtig gebaut werden kann. Also ein Docker Image, was genau das tut, was ich möchte und nicht mehr.

Das hat zum Beispiel viel weniger OVA hat als eine komplette virtuelle Maschine, die ich auf einem wirklichen physischen Server installieren würde. Also ich kann natürlich auch in Docker ein komplettes Betriebssystem z.B. Ubuntu. Was anderes aus dem Linux Kosmos installieren. Aber ich kann eben auch viel, viel weniger nehmen und damit viel Leichtgewichtige und Performanz unterwegs sein.

Die Entwicklung verändert. Ein weiterer Vorteil ist natürlich bei Docker Wenn du die Abhängigkeiten für die Anwendungen auch für diese Docker Layer definiert hast, dann ist auch das Setup eines neuen Entwicklungs Laptops für ein neues Teammitglied oder eines neuen Service zu Testzwecken super, super einfach. Man installiert die Runtime und Independents, die Manager für das jeweilige Projekt, und innerhalb weniger Minuten hat man eine neue Umgebung da stehen.

Das ist wirklich einfach dadurch zu Provisionsbasis.

Der dritte Faktor ist die Konfiguration Konfiguration, und zwar besagt das Manifest, dass Konfiguration als Salles das definiert ist, was zwischen den Einzelnen die Bleus der Stage Entertainment unterschiedlich ist, also beispielsweise Pfade zu Datenbanken oder anderen Services, die der DNS Name oder die IP-Adresse unterschiedlich kredenzte, Builds zu externen Diensten oder zu cloud-diensten Konfiguration oder Purdy Play offs spezielle Pfade zum temporären Cashs Ordner zum Beispiel.

Das ist vielleicht auf dem lokalen Laptop andere als offen Produktions Server, einfach weil der Platz anforderungen. Andere sind gehaust, Nemes und so weiter. Das sollte man auf gar keinen Fall im Source Code speichern, sondern als externe Konfiguration. Und so wurden Anwendungen, würde ich sagen, auch seit Jahren schon gebaut, dass man sagt Bitte so nicht in den Source Code, sondern in konfigurationsdateien. Was hinzukommt Beim Cloud Nativ Development ist das, so eine flache konfigurationsdatei jetzt nicht immer mehr reicht, sondern dass man das Environment variablen verpackt, ein Sprach und STANDARD verwendet, um diese Konfiguration zu hinterlegen.

Das ist ein wichtiger Punkt an der Stelle, weil es einfach auch dem Entwickler oder der EntwicklerInnen immer mal wieder passieren kann, dass man, wenn man zum Beispiel erst mal auf seiner lokalen Maschine, wirklich auf seinem Laptop entwickelt, um es dann auf einem meiner Cloud Stage Umgebung zu testen, einfach vergisst, einen Parameter zu ändern. Wenn man in so einer Konfiguration von selbst, der kleinsten Applikation, das schnell ein paar 100 Parameter, die da zusammenkommen können. Und jetzt reden wir noch nicht über Anwendungen, wo Dutzende EntwicklerInnen und Entwickler dran gesessen haben, wo das wirklich wirklich viel wird.

Und das muss dadurch einfach sichergestellt sein, dass da nichts schiefgehen kann und b dass das alles zentral auch wieder in der Code ist. Diese Verweise darauf entsprechend signiert sein können. Und man hat mit, sodass Sie die Pipeline natürlich dann auch noch den Vorteil, dass, wenn man jetzt sagt, die Bitte nach Produktion oder nach Stag oder nach Development oder Produktion oder wie auch immer, dass die Pipeline das dann für einen schon übernehmen kann, wenns richtig konfiguriert ist.

Generell sollte man einfach nichts Umgebung Spezifisches im Sourcecode haben. Das riecht schon nach Katastrophe. Da sind wahrscheinlich schon Firmen untergegangen, weil dieser Ratschlag nicht beherzigt wurde.

Das Schlimmste, was man machen kann, ist fade zu Subsysteme, das oder oder Hausnamen sowas im Source Code Hardcore drinstehen zu haben. Das ist der Kardinalfehler schlechthin. Das kennt jeder. Das fängt schon in der Schule an, wenn man mal programmiert hat. Das ist immer schlimm, wenn man mal irgendwas ändern muss. Ich denke, dass man auch bei dem ganzen Configuration Thema auch berücksichtigen sollte, dass Zugangsdaten jedenfalls für Datenbanken für die Cloud als solche oder auch Haq hieß, um auf entfernte Systeme zuzugreifen.

Das war es, was ja durchaus sicherheitsrelevant ist, auch für den Kunden, bei dem man das gerade macht, oder für das eigene System, das sowas auch nicht in der codebasis liegen sollte. Selbst wenn Umgebungen wie Couchgarnitur einem da eine Verschlüsselung anbieten, die aber auch nichts anderes ist als in dem Fall eine ganz simple Base 64 Codierung, sodass man das eigentlich einfach wieder zurück decodieren kann, um es wieder im Klartext lesen zu können. Da muss man also ein bisschen aufpassen, wie das gelöst wird.

Dafür bietet U-Bahn-Netz aber Möglichkeiten, das anderweitig zu lösen. Nur sowas sollte man dann auch nicht in der Code BEWUSSTEREN stecken, sondern eben anders machen, z.B. über die umgebungslärm.

Es gibt den sogenannten Lackmustest, da sagt man Könntest du deine Anwendung so wie sie ist, als open source Anwendung veröffentlichen. Und wenn dann die Antwort ist nein, dann hast du wahrscheinlich in der Konfiguration Dinge, die du nicht. Also die Konfiguration würde nicht Komitat werden. Ob man den Rest der Anwendungen. Sorgen könnte man, wenn du da Nein sagst, dann ist die Wahrscheinlichkeit hoch, dass du in der Anwendung Dinge hast hast, die du nicht vielleicht öffentlich einsehbar haben möchtest.

Oder du hast halt immer noch konfigurationsdatei. Damit war Hardcore da drin. Stehen die nicht über so ein externes Netz dann irgendwie weitergereicht werden?

Genau, oder? Ein nächster Faktor Nummer 4 ist das Kernthema für mich, in dem Micro Service Context heißt nämlich Backing Services oder zu Deutsch Dienste. Hier geht es darum, dass man Dienste, die die Anwendungen, aus denen sich die Anwendung zusammensetzt, als Ressourcen betrachten soll. Im Grunde kann man sich das so vorstellen Man hat eine Anwendung, die bleiben wir mal bei dem Bild App laut Bild skalieren und abblockt Thema, die ein Bild entgegen nimmt von einer Website oder auch von einem Amazon.

Erst drei Bake zum Beispiel. Dieses Bild skaliert und dann woanders hin schickt, per E-Mail beispielsweise. Dann ist der Amazon S3 backed ist ein Dienst, und auch der E-Mail-Server, an denen ich das Bild quasi übergebe, ist ein Dienst. Weitere Dienste sind Datenbanken. Message, Kues, crashes wie Mikesch, die alles, was in diesem Konglomerat lebt, kann als Dienst bezeichnet werden und muss der Anwendung sozusagen zuarbeiten. Die Anwendung selber hat über die Konfiguration dann diese Eltz auf die Dienste und kann mit diesen Diensten interagieren.

Also den Download durchführen oder die Mail verschicken. Wichtig ist hier auch, dass diese Urals dann nicht in der Anwendung drinstehen, sondern konfigurierbar sind. Der Unterschied zwischen meiner lokalen Laptop Installation und der produktiv Umgebung liegt rein in der Konfiguration.

Ja, das kann man sicherlich alles nicht immer in der Anwendung direkt mit verschicken. Quasi. Natürlich kann ich mir ein Email Client und SMTP Relay da lokal einrichten, aber sobald das an größere Dinge geht, ist das auf jeden Fall der Weg, wie man das machen sollte. Man möchte ja nicht sein komplettes ökosystem selber diplomen, sondern nur das, was wirklich anwendungs spezifisch ist. Und gerade in einem Enterprise Umfeld ist es ja auch oft so, dass es von Expertengruppen oder einzelnen Experten gehostet und betreut werden, die z.B. Datenbanken State Full Applications wie eine Datenbank, die möchte man vielleicht auch gar nicht in einem so ja fast schon ephemere Zahlensystem wie der Cloud hosten, sondern da möchte man ja vielleicht sogar ganz explizit eine anders geartete Lösung, sei es mit Redundanz und allem Pipapo, sodass man das auf jeden Fall als externen Service haben will, zu dem man nur noch den Connection String oder eine URL übergeben muss.

Genau.

Wichtig ist, glaube ich, hier als vierten Faktor mitzunehmen. Diese Dienste müssen eben flexibel konfiguriert sein. Es darf keinen Unterschied machen von der anwendungs Logik her, ob ein Dienst auf dem lokalen Laptop ausgeführt wird oder in der Produktion. Also klar, der Configuration String ist wahrscheinlich ein anderer. Aber ob das jetzt eine meist Nicol Datenbank ist oder ein ganzer Cluster, das sollte abstrahiert sein. Eine Bedingung hier ist natürlich, dass auch dann Ressourcen oder an entgangene Dienste ausfallen können und dass das in der Anwendung abgefangen werden muss.

Wenn die Datenbank nicht zur Verfügung steht, der E-Mail-Server nicht zur Verfügung steht, dann muss die Anwendung eben entsprechend darauf reagieren, und sei es, wenn sie geplant die Arbeit einstellt.

Der Vorteil Wenn man sowas bei seinem Provider einkauft, sag ich mal. ist natürlich, das die Abhängigkeit dann in einem Service level agreements steckt, was man was man da schließt. Da wird dafür gesorgt, dass sowas da ist, wenn man das mit seiner eigenen firmeninternen Datenbank bei dem Beispiel zu bleiben macht, dann hat man natürlich Kolleginnen oder Kollegen, die sich da eventuell drum kümmern müssen. Und noch ein weiterer Vorteil ist natürlich, dass du gerade gesagt Wenn ich anfange, das Ganze auf meinem Laptop zu entwickeln, dann möchte ich vielleicht auch gar nicht nicht mal gegen die Staging Datenbank der Firma entwickeln, geschweige denn gegen das Produktiv System, sondern vielleicht gegen eine lokale Instanz, die ich mir hier über meine Shell einfach selber installiert habe.

Das hat doch einfach vielleicht Design Gründe, warum man da diese Flexibilität auch möchte, spielt auch so ein bisschen in den Punkt Konfiguration mit rein, dass man da nicht Code und Konfiguration vermischt.

Kommen wir zum fünften Faktor Bild Release and Run. Diese drei Phasen sollten streng voneinander getrennt werden. Dazu sollten wir diese drei Phasen vielleicht erst einmal erklären. Die erste Phase ist die Bild Phase. Da wird der Quellcode aus einem Code Repository ausgeschenkt, wird zu virtuellen Maschinencode oder wird zum. Beziehungsweise Was meine ich mit virtuelle Maschinencode, dass wir zum Beispiel Java Bait Code nennt, der dann auf Java ausgeführt wird, kompiliert und die die Pentz sies werden hinzugefügt. Das Band Link erfolgt ebenfalls, das heißt ausführbaren Maschinencode inklusive der.

Bei einem Programm könnte das auch ein Static Bild sein, wo alles dann zusammengefügt ist. Das ist die Phase. Danach schließt sich die Ré Lies Phase an. Ich habe diesen Maschinencode und füge jetzt ein Umgebung spezifische Konfiguration hinzu. Für den lokalen Laptop, für die Produktion Umgebung und daraus entsteht zusammen also aus dem Bild plus der Konfiguration entsteht dann das Release. Dieses Release, also Maschinencode plus Konfiguration, kann dann ausgeführt werden auf einer bestimmten Umgebung Testumgebung, Produktions, Umgebung, lokaler Entwicklungsleiter, top.

Das bezeichnet dann einen Run. Also nochmal Phase 1 Bild, Phase 2 Das Release und Phase 3 ist der Run, also eine in Ausführung befindliche App.

In der zuvor konfigurierten Umgebung habe ich eine Frage, und zwar würde mich interessieren, wo du an der Stelle die Infrastruktur Coat Komponenten orten ist, weil ich kann ja beim Thema Java bleiben, das der Java Code gesagt. Wenn ich eine Java Applikation schreibe, kann ich das ja auch anders machen als in einer kompletten Stand Alone Factor App, sodass, wenn ich das so machen möchte, ich meine Umgebung auch mit Diplomen muss, also spreche ich muss.

Wenn ich das, um beim Stichwort Docker zubleiben, dann muss ich sagen Okay, ich möchte das Ganze. In einem leichtgewichtigen Red hat Linux möchte ich das betreiben, weil ich noch andere Komponenten brauche. Welche dieser drei Abschnitte fällt? Das finde ich rein.

Ich glaube, das fällt in einen extra Abschnitt, denn hier geht es ja nur darum, die App zu erzeugen. Also ich mich neben dem Aus dem Code Repository den Code füge die Konfiguration hinzu und lasse es ausführen. Und die Infrastruktur als Service ist ja. Wäre dann eine eigene coat bake. OK, diese eigene Code hat hätte dann auch diese drei Phasen Bild really run, und der Bild wäre einfach bei terraforming nimmst du einfach dieses Skript. Beispiel Release wäre Du führst das auf einer bestimmten Umgebung aus einer bestimmten Cloud Umgebung zum Beispiel, die es dann eben konfiguriert.

Und Run ist dann einfach die laufende Infrastruktur, die bereitgestellt ist. Und jetzt kommt Bild Release and run für die Java App in deinem Beispiel.

Das wäre das Beispiel Infrastruktur mit terraforming. Okay, da bin ich völlig bei dir. Da hab ich mich dann vielleicht missverständlich ausgedrückt, weil ich tatsächlich auf, sagen wir mal das Docker Image hinaus wollte, indem eine Applikation Dania läuft. Ah, ok, das würde ich nämlich persönlich unter dem Thema Bild einordnen, weil ich das Image ja auch bauen muss, im wahrsten Sinne des Wortes. Oder wie siehst du das?

Das kommt jetzt darauf an, würde ich sagen, ob die Konfiguration ein gebacken ist in deinem Docker Image oder nicht. Wenn sie es nicht ist, was sie nicht sein sollte, dann ist es auf jeden Fall die Bild Phase, weil die Konfiguration würde dem Docker Image über die wärmend Variablen mitgegeben werden.

Genau. Normalerweise würde ich das so konfigurieren, dass das Docker Image, bestimmte Umgebungen, Variablen erwartet. Und die werden genau in der Umgebung, in die ich das Image herein die bleue gesetzt. Um bei dem kybernetische Beispiel von vorhin zu bleiben, würde dann eben das Docker Image, die Umgebung, Variablen in dem Kybernetische finden und könnte damit daneben konfiguriert sein.

Denn dann würde ich Docker images zur Bild Frohsinns, die die pendelnd C.S wären ja sozusagen auch diese einzelnen Docker Image stacks plus der Quellcode oder der übersetzte Quellcode. Je nach dem befindet sich ja dann auch im Docker Image.

So hätte ich das auch gesehen.

Wichtig ist halt, dass man nicht das tut, was man in den alten Tagen gemacht hat sich per CCA auf den Server oder in eine beliebige Umgebung einloggt und dann per Texteditor die konfigurationsdateien nur auf dem Server anpasst oder kompilierte Sourcecode Dateien nur auf dem Server anpasst, das man quasi an der ganzen Kette vorbei nach vorne greift und da händisch änderungen durchführt. Das fehlt der eine oder andere, der hinreichend. Die Erfahrung hat, wird das schon gemacht haben. Es wird auch für Feuerwehreinsätze manchmal notwendig.

Aber es ist ganz, ganz schlechter Stil, irgendwelche Konfigurationen per CCA vorne auf produktiv Maschinen zu ändern.

Deshalb tritt hier als Paradigma diese Trennung vollzogen, zumal man an der Stelle auch gezielt aus Sicherheitsgründen hart zugriff. Hinein beziehungsweise in den Container hinein, indem die Anwendung läuft. Einfach verbieten kann. Dadurch wäre es überhaupt nicht möglich, an der Stelle etwas zu ändern, weil theoretisch ist es möglich. Aber eigentlich möchte man in den meisten Fällen gar nicht. Um eben auch solche Configuration änderungen durch die Hintertür zu vermeiden, kommen wir zum sexten Faktor.

Danach haben wir sozusagen Halbzeit, Prozesse oder auf Englisch. Prozesses ist der sechste Faktor. Was bedeutet das konkret? Eine 12 Factor App oder Prozesse einer 12 Faktur App sind stattlich und teilen nichts. Scheeren nothing, das heißt eine defacto App. Ich sage mal, zehn Requests gehen auf diese App ein und die können im Grunde alle parallel bearbeitet werden, weil der eine Prozess sichergehen kann, dass er nichts benötigt von dem anderen Prozess. Es gibt keine mev Texte oder exclusiv Zugriffe.

Das kann alles parallel erfolgen. Das ist hier damit gemeint. Das ist du hast es eben erwähnt. Wichtig, wenn man skalieren möchte, weil wenn man Abhängigkeiten schaffen würde innerhalb von Apps, dann wäre die Skalierbarkeit eingeschränkt, und die Anwendung käme irgendwo an den Punkt, wo sich ein Flaschenhals auftun würde und man eben nicht mehr endlos skalieren kann.

Genau deswegen sind ich habe es auch schon State voll Application genannt z.B. Datenbanken überhaupt nicht diniert. Dafür in solchen Kontexten betrieben zu werden, das ist prinzipiell möglich. Im Rahmen gibt es die Möglichkeit, mit sogenannten State full sets zu gewährleisten, dass eben der Zustand der Applikation immer wohl definiert ist und auch über Replika hinweg das alles immer in einem guten Zustand und definierten Zustand ist. Aber das sorgt natürlich für nicht mehr optimale Skalierbarkeit. Und auch die Parallele, die sehr Barkat, also viele Anfragen einfach gleichzeitig auf viele Instanzen verteilen zu können, wird dadurch natürlich konterkariert.

Und das möchte man an der Stelle ja eigentlich vermeiden. Das heißt, man muss sich ja überlegen Ist diese Umgebung die richtige für meine Anwendung? Es geht hier um diese App Services und die Datenbanken oder Cashs. Die werden ja dann quasi Ressourcen, die von der App konsumiert werden, die wiederum eigene Skalierung Mechanismen haben.

Genau aus dem Grund möchte man ja dann vielleicht auch Datenbanken als externen Service betreiben, selbst wenn es eigentlich als z.B. eine kleine Datenbank sein soll. Auch in der Micro Service Umgebung möglich wäre.

Prinzipiell richtig ist in dem Fall auch das Ließ. Das heißt, der Staat muss immer per sistiert werden. Das hast du jetzt nochmal deutlich dargelegt. Dieser Scheeren nothing Ansatz, der gilt auch natürlich auf dateisystemen Ebene. Also das lokale fall. System darf schon für eine einzelne Transaktion als Cash herhalten. Man kann sich vorstellen, wie das Bild wird irgendwo runtergeladen, es muss abgespeichert werden, dann wird es skaliert und dann weg per sistiert. Also nach der Skalierung, das Endergebnis sozusagen.

Irgendwo muss das Bild zwischengespeichert werden, und man braucht so eine Scratch Disk oder ein temp Verzeichnis, wo das gemacht werden kann, oder? Ich weiß von einem Projekt bei dir. Du hast viele Dateien runtergeladen, die mussten gepackt werden oder entpackt werden. Sowas muss man natürlich auf dem System machen. Aber das Endergebnis sollte immer wieder in ein Persistenz nicht Datenbank beispielsweise zurück gespeichert werden.

Genau, oder Cloud Storage. Drei Backups zum Beispiel. Man muss das Ganze vor dem Hintergrund betrachten. Ich bin immer gerne beim Cohn-Bendits Umfeld, wenn man da so einen Pott hat, der in der kybernetische Podcast folge. Darüber gesprochen Der Speicher da drin ist komplett. Meral, weil zu jedem Zeitpunkt könnte dieser Pod sterben oder vom Manager runtergefahren werden und an anderer Stelle wieder hochgefahren werden. Das heißt im Speicher, dieses potz Dinge auch nur kurzfristig abzulegen, ist keine gute Idee.

Dafür sollte man immer nochmal eine Persistenz Schicht im Hintergrund haben. Und wenn es nur für so Aktionen ist, wie du gerade gesagt hast, um z.B. einen Tabat zu packen oder ein Chip Archiv. Selbst das sollte man auf einer anderen Speicher Schicht machen als die in einem Dateisystem vorliegt. In so einer Umgebung gebe ich dir vollkommen recht.

Ein interessantes Detail hier ist, dass die häufig verwendete Methode von Sticky Sessions, also man hat, was man hat drei Webserver und davor ein Laut Blanka und die Endkunden greifen auf die Website zu. Kunde 1 wird auf Server 1 geleitet, Kunde 2 auf Server 2. Jetzt merkt sich der laut Balance anhand der Cucina die Aha, das ist der jenige hat auf Server 1 zugegriffen. Alle Folge Requests. Nach dem ersten ruhte ich auf Server 1 von dieser einen Person, von der nächsten Person auf Server.

Und so weiter. Das bedeutet, dass der Eins kriegt alle Requests von dieser einen Person. Dadurch kann der Server 1 in seinem Arbeitsspeicher diese Session Informationen verwalten. Und weil er immer sicher ist, dass unsereins immer zu ihnen durchgestellt wird. Und das ist explizit. Ich möchte das hier sagen eine Verletzung dieses 12 Faktor Paradigmas an dieser Stelle, weil eben nicht sauber dieser Session State in einem radix Kiewel Houstons oder so abgespeichert wird. Welche verhindern würde man, wenn der Nutzer eine Transaktion startet Webserver 1 durch ein Harz4 defekt oder wird irgendwie heruntergefahren?

Ist diese Transaktion komplett zerstört? Kein anderer Webserver, weil die Daten ja nicht synchronisiert wurden oder per sistiert wurden, kann diese Session zu Ende fortführen, weil die Daten eben im flüchtigen Speicher verloren gegangen sind?

Genau. Ich habe solche Anwendungen noch nicht entwickelt. Aber auch da müsste man sich dann entsprechende Gedanken machen, wo man diese Informationen ablegt, damit für andere Systeme die zugriffsmöglichkeit noch besteht.

Okay, wir haben Faktoren 1 bis 6 besprochen. Nach der Zeit. Ich würde sagen, die Faktoren 7 bis 12 besprechen wir in einer zweiten podcaster Episode zum gleichen Thema, um den anderen sechs Faktoren auch den entsprechenden Zeitrahmen einzuräumen.

Genau und das ständig mit eigenen Erfahrungen anreichern. Dann ist die Zeit, für die wir gerade gesehen haben, eben auch schnell rum. Oder wenn man nochmal über die eine oder andere Frage diskutiert.

Aber ich denke, das wollen unsere Zuhörer. Die wollen hören, welche Erfahrung wir haben, und sind ja auch interessiert. Da sind wir beim Thema. Wenn unsere Zuhörer Fragen haben, sendet uns gerne eine E-Mail an Podcasts. Gilbert de Feedback nehmen wir auch gerne unter der E-Mail entgegen.

Wir bitten ganz herzlich, unseren Podcast zu bewerten, dass gerne eine Fünf-Sterne-Bewegung da abonniert uns und schaut auf Skill bei Slash Blog vorbei für weitere spannende Technologie Themen. Oli Es war mir eine Freude.

Vielen vielen Dank, sehr gerne auch Spaß gemacht. Sind ja Themen, die wir beide schon mal beackert haben und entsprechend uns Spaß machen, darüber zu reden. Ich freue mich aufs nächste Mal, ich mich auch.

Ich denke im Kontext der Faktoren sieben bis zwölf sehr gerne. Vielen Dank.

Ein schöner Abend.