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.