Latest / Coding Buddies | Tech & Dev-Mindset / DevOps #7 - Manuell deployen? Zeit für Infrastructure as Code!

Transcript

DevOps #7 - Manuell deployen? Zeit für Infrastructure as Code! · Coding Buddies | Tech & Dev-Mindset

0:00
Denn Infrastruktur wird nur aufgebaut, wenn also dein
0:03
Secrets Manager kommt, nur mit der Infrastruktur.
0:04
So na das Henna I Coding genau Coding Buddies Dein Podcast rund
0:10
um Softwareentwicklung und aktueller Tech News herzlich
0:13
Willkommen. Halli Hallo und herzlich
0:26
Willkommen zur neuen Folge des Kolumbolis Podcast schön, dass
0:30
du wieder eingeschaltet hast, dass wir wieder zusammengefunden
0:32
haben, deine Gastgeber. Und ja, wie soll es anders sein,
0:35
meine Wenigkeit, der Tino und der fantastische Fabi, der schon
0:39
wieder lächelt, er ist, er hat Bock, ich sehe es, ich sehe es
0:42
einfach, er hat Bock auf diese Folge, er ist bereit, deswegen
0:45
mag ich ihn jetzt begrüßen fabi was geht?
0:47
Ab was geht ab? Liebe geht raus an alle draußen
0:51
im Podcast jetzt einschalten. Wie geht's dir?
0:56
Alles gut? Ich bin müde, weil ich bin
1:00
irgendwie müde. Aber Scheiße, hör ich mal viel
1:02
öfter in letzter Zeit von dir. Was ist da los?
1:06
Ne, ist wahrscheinlich die Frühjahrsmüdigkeit, ich weiß
1:08
nicht gibt es sowas? Ich bin Frühjahrsmüdigkeit bei
1:12
dir anscheinend schon, weil sie ist sehr ausgeprägt, auf jeden
1:14
Fall aber aber weißt du was ich krass finde ist wenn man so auf
1:19
einen Monat guckt wir haben schon wieder bald das erste
1:22
halbe Jahr rum. Crazy oder?
1:26
Also ein bisschen ist noch ja, ja, ja, okay für die, die es
1:29
jetzt ganz genau nehmen, aber für mich geht's schon wieder in
1:32
die Richtung so ja okay das erste Halbjahr ist rum, ich hab
1:34
grad durchgerechnet, so Alter, das ist ja noch nicht mal Juni
1:39
ah ich weiß noch zum Blick auf den Kalender, ich weiß was das
1:42
ist, aber das ist doch krass irgendwie, wie schnell das schon
1:43
wieder alles geht also ich finde die Wochen die Rasen.
1:47
Ja, das sowieso. Aber ich finde, dass es so das
1:51
Jahr geht los. Dann ist auf einmal so März,
1:54
dann zieht sich der März so n bisschen finde ich und dann
1:57
denkt man wieder so okay halbes Jahr schon wieder rum, dann hat
1:59
man irgendwie n weiß nicht, dann ist so Sommer ne das finde ich
2:03
dauert irgendwie zum Glück bei mir mal n bisschen länger so vom
2:06
Feeling her und dann ist auf einmal zack wieder Weihnachten
2:09
also so wenn du gerade so im August direkt zu Weihnachten.
2:11
Ja, wenn du gerade so im August weißt du, auf der Terrasse sitzt
2:14
gerade grillst oder so und dann machst du einmal schnipp und
2:18
zack, ist wieder Weihnachten. Steht schon wieder Rudolf im
2:21
Garten, so bin ich wieder eingeflogen.
2:24
Ja, ich finde es auch spannend, wie schnell das einfach immer
2:27
alles so an einem vorbeizieht. Also ja, man nimmt es ja schon
2:31
aktiv wahr und ich versuche auch wirklich die Zeit immer zu
2:33
genießen, ne, aber es ist trotzdem krass wie schnell das
2:35
geht und warum ich drauf komme ist weil ich finde man merkt das
2:39
auch so ein bisschen am Podcast so jede Woche ne Folge man denkt
2:43
immer so von Folge zu Folge aber wenn man sich das so im
2:45
Gesamtkontext ansieht. Merkt man mal, wie die Zeit
2:48
vergeht, weil uns ist ja aufgefallen, dass wir auch schon
2:51
ne ganze Zeit keine Def Ops folge mehr zu der Reihe gemacht
2:54
haben und das wollen wir ja heute ändern.
2:58
Ja stimmt und bevor wir aber rein starten.
3:03
Noch n kleiner Aufruf liebe Zuhörer, liebe Zuhörer, falls
3:07
dir der Podcast gefällt und auch die Def Ops Reihe zum Beispiel,
3:10
denn heute kommt wieder eine Folge dazu, dann lass uns das
3:13
doch gerne wissen. Schick uns auch gerne n Feedback
3:15
und wenn du Lust hast in den Shownotes findest du n kleinen
3:18
Spendling, damit würdest du uns mega unterstützen, dann vielen
3:20
Dank dafür schon mal und dann würde ich sagen Fabi stell doch
3:24
mal. Das heutige Thema Vorfilm ab,
3:27
das hab ich gerade ja genau, es geht heute mal wieder um ne def
3:32
of Folge wie du schon meintest und zwar um nichts weniger
3:35
Wichtigeres als Infrastructure as Code, also IAC und das ist
3:41
natürlich sehr sehr wichtig. Also wir haben ja bisher zum
3:44
Beispiel schon über CIC geredet, Staging über Logging und
3:48
Observability und das sind ja alles Punkte, wo du irgendwie
3:53
deine Infrastruktur aufbauen musst und.
3:54
Ne, also du musst ja irgendwie, du brauchst ja Server, du
3:57
brauchst n Service, der irgendwie lockt, du musst gucken
4:00
wie du lockst, wie du vielleicht deinen Logger konfigurierst oder
4:03
frag mich nicht, ne, du musst wissen wie du ne Stage aufbaust
4:08
und genau dafür, damit das alles auch richtig flutschen kann, sag
4:12
ich jetzt mal braucht man halt am besten infrastructures Code.
4:16
Ne und was jetzt infrastructures Code genau ist, warum das für
4:20
Def Ops wichtig ist, was da vielleicht für Best practices
4:23
sind und was es für Fallstricke und Herausforderungen gibt, das
4:26
wollen wir eigentlich jetzt mal so in dieser Folge besprechen
4:28
und uns angucken und unsere eigenen Meinungen, Erfahrungen
4:33
noch mitteilen, so wie immer ne. Ja, klingt auf jeden Fall sehr
4:39
cool und ist auch n super wichtiger Bereich, also
4:42
essentiell notwendig, wie man es auch immer sagen möchte.
4:45
Also es geht. Unserer Meinung nach nicht ohne.
4:47
Es ist wirklich ein wichtiger Baustein und deswegen lass uns
4:52
doch mal anfangen mit so ein bisschen Definition was
4:56
Infrastructure is code eigentlich ist.
5:00
Wie könnte man das so ein bisschen auf den Punkt bringen,
5:02
also im Prinzip wenn man es definieren müsste, kann man
5:05
sagen, es ist im Prinzip die Automatisierung und Verwaltung
5:10
genau dieser Infrastruktur, die du gerade genannt hast, die wir
5:13
ja auch in den vergangenen Folgen viel besprochen haben
5:15
und. Über Code, also dass ich das
5:18
wirklich codiere sozusagen in Code verfasse, anstatt manuell
5:22
zu konfigurieren. Ich kann natürlich meine Server
5:25
auch manuell manuell konfigurieren, du hast meistens
5:29
Benutzeroberflächen, wo du alles einstellen kannst.
5:31
Gar kein Thema, das funktioniert alles.
5:33
Aber es geht jetzt darum zu sagen, Nein, wir konfigurieren
5:37
es nicht manuell mit Maus und Tastatur und ich brauche n
5:40
Mitarbeiter quasi jedes Mal dafür, sondern über Code wird
5:44
das Ganze definiert. Die Infrastruktur, das heißt
5:48
wenn man das so n bisschen vergleichen sollte, wir haben im
5:52
Prinzip. Eine Version unserer
5:55
Infrastruktur für die Serverlandschaft codiert
5:58
sozusagen. Also ich habe Code, der
6:00
beschreibt, wie eine spezieller Stand unserer Infrastruktur
6:04
aussieht. Genau.
6:06
Wenn man sich jetzt so Pseudocode vorstellt, steht da
6:08
drin sowas wie fahre einen Server hoch, lade zum Beispiel
6:12
da folgendes Artefakt hin und deploye Anwendung x auf diesen
6:17
Server jetzt mal so ganz ganz auf ganz ganz hohen.
6:19
Einblick aber genauso kann man sich das ja vorstellen.
6:21
Zieh dir den neuesten Stand von deiner Anwendung genau, führe
6:26
die Tests aus so. Genau, weil sie da bei CICD
6:30
sind, ganz genau, und das ist halt, also es hat ja diverse
6:34
Vorteile. Und zwar gerade weil du
6:37
meintest, du hast ja zum Beispiel, wenn du deine deine
6:40
Oberfläche zum Beispiel benutzt, um manuell deine Server
6:43
Landschaft aufzubauen und deine Infrastruktur, dann hast du ja
6:48
das Problem, dass du angenommen, du möchtest zum Beispiel Stage 1
6:52
aufsetzen, ne, also zum Beispiel die Dev Stage beispielsweise
6:56
über Stages hatten wir auch schon geredet und weiß nicht die
6:59
QR Stage und die prod Stage so. Und du machst das alles manuell,
7:04
dann hast du ja eventuell das Problem, dass du sagst, na ja,
7:07
OK, ich warte mal. Wie hab ich das bei die Dev
7:10
Umgebung, die hat dich aufgesetzt vor einem halben Jahr
7:12
aber jetzt brauchen wir ne QR Umgebung ah hoffentlich vergess
7:15
ich nichts ne also diese wiederholbarkeit, also dass du
7:19
deine Infrastruktur 1 zu 1 reproduzieren kannst, die wird
7:23
das wird echt schwierig ne wenn du das nicht irgendwie in in so
7:27
ne Art infrastructures Code verpackst ne weil zum Beispiel.
7:32
Erstens musst du dich daran erinnern und vielleicht sagen,
7:34
ja, guck mal hier, da habe ich ja den Klick gemacht in
7:37
Anführungsstrichen, da habe ich genau das und das eingegeben,
7:41
was auch immer, wenn man es jetzt mal so wirklich, ganz
7:44
salopp sagen möchte. Und wenn du jetzt zum Beispiel
7:49
sagst, ja gut, du kannst ja auch dokumentieren, ja, aber das ist
7:51
ein Riesenaufwand, wenn du eh schon den Code schreibst, wieso
7:53
dokumentieren, das manuell machen, wenn du dann nicht aber
7:56
einfach sagen kannst okay ich. Ich kann halt einfach meinen
8:00
Infrastruktur als Code Template nehmen und sagen und jetzt los,
8:03
bau das so auf, also wiederholbarkeit um es kurz zu
8:06
fassen ist halt ein Vorteil, der ist halt sehr sehr wichtig.
8:10
Ja, weil wie du ja meinst, es ist super fehleranfällig, wenn
8:12
man das denn quasi nicht über IAC macht.
8:17
Mal angenommen du hast jetzt ein Entwicklerteam und arbeitest ja
8:21
zum Beispiel. Wie auch immer, an Frontend ne
8:24
sehen wir einfach mal ne Website und mehrere Leute arbeiten da
8:28
drauf, pflegen Ihre Änderungen ein und gehen jetzt immer zu dem
8:32
Dev Ops Mitarbeiter und sagen ey übrigens ich hab jetzt hier in
8:35
unserer Repository ne neue Änderung reingehauen.
8:39
Check die doch mal durch. Teste das mal durch, probier mal
8:42
alles, dann guckst du mal ob das funktioniert und wenn es geht,
8:46
dann geh mal bitte auf den Server und Roll mal da per Hand
8:50
die neue Version aus, das heißt Bau da mal zum Beispiel n
8:52
Container auf und starte mal das Frontend damit das dann quasi
8:56
global zur Verfügung steht so der macht jetzt 1000 Schritte
9:00
wenn man jetzt wirklich davon ausgeht der Macht das manuell so
9:03
und jetzt kommen 56 mal am Tag Leute und sagen ey ich hab
9:06
übrigens hier den Button geändert ne.
9:09
Hammer Deployder Swi wird. Na dann hat er wohl viel
9:13
anfällig, dann hat er aber das ist halt so fehlanfällig, weil
9:16
der ja da wird niemals was schiefgehen und genau das ist
9:20
der Punkt ne diese wiederholbarkeit, du musst es ja
9:23
sehr sehr oft machen. Ne.
9:26
Und du willst es immer gleich machen und das ist halt wirklich
9:29
ein riesen Vorteil, wenn einfach festgeschrieben ist durch diesen
9:33
Code was zu tun ist und absolut klar ist, in welcher Reihenfolge
9:38
das auch passiert, dass nichts ausbleibt, dass alle Stages
9:41
durchlaufen wären und so weiter und ein Punkt, der dabei auch
9:45
noch richtig essentiell ist und den darf man nicht
9:48
unterschätzen. Diese Infrastructure ist Code
9:52
kannst du ja genauso versionieren wie dein
9:54
Softwareprojekt an sich und. Zum Beispiel mit Git.
9:57
Das heißt, du hast einen riesen Vorteil dadurch, dass du
10:01
Versioniert eine Version deiner Infrastruktur hast.
10:05
Und solltest du n Fehler einbauen, kannst du auch immer
10:07
wieder zurückgehen und so weiter du hast es halt wirklich als
10:11
Historie abgelegt und dementsprechend auch wie du
10:14
meintest ne Dokumentation da drin und das finde ich ist halt
10:18
n riesen riesen Vorteil da die. Musst du halt nicht on top
10:20
setzen, ne? Als Beispiel angenommen, Du
10:23
sagst du möchtest den Server noch mal ein bisschen neu
10:25
konfigurieren, weil da ist dir was aufgefallen und du
10:31
konfigurierst den Server und auf einmal startet der Server nicht
10:34
mehr oder was auch immer, dann ist langsam oder kannst dir
10:38
irgendwas ausdenken was es halt alles so gibt, aber dann kannst
10:42
du halt genau vielleicht auch wenn du es nicht selber gemacht
10:45
hast, sondern vielleicht ein Teamkollege der gestern in
10:47
Urlaub gegangen ist. Dann kannst du gucken, OK, was
10:49
ist denn jetzt zum Beispiel eine Infrastruktur, was wurde denn
10:51
verstellt? Ne, wenn du das jetzt, wenn
10:53
jetzt aber das ganze über irgendeine Oberfläche eingegeben
10:56
wurde oder sonst was, dann kannst du es halt nicht wirklich
10:59
richtig gut nachvollziehen, du weißt halt gar nicht, was ist
11:01
denn gerade passiert, was wurde denn eingestellt?
11:04
Ne also du du hast halt nicht diese diese Version deiner
11:07
Infrastruktur dann am Ende und. Das ist halt da.
11:10
Klickst du dich dann wild durch irgendeine UI durch und
11:12
versuchst irgendwo zu ergründen, wo sich was geändert haben
11:16
könnte. Das ist die Hölle auf Erden.
11:19
Definitiv, ja, genau. Und aber das sind halt diese
11:23
ganzen Vorteile von infrastructures Code, ne.
11:25
Also wir haben ja jetzt gesagt, die Wiederholbarkeit, die
11:29
Versionierbarkeit Dokumentation durch Code und die
11:31
automatisierte Bereitstellung ne von irgendwelchen Containern von
11:34
Deiner Software von der neuen Version und so weiter ja das ist
11:37
natürlich super und jetzt haben wir OK Infrastruktur
11:41
infrastructures Code, gute Sache und.
11:44
Wir sind ja jetzt in der Def Ops Folge und dann ist ja die Frage
11:46
OK, wieso ist der infrastructures Code jetzt auch
11:50
wirklich wichtig im def ops Kontext sag ich jetzt mal ne,
11:53
das ist ja an sich jetzt ne gute.
11:54
Frage, Was ist da der Key? Also was sind die Punkte?
12:01
Ja, also den einen Hauptpunkt haben wir ja eigentlich schon
12:07
angesprochen, dass das ganze Halt automatisierbar ist.
12:09
Ne, also diese Infrastruktur die ich mir aufbaue.
12:12
Kann ich automatisiert ausrollen?
12:15
Und davon lebt ja dev Ops irgendwo auch am Ende, dass du
12:19
halt sagen kannst, OK, ich muss jetzt nicht manuell Server
12:22
einrichten, Datenbanken einrichten oder oder sei es nur
12:26
du hast einen neuen Kollegen und der braucht eine
12:28
Entwicklungsumgebung, die vielleicht ein bisschen größer
12:30
oder komplizierter ist, dann musst du halt nicht manuell
12:33
immer alles einrichten, sondern du hast das halt automatisiert
12:37
in der Hinterhand, sage ich mal und sagst OK, hier pass auf.
12:40
Lass das laufen und dann bist du am Start sozusagen.
12:44
Also du kannst ja so n Skript, muss ja nicht nur beispielsweise
12:48
in der Cloud laufen oder auf irgendwelchen Servern, du kannst
12:50
es ja auch lokal laufen lassen, je nachdem wie die aufgebaut
12:54
sind, aber die Möglichkeit besteht ja ne, dass du halt
12:57
diese Infrastruktur auch lokal bei einem neuen Kollegen zum
12:59
Beispiel einrichten kannst. Und das finde ich, ist halt n
13:02
riesen riesen Benefit dabei. Da hatte ich zum Beispiel auch
13:06
mal was richtig cooles. Ein alter Kollege, der hat dann
13:10
irgendwann für die, für die ich sag, jetzt mal Abteilung hat so
13:14
n Skript geschrieben und dann konntest du einfach dieses
13:17
Skript auf deinem Rechner ausführen, konntest einfach
13:20
starten und dann wurden eigentlich so die ganzen
13:22
gängigen Sachen, die man eigentlich so bei uns verwendet
13:26
hat, dann einfach installiert. Die IDI was weiß ich zum
13:30
Beispiel ne ne git CLI frag mich nicht docker.
13:35
Und und so weiter ne, also diese ganzen Sachen wurden halt
13:37
einfach installiert wurde. Das ist dann halt am Ende zum
13:40
Beispiel über Homebrew passiert meistens, aber das Ding ist, das
13:44
ist ja super, super entspannt also in wenn wenn es jetzt zum
13:47
Infrastructure Code geht ist es ja nicht immer nur und das finde
13:50
ich gut, dass du das noch mal gesagt hast.
13:52
Immer nur dieses Remote. Ich setz meine Serverlandschaft
13:55
für meine Anwendungen auf, sondern es geht ja auch dahin,
13:57
dass du als Def Ops Team zum Beispiel das Automatisierst und
14:01
sagst, ey, es gibt n Onboarding, guck mal hier, du brauchst dich
14:04
jetzt nicht hinsetzen und alles manuell, ne das brauchst du, das
14:07
brauchst du. Ach jetzt hab ich wieder das
14:09
vergessen, ich kann ja noch gar nicht arbeiten oder was auch
14:11
immer, sondern dass du halt wirklich sagst, so OK cool, ich
14:14
hab hier n Skript, ich führ das aus und eigentlich.
14:17
Ich sag mal im Normalfall zu 90% kannst du dann sofort loslegen,
14:21
ne und das ist halt schon irgendwie cool und dann rattert
14:23
das dann Kaffee. Holen und dann geht es.
14:25
Los. Genau dann rattert das dann ne
14:26
Kaffeelänge und dann ist super. Also das fand ich auf jeden Fall
14:28
richtig cool. Ne, also über sowas kann man
14:30
natürlich auch nachdenken, dass man halt noch diesen Schritt
14:33
geht und sagt, was kann man denn automatisieren?
14:36
Was ja auch irgendwo Infrastruktur am Ende ist.
14:38
Ne ja und da kommen wir auch gleich zum nächsten riesen
14:42
Pluspunkt diese Reproduzierbarkeit.
14:45
Mal angenommen du hast so n. Onboarding Tag ja, also bist
14:49
vielleicht in einem größeren Unternehmen.
14:51
Es fangen jetzt ein paar neue Kollegen an, also ja meinetwegen
14:54
55 neue Kollegen und Kolleginnen, ne, jetzt bist du
15:00
der eine der sich super in dieser Entwicklungsumgebung
15:02
auskennt und hast keine hast das nicht kodiert deine
15:06
Infrastruktur ne also du hast das nicht automatisiert, wie
15:10
würde das ablaufen? Du gehst zum ersten Kollegen.
15:13
Richtest das alles ein, erklärst ihm das hier.
15:16
Du brauchst das, du musst das installieren und so Weitergehst
15:19
zum nächsten. Du kannst dich ja nicht
15:20
aufteilen, das heißt, das muss ja sequentiell abgearbeitet
15:23
werden. Ja, diese diese Einrichtung, und
15:26
wenn du jetzt aber das ganze Infrastructure is code mäßig
15:29
aufsetzt, kannst du einfach sagen hier Leute.
15:33
Das Rebo zieht euch, das richtet euch alles ein und ihr seid am
15:36
Start, wenn ihr fertig seid, können wir dann alle gemeinsam
15:39
quasi über die nächsten Schritte reden.
15:41
Also du kannst es halt parallelisieren, ne und
15:44
konsistent halten, das heißt es wird bei allen Fingers crosst,
15:48
aber in der Regel schon ne gleich eingerichtet sein am Ende
15:55
ich mein Gut der bekanntlich sitzt der Fehler oft vorm PC,
15:58
wer weiß was der eine oder andere neben dem mittlerweile
16:00
noch macht, aber. Das ist trotzdem der riesen
16:04
Pluspunkt dabei. Ne ja richtig und Konsistenz zum
16:07
Beispiel auch gerade weil wir auch schon über Staging geredet
16:09
haben. Es ist ja auch immer super wenn
16:11
du ich ich weiß nicht ob man das, also ich hab es schon
16:15
erlebt, dass du halt du hast irgendeine ne Umgebung, du setzt
16:17
halt dann zum Beispiel Prott auf oder so oder QA oder ne meine
16:23
Lieblingsumgebung nenn sie wie du möchtest und dann sagst du
16:26
aber ja, aber zum Beispiel. Das funktioniert da nicht so wie
16:29
da, weil da ist zum Beispiel Prot ist ganz anders
16:32
konfiguriert als zum Beispiel dev.
16:34
So also das ist ja wirklich, das ist ja was ganz anderes, und
16:36
damit hast du dann aber auch schon wieder den Punkt, dass du
16:39
ja sagst, okay, wie willst du denn auf Dev etwas testen, wenn
16:43
Prot ganz ganz anders konfiguriert ist?
16:45
Ne, und damit du halt eben nicht diese in in die Versuchung
16:49
kommst zu sagen, ey ich möchte jetzt aber vielleicht, dass, das
16:52
mache ich manuell mal ein bisschen so und das mache ich
16:54
manuell ein bisschen so, dass du gar nicht erst da.
16:57
In diese Falle tappen kannst. Ja.
16:59
Hilft dir halt auch infrastructures Code.
17:02
Ja, du kannst halt sagen, das ist meine Stage, so ist meine
17:04
Stage aufgebaut und go ne jetzt mal unabhängig davon, dass du
17:08
vielleicht irgendwie andere. Services auf anderen Stages
17:13
wiederum ansprichst also externe Services.
17:16
Ne, das ist sei mal dahingestellt ne, aber ich mein
17:18
jetzt wirklich die Konfiguration deines Netzwerkes innerhalb der
17:22
Cloud oder was auch immer ne also da es gibt so viel was man
17:25
einstellen kann, was man theoretisch auch wirklich falsch
17:27
einstellen kann und da ist es natürlich absolut wichtig, dass
17:32
das wirklich auch immer gleich funktioniert.
17:36
Ja, weil diese Überraschung, die du dann haben kannst, so
17:39
komisch. Also bei mir hat es
17:40
funktioniert, auf meiner Maschine läuft das ja, auf
17:43
Server a läuft das, das sind somit die schlimmsten Aussagen
17:46
die man tätigen kann, weil dann stehst du halt echt vor dem
17:48
großen Unbekannten und denkst dir so was jetzt, also jetzt
17:53
müssen wir erstmal rausfinden was hier los ist und dann weißt
17:56
du halt zum Beispiel nicht mehr, dass Kollege XY ja vielleicht
17:59
noch ein 2 Klicks manuell gemacht hat, irgendwas
18:02
umgestellt hat. Das ist die Server 5 rechts
18:05
hinten in der Ecke meinst du genau der böse Server 5 hinten
18:08
rechts in der Ecke ist es wieder, der ist ja schon
18:10
mehrfach hier im Podcast aufgetaucht, er ist immer der
18:14
Übeltäter am Ende. Ja, ansonsten hatten wir auch
18:18
schon über Versionierbarkeit geredet und finde ich auch
18:20
Transparenz. Es spielt da ne wichtige Rolle,
18:23
weil angenommen dieser Punkt, wir sind jetzt noch mal wieder
18:26
in diesem Modus, wir konfigurieren irgendwas manuell
18:30
so, dann hast du ja entweder die.
18:32
Also entweder hast du den Punkt, dass du immer dann wirklich
18:35
quasi so n Peer Review machen musst, dass noch einer dabei
18:38
sitzt und man dann zusammen sozusagen verifiziert.
18:41
OK, wir machen das jetzt so und so und so ne trotzdem nicht gut,
18:44
wenn es manuell ist. Aber selbst wenn du das alleine
18:47
machst und dann hinterher sagst du Pass auf, ich hab jetzt das
18:49
und das so und so eingestellt, aber angenommen du hast keine
18:53
Ahnung 10 manuelle Schritte gemacht, ne so, dann vergisst du
18:56
halt vielleicht 2 davon, ne sind vielleicht sogar mehr und dann.
19:02
Weiß ja gar nicht, also kannst du ja gar nicht dieses dieses
19:05
ich sag ich nenn es jetzt einfach mal dieses Code review
19:07
machen ne also wenn du Infrastruktur als Code hast,
19:09
dann kannst du ja dein dein dein Infrastruktur über den Code
19:12
anpassen und dann hinterher ganz normal mit Git einfach dieses
19:16
div machen und sagen guck mal hier habe ich das verändert,
19:19
hier habe ich das verändert ne also das heißt du kannst nicht
19:21
nur nachvollziehen. Im Nachhinein, wenn vielleicht
19:24
was schief geht oder wenn wenn es auch gut gegangen ist, was es
19:27
für Änderungen gab, sondern du kannst auch super eine Art Code
19:30
Review für die Infrastruktur machen und das ist halt auch.
19:34
Ziemlich also eine ziemlich geile Sache, absolut.
19:39
Und die Verantwortlichkeiten rücken ja auch mehr zusammen.
19:41
Ich meine, wir reden ja hier in der Def Ops Reihe logischerweise
19:44
über Def Ops und da geht es ja darum, dass du auch Defs und Ops
19:48
quasi näher zusammenbringst und dass sie.
19:51
Halt zusammenarbeiten ne und nicht sag ich mal die Developer
19:54
das so Rüberreichen nach dem Motto und jetzt sorg dafür, dass
19:57
es in die Welt kommt und das ist halt n riesen Punkt was das
20:01
Ganze auch vereinfacht zu sagen wir wir machen das ganze oder
20:05
nutzen Infrastructure is code ne weil du halt auch quasi sag ich
20:09
mal an einer Codebasis an einem Fundament arbeiten kannst.
20:12
Weil diese Skripte beispielsweise ja sehr oft auch
20:17
mit in dem Projekt Abliegen, das heißt, beide haben ja Zugriff da
20:20
drauf und können das zum Beispiel Reviewen oder abändern.
20:23
Definitiv. Also beide Parteien, wenn man es
20:26
jetzt noch mal getrennt. Betrachtet.
20:29
Obwohl also beim es ist ja immer so ne Death und Ops so 2 Teams
20:33
die nah zusammenarbeiten so in meinem Kopf ist das schon so
20:36
richtig. Es ist halt so ein Team.
20:40
Also weißt du, also du bist du hast Def Ops durchgespielt,
20:43
quasi ein def Ops. Du bist ein def Ops.
20:46
Ja genau das ist ja das Ziel, dann halt wirklich das
20:49
zusammenzubringen, ja genau was auf jeden Fall.
20:53
Noch n nächster Punkt ist der mir jetzt direkt einfallen würde
20:55
wäre, dass man halt einfach auch schneller irgendwas
20:58
bereitstellen kann. Ne ich meine ja absolut.
21:01
Klar. Hatten wir auch schon so n
21:03
bisschen drüber geredet. Einfach angenommen du sagst OK.
21:08
Du brauchst eine neue Stage und ich hatte es auch schon mal
21:11
einem alten Projekt. Da haben wir erstmal mit einer,
21:14
ich glaube wir hatten einfach nur eine Sandbox Stage, weil wir
21:17
nur gesagt haben okay, wir machen gerade ein MVP.
21:19
Es gibt eigentlich nicht großartig Daten die irgendwie
21:23
konsistent gehalten werden müssen, wir können die jederzeit
21:25
weghauen, alles gar kein Problem, das heißt wir hatten
21:28
einfach nur eine Sandbox Stage und haben einfach nur damit
21:30
gearbeitet so und ich weiß aber weil wir mussten halt quasi alle
21:38
so. Dieses diese, diese neue
21:40
Technologie, die neue Cloud Technologie sozusagen uns in der
21:43
ganzen Abteilung drauf drücken, damit man halt damit arbeiten
21:46
konnte, weil das Halt so n Shit gab und da war es dann so, dass
21:51
wir erstmal relativ viel ausprobiert haben, ne und dann
21:54
irgendwann also erstmal so manuelle Testschritte gemacht
21:56
haben um zu gucken OK, funktioniert das jetzt wirklich
21:59
richtig wie man sich das vorstellt ne n bisschen damit
22:02
rumgespielt mit dieser ich sag mal Oberfläche, dass man halt so
22:06
einfach n Feeling dafür bekommen hat.
22:08
Und dann hat man das Ganze irgendwann in diese
22:11
infrastructures Code gegossen, damit man es halt einfach
22:14
schnell hochfahren kann. Und dann war es aber irgendwann
22:16
soweit, dass wir gesagt haben, OK, wir brauchen jetzt aber
22:18
wirklich mal ne ne ne prod stage, ne prod so und.
22:23
Da war es halt einfach super hilfreich, dass es halt einfach
22:26
dieses Template gab, um zu sagen okay, wir fahren jetzt die also
22:29
die die gleiche Infrastruktur noch mal hoch auf einer anderen
22:32
Stage und nennen die Halt dann prod.
22:33
So also das ist dann halt diese kleine andere Konfiguration hat
22:37
einen anderen Namen, hat vielleicht wie gesagt andere
22:40
Services die angesprochen werden, also beziehungsweise der
22:42
gleiche Service auf einer anderen Stage wiederum aber
22:46
hätten wir das manuell gemacht. Ja, dann hätten wir
22:49
wahrscheinlich deinen ganzen Tag dran gesessen und so hat es halt
22:52
vielleicht ja, lassen wir jetzt nicht lügen, ne halbe Stunde
22:55
gedauert, bis wirklich die Infrastruktur initialisiert und
22:57
hochgefahren wurde, ne? Ja.
23:00
Also ne krasse, das ist. Natürlich n Riesen genau ist n
23:03
riesen Unterschied und gleichzeitig halt auch sicherer.
23:05
Ne also wenn du jetzt das Ganze noch mal manuell aufziehst wird
23:08
auf jeden Fall was schief gehen, da kannst du eigentlich von
23:11
ausgehen und genauso ist ja die Frage wenn du jetzt zum Beispiel
23:15
sagst. Wir brauchen eine neue Stage und
23:17
wir machen vielleicht kleine Anpassung, weil die Stage ein
23:19
bisschen anders ist, ne oder eine andere Konfiguration und da
23:23
geht was schief, dann kannst du es halt auch immer per Rollback
23:25
zurücksetzen und das genauso schnell, aber wie auch vorhin
23:29
meintest genau, weil du hattest ja vorhin gesagt, angenommen der
23:33
Server fährt dann nicht mehr hoch, ja was machst du dann?
23:36
Das kann halt wirklich Geld kosten, dem Unternehmen ne so
23:39
ein Server Ausfall beziehungsweise ein Service
23:41
Ausfall, dass du nicht mehr erreichbar bist.
23:44
Dann ist es natürlich goldwert zu sagen, ey, wir machen jetzt
23:47
einfach erstmal n rollback und gehen auf den alten Stand zurück
23:51
und der Server ist aber n paar Minuten wieder am Start oder
23:54
vielleicht maximal ne halbe Dreiviertelstunde, je nachdem
23:57
wie wie groß die Pipeline ist, ne?
23:59
Da hatte ich auch mal n ganz lustigen Fall ne, weil das ist
24:02
nämlich wirklich auch interessant.
24:03
Rollback OK möglich, aber was auch absolut n valider Punkt
24:08
sein kann ist hatte ich auch schon mal.
24:10
Die Umgebung war wirklich kaputt, ne?
24:13
Und wir wussten gar nicht mehr, OK, Mist, was ist denn jetzt
24:16
los? Und dann haben wir einfach die
24:17
Komplettumgebung abgeräumt, also wirklich gesagt, komm, schmeiß
24:20
das alles weg und dadurch, dass man es halt nicht manuell wieder
24:23
als klicki, klicki, bunti und alles ne aufbauen musste,
24:26
sondern einfach wieder das Template Reinschießt.
24:29
Wurde die einmal wieder aufgebaut?
24:30
Die Umgebung, alles war wieder gut so, also dann halt von
24:33
Rollback von der vorherigen Version definitiv, aber dass man
24:36
wirklich sagt, OK ich schmeiß auch einfach alles weg und bau
24:38
es noch mal neu auf vom vom Scratch so teilweise deutlich
24:42
schneller, als dass du dann noch mal sagst OK, also manchmal, das
24:46
ist wirklich auch das Wichtige bei Infrastruktur möchte ich
24:48
auch noch mal schon mal direkt spoilern, du kannst dich da auch
24:53
wirklich. In eine Einbahnstraße
24:55
manövrieren, dass du sagst, wenn du das jetzt konfiguriert hast
24:58
und das einmal hoch, also live geschaltet hast, diese
25:01
Infrastruktur, dann kommst du da nicht mehr zurück und deswegen
25:05
ist es manchmal auch notwendig zu sagen, einmal komplett
25:07
abräumen, wieder neu hochfahren und diese schnelle
25:11
Bereitstellung dann wieder. Das ist auch richtig essentiell
25:13
und das geht auch nur mit infrastructures Code.
25:16
Ja. Und wenn wir auch bei dem Thema
25:20
Ausfälle sind oder dass halt irgendwas schief läuft, kann man
25:24
natürlich auch ganz klar sagen, dass du mit Infrastructure is
25:27
Code auch die Möglichkeit hast gewisse Sicherheiten einzubauen.
25:31
Ne, also beispielsweise Security Policies, Checks, das ist ja
25:36
alles möglich, dass du sagen kannst, beispielsweise weil ich
25:40
ja vorhin meinte jemand committed was ne Änderung zum
25:44
Beispiel auf dem Frontend und geht jetzt zu dem Dev ops.
25:48
Mitarbeiter und sagt hier manuell los geht es.
25:50
Mach das mal alles ne, dann kann der das natürlich auch checken,
25:53
vergisst aber vielleicht was oder oder macht es nicht
25:56
gründlich genug, weil er es schon fünfmal am Tag gemacht hat
25:58
und genauso kannst du in deine in deinem Code in deinen
26:02
Skripten genau so ne Security Aspekte auch einbauen.
26:05
Ja die denn zum Beispiel schon beim Commit gecheckt werden und
26:09
das sind halt auch Riesenpunkte die dafür sprechen einfach es so
26:13
umzusetzen. Oder die das schon zur Pflicht
26:16
machen. Muss man einfach so sagen, ja,
26:18
definitiv, also es ist ja auch zum Beispiel wenn du sagst, OK,
26:21
wir haben ne Datenbank und die muss jetzt auf einmal
26:23
verschlüsselt werden, ne, dann kannst du im Normalfall oder in
26:28
gängigen sag ich jetzt mal Infrastrukturen die du halt
26:32
nutzen kannst in der Cloud, wenn du so n infrastructures Code
26:35
nutzen kannst, hast du halt die Möglichkeit denn sowas zu sagen
26:38
wie ja hier bitte einmal Datenbank XY verschlüsseln mit.
26:43
Dem und dem Algorithmus, was auch immer ne.
26:45
Also da gibt es ja dann verschiedene Konfigurationen was
26:47
man nehmen kann und das ist aber dann im Endeffekt eigentlich nur
26:50
eine Zeile die du hinzufügst. Und im Endeffekt hast du, kannst
26:56
du diese Infrastruktur sozusagen neu deployen und es funktioniert
26:58
dann auch wieder für alle Stages.
27:00
Du musst also jetzt auch nicht wieder hingehen und sagen okay,
27:01
ich habe 5 stages, ich gehe jetzt da rein, klicke hier ja
27:04
bitte einmal die Datenbank hier verschlüsseln okay dann hier
27:08
nächste Stage, hier wieder Datenbank wieder verschlüsseln
27:10
und so weiter. Es kann halt auch durchaus sein,
27:13
dass du zum Beispiel für eine eigene Stage auch wieder
27:15
sozusagen einen eigenen Account anlegst.
27:17
Das heißt, im Worst case musst du dich dann, wenn du es manuell
27:19
machst, dort einloggen, ausloggen, wieder einloggen,
27:22
dahin manövrieren, ne. Also es ist halt dann echt ein
27:26
bisschen was zu tun und so hast du das halt einfach nur mit
27:28
einer Zeile und dann fire und ne, die sozusagen deployen in
27:33
Anführungsstrichen, dann ist fertig, dann wird deine
27:34
Infrastruktur eingerichtet, das ist halt cool, ein guter Punkt.
27:41
Genau. Also das ist auf jeden Fall.
27:42
Es ist ja auch n bisschen so Richtung Compliance, ne, dass du
27:45
halt auch nachweislich, also es ist halt niedergeschrieben als
27:49
Code, was passiert ne und du kannst es halt nachweisen und
27:52
wenn es wie Versioniert ist, kannst du auch noch zeigen, wie
27:54
es sich über die Iteration weiterentwickelt hat.
27:57
Ne und das sind je nachdem in welchem Projekt man arbeitet
28:00
halt unfassbar wichtige Punkte auch Richtung The Tracability
28:05
zum Beispiel. Ja das spielt ja da auch ne
28:06
Rolle. Aber kommen wir mal noch n
28:10
bisschen zu der Def Ops Kultur zurück.
28:13
Da haben wir auch quasi die Reihe mit eröffnet so n bisschen
28:16
ne diese ganze der ganze kulturelle Gedanke dahinter und
28:19
da würde ich noch mal gerne aufgreifen, dass wir ganz
28:22
ursprünglich am Anfang vor Monaten quasi gesagt hatten,
28:27
dass es ja in dieser Def Ops Kultur auch darum geht
28:31
Wissensilos abzubauen und da muss man ja sagen, dass
28:35
Infrastructure escode. N super Mittel dafür ist, weil
28:39
du halt jetzt nicht mehr den obs Mitarbeiter hast.
28:43
Also jetzt ohne def. Der jetzt in seinem Büro im
28:46
Dunkeln da die Server einrichtet und alles dafür sorgt oder alles
28:50
dafür tut, dass das irgendwie funktioniert, aber keiner weiß
28:53
was er da eigentlich macht, weil das wäre ja n riesen Wissenssilo
28:58
am Ende was denn aufgebaut wurde, weil wenn diese Person
29:01
kündigt im Urlaub ist oder was auch immer.
29:04
Da halt nichts mehr passiert, wenn dann da Fehler auftauchen,
29:06
dann weiß keiner was los ist. Und mit Infrastructure is Code
29:11
kannst du halt auch die Entwickler mit ins Boot holen
29:14
und dass sie quasi ihre eigene Infrastruktur mitgestalten
29:17
können. Mit Coden können, dass sich.
29:21
Die Ops Leute aber, die n bisschen mehr Richtung Ops
29:24
gehen, ne das ist ja dann auch so n bisschen so Gewichtung sag
29:26
ich mal bei dev ops sich halt auf andere Aspekte konzentrieren
29:31
können oder mehr fokussieren können, wie zum Beispiel was
29:34
hatten wir in der letzten Folge das Monitoring zum Beispiel oder
29:37
zum Beispiel wie du vorhin meintest Skalierung ne wie kann
29:40
ich das ganze jetzt auf mehreren Servern ausräumen, wie kann ich
29:43
das gut skalieren das Ganze. Und da kann man halt sagen, dass
29:48
so ein so ein Code, diese Infrastructure is code, so ein
29:52
gemeinsamer Nenner für alle Entwickler sein kann und du
29:56
dadurch noch enger zusammenarbeiten kannst.
29:59
Ja, richtig. Und also ist auf jeden Fall ein
30:02
sehr wichtiger Punkt, also diese, diese, gerade diese
30:04
Kultur, die dahinter steht, finde ich, ist auf jeden Fall
30:09
ein wichtiger Gedanke, den sollte man auf jeden Fall auch
30:11
nicht außen vor lassen und. Weil wir ja vorhin auch noch mal
30:15
bei CICD Pipelines waren. Ne, also das hat, da hatten wir
30:18
ja auch gerade über CI und CD auch ne eigene Folge gemacht,
30:24
wollte ich jetzt noch einmal kurz aufgreifen, weil ich finde
30:27
es eigentlich irgendwie ganz spannend, dass man ja wirklich
30:30
sagen kann, wenn du kein Infrastructure als Code hast,
30:33
dann kannst du auch nicht wirklich continuous deliver ne,
30:38
weil. Wie gesagt, wenn du diese
30:41
Infrastruktur als das ist n zungenbrecher, ja wenn du das
30:46
nicht hast, ne so, dann musst du ja wie gesagt du machst alles
30:49
manuell, du legst keine Ahnung, du legst n Server an, du änderst
30:53
deine sicherheitsgruppen, du konfigurierst dein Netzwerk,
30:56
frag mich noch ne, also du klickst dich da durch und hoffst
30:59
ja eigentlich, dass es funktioniert, vielleicht bist du
31:01
routiniert und kriegst das irgendwie hin, ich find es aber
31:03
irgendwie noch mal gut, auch noch mal zu betonen, dass ne
31:07
Pipeline. Ne, die ja auch sehr, sehr
31:10
essentiell ist bei der ganzen Automatisierung von der
31:13
Bereitstellung von Software und dem zufolge auch von DEV ops,
31:17
dass eigentlich eine Pipeline da endet, wo die manuelle
31:20
Infrastruktur oder die Konfiguration der manuellen
31:23
Infrastruktur beginnt. Ne, weil egal wo du zum Beispiel
31:27
irgendwas manuell machst. Ne, du willst jetzt zum Beispiel
31:30
keine Ahnung, du willst willst irgendwie du willst irgendwie
31:32
Tests laufen lassen so und du musst da irgendwie manuell dich
31:35
durchklicken. Dann hast du ja im Endeffekt die
31:38
ganze Automatisierung, die du mit Def Ops erreichen willst,
31:41
stillgelegt. An der Stelle ne und damit endet
31:44
das Halt und alles was du sag ich jetzt mal manuell machen
31:48
musst, bricht ja im Endeffekt dann so n bisschen diesen diesen
31:53
Pipeline Gedanken von es wird Code wird eingecheckt sozusagen
31:57
bis hinzu Code wird deployed ne und klar wie gesagt wir hatten
32:01
ja auch über bei CD über Delivery und Deployment geredet,
32:05
da gibt es vielleicht. Unter Umständen die Möglichkeit,
32:09
dass man da einen kleinen manuellen Step machen muss, ne?
32:13
Der ja aber gewollt ist. Genau in dem Fall noch.
32:16
Aber ich finde das noch mal so, als als Gedankengang noch mal
32:20
wichtig zu sagen, Dev OPS ist ja steht ja für Automatisierung,
32:23
für Geschwindigkeit und wenn du anfängst, dann wieder irgendwas
32:27
manuell zu machen, dann funktioniert es halt nicht und
32:30
damit brichst du ja zum Beispiel auch deine ganze CICD Pipeline,
32:33
beispielsweise ne. Bis auf diesen einen.
32:35
Ja, das. Ist das ist ein mega guter
32:37
Punkt, das genauso zu betrachten, weil sobald ich
32:40
wirklich manuell was machen muss, habe ich halt meine
32:43
Automatisierung verloren. Also es ist ja logischerweise
32:47
ne, aber es ist wirklich wichtig, dass mal genauso
32:49
anzusprechen, wenn ich nicht sage Lauf los Pipeline so mach
32:56
das was ich was ich möchte und am Ende ist eine neue Version,
33:00
zum Beispiel die Ploid, sondern da irgendwelche Schritte
33:02
dazwischen sind. Dann bau ich mir
33:04
fehleranfälligkeiten rein und hole mir Probleme rein wie ey.
33:08
Aber vorhin hat das noch funktioniert.
33:10
Ja, was hast du denn vorhin gemacht?
33:12
Ja genau das gleiche Hallo, warum sollte ich was anderes
33:15
gemacht haben, weißt du und dann ah OK ich hab was anderes
33:18
gemacht und genau das verhinderst du damit, das muss
33:22
halt wirklich vollautomatisiert durchlaufen.
33:24
Und das finde ich wirklich eine coole Sache zu sagen okay,
33:26
sobald ich irgendwie manuell eingreifen muss, habe ich quasi
33:29
diesen Pipeline gedankenverloren.
33:31
Ja, also gerade auch das vielleicht noch mal so als
33:35
Beispiel auf den Punkt zu bringen.
33:36
Du hast vielleicht eine Pipeline, die funktioniert bis
33:38
bis auf Dev zum Beispiel oder Prot du willst aber zum Beispiel
33:41
noch vor Prot noch mal eine Dev Stage dazu bauen, das kannst du
33:44
vielleicht irgendwie manuell dir dann die Dev Stage aufbauen und
33:48
die Pipeline läuft dann auf einmal über die Dev stage, weil
33:50
du die mit einbindet. Ne, aber dieser manuelle Schritt
33:54
dann diese Stage also aufzubauen, dazwischen zu
33:57
schalten, das Haut dir ja im Endeffekt diesen diesen
34:01
Automatisierungsgedanken dann raus ne, also da da ist dann
34:04
sozusagen dieser Bruch drin, den du ja im Endeffekt über die
34:07
Infrastruktur as Code am Ende sozusagen dann gewährleistest.
34:12
Dadurch ne und ich find auch immer weil das ich was, wo man
34:17
ganz oft vielleicht irgendwie auch mal gerne mal hinkommt mit
34:20
dem Gedankengang ist und. Das funktioniert in dem und dem
34:23
Kontext nicht und ich finde immer, dass es trotzdem, egal in
34:27
welchem Moment es gut ist zu sagen, wie funktioniert es, was
34:31
ist mein Zielbild, mein wunschbild, wo möchte ich
34:34
eigentlich wirklich gerne hin und wie kann ich das erreichen,
34:38
weil oftmals kommt man dann, vielleicht kenn ich auch von
34:41
mir, dass man halt einfach sagt, so ja, aber das geht doch gar
34:43
nicht so OK, denken wir mal noch mal anders und sagen, OK, wie
34:47
können wir das denn erreichen? Ne, weil oftmals hat man dann
34:50
sowas wie. Ja, aber ich habe gar keinen,
34:53
weiß nicht AWS, Azure oder was auch immer, das darf ich gar
34:55
nicht nutzen. Okay gut heißt ja nicht, dass
34:59
es, dass es nicht geht. Wie geht es ja super.
35:06
Wichtiger Punkt jedes Projekt ist anders und du kommst
35:10
vielleicht aus anderen Branchen. Andere Technologie, dass du halt
35:15
nicht so diesen 0 815, aber nicht negativ gemeint, also
35:19
wirklich so diesen Standard. Pipeline weg gehen kannst, so
35:23
wie es quasi neben Lehrbuch steht.
35:25
Aber es ist auch irgendwo eine Mindset frage.
35:27
Def Ops ist eine Mindset Frage und das hast du gerade schon
35:30
wirklich schön gesagt, weil nur weil ich vielleicht nicht 100%
35:34
es gleich machen kann, heißt es nicht, dass ich nicht 90% davon
35:37
doch umsetzen könnte oder zumindestens mir eine kleine
35:41
Pipeline aufbauen kann und da hast du ja schon viel mehr
35:44
gewonnen als es gar nicht zu haben am Ende ja.
35:47
Bin ich auf jeden Fall ganz bei dir.
35:48
Also da muss man halt wirklich offen rangehen und vor allen
35:51
Dingen lösungsorientiert, das ist halt super.
35:53
Entscheidend dabei, aber dann lass uns doch, das ist n guter
35:57
Punkt mal so n bisschen über Best practices reden wie ich
36:00
denn dahin komme. Ja, also ich meine gut, wenn du
36:03
jetzt zum Beispiel sagst, wir, also wir haben ja ne
36:05
infrastructures Code ist Code, was hilft da auf jeden Fall zum
36:09
Beispiel schon mal Version control, zum Beispiel sowas wie
36:12
Git oder so einfach das ganze mit Versionieren.
36:15
Also du hast deine. Software Anwendung, die wird
36:17
Versioniert ist ja ne ganz klare Sache.
36:19
Genauso ist es dann halt auch ne klare Sache zu sagen, OK wir
36:23
versionieren halt eben auch unsere unsere Infrastruktur mit
36:25
ne. Und da kann man jetzt auch
36:30
sagen, wenn ich es versioniere und das Ganze wie Code betrachte
36:32
und so sollte ich es auch betrachten, gelten natürlich
36:35
auch Coding Guidelines, sag ich mal, aber nicht jetzt.
36:41
Im Prinzip wie formatiere ich meinen Code ja OKOK, aber es ist
36:44
ja wahrscheinlich ne andere Skriptsprache als vielleicht
36:47
deine eigentliche Programmiersprache des Projekts,
36:48
keine Frage, aber was ich damit meine ist behandel es wie Code
36:53
das heißt Don't repeat yourself ne mach nicht so n riesen Blog
36:57
als Skript wo alles irgendwie 534 1000 mal passiert sondern
37:02
mach es modular. Zum Beispiel hab ich denn Blöcke
37:05
da drin ja also so Abschnitte meiner Infrastruktur die ich
37:08
wieder verwenden kann für eine Stay also.
37:11
Ja, zum Beispiel. Und dass du halt einfach das
37:14
sauber hältst, verständlich hältst und auch wartbar und
37:18
skalierbar, also diese ganz normalen Ansätze, die ich bei
37:21
meinem Code auch haben. Möchte ja richtig don't you Pete
37:26
yourself. Gutes Stichwort haben wir auch
37:28
mal eine Folge drüber gemacht, genau das kann man hier auch
37:31
anwenden. Und ansonsten ne absolute Best
37:37
Practice und das haben wir leider auch schon anders erlebt,
37:39
oder? Das sind so typische Fails, die
37:42
einem begegnen, wo denn alle so die Hände über dem Kopf
37:45
zusammenschlagen. Wie kann er nur, wie kann sowas
37:48
nur passieren. Oh mein Gott, das ist ja so
37:49
peinlich, dass das passiert, Stichwort Secrets in der
37:54
Pipeline credentials was auch immer.
37:57
Dass die geleakt werden, dass die mit eingecheckt werden, dass
38:00
man auf einmal sieht, OK, der hat jetzt ein Secret mit
38:02
eingecheckt, sein Token, nur ist alles hin, Leute ernsthaft
38:08
achtet da drauf, es ist verdammt wichtig das nicht zu tun und es
38:11
kann passieren und da können auch Checks helfen, aber das ist
38:16
natürlich Best Practice, ganz klar diese Infrastruktur, den
38:19
Code von den Secrets zu trennen. Ja, was mir noch einfällt ist,
38:24
was zumindest auch meine Erfahrung widerspiegelt, dass.
38:28
Dass es gut ist, wenn du eine Anwendung, also eine Anwendung,
38:33
darf vom Code her niemals wissen.
38:36
Im besten Fall, welche Stage es gerade ist.
38:39
Also wenn du jetzt zum Beispiel als kleines Beispiel, wenn du
38:42
sagst, Du verwendest zum Beispiel für die Prot.
38:44
Stage, verwendest du zum Beispiel einen den Service XY
38:48
auch auf der Prot Stage so und aber du hast zum Beispiel noch
38:52
eine Dev Stage und dieser Service XY hat auch eine Dev
38:55
Stage, einfach nur um sozusagen die.
38:58
Eben halt den Traffic von bei irgendwelchen Tests und so von
39:01
der Prod. Stage auch fernzuhalten, so dass
39:04
du dann aber zum Beispiel nicht sagst in deiner Anwendung, dass
39:08
irgendwo in deiner Anwendung zum Beispiel, dass die URL von der
39:11
Prod Stage drin ist und die URL von der von der DEV Stage von
39:14
diesem x Service XY, sondern dass du das sozusagen auf der
39:19
Infrastruktur Ebene, also Infrastructure als Code Ebene
39:22
als Parameter reingibst, das heißt diese.
39:25
Du gibst dann im Endeffekt du hast nicht in deiner Software
39:30
hier URL oder Rest URL zum zur, zur pro Stage und zur Death
39:35
Stage ne, also du hast nicht 2 ur LS drin, sondern die
39:37
Anwendung weiß nur wenn ich starte dann bin ich auf
39:41
irgendeiner Stage und gegen irgendeine URL wenn ich diesen
39:44
Service anspreche und diese URL kriege ich von außen weil das
39:48
skaliert tausendmal besser also angenommen du willst eine neue
39:51
Stage hochfahren und sagst okay die Stage ist jetzt aber zum
39:54
Beispiel QA und. Und es gibt eine QR URL.
39:58
Dann ist es ja absolut wichtig, dann zu wissen, OK, wo gehe ich
40:02
dann hin, klar, aber du musst jetzt nicht deinen Code
40:04
anfassen, du musst nur von außen sagen, das ist eine neue Stage
40:08
und die geht zum Beispiel bei Service XY gegen diese URL und
40:12
das ist an der Stelle wichtig, weil du dann sozusagen nur deine
40:16
Infrastruktur anpassen musst, nicht aber deine Software.
40:20
Weil wenn ne, wenn du diese ur LS in deinem Code drin hättest,
40:22
müsstest du ja sozusagen noch diese neue ur l auch ebenso da
40:26
hinzufügen und ne neue Stage aufsetzen und das sind einfach
40:30
so n paar Sachen. Ne Stage sollte niemals selber
40:33
wissen im Vorfeld oder Informationen über verschiedene
40:37
Stages drin haben, das skaliert ja auch gar nicht.
40:39
Hast du 10 stages hast du auf einmal 10 URLS drin oder was?
40:41
Also ne. Ja, und da Stichwort
40:44
Skalierbarkeit ist da halt dann auch wirklich der entscheidende
40:47
Faktor. Am Ende.
40:48
Genau. Was haben wir denn noch so als
40:51
Best Practice? Natürlich testen oder
40:56
automatisierte Checks haben wir jetzt mehrfach gesagt, noch mal
40:59
angemerkt, weil es wirklich wichtig ist.
41:00
Du kannst halt auch Infrastructure ist Code abtesten
41:04
du kannst testen ob alles passt. Du kannst Checks in der Pipeline
41:08
laufen lassen und das sollte man auch tun, ist halt vielleicht
41:12
noch mal so ein Thema für sich, da würde ich jetzt gar nicht zu
41:14
tief darauf eingehen, weil das hat auch ein Riesenfeld, ist
41:16
also auch wieder hier und. Die Anmerkung, Falls Liebe
41:20
zuhören, Liebe zuhören das Thema Dich interessiert, lass es uns
41:22
wissen, machen wir gerne noch ne def Ops folge zu dem Thema, aber
41:26
würde ich jetzt hier erstmal nicht weiter vertiefen.
41:29
Richtig, aber, und da können wir noch mal von den Best practices,
41:33
ne, was soll man machen auch noch mal zu den Fallstricken
41:35
kommen und Herausforderungen, sowas gibt es ja auch immer,
41:37
kommt man ja nicht drum rum ne ist richtig.
41:42
Weil ich sag mal, infrastructures Code ist ja
41:44
jetzt auch nicht so rulesam all so nach dem Motto, sondern man
41:49
muss natürlich immer gucken, was man denn wo man sich gerade
41:53
bewegt. Als Beispiel, wenn du jetzt
41:55
wirklich sehr, sehr einfache Tasks hast, vielleicht mal kurz
41:58
was ausprobierst, dann musst du jetzt nicht das ganze
42:00
Infrastruktur Esco wie ich auch meinte, ne als wir damals das
42:05
die das angefangen haben zum Beispiel mit dem neuen Cloud
42:07
Service zu arbeiten. Ne, in meinem alten Job
42:10
sozusagen, wo ich mal gearbeitet hab.
42:13
Da probiert man sich erstmal aus erstmal so ne Art Proof of
42:16
Concept schaffen und dann kann man das ganze sozusagen
42:19
hinterher vielleicht noch mal infrastoctors Code gießen, aber
42:22
vielleicht ist der Task auch einfach nicht komplex genug in
42:26
Anführungsstrichen. Ne ja großer Punkt, weil es
42:34
einfach n riesen Overhead wär, muss man ganz klar so sagen,
42:37
denn einfach an der Stelle und. Was natürlich auch ein
42:40
Fallstrick sein kann, ist ein Mix aus Infrastructure is code.
42:46
Ja, also dass du quasi deine deine ganze Infrastruktur
42:50
kodiert, vorliegen hast und gleichzeitig eine Art Drift
42:53
stattfindet, weil vielleicht manuelle Änderungen noch gemacht
42:55
werden, falls das zulässig ist. Das kann passieren und du
42:59
einfach irgendwie in so einen undefinierten Zustand kommst.
43:04
Auch schon erlebt. Das ist ganz schwierig, das ist,
43:07
da muss man auch wirklich aufpassen.
43:09
Gerade also man kommt relativ schnell mal so in die Versuchung
43:13
zu sagen, ah, ich pass auf, ich mach, ich teste das mal kurz
43:16
manuell, ich mach ich, ich gieß das jetzt nicht in
43:18
infrastructures Code, sondern ich probier es einmal kurz aus,
43:21
dann wird das, dann macht man das und dann stellt man es aber
43:24
nicht zurück, weil man es halt, man ist abgelenkt und vergisst
43:29
es und dann ist auf einmal irgendwie und du denkst dir, so
43:30
was ist denn hier passiert, keiner weiß mehr was los ist.
43:33
Völlige Panik, das ist auf jeden Fall auch sehr wichtig.
43:38
Was ich auch schon mal hatte, da muss man auch ein bisschen
43:42
aufpassen manchmal, wenn du zum Beispiel.
43:44
Manchmal hat man Momente, wo du so gewisse Schritte brauchst,
43:49
dass du sagst, okay, du willst deine Infrastruktur aufbauen,
43:53
brauchst aber bestimmte Secrets zum Beispiel, und diese Secrets
43:57
müssen aber in einem Secret Manager in deiner Infrastruktur,
44:02
in einer Cloud Infrastruktur zum Beispiel liegen, so.
44:06
Und dann ist halt die Frage ja gut, aber dein Secret Manager
44:09
gehört ja eigentlich zu deiner Infrastruktur.
44:11
Also du kannst ja sozusagen den Infrastrukturen theoretisch
44:13
nicht aufbauen, bevor du nicht alle Secrets hast.
44:16
Und deine Infrastruktur wird nur aufgebaut, wenn also dein
44:19
Secrets Manager kommt nur mit der Infrastruktur.
44:21
So na das Henna iphone. Genau.
44:24
Also das sind manchmal auch so, ich sag mal vielleicht
44:26
Fallstricke, wo man sich immer noch mal n bisschen überlegen
44:28
muss. Kann es denn vielleicht sein,
44:30
dass du deine Infrastruktur in 2 Steps aufbauen musst, dass du
44:32
sagst, OK, erstmal step 1, du? Ne erstellst den Secrets
44:37
Manager, dann legst du deine Secrets an die du brauchst und
44:40
dann kannst du den Rest sozusagen machen.
44:43
Also sowas hatte ich auch schon ne.
44:45
Ja, also man muss ganz klar sagen, so ne Pipeline oder so ne
44:51
ganze Infrastruktur kann halt unglaublich komplex werden und
44:55
diese dieser hohe Grad an Komplexität.
44:58
Sorgt meistens für viele Abhängigkeiten.
45:00
Versteckte Abhängigkeiten, die auf den ersten Blick dann gar
45:03
nicht mehr so ersichtlich sind, obwohl es da natürlich hilft,
45:05
wieder sauberen Code zu haben, der quasi transparent ist.
45:10
Aber das bringt natürlich einfach Probleme mit sich.
45:13
Und jetzt wo du es angesprochen hast, so diese 2 Steps, aha, das
45:16
muss ich machen. Nee, ich muss erst das machen,
45:18
das zeigt ja auch, dass man ne gewisse Lernkurve benötigt.
45:24
Ja, also. Es kommt in dem Moment, wenn ich
45:27
sage, ich möchte mich mit Death Ops beschäftigen, kommt ne
45:29
riesen Tool Landschaft auf einen zu, ne was alles möglich ist.
45:33
Es gibt 1000 verschiedene Möglichkeiten sowas umzusetzen.
45:37
Das heißt du hast halt so n so n Tooling Overhead der erstmal
45:41
bewältigt werden muss und die Lernkurve halt auch gemeistert
45:44
werden muss. Das muss man ja auch fairerweise
45:46
sagen, es ist ja nicht so. Infrastructure is Code, habe ich
45:49
jetzt gehört. Die Folge vielen Dank ihr
45:52
beiden, ich leg jetzt los und ich mach das heute Abend ist
45:55
fertig, also wenn dann Chapeau wenn man sich vorher nie damit
45:58
beschäftigt hat. Also man muss halt schon
46:00
wirklich bisschen Zeit und Hirnschmalz da reinstecken, aber
46:06
wie gesagt es lohnt sich am Ende sehr sehr.
46:08
Dolle, selbst wenn du von einem Cloud Service zum Beispiel auf
46:10
den anderen Umsteigst ne wie gesagt das ist das was mir halt
46:13
in der Vergangenheit passiert ist.
46:15
Und das hat dann ja wirklich für alle gegolten.
46:17
Und dann hattest du auf einmal wirklich, wir wussten OK, in x
46:23
Monaten in so einem halben Jahr oder so müssen wir wirklich
46:26
komplett alles, alle Anwendungen, die wir in unserer
46:29
Abteilung quasi entwickeln, die mussten umgestellt werden und
46:33
dann denkst du dir so, OK, das wird richtig krass, weil gefühlt
46:36
keiner hier oder die wenigsten haben irgendwie ne Erfahrung mit
46:40
dem neuen Cloud Dienst und dann denkst du dir so OK dann.
46:43
Da musst du jetzt aber wirklich erstmal einen Gewissen, sagen
46:47
wir mal, eine gewisse Lernkurve an den Start bringen, damit du
46:50
es im Endeffekt hinterher händeln kannst.
46:52
Und dass es auch wirklich funktioniert.
46:55
Also es war auf jeden Fall keine einfache Aufgabe, weil man
46:58
wirklich es ist komplex wie du meintest.
47:01
Ja, kommt natürlich auf den Cloud Service drauf an.
47:05
Ja, aber wenn wir jetzt zum Beispiel Edger oder Abs nehmen,
47:09
das ist das ist, das ist gigantisch.
47:12
Sich damit auseinanderzusetzen, richtig, ist einfach auch so,
47:16
ja. Hast du noch was?
47:20
Nee, magst du noch n Fazit ziehen zur Folge?
47:23
Ja, also cool Infrastructure is code ist ne coole Sache, coole
47:29
Sache, Daumen hoch ja nee also. Ich würde mal sagen, wenn man
47:33
wirklich sagt, OK, ich mein es ernst mit def Ops und möchte in
47:37
diesem Bereich eintauchen und da mitarbeiten, dann führt halt an
47:39
infrastructures Code kein Weg vorbei.
47:42
Ich würde sogar sagen generell eigentlich nicht mehr, also wenn
47:46
man jetzt sag ich jetzt mal in diesem dabei ist
47:49
Softwareentwicklung zu lernen, wenn man da gerade eintaucht
47:53
oder vielleicht früher also ne in in einem frühen Stadium dabei
47:56
ist, dann kann man jetzt auf jeden Fall schon wissen das
47:59
kommt auf einen zu ne. Vielleicht noch nicht direkt,
48:02
aber es wird auf jeden Fall kommen und das ist eigentlich
48:06
relativ fix, dass man sich irgendwann damit beschäftigt und
48:10
es geht jetzt auch nicht genau um die einzelnen Tools, also ist
48:13
es jetzt diese Cloud oder der Cloud Service oder frag mich
48:17
nicht mehr, also diese darum geht es nicht, sondern es geht
48:20
wirklich darum auch die Prinzipien dann zu
48:22
verinnerlichen, also die Automatisierung, dass man damit
48:25
super automatisieren kann, dass man damit eine super gute.
48:29
Transparenz schaffen kann über seine Infrastruktur, die man
48:32
aufbaut, und dass es natürlich unglaublich effizient ist.
48:36
Und was natürlich immer wichtig ist, nicht gleich
48:40
mammutprojekte. Nehmen, klein anfangen, aber
48:42
wichtig ist irgendwann einfach wirklich mal anzufangen, damit,
48:45
sich irgendwann damit zu beschäftigen.
48:48
Genau, ja, schön zusammengefasst habe ich eigentlich auch gar
48:54
nichts mehr hinzuzufügen. Wie gesagt, der letzte Punkt ist
48:56
wichtig, auch wenn die. Eine steile also, auch wenn
49:01
einem quasi dieser Overhead erstmal gegenüber steht zu
49:04
sagen, wo fange ich jetzt an, ich muss jetzt irgendwie mich
49:06
für Tools entscheiden. Es gibt natürlich auch, das ist
49:09
ja nichts. Neues in der
49:10
Softwareentwicklung. Richtig, das ist ja nichts
49:12
Neues, das kennt ihr doch alle. Aber es gibt halt auch zig
49:15
Tutorials, es gibt bekannte Anbieter, wo man das, also wo
49:19
man wirklich ein bisschen an die Hand genommen wird, ansonsten
49:22
kommt gerne in unseren Discord vorbei.
49:25
Liebe zuhören, liebe Zuhörer, falls du das noch nicht bist,
49:27
also noch nicht Teil unserer Discord Community bist, da gibt
49:30
es auch Leute, die sich da sehr gut mit auskennen und helfen
49:33
können. Und wie gesagt, der erste
49:35
Schritt ist der schwerste, aber danach macht es auch wirklich
49:38
Spaß. Ist ein cooles Thema, womit man
49:40
sich auf jeden Fall heutzutage auseinandersetzen sollte,
49:43
absolut Jo fabi würde ich sagen, haben wir das Thema doch wieder
49:48
ausführlich besprochen. Blick auf die Uhr.
49:51
Wir sind auch schon wieder fortgeschritten in der Zeit,
49:53
aber es ist immer noch im Rahmen.
49:54
Also alles gut, ja, da bleibt mir doch eigentlich nichts mehr
49:59
zu sagen, außer wenn Dir die Folge und der Podcast gefällt,
50:02
dann lass auf jeden Fall eine Bewertung da, das würde uns mega
50:06
freuen und auch mega helfen und schreib uns auf jeden Fall auf
50:10
der Podcast Mail oder im Discord über deine Erfahrung mit
50:13
infrastructures Code auch bei Fragen Haus in Discord rein.
50:17
Wie Tino meinte, Da sind Leute, die gerne helfen und ich würde
50:22
sagen, wir hören uns in der nächsten Folge wieder und zwar
50:24
nächsten Donnerstag. Macht es gut, deine Coaling
50:27
Buddies. Gemeinsam besser.