DevOps #7 - Manuell deployen? Zeit für Infrastructure as Code! - podcast episode cover

DevOps #7 - Manuell deployen? Zeit für Infrastructure as Code!

May 08, 202551 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

Du planst deine eigene CI/CD-Pipeline? Dann wirst du diese Folge brauchen.

Im neuesten Teil unserer DevOps-Reihe geht’s um Infrastructure as Code – und warum du damit endlich Schluss machst mit manuellen Setups, Chaos und Inkompatibilitäten.


Du bist auf der Suche nach einer IDE, die keine Wünsche öffnen lasst?

Hol dir jetzt deine Jahreslizenz für jede JetBrains IDE und spare 25% mit dem Code "CODINGBUDDIES".


Hat dir die Folge gefallen? Wir freuen uns natürlich auch über eine kleine Spende unter:

https://streamlabs.com/thecodingbuddies/tip

Dies ermöglicht uns unseren Content weiter zu verbessern. Vielen Dank!


Folge uns doch zusätzlich auf unseren anderen Plattformen oder schau auf unserer Website vorbei:

Website: www.codingbuddies.de

Discord: https://discord.gg/C2Zntw6Sq4

Instagram: https://www.instagram.com/the_coding_buddies

Youtube: https://www.youtube.com/@thecodingbuddies

Twitch: https://www.twitch.tv/thecodingbuddies

TikTok: https://www.tiktok.com/@thecodingbuddies


Du hast Feedback für uns?

Schreib uns über: [email protected]!

Transcript

Denn Infrastruktur wird nur aufgebaut, wenn also dein Secrets Manager kommt, nur mit der Infrastruktur.

So na das Henna I Coding genau Coding Buddies Dein Podcast rund um Softwareentwicklung und aktueller Tech News herzlich Willkommen. Halli Hallo und herzlich Willkommen zur neuen Folge des Kolumbolis Podcast schön, dass du wieder eingeschaltet hast, dass wir wieder zusammengefunden haben, deine Gastgeber. Und ja, wie soll es anders sein, meine Wenigkeit, der Tino und der fantastische Fabi, der schon wieder lächelt, er ist, er hat Bock, ich sehe es, ich sehe es

einfach, er hat Bock auf diese Folge, er ist bereit, deswegen mag ich ihn jetzt begrüßen fabi was geht? Ab was geht ab? Liebe geht raus an alle draußen im Podcast jetzt einschalten. Wie geht's dir? Alles gut? Ich bin müde, weil ich bin irgendwie müde. Aber Scheiße, hör ich mal viel öfter in letzter Zeit von dir. Was ist da los? Ne, ist wahrscheinlich die Frühjahrsmüdigkeit, ich weiß

nicht gibt es sowas? Ich bin Frühjahrsmüdigkeit bei dir anscheinend schon, weil sie ist sehr ausgeprägt, auf jeden Fall aber aber weißt du was ich krass finde ist wenn man so auf einen Monat guckt wir haben schon wieder bald das erste halbe Jahr rum. Crazy oder?

Also ein bisschen ist noch ja, ja, ja, okay für die, die es jetzt ganz genau nehmen, aber für mich geht's schon wieder in die Richtung so ja okay das erste Halbjahr ist rum, ich hab grad durchgerechnet, so Alter, das ist ja noch nicht mal Juni ah ich weiß noch zum Blick auf den Kalender, ich weiß was das ist, aber das ist doch krass irgendwie, wie schnell das schon wieder alles geht also ich finde die Wochen die Rasen. Ja, das sowieso. Aber ich finde, dass es so das

Jahr geht los. Dann ist auf einmal so März, dann zieht sich der März so n bisschen finde ich und dann denkt man wieder so okay halbes Jahr schon wieder rum, dann hat man irgendwie n weiß nicht, dann ist so Sommer ne das finde ich dauert irgendwie zum Glück bei mir mal n bisschen länger so vom Feeling her und dann ist auf einmal zack wieder Weihnachten also so wenn du gerade so im August direkt zu Weihnachten.

Ja, wenn du gerade so im August weißt du, auf der Terrasse sitzt gerade grillst oder so und dann machst du einmal schnipp und zack, ist wieder Weihnachten. Steht schon wieder Rudolf im Garten, so bin ich wieder eingeflogen. Ja, ich finde es auch spannend, wie schnell das einfach immer

alles so an einem vorbeizieht. Also ja, man nimmt es ja schon aktiv wahr und ich versuche auch wirklich die Zeit immer zu genießen, ne, aber es ist trotzdem krass wie schnell das geht und warum ich drauf komme ist weil ich finde man merkt das auch so ein bisschen am Podcast so jede Woche ne Folge man denkt immer so von Folge zu Folge aber wenn man sich das so im

Gesamtkontext ansieht. Merkt man mal, wie die Zeit vergeht, weil uns ist ja aufgefallen, dass wir auch schon ne ganze Zeit keine Def Ops folge mehr zu der Reihe gemacht haben und das wollen wir ja heute ändern. Ja stimmt und bevor wir aber rein starten. Noch n kleiner Aufruf liebe Zuhörer, liebe Zuhörer, falls dir der Podcast gefällt und auch die Def Ops Reihe zum Beispiel, denn heute kommt wieder eine Folge dazu, dann lass uns das

doch gerne wissen. Schick uns auch gerne n Feedback und wenn du Lust hast in den Shownotes findest du n kleinen Spendling, damit würdest du uns mega unterstützen, dann vielen Dank dafür schon mal und dann würde ich sagen Fabi stell doch mal. Das heutige Thema Vorfilm ab, das hab ich gerade ja genau, es geht heute mal wieder um ne def of Folge wie du schon meintest und zwar um nichts weniger Wichtigeres als Infrastructure as Code, also IAC und das ist

natürlich sehr sehr wichtig. Also wir haben ja bisher zum Beispiel schon über CIC geredet, Staging über Logging und Observability und das sind ja alles Punkte, wo du irgendwie deine Infrastruktur aufbauen musst und.

Ne, also du musst ja irgendwie, du brauchst ja Server, du brauchst n Service, der irgendwie lockt, du musst gucken wie du lockst, wie du vielleicht deinen Logger konfigurierst oder frag mich nicht, ne, du musst wissen wie du ne Stage aufbaust und genau dafür, damit das alles auch richtig flutschen kann, sag ich jetzt mal braucht man halt am besten infrastructures Code.

Ne und was jetzt infrastructures Code genau ist, warum das für Def Ops wichtig ist, was da vielleicht für Best practices sind und was es für Fallstricke und Herausforderungen gibt, das wollen wir eigentlich jetzt mal so in dieser Folge besprechen und uns angucken und unsere eigenen Meinungen, Erfahrungen noch mitteilen, so wie immer ne. Ja, klingt auf jeden Fall sehr cool und ist auch n super wichtiger Bereich, also essentiell notwendig, wie man es auch immer sagen möchte.

Also es geht. Unserer Meinung nach nicht ohne. Es ist wirklich ein wichtiger Baustein und deswegen lass uns doch mal anfangen mit so ein bisschen Definition was Infrastructure is code eigentlich ist.

Wie könnte man das so ein bisschen auf den Punkt bringen, also im Prinzip wenn man es definieren müsste, kann man sagen, es ist im Prinzip die Automatisierung und Verwaltung genau dieser Infrastruktur, die du gerade genannt hast, die wir ja auch in den vergangenen Folgen viel besprochen haben und. Über Code, also dass ich das wirklich codiere sozusagen in Code verfasse, anstatt manuell

zu konfigurieren. Ich kann natürlich meine Server auch manuell manuell konfigurieren, du hast meistens Benutzeroberflächen, wo du alles einstellen kannst. Gar kein Thema, das funktioniert alles. Aber es geht jetzt darum zu sagen, Nein, wir konfigurieren es nicht manuell mit Maus und Tastatur und ich brauche n Mitarbeiter quasi jedes Mal dafür, sondern über Code wird

das Ganze definiert. Die Infrastruktur, das heißt wenn man das so n bisschen vergleichen sollte, wir haben im Prinzip. Eine Version unserer Infrastruktur für die Serverlandschaft codiert sozusagen. Also ich habe Code, der beschreibt, wie eine spezieller Stand unserer Infrastruktur aussieht. Genau.

Wenn man sich jetzt so Pseudocode vorstellt, steht da drin sowas wie fahre einen Server hoch, lade zum Beispiel da folgendes Artefakt hin und deploye Anwendung x auf diesen Server jetzt mal so ganz ganz auf ganz ganz hohen. Einblick aber genauso kann man sich das ja vorstellen.

Zieh dir den neuesten Stand von deiner Anwendung genau, führe die Tests aus so. Genau, weil sie da bei CICD sind, ganz genau, und das ist halt, also es hat ja diverse Vorteile. Und zwar gerade weil du meintest, du hast ja zum Beispiel, wenn du deine deine Oberfläche zum Beispiel benutzt, um manuell deine Server Landschaft aufzubauen und deine Infrastruktur, dann hast du ja das Problem, dass du angenommen, du möchtest zum Beispiel Stage 1

aufsetzen, ne, also zum Beispiel die Dev Stage beispielsweise über Stages hatten wir auch schon geredet und weiß nicht die QR Stage und die prod Stage so. Und du machst das alles manuell, dann hast du ja eventuell das Problem, dass du sagst, na ja,

OK, ich warte mal. Wie hab ich das bei die Dev Umgebung, die hat dich aufgesetzt vor einem halben Jahr aber jetzt brauchen wir ne QR Umgebung ah hoffentlich vergess ich nichts ne also diese wiederholbarkeit, also dass du deine Infrastruktur 1 zu 1 reproduzieren kannst, die wird das wird echt schwierig ne wenn du das nicht irgendwie in in so ne Art infrastructures Code verpackst ne weil zum Beispiel.

Erstens musst du dich daran erinnern und vielleicht sagen, ja, guck mal hier, da habe ich ja den Klick gemacht in Anführungsstrichen, da habe ich genau das und das eingegeben, was auch immer, wenn man es jetzt mal so wirklich, ganz salopp sagen möchte. Und wenn du jetzt zum Beispiel sagst, ja gut, du kannst ja auch dokumentieren, ja, aber das ist ein Riesenaufwand, wenn du eh schon den Code schreibst, wieso dokumentieren, das manuell machen, wenn du dann nicht aber

einfach sagen kannst okay ich. Ich kann halt einfach meinen Infrastruktur als Code Template nehmen und sagen und jetzt los, bau das so auf, also wiederholbarkeit um es kurz zu fassen ist halt ein Vorteil, der ist halt sehr sehr wichtig. Ja, weil wie du ja meinst, es ist super fehleranfällig, wenn man das denn quasi nicht über IAC macht.

Mal angenommen du hast jetzt ein Entwicklerteam und arbeitest ja zum Beispiel. Wie auch immer, an Frontend ne sehen wir einfach mal ne Website und mehrere Leute arbeiten da drauf, pflegen Ihre Änderungen ein und gehen jetzt immer zu dem Dev Ops Mitarbeiter und sagen ey übrigens ich hab jetzt hier in unserer Repository ne neue Änderung reingehauen.

Check die doch mal durch. Teste das mal durch, probier mal alles, dann guckst du mal ob das funktioniert und wenn es geht, dann geh mal bitte auf den Server und Roll mal da per Hand die neue Version aus, das heißt Bau da mal zum Beispiel n Container auf und starte mal das Frontend damit das dann quasi global zur Verfügung steht so der macht jetzt 1000 Schritte wenn man jetzt wirklich davon ausgeht der Macht das manuell so und jetzt kommen 56 mal am Tag Leute und sagen ey ich hab

übrigens hier den Button geändert ne. Hammer Deployder Swi wird. Na dann hat er wohl viel anfällig, dann hat er aber das ist halt so fehlanfällig, weil der ja da wird niemals was schiefgehen und genau das ist der Punkt ne diese wiederholbarkeit, du musst es ja

sehr sehr oft machen. Ne. Und du willst es immer gleich machen und das ist halt wirklich ein riesen Vorteil, wenn einfach festgeschrieben ist durch diesen Code was zu tun ist und absolut klar ist, in welcher Reihenfolge das auch passiert, dass nichts ausbleibt, dass alle Stages durchlaufen wären und so weiter und ein Punkt, der dabei auch noch richtig essentiell ist und den darf man nicht unterschätzen. Diese Infrastructure ist Code kannst du ja genauso versionieren wie dein

Softwareprojekt an sich und. Zum Beispiel mit Git. Das heißt, du hast einen riesen Vorteil dadurch, dass du Versioniert eine Version deiner Infrastruktur hast. Und solltest du n Fehler einbauen, kannst du auch immer wieder zurückgehen und so weiter du hast es halt wirklich als Historie abgelegt und dementsprechend auch wie du meintest ne Dokumentation da drin und das finde ich ist halt n riesen riesen Vorteil da die. Musst du halt nicht on top

setzen, ne? Als Beispiel angenommen, Du sagst du möchtest den Server noch mal ein bisschen neu konfigurieren, weil da ist dir was aufgefallen und du konfigurierst den Server und auf einmal startet der Server nicht mehr oder was auch immer, dann ist langsam oder kannst dir irgendwas ausdenken was es halt alles so gibt, aber dann kannst du halt genau vielleicht auch wenn du es nicht selber gemacht hast, sondern vielleicht ein Teamkollege der gestern in

Urlaub gegangen ist. Dann kannst du gucken, OK, was ist denn jetzt zum Beispiel eine Infrastruktur, was wurde denn verstellt? Ne, wenn du das jetzt, wenn jetzt aber das ganze über irgendeine Oberfläche eingegeben wurde oder sonst was, dann kannst du es halt nicht wirklich richtig gut nachvollziehen, du weißt halt gar nicht, was ist denn gerade passiert, was wurde denn eingestellt? Ne also du du hast halt nicht diese diese Version deiner Infrastruktur dann am Ende und. Das ist halt da.

Klickst du dich dann wild durch irgendeine UI durch und versuchst irgendwo zu ergründen, wo sich was geändert haben könnte. Das ist die Hölle auf Erden. Definitiv, ja, genau. Und aber das sind halt diese ganzen Vorteile von infrastructures Code, ne.

Also wir haben ja jetzt gesagt, die Wiederholbarkeit, die Versionierbarkeit Dokumentation durch Code und die automatisierte Bereitstellung ne von irgendwelchen Containern von Deiner Software von der neuen Version und so weiter ja das ist natürlich super und jetzt haben wir OK Infrastruktur infrastructures Code, gute Sache und.

Wir sind ja jetzt in der Def Ops Folge und dann ist ja die Frage OK, wieso ist der infrastructures Code jetzt auch wirklich wichtig im def ops Kontext sag ich jetzt mal ne, das ist ja an sich jetzt ne gute. Frage, Was ist da der Key? Also was sind die Punkte? Ja, also den einen Hauptpunkt haben wir ja eigentlich schon angesprochen, dass das ganze Halt automatisierbar ist. Ne, also diese Infrastruktur die ich mir aufbaue. Kann ich automatisiert ausrollen?

Und davon lebt ja dev Ops irgendwo auch am Ende, dass du halt sagen kannst, OK, ich muss jetzt nicht manuell Server einrichten, Datenbanken einrichten oder oder sei es nur du hast einen neuen Kollegen und der braucht eine Entwicklungsumgebung, die vielleicht ein bisschen größer oder komplizierter ist, dann musst du halt nicht manuell immer alles einrichten, sondern du hast das halt automatisiert in der Hinterhand, sage ich mal und sagst OK, hier pass auf.

Lass das laufen und dann bist du am Start sozusagen. Also du kannst ja so n Skript, muss ja nicht nur beispielsweise in der Cloud laufen oder auf irgendwelchen Servern, du kannst es ja auch lokal laufen lassen, je nachdem wie die aufgebaut sind, aber die Möglichkeit besteht ja ne, dass du halt diese Infrastruktur auch lokal bei einem neuen Kollegen zum Beispiel einrichten kannst. Und das finde ich, ist halt n riesen riesen Benefit dabei. Da hatte ich zum Beispiel auch

mal was richtig cooles. Ein alter Kollege, der hat dann irgendwann für die, für die ich sag, jetzt mal Abteilung hat so n Skript geschrieben und dann konntest du einfach dieses Skript auf deinem Rechner ausführen, konntest einfach starten und dann wurden eigentlich so die ganzen gängigen Sachen, die man eigentlich so bei uns verwendet hat, dann einfach installiert. Die IDI was weiß ich zum Beispiel ne ne git CLI frag mich nicht docker.

Und und so weiter ne, also diese ganzen Sachen wurden halt einfach installiert wurde. Das ist dann halt am Ende zum Beispiel über Homebrew passiert meistens, aber das Ding ist, das ist ja super, super entspannt also in wenn wenn es jetzt zum Infrastructure Code geht ist es ja nicht immer nur und das finde ich gut, dass du das noch mal gesagt hast.

Immer nur dieses Remote. Ich setz meine Serverlandschaft für meine Anwendungen auf, sondern es geht ja auch dahin, dass du als Def Ops Team zum Beispiel das Automatisierst und sagst, ey, es gibt n Onboarding, guck mal hier, du brauchst dich jetzt nicht hinsetzen und alles manuell, ne das brauchst du, das brauchst du. Ach jetzt hab ich wieder das vergessen, ich kann ja noch gar nicht arbeiten oder was auch immer, sondern dass du halt wirklich sagst, so OK cool, ich

hab hier n Skript, ich führ das aus und eigentlich. Ich sag mal im Normalfall zu 90% kannst du dann sofort loslegen, ne und das ist halt schon irgendwie cool und dann rattert das dann Kaffee. Holen und dann geht es. Los. Genau dann rattert das dann ne Kaffeelänge und dann ist super. Also das fand ich auf jeden Fall richtig cool. Ne, also über sowas kann man natürlich auch nachdenken, dass man halt noch diesen Schritt geht und sagt, was kann man denn automatisieren?

Was ja auch irgendwo Infrastruktur am Ende ist. Ne ja und da kommen wir auch gleich zum nächsten riesen Pluspunkt diese Reproduzierbarkeit. Mal angenommen du hast so n. Onboarding Tag ja, also bist vielleicht in einem größeren Unternehmen.

Es fangen jetzt ein paar neue Kollegen an, also ja meinetwegen 55 neue Kollegen und Kolleginnen, ne, jetzt bist du der eine der sich super in dieser Entwicklungsumgebung auskennt und hast keine hast das nicht kodiert deine Infrastruktur ne also du hast das nicht automatisiert, wie würde das ablaufen? Du gehst zum ersten Kollegen. Richtest das alles ein, erklärst ihm das hier. Du brauchst das, du musst das installieren und so Weitergehst

zum nächsten. Du kannst dich ja nicht aufteilen, das heißt, das muss ja sequentiell abgearbeitet werden. Ja, diese diese Einrichtung, und wenn du jetzt aber das ganze Infrastructure is code mäßig aufsetzt, kannst du einfach sagen hier Leute. Das Rebo zieht euch, das richtet euch alles ein und ihr seid am Start, wenn ihr fertig seid, können wir dann alle gemeinsam quasi über die nächsten Schritte reden.

Also du kannst es halt parallelisieren, ne und konsistent halten, das heißt es wird bei allen Fingers crosst, aber in der Regel schon ne gleich eingerichtet sein am Ende ich mein Gut der bekanntlich sitzt der Fehler oft vorm PC, wer weiß was der eine oder andere neben dem mittlerweile noch macht, aber. Das ist trotzdem der riesen Pluspunkt dabei. Ne ja richtig und Konsistenz zum Beispiel auch gerade weil wir auch schon über Staging geredet

haben. Es ist ja auch immer super wenn du ich ich weiß nicht ob man das, also ich hab es schon erlebt, dass du halt du hast irgendeine ne Umgebung, du setzt halt dann zum Beispiel Prott auf oder so oder QA oder ne meine Lieblingsumgebung nenn sie wie du möchtest und dann sagst du aber ja, aber zum Beispiel. Das funktioniert da nicht so wie da, weil da ist zum Beispiel Prot ist ganz anders konfiguriert als zum Beispiel dev.

So also das ist ja wirklich, das ist ja was ganz anderes, und damit hast du dann aber auch schon wieder den Punkt, dass du ja sagst, okay, wie willst du denn auf Dev etwas testen, wenn Prot ganz ganz anders konfiguriert ist? Ne, und damit du halt eben nicht diese in in die Versuchung kommst zu sagen, ey ich möchte jetzt aber vielleicht, dass, das mache ich manuell mal ein bisschen so und das mache ich manuell ein bisschen so, dass du gar nicht erst da. In diese Falle tappen kannst. Ja.

Hilft dir halt auch infrastructures Code. Ja, du kannst halt sagen, das ist meine Stage, so ist meine Stage aufgebaut und go ne jetzt mal unabhängig davon, dass du vielleicht irgendwie andere. Services auf anderen Stages wiederum ansprichst also externe Services.

Ne, das ist sei mal dahingestellt ne, aber ich mein jetzt wirklich die Konfiguration deines Netzwerkes innerhalb der Cloud oder was auch immer ne also da es gibt so viel was man einstellen kann, was man theoretisch auch wirklich falsch einstellen kann und da ist es natürlich absolut wichtig, dass das wirklich auch immer gleich funktioniert. Ja, weil diese Überraschung, die du dann haben kannst, so

komisch. Also bei mir hat es funktioniert, auf meiner Maschine läuft das ja, auf Server a läuft das, das sind somit die schlimmsten Aussagen die man tätigen kann, weil dann stehst du halt echt vor dem großen Unbekannten und denkst dir so was jetzt, also jetzt müssen wir erstmal rausfinden was hier los ist und dann weißt du halt zum Beispiel nicht mehr, dass Kollege XY ja vielleicht noch ein 2 Klicks manuell gemacht hat, irgendwas

umgestellt hat. Das ist die Server 5 rechts hinten in der Ecke meinst du genau der böse Server 5 hinten rechts in der Ecke ist es wieder, der ist ja schon mehrfach hier im Podcast aufgetaucht, er ist immer der Übeltäter am Ende. Ja, ansonsten hatten wir auch schon über Versionierbarkeit geredet und finde ich auch Transparenz. Es spielt da ne wichtige Rolle, weil angenommen dieser Punkt, wir sind jetzt noch mal wieder in diesem Modus, wir konfigurieren irgendwas manuell

so, dann hast du ja entweder die. Also entweder hast du den Punkt, dass du immer dann wirklich quasi so n Peer Review machen musst, dass noch einer dabei sitzt und man dann zusammen sozusagen verifiziert. OK, wir machen das jetzt so und so und so ne trotzdem nicht gut,

wenn es manuell ist. Aber selbst wenn du das alleine machst und dann hinterher sagst du Pass auf, ich hab jetzt das und das so und so eingestellt, aber angenommen du hast keine Ahnung 10 manuelle Schritte gemacht, ne so, dann vergisst du halt vielleicht 2 davon, ne sind vielleicht sogar mehr und dann.

Weiß ja gar nicht, also kannst du ja gar nicht dieses dieses ich sag ich nenn es jetzt einfach mal dieses Code review machen ne also wenn du Infrastruktur als Code hast, dann kannst du ja dein dein dein Infrastruktur über den Code anpassen und dann hinterher ganz normal mit Git einfach dieses div machen und sagen guck mal hier habe ich das verändert, hier habe ich das verändert ne also das heißt du kannst nicht

nur nachvollziehen. Im Nachhinein, wenn vielleicht was schief geht oder wenn wenn es auch gut gegangen ist, was es für Änderungen gab, sondern du kannst auch super eine Art Code Review für die Infrastruktur machen und das ist halt auch. Ziemlich also eine ziemlich geile Sache, absolut. Und die Verantwortlichkeiten rücken ja auch mehr zusammen.

Ich meine, wir reden ja hier in der Def Ops Reihe logischerweise über Def Ops und da geht es ja darum, dass du auch Defs und Ops quasi näher zusammenbringst und dass sie.

Halt zusammenarbeiten ne und nicht sag ich mal die Developer das so Rüberreichen nach dem Motto und jetzt sorg dafür, dass es in die Welt kommt und das ist halt n riesen Punkt was das Ganze auch vereinfacht zu sagen wir wir machen das ganze oder nutzen Infrastructure is code ne weil du halt auch quasi sag ich mal an einer Codebasis an einem Fundament arbeiten kannst.

Weil diese Skripte beispielsweise ja sehr oft auch mit in dem Projekt Abliegen, das heißt, beide haben ja Zugriff da drauf und können das zum Beispiel Reviewen oder abändern. Definitiv. Also beide Parteien, wenn man es jetzt noch mal getrennt. Betrachtet. Obwohl also beim es ist ja immer so ne Death und Ops so 2 Teams die nah zusammenarbeiten so in meinem Kopf ist das schon so richtig. Es ist halt so ein Team.

Also weißt du, also du bist du hast Def Ops durchgespielt, quasi ein def Ops. Du bist ein def Ops. Ja genau das ist ja das Ziel, dann halt wirklich das zusammenzubringen, ja genau was auf jeden Fall. Noch n nächster Punkt ist der mir jetzt direkt einfallen würde wäre, dass man halt einfach auch schneller irgendwas bereitstellen kann. Ne ich meine ja absolut. Klar. Hatten wir auch schon so n bisschen drüber geredet. Einfach angenommen du sagst OK.

Du brauchst eine neue Stage und ich hatte es auch schon mal einem alten Projekt. Da haben wir erstmal mit einer, ich glaube wir hatten einfach nur eine Sandbox Stage, weil wir nur gesagt haben okay, wir machen gerade ein MVP.

Es gibt eigentlich nicht großartig Daten die irgendwie konsistent gehalten werden müssen, wir können die jederzeit weghauen, alles gar kein Problem, das heißt wir hatten einfach nur eine Sandbox Stage und haben einfach nur damit gearbeitet so und ich weiß aber weil wir mussten halt quasi alle so. Dieses diese, diese neue Technologie, die neue Cloud Technologie sozusagen uns in der ganzen Abteilung drauf drücken, damit man halt damit arbeiten

konnte, weil das Halt so n Shit gab und da war es dann so, dass wir erstmal relativ viel ausprobiert haben, ne und dann irgendwann also erstmal so manuelle Testschritte gemacht haben um zu gucken OK, funktioniert das jetzt wirklich richtig wie man sich das vorstellt ne n bisschen damit rumgespielt mit dieser ich sag mal Oberfläche, dass man halt so einfach n Feeling dafür bekommen hat. Und dann hat man das Ganze irgendwann in diese infrastructures Code gegossen, damit man es halt einfach

schnell hochfahren kann. Und dann war es aber irgendwann soweit, dass wir gesagt haben, OK, wir brauchen jetzt aber wirklich mal ne ne ne prod stage, ne prod so und. Da war es halt einfach super hilfreich, dass es halt einfach dieses Template gab, um zu sagen okay, wir fahren jetzt die also die die gleiche Infrastruktur noch mal hoch auf einer anderen Stage und nennen die Halt dann prod.

So also das ist dann halt diese kleine andere Konfiguration hat einen anderen Namen, hat vielleicht wie gesagt andere Services die angesprochen werden, also beziehungsweise der gleiche Service auf einer anderen Stage wiederum aber hätten wir das manuell gemacht. Ja, dann hätten wir wahrscheinlich deinen ganzen Tag dran gesessen und so hat es halt vielleicht ja, lassen wir jetzt nicht lügen, ne halbe Stunde gedauert, bis wirklich die Infrastruktur initialisiert und

hochgefahren wurde, ne? Ja. Also ne krasse, das ist. Natürlich n Riesen genau ist n riesen Unterschied und gleichzeitig halt auch sicherer. Ne also wenn du jetzt das Ganze noch mal manuell aufziehst wird auf jeden Fall was schief gehen, da kannst du eigentlich von ausgehen und genauso ist ja die Frage wenn du jetzt zum Beispiel

sagst. Wir brauchen eine neue Stage und wir machen vielleicht kleine Anpassung, weil die Stage ein bisschen anders ist, ne oder eine andere Konfiguration und da geht was schief, dann kannst du es halt auch immer per Rollback zurücksetzen und das genauso schnell, aber wie auch vorhin meintest genau, weil du hattest ja vorhin gesagt, angenommen der Server fährt dann nicht mehr hoch, ja was machst du dann?

Das kann halt wirklich Geld kosten, dem Unternehmen ne so ein Server Ausfall beziehungsweise ein Service Ausfall, dass du nicht mehr erreichbar bist. Dann ist es natürlich goldwert zu sagen, ey, wir machen jetzt einfach erstmal n rollback und gehen auf den alten Stand zurück und der Server ist aber n paar Minuten wieder am Start oder vielleicht maximal ne halbe Dreiviertelstunde, je nachdem wie wie groß die Pipeline ist, ne?

Da hatte ich auch mal n ganz lustigen Fall ne, weil das ist nämlich wirklich auch interessant. Rollback OK möglich, aber was auch absolut n valider Punkt sein kann ist hatte ich auch schon mal. Die Umgebung war wirklich kaputt, ne? Und wir wussten gar nicht mehr, OK, Mist, was ist denn jetzt

los? Und dann haben wir einfach die Komplettumgebung abgeräumt, also wirklich gesagt, komm, schmeiß das alles weg und dadurch, dass man es halt nicht manuell wieder als klicki, klicki, bunti und alles ne aufbauen musste, sondern einfach wieder das Template Reinschießt. Wurde die einmal wieder aufgebaut?

Die Umgebung, alles war wieder gut so, also dann halt von Rollback von der vorherigen Version definitiv, aber dass man wirklich sagt, OK ich schmeiß auch einfach alles weg und bau es noch mal neu auf vom vom Scratch so teilweise deutlich schneller, als dass du dann noch mal sagst OK, also manchmal, das ist wirklich auch das Wichtige bei Infrastruktur möchte ich auch noch mal schon mal direkt spoilern, du kannst dich da auch

wirklich. In eine Einbahnstraße manövrieren, dass du sagst, wenn du das jetzt konfiguriert hast und das einmal hoch, also live geschaltet hast, diese Infrastruktur, dann kommst du da nicht mehr zurück und deswegen ist es manchmal auch notwendig zu sagen, einmal komplett abräumen, wieder neu hochfahren und diese schnelle Bereitstellung dann wieder. Das ist auch richtig essentiell und das geht auch nur mit infrastructures Code.

Ja. Und wenn wir auch bei dem Thema Ausfälle sind oder dass halt irgendwas schief läuft, kann man natürlich auch ganz klar sagen, dass du mit Infrastructure is Code auch die Möglichkeit hast gewisse Sicherheiten einzubauen. Ne, also beispielsweise Security Policies, Checks, das ist ja alles möglich, dass du sagen kannst, beispielsweise weil ich ja vorhin meinte jemand committed was ne Änderung zum Beispiel auf dem Frontend und geht jetzt zu dem Dev ops.

Mitarbeiter und sagt hier manuell los geht es. Mach das mal alles ne, dann kann der das natürlich auch checken, vergisst aber vielleicht was oder oder macht es nicht gründlich genug, weil er es schon fünfmal am Tag gemacht hat und genauso kannst du in deine in deinem Code in deinen Skripten genau so ne Security Aspekte auch einbauen. Ja die denn zum Beispiel schon beim Commit gecheckt werden und das sind halt auch Riesenpunkte die dafür sprechen einfach es so

umzusetzen. Oder die das schon zur Pflicht

machen. Muss man einfach so sagen, ja, definitiv, also es ist ja auch zum Beispiel wenn du sagst, OK, wir haben ne Datenbank und die muss jetzt auf einmal verschlüsselt werden, ne, dann kannst du im Normalfall oder in gängigen sag ich jetzt mal Infrastrukturen die du halt nutzen kannst in der Cloud, wenn du so n infrastructures Code nutzen kannst, hast du halt die Möglichkeit denn sowas zu sagen wie ja hier bitte einmal Datenbank XY verschlüsseln mit.

Dem und dem Algorithmus, was auch immer ne. Also da gibt es ja dann verschiedene Konfigurationen was man nehmen kann und das ist aber dann im Endeffekt eigentlich nur eine Zeile die du hinzufügst. Und im Endeffekt hast du, kannst du diese Infrastruktur sozusagen neu deployen und es funktioniert dann auch wieder für alle Stages.

Du musst also jetzt auch nicht wieder hingehen und sagen okay, ich habe 5 stages, ich gehe jetzt da rein, klicke hier ja bitte einmal die Datenbank hier verschlüsseln okay dann hier nächste Stage, hier wieder Datenbank wieder verschlüsseln und so weiter. Es kann halt auch durchaus sein, dass du zum Beispiel für eine eigene Stage auch wieder sozusagen einen eigenen Account anlegst.

Das heißt, im Worst case musst du dich dann, wenn du es manuell machst, dort einloggen, ausloggen, wieder einloggen, dahin manövrieren, ne. Also es ist halt dann echt ein bisschen was zu tun und so hast du das halt einfach nur mit einer Zeile und dann fire und ne, die sozusagen deployen in Anführungsstrichen, dann ist fertig, dann wird deine Infrastruktur eingerichtet, das ist halt cool, ein guter Punkt. Genau. Also das ist auf jeden Fall.

Es ist ja auch n bisschen so Richtung Compliance, ne, dass du halt auch nachweislich, also es ist halt niedergeschrieben als Code, was passiert ne und du kannst es halt nachweisen und wenn es wie Versioniert ist, kannst du auch noch zeigen, wie es sich über die Iteration weiterentwickelt hat.

Ne und das sind je nachdem in welchem Projekt man arbeitet halt unfassbar wichtige Punkte auch Richtung The Tracability zum Beispiel. Ja das spielt ja da auch ne Rolle. Aber kommen wir mal noch n bisschen zu der Def Ops Kultur zurück.

Da haben wir auch quasi die Reihe mit eröffnet so n bisschen ne diese ganze der ganze kulturelle Gedanke dahinter und da würde ich noch mal gerne aufgreifen, dass wir ganz ursprünglich am Anfang vor Monaten quasi gesagt hatten, dass es ja in dieser Def Ops Kultur auch darum geht Wissensilos abzubauen und da muss man ja sagen, dass Infrastructure escode. N super Mittel dafür ist, weil du halt jetzt nicht mehr den obs Mitarbeiter hast.

Also jetzt ohne def. Der jetzt in seinem Büro im Dunkeln da die Server einrichtet und alles dafür sorgt oder alles dafür tut, dass das irgendwie funktioniert, aber keiner weiß was er da eigentlich macht, weil das wäre ja n riesen Wissenssilo am Ende was denn aufgebaut wurde, weil wenn diese Person kündigt im Urlaub ist oder was auch immer. Da halt nichts mehr passiert, wenn dann da Fehler auftauchen,

dann weiß keiner was los ist. Und mit Infrastructure is Code kannst du halt auch die Entwickler mit ins Boot holen und dass sie quasi ihre eigene Infrastruktur mitgestalten können. Mit Coden können, dass sich.

Die Ops Leute aber, die n bisschen mehr Richtung Ops gehen, ne das ist ja dann auch so n bisschen so Gewichtung sag ich mal bei dev ops sich halt auf andere Aspekte konzentrieren können oder mehr fokussieren können, wie zum Beispiel was hatten wir in der letzten Folge das Monitoring zum Beispiel oder zum Beispiel wie du vorhin meintest Skalierung ne wie kann ich das ganze jetzt auf mehreren Servern ausräumen, wie kann ich das gut skalieren das Ganze. Und da kann man halt sagen, dass

so ein so ein Code, diese Infrastructure is code, so ein gemeinsamer Nenner für alle Entwickler sein kann und du dadurch noch enger zusammenarbeiten kannst. Ja, richtig. Und also ist auf jeden Fall ein sehr wichtiger Punkt, also diese, diese, gerade diese Kultur, die dahinter steht, finde ich, ist auf jeden Fall ein wichtiger Gedanke, den sollte man auf jeden Fall auch nicht außen vor lassen und. Weil wir ja vorhin auch noch mal

bei CICD Pipelines waren. Ne, also das hat, da hatten wir ja auch gerade über CI und CD auch ne eigene Folge gemacht, wollte ich jetzt noch einmal kurz aufgreifen, weil ich finde es eigentlich irgendwie ganz spannend, dass man ja wirklich sagen kann, wenn du kein Infrastructure als Code hast, dann kannst du auch nicht wirklich continuous deliver ne,

weil. Wie gesagt, wenn du diese Infrastruktur als das ist n zungenbrecher, ja wenn du das nicht hast, ne so, dann musst du ja wie gesagt du machst alles manuell, du legst keine Ahnung, du legst n Server an, du änderst deine sicherheitsgruppen, du konfigurierst dein Netzwerk, frag mich noch ne, also du klickst dich da durch und hoffst ja eigentlich, dass es funktioniert, vielleicht bist du routiniert und kriegst das irgendwie hin, ich find es aber

irgendwie noch mal gut, auch noch mal zu betonen, dass ne Pipeline. Ne, die ja auch sehr, sehr essentiell ist bei der ganzen Automatisierung von der Bereitstellung von Software und dem zufolge auch von DEV ops, dass eigentlich eine Pipeline da endet, wo die manuelle Infrastruktur oder die Konfiguration der manuellen Infrastruktur beginnt. Ne, weil egal wo du zum Beispiel

irgendwas manuell machst. Ne, du willst jetzt zum Beispiel keine Ahnung, du willst willst irgendwie du willst irgendwie Tests laufen lassen so und du musst da irgendwie manuell dich durchklicken. Dann hast du ja im Endeffekt die ganze Automatisierung, die du mit Def Ops erreichen willst,

stillgelegt. An der Stelle ne und damit endet das Halt und alles was du sag ich jetzt mal manuell machen musst, bricht ja im Endeffekt dann so n bisschen diesen diesen Pipeline Gedanken von es wird Code wird eingecheckt sozusagen bis hinzu Code wird deployed ne und klar wie gesagt wir hatten ja auch über bei CD über Delivery und Deployment geredet, da gibt es vielleicht. Unter Umständen die Möglichkeit, dass man da einen kleinen manuellen Step machen muss, ne?

Der ja aber gewollt ist. Genau in dem Fall noch. Aber ich finde das noch mal so, als als Gedankengang noch mal wichtig zu sagen, Dev OPS ist ja steht ja für Automatisierung, für Geschwindigkeit und wenn du anfängst, dann wieder irgendwas manuell zu machen, dann funktioniert es halt nicht und damit brichst du ja zum Beispiel auch deine ganze CICD Pipeline, beispielsweise ne. Bis auf diesen einen.

Ja, das. Ist das ist ein mega guter Punkt, das genauso zu betrachten, weil sobald ich wirklich manuell was machen muss, habe ich halt meine Automatisierung verloren. Also es ist ja logischerweise ne, aber es ist wirklich wichtig, dass mal genauso anzusprechen, wenn ich nicht sage Lauf los Pipeline so mach das was ich was ich möchte und am Ende ist eine neue Version, zum Beispiel die Ploid, sondern da irgendwelche Schritte

dazwischen sind. Dann bau ich mir fehleranfälligkeiten rein und hole mir Probleme rein wie ey. Aber vorhin hat das noch funktioniert. Ja, was hast du denn vorhin gemacht? Ja genau das gleiche Hallo, warum sollte ich was anderes gemacht haben, weißt du und dann ah OK ich hab was anderes gemacht und genau das verhinderst du damit, das muss halt wirklich vollautomatisiert durchlaufen.

Und das finde ich wirklich eine coole Sache zu sagen okay, sobald ich irgendwie manuell eingreifen muss, habe ich quasi diesen Pipeline gedankenverloren. Ja, also gerade auch das vielleicht noch mal so als Beispiel auf den Punkt zu bringen.

Du hast vielleicht eine Pipeline, die funktioniert bis bis auf Dev zum Beispiel oder Prot du willst aber zum Beispiel noch vor Prot noch mal eine Dev Stage dazu bauen, das kannst du vielleicht irgendwie manuell dir dann die Dev Stage aufbauen und die Pipeline läuft dann auf einmal über die Dev stage, weil

du die mit einbindet. Ne, aber dieser manuelle Schritt dann diese Stage also aufzubauen, dazwischen zu schalten, das Haut dir ja im Endeffekt diesen diesen Automatisierungsgedanken dann raus ne, also da da ist dann sozusagen dieser Bruch drin, den du ja im Endeffekt über die Infrastruktur as Code am Ende sozusagen dann gewährleistest. Dadurch ne und ich find auch immer weil das ich was, wo man ganz oft vielleicht irgendwie auch mal gerne mal hinkommt mit

dem Gedankengang ist und. Das funktioniert in dem und dem Kontext nicht und ich finde immer, dass es trotzdem, egal in welchem Moment es gut ist zu sagen, wie funktioniert es, was ist mein Zielbild, mein wunschbild, wo möchte ich eigentlich wirklich gerne hin und wie kann ich das erreichen, weil oftmals kommt man dann, vielleicht kenn ich auch von mir, dass man halt einfach sagt, so ja, aber das geht doch gar nicht so OK, denken wir mal noch mal anders und sagen, OK, wie

können wir das denn erreichen? Ne, weil oftmals hat man dann sowas wie. Ja, aber ich habe gar keinen, weiß nicht AWS, Azure oder was auch immer, das darf ich gar nicht nutzen. Okay gut heißt ja nicht, dass es, dass es nicht geht. Wie geht es ja super.

Wichtiger Punkt jedes Projekt ist anders und du kommst vielleicht aus anderen Branchen. Andere Technologie, dass du halt nicht so diesen 0 815, aber nicht negativ gemeint, also wirklich so diesen Standard. Pipeline weg gehen kannst, so wie es quasi neben Lehrbuch steht. Aber es ist auch irgendwo eine Mindset frage.

Def Ops ist eine Mindset Frage und das hast du gerade schon wirklich schön gesagt, weil nur weil ich vielleicht nicht 100% es gleich machen kann, heißt es nicht, dass ich nicht 90% davon doch umsetzen könnte oder zumindestens mir eine kleine Pipeline aufbauen kann und da hast du ja schon viel mehr gewonnen als es gar nicht zu haben am Ende ja. Bin ich auf jeden Fall ganz bei dir. Also da muss man halt wirklich offen rangehen und vor allen Dingen lösungsorientiert, das ist halt super.

Entscheidend dabei, aber dann lass uns doch, das ist n guter Punkt mal so n bisschen über Best practices reden wie ich denn dahin komme. Ja, also ich meine gut, wenn du jetzt zum Beispiel sagst, wir, also wir haben ja ne infrastructures Code ist Code, was hilft da auf jeden Fall zum Beispiel schon mal Version control, zum Beispiel sowas wie Git oder so einfach das ganze mit Versionieren. Also du hast deine. Software Anwendung, die wird Versioniert ist ja ne ganz klare Sache.

Genauso ist es dann halt auch ne klare Sache zu sagen, OK wir versionieren halt eben auch unsere unsere Infrastruktur mit ne. Und da kann man jetzt auch sagen, wenn ich es versioniere und das Ganze wie Code betrachte und so sollte ich es auch betrachten, gelten natürlich auch Coding Guidelines, sag ich mal, aber nicht jetzt.

Im Prinzip wie formatiere ich meinen Code ja OKOK, aber es ist ja wahrscheinlich ne andere Skriptsprache als vielleicht deine eigentliche Programmiersprache des Projekts, keine Frage, aber was ich damit meine ist behandel es wie Code das heißt Don't repeat yourself ne mach nicht so n riesen Blog als Skript wo alles irgendwie 534 1000 mal passiert sondern

mach es modular. Zum Beispiel hab ich denn Blöcke da drin ja also so Abschnitte meiner Infrastruktur die ich wieder verwenden kann für eine Stay also. Ja, zum Beispiel. Und dass du halt einfach das sauber hältst, verständlich hältst und auch wartbar und skalierbar, also diese ganz normalen Ansätze, die ich bei meinem Code auch haben. Möchte ja richtig don't you Pete yourself. Gutes Stichwort haben wir auch mal eine Folge drüber gemacht, genau das kann man hier auch

anwenden. Und ansonsten ne absolute Best Practice und das haben wir leider auch schon anders erlebt, oder? Das sind so typische Fails, die einem begegnen, wo denn alle so die Hände über dem Kopf zusammenschlagen. Wie kann er nur, wie kann sowas nur passieren. Oh mein Gott, das ist ja so peinlich, dass das passiert, Stichwort Secrets in der Pipeline credentials was auch immer.

Dass die geleakt werden, dass die mit eingecheckt werden, dass man auf einmal sieht, OK, der hat jetzt ein Secret mit eingecheckt, sein Token, nur ist alles hin, Leute ernsthaft achtet da drauf, es ist verdammt wichtig das nicht zu tun und es kann passieren und da können auch Checks helfen, aber das ist natürlich Best Practice, ganz klar diese Infrastruktur, den Code von den Secrets zu trennen. Ja, was mir noch einfällt ist, was zumindest auch meine Erfahrung widerspiegelt, dass.

Dass es gut ist, wenn du eine Anwendung, also eine Anwendung, darf vom Code her niemals wissen. Im besten Fall, welche Stage es gerade ist. Also wenn du jetzt zum Beispiel als kleines Beispiel, wenn du sagst, Du verwendest zum Beispiel für die Prot. Stage, verwendest du zum Beispiel einen den Service XY auch auf der Prot Stage so und aber du hast zum Beispiel noch eine Dev Stage und dieser Service XY hat auch eine Dev Stage, einfach nur um sozusagen die.

Eben halt den Traffic von bei irgendwelchen Tests und so von der Prod. Stage auch fernzuhalten, so dass du dann aber zum Beispiel nicht sagst in deiner Anwendung, dass irgendwo in deiner Anwendung zum Beispiel, dass die URL von der Prod Stage drin ist und die URL von der von der DEV Stage von diesem x Service XY, sondern dass du das sozusagen auf der Infrastruktur Ebene, also Infrastructure als Code Ebene als Parameter reingibst, das heißt diese.

Du gibst dann im Endeffekt du hast nicht in deiner Software hier URL oder Rest URL zum zur, zur pro Stage und zur Death Stage ne, also du hast nicht 2 ur LS drin, sondern die Anwendung weiß nur wenn ich starte dann bin ich auf irgendeiner Stage und gegen irgendeine URL wenn ich diesen Service anspreche und diese URL kriege ich von außen weil das skaliert tausendmal besser also angenommen du willst eine neue Stage hochfahren und sagst okay die Stage ist jetzt aber zum

Beispiel QA und. Und es gibt eine QR URL. Dann ist es ja absolut wichtig, dann zu wissen, OK, wo gehe ich dann hin, klar, aber du musst jetzt nicht deinen Code anfassen, du musst nur von außen sagen, das ist eine neue Stage und die geht zum Beispiel bei Service XY gegen diese URL und das ist an der Stelle wichtig, weil du dann sozusagen nur deine Infrastruktur anpassen musst, nicht aber deine Software.

Weil wenn ne, wenn du diese ur LS in deinem Code drin hättest, müsstest du ja sozusagen noch diese neue ur l auch ebenso da hinzufügen und ne neue Stage aufsetzen und das sind einfach so n paar Sachen. Ne Stage sollte niemals selber wissen im Vorfeld oder Informationen über verschiedene Stages drin haben, das skaliert ja auch gar nicht. Hast du 10 stages hast du auf einmal 10 URLS drin oder was?

Also ne. Ja, und da Stichwort Skalierbarkeit ist da halt dann auch wirklich der entscheidende Faktor. Am Ende. Genau. Was haben wir denn noch so als Best Practice? Natürlich testen oder automatisierte Checks haben wir jetzt mehrfach gesagt, noch mal angemerkt, weil es wirklich wichtig ist. Du kannst halt auch Infrastructure ist Code abtesten

du kannst testen ob alles passt. Du kannst Checks in der Pipeline laufen lassen und das sollte man auch tun, ist halt vielleicht noch mal so ein Thema für sich, da würde ich jetzt gar nicht zu tief darauf eingehen, weil das hat auch ein Riesenfeld, ist also auch wieder hier und. Die Anmerkung, Falls Liebe zuhören, Liebe zuhören das Thema Dich interessiert, lass es uns wissen, machen wir gerne noch ne def Ops folge zu dem Thema, aber würde ich jetzt hier erstmal nicht weiter vertiefen.

Richtig, aber, und da können wir noch mal von den Best practices, ne, was soll man machen auch noch mal zu den Fallstricken kommen und Herausforderungen, sowas gibt es ja auch immer, kommt man ja nicht drum rum ne ist richtig. Weil ich sag mal, infrastructures Code ist ja jetzt auch nicht so rulesam all so nach dem Motto, sondern man muss natürlich immer gucken, was man denn wo man sich gerade

bewegt. Als Beispiel, wenn du jetzt wirklich sehr, sehr einfache Tasks hast, vielleicht mal kurz was ausprobierst, dann musst du jetzt nicht das ganze Infrastruktur Esco wie ich auch meinte, ne als wir damals das die das angefangen haben zum Beispiel mit dem neuen Cloud Service zu arbeiten. Ne, in meinem alten Job sozusagen, wo ich mal gearbeitet hab.

Da probiert man sich erstmal aus erstmal so ne Art Proof of Concept schaffen und dann kann man das ganze sozusagen hinterher vielleicht noch mal infrastoctors Code gießen, aber vielleicht ist der Task auch einfach nicht komplex genug in Anführungsstrichen. Ne ja großer Punkt, weil es einfach n riesen Overhead wär, muss man ganz klar so sagen, denn einfach an der Stelle und. Was natürlich auch ein Fallstrick sein kann, ist ein Mix aus Infrastructure is code.

Ja, also dass du quasi deine deine ganze Infrastruktur kodiert, vorliegen hast und gleichzeitig eine Art Drift stattfindet, weil vielleicht manuelle Änderungen noch gemacht werden, falls das zulässig ist. Das kann passieren und du einfach irgendwie in so einen undefinierten Zustand kommst. Auch schon erlebt. Das ist ganz schwierig, das ist, da muss man auch wirklich aufpassen.

Gerade also man kommt relativ schnell mal so in die Versuchung zu sagen, ah, ich pass auf, ich mach, ich teste das mal kurz manuell, ich mach ich, ich gieß das jetzt nicht in infrastructures Code, sondern ich probier es einmal kurz aus, dann wird das, dann macht man das und dann stellt man es aber nicht zurück, weil man es halt, man ist abgelenkt und vergisst es und dann ist auf einmal irgendwie und du denkst dir, so was ist denn hier passiert, keiner weiß mehr was los ist.

Völlige Panik, das ist auf jeden Fall auch sehr wichtig. Was ich auch schon mal hatte, da muss man auch ein bisschen aufpassen manchmal, wenn du zum Beispiel. Manchmal hat man Momente, wo du so gewisse Schritte brauchst, dass du sagst, okay, du willst deine Infrastruktur aufbauen, brauchst aber bestimmte Secrets zum Beispiel, und diese Secrets müssen aber in einem Secret Manager in deiner Infrastruktur, in einer Cloud Infrastruktur zum Beispiel liegen, so.

Und dann ist halt die Frage ja gut, aber dein Secret Manager gehört ja eigentlich zu deiner Infrastruktur. Also du kannst ja sozusagen den Infrastrukturen theoretisch nicht aufbauen, bevor du nicht alle Secrets hast. Und deine Infrastruktur wird nur aufgebaut, wenn also dein Secrets Manager kommt nur mit der Infrastruktur. So na das Henna iphone. Genau. Also das sind manchmal auch so, ich sag mal vielleicht Fallstricke, wo man sich immer noch mal n bisschen überlegen

muss. Kann es denn vielleicht sein, dass du deine Infrastruktur in 2 Steps aufbauen musst, dass du sagst, OK, erstmal step 1, du? Ne erstellst den Secrets Manager, dann legst du deine Secrets an die du brauchst und dann kannst du den Rest sozusagen machen. Also sowas hatte ich auch schon ne. Ja, also man muss ganz klar sagen, so ne Pipeline oder so ne ganze Infrastruktur kann halt unglaublich komplex werden und diese dieser hohe Grad an Komplexität.

Sorgt meistens für viele Abhängigkeiten. Versteckte Abhängigkeiten, die auf den ersten Blick dann gar nicht mehr so ersichtlich sind, obwohl es da natürlich hilft, wieder sauberen Code zu haben, der quasi transparent ist. Aber das bringt natürlich einfach Probleme mit sich. Und jetzt wo du es angesprochen hast, so diese 2 Steps, aha, das muss ich machen. Nee, ich muss erst das machen, das zeigt ja auch, dass man ne gewisse Lernkurve benötigt.

Ja, also. Es kommt in dem Moment, wenn ich sage, ich möchte mich mit Death Ops beschäftigen, kommt ne riesen Tool Landschaft auf einen zu, ne was alles möglich ist. Es gibt 1000 verschiedene Möglichkeiten sowas umzusetzen. Das heißt du hast halt so n so n Tooling Overhead der erstmal bewältigt werden muss und die Lernkurve halt auch gemeistert werden muss. Das muss man ja auch fairerweise sagen, es ist ja nicht so. Infrastructure is Code, habe ich

jetzt gehört. Die Folge vielen Dank ihr beiden, ich leg jetzt los und ich mach das heute Abend ist fertig, also wenn dann Chapeau wenn man sich vorher nie damit beschäftigt hat. Also man muss halt schon wirklich bisschen Zeit und Hirnschmalz da reinstecken, aber wie gesagt es lohnt sich am Ende sehr sehr. Dolle, selbst wenn du von einem Cloud Service zum Beispiel auf den anderen Umsteigst ne wie gesagt das ist das was mir halt in der Vergangenheit passiert ist.

Und das hat dann ja wirklich für alle gegolten. Und dann hattest du auf einmal wirklich, wir wussten OK, in x Monaten in so einem halben Jahr oder so müssen wir wirklich komplett alles, alle Anwendungen, die wir in unserer Abteilung quasi entwickeln, die mussten umgestellt werden und dann denkst du dir so, OK, das wird richtig krass, weil gefühlt keiner hier oder die wenigsten haben irgendwie ne Erfahrung mit dem neuen Cloud Dienst und dann denkst du dir so OK dann.

Da musst du jetzt aber wirklich erstmal einen Gewissen, sagen wir mal, eine gewisse Lernkurve an den Start bringen, damit du es im Endeffekt hinterher händeln kannst. Und dass es auch wirklich funktioniert. Also es war auf jeden Fall keine einfache Aufgabe, weil man wirklich es ist komplex wie du meintest. Ja, kommt natürlich auf den Cloud Service drauf an. Ja, aber wenn wir jetzt zum Beispiel Edger oder Abs nehmen, das ist das ist, das ist gigantisch.

Sich damit auseinanderzusetzen, richtig, ist einfach auch so, ja. Hast du noch was? Nee, magst du noch n Fazit ziehen zur Folge? Ja, also cool Infrastructure is code ist ne coole Sache, coole Sache, Daumen hoch ja nee also. Ich würde mal sagen, wenn man wirklich sagt, OK, ich mein es ernst mit def Ops und möchte in diesem Bereich eintauchen und da mitarbeiten, dann führt halt an infrastructures Code kein Weg vorbei.

Ich würde sogar sagen generell eigentlich nicht mehr, also wenn man jetzt sag ich jetzt mal in diesem dabei ist Softwareentwicklung zu lernen, wenn man da gerade eintaucht oder vielleicht früher also ne in in einem frühen Stadium dabei ist, dann kann man jetzt auf jeden Fall schon wissen das kommt auf einen zu ne. Vielleicht noch nicht direkt, aber es wird auf jeden Fall kommen und das ist eigentlich relativ fix, dass man sich irgendwann damit beschäftigt und

es geht jetzt auch nicht genau um die einzelnen Tools, also ist es jetzt diese Cloud oder der Cloud Service oder frag mich nicht mehr, also diese darum geht es nicht, sondern es geht wirklich darum auch die Prinzipien dann zu verinnerlichen, also die Automatisierung, dass man damit super automatisieren kann, dass man damit eine super gute. Transparenz schaffen kann über seine Infrastruktur, die man aufbaut, und dass es natürlich unglaublich effizient ist.

Und was natürlich immer wichtig ist, nicht gleich mammutprojekte. Nehmen, klein anfangen, aber wichtig ist irgendwann einfach wirklich mal anzufangen, damit, sich irgendwann damit zu beschäftigen. Genau, ja, schön zusammengefasst habe ich eigentlich auch gar nichts mehr hinzuzufügen. Wie gesagt, der letzte Punkt ist wichtig, auch wenn die. Eine steile also, auch wenn einem quasi dieser Overhead erstmal gegenüber steht zu sagen, wo fange ich jetzt an, ich muss jetzt irgendwie mich

für Tools entscheiden. Es gibt natürlich auch, das ist ja nichts. Neues in der Softwareentwicklung. Richtig, das ist ja nichts Neues, das kennt ihr doch alle. Aber es gibt halt auch zig Tutorials, es gibt bekannte Anbieter, wo man das, also wo man wirklich ein bisschen an die Hand genommen wird, ansonsten kommt gerne in unseren Discord vorbei.

Liebe zuhören, liebe Zuhörer, falls du das noch nicht bist, also noch nicht Teil unserer Discord Community bist, da gibt es auch Leute, die sich da sehr gut mit auskennen und helfen können. Und wie gesagt, der erste Schritt ist der schwerste, aber danach macht es auch wirklich Spaß. Ist ein cooles Thema, womit man sich auf jeden Fall heutzutage auseinandersetzen sollte, absolut Jo fabi würde ich sagen, haben wir das Thema doch wieder ausführlich besprochen. Blick auf die Uhr.

Wir sind auch schon wieder fortgeschritten in der Zeit, aber es ist immer noch im Rahmen. Also alles gut, ja, da bleibt mir doch eigentlich nichts mehr zu sagen, außer wenn Dir die Folge und der Podcast gefällt, dann lass auf jeden Fall eine Bewertung da, das würde uns mega freuen und auch mega helfen und schreib uns auf jeden Fall auf der Podcast Mail oder im Discord über deine Erfahrung mit infrastructures Code auch bei Fragen Haus in Discord rein.

Wie Tino meinte, Da sind Leute, die gerne helfen und ich würde sagen, wir hören uns in der nächsten Folge wieder und zwar nächsten Donnerstag. Macht es gut, deine Coaling Buddies. Gemeinsam besser.

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android
Open in Metacast