Moin Burkhardt, wie geht's? Moin Gerrit, gut wie immer. Was dich dann heute Gerrit? Super, das freut mich. Genau, ich dachte wir sprechen heute mal über Microservices oder Microservice Architekturen. weil ich höre immer wieder davon, ich höre auch ganz viel von irgendwelchen Technologien in dem ganzen Umfeld, sowas wie Docker, Kubernetes und ich muss ganz ehrlich sagen, Mir fehlt da der Zusammenhang oder beziehungsweise ist mir nicht ganz klar, wer da was tut. Warum überhaupt Microservice?
und was vielleicht auch Alternativen sind. Von daher würde ich mal einfach rein starten und vielleicht kannst du uns einen kleinen Überblick verschaffen, was ist ein Microservice und was ist so toll daran. Ja, alles klar, Gehren.
Also ich muss mich erst mal sortieren, du hast irgendwie Microservice gesagt und du hast auch Kubernetes gesagt. Ich schließe gleich mal Kubernetes aus für diese Serie heute, weil Microservices selber schon ein richtiges Thema sind und Kubernetes das nächste Kapitel im Buch auflegt. Also Microservice, ja, ich würde sagen, war die im Prinzip eigentlich die größte Revolution seit langem in der Software überhaupt und hat eigentlich dazu geführt, dass...
Ja, das, was wir heute so sehen, diese ganzen Web-Anwendungen, total tolle Tools, die alles Mögliche machen. Im Prinzip gründet das alles auf der Microservice-Architektur. Was heißt das und was ist das? Also, da muss man vielleicht ein bisschen zurückgehen. Als ich mein erstes Projekt so gemacht habe, da gab es noch keine Microservices. Was ist ein Microservice? Im Prinzip ist ein Microservice Ja, ein abgeschlossener Raum, in dem Software funktionieren kann.
Man schreibt ja Software in irgendeiner Programmiersprache, davon gibt es ja ganz schön viele, C++, Node.js und so weiter. Sprechen wir vielleicht mal anders auch nochmal genauer drüber. Sprechen wir auch nochmal genauer drüber, genau, aber wenn wir jetzt von Microservices sprechen, dann gehe ich mal davon aus, dass wir irgendwas programmieren wollen. Genau, und jetzt alleine so eine Programmiersprache da zu haben, damit anzufangen, das braucht halt auch gewisse...
Einstellungen, Settings auf deinem Rechner. Also du kannst jetzt nicht einfach so mit C++ anfangen, wenn du Windows 11 aufmachst, da ist nichts vorbereitet für C++. Also musst du dir Sachen installieren, Abhängigkeiten, den Compiler und den ganzen Kram. Ja, und typischerweise hat man das früher tatsächlich alles auf seinem System installiert, um dann da Code zu entwickeln. Auf seinem System meinst du mein lokaler Computer? Ja, genau.
So, und dann hast du da Code entwickelt, sagen wir mal C++ geschrieben, mit den Abhängigkeiten, die so um dich rum sind. Man kann vielleicht vereinfacht so sagen, wenn du zum Beispiel einen Programmcode schreibst, dann ist der grundsätzlich erstmal nicht so ganz allein funktional. Der hat irgendwie immer wie so ein... wie so ein Spinnennetz, was so in die Ecken und Enden deines eigenen Rechners geht, werden da irgendwelche Libraries und so weiter noch angerufen, damit das überhaupt funktioniert.
Und wenn du dann den Code nimmst und hast keine Microservices und versuchst den auf dem nächsten Rechner, der nicht deiner ist mit dem Porsche, irgendwie loslaufen zu lassen. funktioniert das erstmal nicht. Zu 99% funktioniert das erstmal nicht. Vor allen Dingen nicht, wenn man jetzt noch so einer Low-Level-Technologie wie C++ unterwegs ist.
Weil nämlich der andere Rechner dann wieder eine andere Version von den und den hat und wieder andere Abhängigkeiten oder da fehlt was und so weiter. Wir wissen ja alles, es geht ja immer schnell voran mit diesen ganzen Abhängigkeiten und Versionen. Und das ist eigentlich eine Katastrophe gewesen, schon immer. Weil das Deployen, das Ausliefern von Software...
total davon abhängig war, wie das Ziel des Themen, auf dem ich ausliefere, aussieht und war das dafür vorbereitet. Und alles, was ich jetzt gesagt habe, ist auch nur die Spitze vom Eisberg.
Oft ist es ja so, wenn du eine komplexe Anwendung hast, dann willst du vielleicht gar nicht nur in einer Programmiersprache ein politisches Programm machen, sondern du brauchst irgendwie eine Datenbank, dann brauchst du irgendwie ein User-Interface, brauchst irgendwie sowas wie ein Backend und so weiter. Und da eignen sich ja nicht...
Es gibt im Prinzip keine Technologie, die dafür alles gut ist. Dann hast du halt die präferierten Programmiersprache- und Softwaretechnologien für die jeweiligen Aufgaben. Und wenn du dann jetzt auch noch anfängst zu mischen...
und überlegst dir dann, was du für ein Chaos auf dem System hast und für Abhängigkeiten, die dann sich vielleicht auch noch gegenseitig ausschließen, weil irgendwie eine C++-Bibliothek mit der Node.js-Bibliothek nicht klarkommt, willst du aber beides benutzen, ja, dann kriegst du endgültig Kopfschmerzen.
So, und jetzt kommen die Microservices und sagen, es ist Schluss damit. Wir kapseln quasi den Raum ab, in dem eine Technologie, eine Programmiersprache, ein kleines Programm leben kann. Und alles dann, was du installieren musst, quasi wie so ein Mini-Betriebssystem. So ist es tatsächlich auch. Es ist nicht ganz so krass wie eine virtuelle Maschine. Das kennt man manchmal. Ich weiß nicht, ob das Leute kennen.
Manchmal kann man ja zum Beispiel im Linux ein Windows hochfahren und so weiter. Da wird quasi komplett der ganze Rechner ritualisiert. Das ist aber... heftig, weil das braucht ewig zu konfigurieren und das Startup-Time ist auch riesengroß. Aber wir sind irgendwo dazwischen bei so einem Microservice, das heißt wir Leben schon in dem Betriebssystem, also sag ich mal, du hast einen Linux und hast einen Microservice, dann lebt der irgendwie mit dem Linux, aber...
Ja, der bringt dir so einen abgeschlossenen Raum, in dem du alles installieren kannst, ohne dass das deinem System gehört. Und jetzt wichtiger ist, und du kannst das, was du da hast, ausprobieren. Und es funktioniert im Container, kannst du es angucken. Und wenn es funktioniert, kannst du den Container
versiegeln, als Image festhalten. Und wenn du das jetzt, dieses Ding auf ein anderes System setzt, dann bist du hundertprozentig sicher, dass es da genauso funktioniert, egal wie der andere Computer ausgestattet ist. weil es aus dieser versiegelte Entität, dieser Service, dieser Microservice,
Der ist garantiert immer gleich funktional, egal wo du das hinpackst. Okay. Vielleicht ganz kurz mal für mich. Ich habe jetzt entstanden, so ein Microservice hat den Vorteil, dass er eigentlich überall läuft. Das ist auch nur, weil er keine oder... Wenig, wahrscheinlich gar keine Abhängigkeit nach außen hat. Ja, er braucht halt die, also wenn man jetzt von Docker, es gibt bestimmt auch andere Microservices, aber mit Abstand, ich würde sagen 99%, keine Ahnung, sage ich jetzt so heraus.
Die Technologie, die man einsetzt, ist halt Docker. Und dann brauchst du halt den Docker-Demon, den Docker-Service. Vielleicht erkennen wir kurz irgendwie Docker, was das ist. Ich habe mir das natürlich auch schon das eine oder andere mal erklären lassen und wenn ich dann vor Kunden sitze und Docker erwähne und das hier und da dann doch mal wieder erklären muss oder vielleicht gar nicht muss, aber einfach mache, um so ein paar Voraussetzungen zu schaffen.
Oder wenn ich es zu Hause erkläre meiner Mutter, dann rede ich dann immer von Schiffscontainern. Und im kleinen Docker-Logo sind auch so Schiffscontainer drin, die irgendwie irgendwas drin haben. Wir wissen gar nicht, was da transportiert wird von Shanghai nach Rotterdam oder umgekehrt. Spielzeug oder Baumaterialien, was auch immer. Aber der Container sieht von außen immer irgendwie gleich aus. Der sieht immer genau gleich rechteckig aus, hat die genormten Maße.
Und ein Container passt an den anderen. Und so stelle ich mir irgendwie Docker im Bereich Software vor. Also ein außen genormtes, standardisiertes Stück, was mit den anderen zusammengesteckt werden kann und einfach überall hingesetzt werden kann. Ja, das stimmt schon so, genau. Es ist nämlich völlig egal, was ich reinstecke. Es kann zum Beispiel in einem Docker-Container nur zum Beispiel eine Datenbank laufen und in einem anderen Docker-Container läuft ein Web-Server.
Nach außen hin lassen sie sich aber alle gleich bedienen, genau. Und da gibt es gar nicht so viel. Also im Prinzip baut man seine, das ist vielleicht die größte Kunst, man baut halt seine gesamte Anwendung. aus mehreren Microservices. Und da muss man dann gucken, dass man das gut aufteilt.
logisch zusammenhängende Sachen in einem Container packt. Das ist aber auch die Kunst wie immer in der Software. Man sollte es halt wieder zu klein machen, was der Container ausführt. Also den Inhalt, dann habe ich quasi einen riesen Container mit nichts drin. Das ist genauso. Es wäre auch ineffizient, wenn man das in der normalen Wirtschaft anguckt, also ein Riesenschiff losfährst und du hast quasi ganz viele Container, aber die transportieren fast nichts.
Dann hast du Overhead, das hast du bei der Software dann auch. Also wenn du nichts reinpackst, du musst aber, was weiß ich, 50 Container starten, damit deine Anwendung läuft. Dann hast du relativ viel Overhead, das braucht viel Speicher.
und verbraucht viel Ressourcen während der Laufzeit. Also die Kunst ist genau das reinzupacken, was zusammengehört, nicht zu viel und nicht zu wenig. Das ist aber auch nochmal ein anderes Thema, wenn man das schafft. Und dann, ja, hast du recht, nach außen ist es im Prinzip immer gleich und du kannst halt diese Container... Du kannst den Inhalt quasi verändern und es neu versiegeln. Dieses Versiegeln ist quasi, ich finde das Bild schön, mit den Containern, das ist dann so eine Art...
Ja, wenn ich meine Software weiterentwickele, dann habe ich ein sogenanntes Image, so heißt es bei Docker. Und dieses Image kann es quasi abschließen. Da kommt eine Plombe drauf, quasi eine Version, ein Tag. Und dann typischerweise kann man auch diesen Container auf so einen Hub, also auf eine Deponie quasi in der Cloud.
dann brauche ich nicht viel mehr als die Docker-Umgebung, um das irgendwo anders zu starten. So funktioniert das zum Beispiel bei uns. Wir bauen halt quasi diese Images, die Container fertig, die können wir auch lokal ausprobieren, dass alles schön läuft. Und wenn wir dann zufrieden sind, kommt Diplom mit drauf. Dann kommt das auf so einen Docker Hub.
Und dann auf irgendeinem Server, das kann ein On-Premise sein oder auf unserer Cloud, sagen wir, hol mal runter die ganzen Container von der Stelle und starte die mal alle. Und dann funktioniert schon die Anwendung. Okay, also für beliebige... Software, die ich so in einzelne Container oder in einzelne Microservices aufgeteilt habe, in sinnvoll große und funktionale Einheiten, kann ich dann quasi überlaufen lassen, wenn vorausgesetzt ist das Docker.
allgemein an der Stelle. Dein Betriebssystem, also dein Rechner, der da gerade läuft, muss halt irgendwie Docker auswählen können. Aber das ist halt, weil deswegen Revolution in der Software, das ist halt überall angekommen und deswegen gibt es halt Docker-Support.
Überall, also ob das ein Windows-Rechner ist, Mac OS oder Linux sowieso, bei den großen geht es, aber selbst fangen jetzt viele Firmen an, Firmen an, die sogar so kleine Industrie-PCs machen oder sogar clevere Klemmen, sag ich mal, wo früher eigentlich nur...
Ja, so Embedded C++ Code, die fangen jetzt alle an, so einen minimalen Docker-Support zu machen. Warum? Ja, weil dann kann ich sogar zu sehr spezialisierter Hardware, irgendwie ein ganz anderer Prozessortyp und so weiter, kann ich trotzdem sehr generell geschriebene Software. Wie installieren, deployen, sagt man. Jetzt, wo du sagst, es gab einen großen Wandel sozusagen in der Software, was man immer wieder hört, wie es vorher war, das war ja monolithische Software. Ja, das ist richtig.
Viele Leute haben natürlich, wenn sie große Software gemacht haben, versucht sowas in der Art selber zu entwickeln und dass sie es wussten, man hat quasi schon versucht, Software aufzuteilen mit Microservices, aber typischerweise hatte man große monolithische Blöcke. Man muss auch sagen, das heißt ja erstmal nicht, dass die Anwendung schlecht ist. Das heißt nur, dass man...
Ja, man hat typischerweise, als ich am Anfang gesagt hatte, relativ hohen Aufwand, das zu pflegen und vor allen Dingen gut zu testen auf den verschiedenen Systemen. Man hat mehr Sicherheit mit den Containern. ob das jetzt besser ist. Das muss man vielleicht mal sagen, das ist vielleicht auch nicht jedem klar. Habe ich eine monolithische Anwendung?
habe ich natürlich ein einfaches Spiel, weil ich, jetzt ist ja so eine Software, kann man sich vielleicht vorstellen, Naja, da habe ich halt viele Funktionen drin und ich habe wie so eine Bibliothek und ich habe meine Schränke und ich kann halt direkt, wenn ich in einem Monolithen bin, an jeden Schrank gehen und mir das Buch rausnehmen, was ich brauche. So, habe ich aber einen Microservice, dann ist das quasi eine abgeschlossene Anwendung.
Alles, was nicht in meinem Microservice ist, ist auch nicht ein Regal, das neben mir steht, sondern das Buch muss ich mir dann erst bei Amazon bestellen quasi. Also das heißt, ich muss tatsächlich, selbst wenn die Docker-Container auf dem gleichen Computer liegen,
Das muss man so tun, als wäre ein normales Netzwerk, als wäre quasi das Internet dazwischen. Ich muss halt quasi alle Daten, alle Bücher, die ich dann haben will, muss ich teuer bestellen. Also ich muss quasi eine Serialisierung machen, ich brauche irgendwie eine Netzwerkschnittstelle. um von A nach B zu sprechen. Das ist eine Würde, die man halt hat.
Die führt natürlich dazu, dass ich mir auch Gedanken machen muss, wie ich das sauber abtrenne. Das gehört dann wieder zu der Encapsulation, dass der Service auch nur das macht, was er soll. Dann muss ich typischerweise eine API, wie man so sagt. Oft wird das über Rest-APIs gemacht. dass ich die Funktionalität dieses Containers sauber von meinem Container ansprechen kann.
Aber alles das ist halt mehr Aufwand im Vergleich zu so einem analytischen System. Okay. Das heißt, nochmal für mich, so ein Microservice oder für die Hörer natürlich. Microservice kann beliebige Funktionen erfüllen, auch mehrere unter Umständen, kann beliebige Programmiersprache geschrieben sein. Es lassen sich dann auch verschiedene Programmiersprachen kombinieren. Eins mit der Programmiersprache, weil die jeweils verschiedene Vorteile mit sich bringen.
Und Nachteile für Anwendungsfälle. Ich brauche eine Art Schnittstelle zwischen den Microservices, damit die in der Lage sind, dazu... zu kommunizieren und eine typische Schnittstelle an der Stelle oder eine API, wenn man in der Software sagen würde, wäre zum Beispiel REST. Oder auch gerne, je nachdem, wenn die Kommunikation sehr auch sehr stark eventgetrieben ist oder sowas gibt es halt auch die sogenannten rpc systeme also remote procedure call
Da wird ganz oft GRPC, das ist so das Gängigste, was glaube ich im Moment für Microsoft, das war von Google erfunden. Ja, aber das ist jetzt eine Alternative, um kommunizieren zu lassen. Genau, aber alle diese... diese APIs müssen halt ermöglichen, quasi über das Netzwerk zu kommunizieren. Das tut man entweder eigentlich heute über REST oder...
oder GARFQL oder GRPC, das sind die großen, das wird aber nochmal Thema vielleicht in einer anderen Serie. Auf jeden Fall, wir haben noch jede Menge Zeit und Folgen. Vielleicht noch ein Thema, du hattest gerade gesagt, es kann halt auch Nachteile haben, das ist das Beispiel mit dem Buch oder vielleicht die Information oder die Funktion, die dann eben nicht gerade zur Verfügung ist, den visionierten Microservice erwähnt.
was bei einer monolithischen Software, die von Anfang an so geplant war, dass sie all jene Use Cases erfüllt, dann doch vorhanden ist. Das wäre dann zum Beispiel so ein Nachteil. Dann gibt es dann noch Anwendungsfälle, wo ich sage,
Da sollte man eigentlich lieber komplett auf die Microservices verzichten und gleich monolithisch daran gehen. Es ist natürlich auch so, warum gibt es das und warum wird das so gerne eingesetzt? Man muss ja auch mal gucken, die Hardware entwickelt sich natürlich immer. stark weiter. Also während man jetzt vor 20 Jahren
wie noch, ich weiß nicht, riesige Festplatten hatten, die dann irgendwie 200 Megabyte konnten oder so. Ich weiß es nicht genau. Es ist ja heute alles, also es ist ja alles schnell und einfach und viel. Wir haben viel Arbeitsspeicher, wir haben viel Festplatte und so weiter. Insofern frisst das kein Boot auf einer normalen Desktop-Anwendung, auf dem Server, ist das überhaupt kein Problem, der Overhead, der durch die Containerisierung entsteht.
Wenn ich jetzt natürlich denke an so kleine Embedded Devices, so Microchips, da läuft ja auch Software drauf. Auch manchmal sogar ganz schön komplex, je nachdem was die so steuern. Oder auch auf dem Raspi und so weiter. Da fängt das schon an, wo man anfangen muss zu überlegen, wie geht das so einfach von den Ressourcen her? Weil schon jeder Container hat einen kleinen Overhead. Das muss ich schon das Gewicht, um das Bild nochmal aufzunehmen von dem.
Von dem Schiff, also das Gewicht des Stahlcontainers drumherum, das muss ich schon auch noch schleppen. Und wenn ich einen Tanker habe, im Internet einen Server, einen riesen Tanker, dann ist es auch egal, dann kann ich auch ein paar Container tragen. Aber ich sag mal, wenn ich jetzt hier auf dem Microsoft bin, dass es irgendwie so ein kleines Segelbötchen ist, ja, wenn ich dann irgendwie fünf Container drauf stelle, dann kannst du es gerade noch so und beim sechsten geht es halt unter.
Das ist vielleicht ein ganz schönes Bild. Plus, dass es natürlich auch etwas langsamer wird, weil diese Kommunikation, diese Schnittstelle, da ist der Reibungseffekt. Also da will ich vielleicht... Da will ich dann vielleicht nicht in so einer Microservice-Architektur machen, ein kleines monolithisches System. Ach, weil genau das ist halt die Kunst, wo man genau gucken muss.
wann entscheide ich, dass ich überhaupt eine Containerisierung benutze und wenn ich es dann tue, wie schneide ich es so zusammen, dass ich auch nicht zu viele Container habe und nicht zu wenig. Das ist noch sinnvoll. Können wir vielleicht noch so ein kleines Idealbild aufzeichnen, gerade im Bereich IoT, über den wir hier meistens sprechen oder meistens sprechen wollen?
wie dort eine Microservice-Architektur aussehen würde, also insbesondere wenn ich halt irgendwie... physische Assets, also Dinge habe, die ich in irgendeiner Form vielleicht auslese, vielleicht auch steuere aus der Cloud oder von irgendwo anders. Sehr gute Frage. Wie könnte das aussehen? Ja, da gibt es so einen ganz klassischen Anwendungsfall eigentlich. Das kann man nicht sofort beantworten.
Naja, in so einem klassischen IoT, da habe ich halt quasi die physikalischen Endgeräte. Irgendeine Maschine, so zum Beispiel eine Drehmaschine oder eine CNC-Maschine oder irgendwas. Und die selber, da gibt es jetzt noch keine Containerisierung. Die haben halt ihre Firmenbild, ihren Kram da drauf. Und das ist typischerweise, das ist dann irgendeine Serveranwendung, zum Beispiel UPCR-Server oder Siemens-Server. Also irgendwas, wo ich eine Netzwerkschnittstelle habe.
So und jetzt gibt es aber das Problem, dass diese Geräte stehen ja meistens, die sind ja nicht direkt mit dem Internet verbunden. Schon gar nicht in Deutschland, vielleicht in Amerika fängt es schon an mit sowas, aber die deutschen Mittelständler sind da schon unzurecht vorsichtig und die Geräte sind halt quasi, also diese physikalischen Dinge sind quasi in einem lokalen Netz.
Zwar netzwerkmäßig verbunden, aber dann hat sie nicht direkt einen Internet-Access. So, und jetzt gibt es diesen Fall für die Raspis. Da sind die, das ist mal so schnell und dirty, quick and dirty Solution. Oder halt Industrie-PCs, wenn man ein bisschen mehr Geld in die Hand nimmt. Da kann man sich vorstellen, kommen die ganzen Kabel rein, von diesen ganzen Maschinen, die ich so habe. Netzwerkkabel oder per WLAN, ist ja auch egal.
Und da muss jetzt eine Anwendung laufen, die quasi diese ganzen... Protokolle, also Siemens, OPC UA und so weiter, die ganze Maschinensteuerung versteht und aufnehmen kann und dann gebündelt in die Cloud weiterschickt. Man nennt das auch Gateway Devices, weil es so eine Art Brücke schlägt zwischen dem privaten Netz und dem bösen Internet. Und jetzt haben wir da wieder ganz viele Hersteller.
Ich will gar nicht meinen Namen nennen, wir wollen hier keine Werbung machen, aber es gibt im Markt zig Hersteller von Industrie-PCs, die wieder verschiedene Betriebssysteme, Chipsetzer und so weiter. Und als Softwarehersteller, so wie wir einer sind, wollen wir quasi ja eigentlich nur einmal so eine Software schreiben, die das auslesen kann. Das ist ja wieder eine Software, die die ganze Maschinen versteht, das einsammelt und zur Cloud weiterschickt. Eine sogenannte Edge Connection.
Und wenn man den jetzt in den Container reinpackt, da brauche ich auch sogar nur einen. Das ist total einfach. Ich habe einen Container. alles und schick das an die Cloud. Das ist deine Aufgabe. Sammeln ein, sprich mit den Maschinen und schick es an die Cloud. Also jetzt ganz noch das Beispiel, der möchte zum Beispiel einen Fehlercode aus einer SPS, Speicherprogrammierer über Steuerung, auslesen, die in so einer Drehmaschine hängt. Ja, die steht...
Kein Mensch weiß, worum es steht, aber die senden so einen Fehlercode und das wird jetzt eingelesen von diesem Gateway bzw. der kleinen Software darauf und dann ist es erstmal darauf. Genau, klassischer Fall. Die Funktionalität, die ich da brauche zu diesem Auslesen, die stecke ich dann quasi in den Container.
Und die ganzen Hersteller von diesen Industrie-PCs, bei denen ist diese Revolution dieser Microsoft auch schon längst angekommen. Denn was die alles mindestens anbieten, ist, dass da irgendwie Docker läuft. So, da habe ich jetzt so einen Container, dann kann ich quasi meinen Container da auf beliebige... Hardware quasi setzen in irgendeinem Hersteller, weil die alle mindestens Docker können.
Der fährt dann diesen Container hoch und dann funktioniert das halt einfach. Ich muss nicht drüber nachdenken, was jetzt... Und da ist die Verbindung nach außen schon mit drin, sozusagen. Die Verbindung, das hat man reinprogrammiert. Genau, man kann sich so vorstellen, man macht irgendwie... abgeschlossenes ist, dann muss es ja trotzdem kommunizieren können. Einmal miteinander und einmal auch mit außen. Man kann sich so vorstellen, ich kann schon Kabel anbocken von außen.
Und ich kann sehr genau festlegen, das ist auch Sicherheitsvorteil, was uns diese Container anbringt, ich kann sehr genau festlegen, auf welchen Ports... Also wie quasi so ein lokaler Windows Defender oder so eine Firewall ist da quasi mit eingebaut, was da genau auf welchen Port raus und rein gehen kann, netzwerktechnisch, genau. Und dann, dass die... Da ist der Vorteil, dann kann ich quasi die Ports zu den Maschinen aufmachen, die richtigen und nur die.
Und dann mache ich einen Port auf, der dann quasi mit dem Internet telefoniert. Und auch genau den kann ich beobachten und absichern und da freut sich halt auch. freuen sich die Herren von der IT-Abteilung, weil die nämlich dann nicht irgendwie was, irgendeine Software haben, die irgendwie ein schwarzes Gewebe ist so und wer weiß nicht so. Man kann halt auch genau drauf gucken, was ist da offen, was fließt da durch von außen, weil es halt standardisiert ist.
Die Leitungen quasi, die aus dem Container rausgehen. Mir gibt es auch schon wieder tausend Tools drumherum. die das machen. Am Ende ist ein Microservice. Vielleicht kommt das nochmal auf die Architektur, die wir da aufmachen. Jetzt sind wir ja noch immer auf dem Gateway, wo sozusagen der erste oder die ersten Microservices ausgeführt werden. Genau. Und dann geht es weiter.
Und dann geht es weiter. Und dann werden die Daten diesmal quasi nicht... innerhalb eines lokalen Systems überspielt, sondern geht tatsächlich von einmal weit über das Internet. zu einem Server zum Beispiel, der in der Cloud liegt. Was heißt in Cloud? Na ja, Cloud ist eigentlich nur das Internet. Also ein Server, der quasi eine Domain hat, die ich von außen erreiche.
Also jemanden, den ich quasi anrufen könnte. So, da wird eine Verbindung aufgebaut und das ist aber in diesem Server gerade wieder ein Container, der das entgegennimmt. Und dann passiert natürlich noch mehr Logik normalerweise, denn ich versuche... Ich versuche schon die sehr aufwendigen Sachen so ein bisschen von der Edge wegzukriegen.
Obwohl es da auch eine Gegenbewegung gibt, natürlich, wenn ich so viel, wie ich machen kann auf der Edge, um den Datenstrom zu reduzieren, das mache ich natürlich. Das kostet mich ja quasi Energie, Zeit, Netzwerk, Auslastung und so weiter. Das heißt, ich versuche, die Daten schon zu reduzieren auf der Kante.
Aber diese ganze Weiterverarbeitung, die jetzt nicht unbedingt auf der Edge passieren muss, mache ich natürlich in der Cloud. Und kann ich vielleicht auch nur, weil ich dann erst Sinn reinbringe in die Daten, weil ich ganz viele von diesen Edge-Connectoren zusammenbringe, an der zentralen Stelle. Genau, und so eine große Anwendung. Ich glaube, unsere hat 15, 16 Container oder so was.
Ich kann ja sowas, ich kann ja mal ein paar, damit man auch eine Idee hat, was da so passiert. Vielleicht gibt es super Beispiele sozusagen, was die alle jeweils einzeln machen. Ja, genau. Ich glaube, viele haben irgendwie hier von Marvel irgendwie Ken Thor irgendwie. Der mit dem großen Hammer. Der mit dem großen Hammer, ganz genau. Und jetzt müsst ihr mir helfen, da gibt es so einen Wächter irgendwie für die...
Ich weiß nicht, ob du dich da auskennst. Ich habe weder Marvel noch DC-Vermaker oder was auch immer. Habe ich leider nicht gesehen. Okay, es gibt jedenfalls so einen Eingangswächter, also auch so einen Webserver, den kann ja typischerweise jeder anrufen. Und da gibt es immer so die Aufgabe am Anfang, das nennt sich Reverse Proxy quasi, den Netzwerkverkehr entgegenzunehmen und quasi nach unten weiter zu verteilen.
So, das ist schon mal, das ist ein Microservice. Ihr macht nichts anderes, als die Konnektion aufzunehmen, zu gucken, was ist da los, wo muss das hin und verteilt es nach unten weiter. Und dann haben wir so Microservices wie eine Datenbank für die Authentifizierung. Da stehen quasi alle Namen von den Nutzern drin und die verschlüsselten Passwörter und so weiter.
Dann haben wir einen Container, der macht die Authentifizierung als Code. Eines ist die Datenbank, quasi wie so ein Pfeilspeicher. Den legt man typischerweise auch in den Container rein. Und der andere macht quasi den ausführenden Code dazu, hin und zurück. Und dann kann man wundervoll containerisieren, zum Beispiel, mal ein krasses Beispiel, wir haben zum Beispiel eine Python-Umgebung.
Denn Python, wenn man das installieren will auf dem Rechner, da gibt es auch wieder verschiedene Versionen, das passt halt nicht zusammen. Also haben wir sauber eine Python-Umgebung in einem Container und dann kann man quasi mit Python diese ganzen schönen, zum Beispiel KI-Rechnungen machen. ja, TensorFlow benutzen und so weiter. Das steckt auch in einem Container. Und der Nächste macht dann JavaScript und rendert die React-Anwendung und so weiter. Und das ist sauber aufgeteilt.
Cool, okay. Soweit verstanden. Vielleicht lassen wir uns nochmal, bevor wir dann zum Ende kommen, auf einen letzten Aspekt kommen. Was, glaube ich, immer wichtig ist bei der Software, ist die Softwarewartung und die Pflege. Ich habe jetzt im Vorfeld ein bisschen gelesen über ein Beispiel von Spotify, die irgendwas mit 600... Entwicklungsteams im Einsatz haben, jeweils ein kleines Thema beackern und so weiter und so fort. Und da im Live-Produkt quasi
Dinge an der Software ändern können und die dann für sich selbst irgendwie releasen, sag ich jetzt mal. Ja, da weiß ich schon ganz viel Falsches dabei. Aber dass solche Dinge nur überhaupt möglich sind durch Microservices, vielleicht bringst du da ein bisschen Licht ins Dunkel, bevor wir dann mal so Richtung Ende kommen. Ja, das bringt im Prinzip das schon mit sich, wenn man halt sagt, ich teile mein System so auf, dass ich funktionale Entititäten habe, die gekapselt sind.
und die quasi eine bestimmte Technologie bündeln. Das sagt ja quasi schon, dass ich sage mal, also das heißt zum Beispiel, dass so ein Frontend, also sowas, wenn ich so eine UI baue, für den Browser angezeigt wird, das wird quasi in einem Container landen. Das ist zum Beispiel die Mindestaufsplittung in so einem Developer-Team. Es gibt halt die Leute, die kennen sich besonders gut aus mit Frontend. Die können halt tolle...
Tolle Web-Anwendungen, die gut aussehen entwickeln und die ganzen CSS-Effekte haben und so weiter. Und dann gibt es halt die anderen, die machen Backend. Also die können toll Datenbanken designen und irgendwie performant irgendwas da rein beschreiben und rauslesen.
Und dann habe ich quasi schon eine Verteilung vom Team. So kann ich irgendwie die Leute aufteilen und dann kommen sie sich auch nicht im Weg und editieren auch nicht an der gleichen Codebase rum, weil das im Prinzip... zwei verschiedene die zwei verschiedene anwendungen sind die zum schluss aber zusammen gehören und dann könnte ich schon dann könnte quasi das frontend entwicklungsteam könnte schon noch internes frontend ganz umstrukturieren
Sobald die aber die API lassen, wie das Frontend nach außen und nach innen kommuniziert mit den anderen Microservices, wenn die da nichts anfassen, können die quasi komplettes Frontend unmodeln. Und jetzt zu deinem Fall, wie kann man das live einschießen in so ein Deployment? Es ist so einfach, wie diesen Container zu stoppen. Das ist eine Sache von, das passiert in ein paar Millisekunden, den neuen Container da reinzuladen und wieder hochzufahren.
Wenn man es so machen würde, wäre es immer noch schlecht, aber dann wäre für ein paar Sekunden quasi das Frontend weg und dann wieder da. Da gibt es dann auch wieder andere Strategien, weil dieser Portalwächter, von dem ich vorher gesprochen habe, der weiß das dann schon vorher. lenkt quasi den ganzen Verkehr erstmal auf so einen Container, um dir das übernimmt, dann kommt der neue Container rein und dann kann man so einfache Sachen machen, die sich
Eigentlich erstmal kompliziert, dann können wir nicht das so A-B-Testing oder A-B-Deployment. Da kann man sagen, okay, ein bestimmter User-Kreis, die kriegen jetzt schon mal die neue UI. Und da sagt der Wächter, okay. Per Zufall oder wie auch immer leite ich jetzt den Gerrit, der gerade in seinem Browser sitzt und wir Spotify angucken. Der kriegt jetzt auf einmal die neue UI.
Und dann leitet der Microservice, der der Gatekeeper ist, quasi um auf den neuen Microservice, den das Team Frontend von Spotify neu gemacht hat, auf den Container. Und alle anderen sehen noch den Inhalt vom iPhone. Das ist halt super cool. Da kann ich halt auch eine total komplexe Anwendung... Ja, relativ einfach irgendwie weiterentwickeln oder auch mal ein Problem fixen oder sowas, ohne dass das Ding gleich im Ganzen geputzt wird.
Praktisch und als müssten wir uns da vielleicht nochmal drüber unterhalten. Ich kenne A, B, Testing, Nose Marketing, habe nicht den einen Nutzern, Website-Besuchern, Message A anzeige, den anderen Message B. Oder mit verschiedenen Ads und so weiter gibt es anscheinend auch in der Software. Gibt es in der Software auch, ja. Bevor wir das besprechen, würde ich aber auch, also viel mehr weiß ich davon auch, ich sollte vielleicht noch ein bisschen mehr davon wissen, aber tatsächlich.
würde ich mich da noch ein bisschen aufgleisen. Aber heute machen wir das ja auch nicht mehr. Jetzt haben wir glaube ich unsere Zuhörer schon mit viel Infos irgendwie... Genau, also du sagst es. Gibt es denn noch etwas, was du glaubst vergessen zu haben, was wir auf jeden Fall noch mitgeben sollten?
Vielleicht kann sich unser Zuhörer schon jetzt ausmalen, wenn man denn eine Anwendung komplett in diese Container gepackt hat, sauber, diese Schnittstellen alle sauber sind. Jetzt reiß ich doch ganz kurz Kubernetes an. Im Prinzip alles, was man so hört mit AWS, also Amazon Web Services, Microsoft Azure Cloud und so weiter und so fort, das basiert alle diese Technologien.
die basieren auf dieser Idee von Kontainerisierung von diesen Microservices, auch Kubernetes. Nur jetzt vielleicht schon mal als Vorschau für eine andere Serie unseres Podcasts. Das geht deswegen so einfach, weil man jetzt diese... Ich nehme nochmal das Schiffsbeispiel. Wenn wir jetzt nur ein Schiff haben, wo die Container sind, dann hat das halt auch...
gewisse Kapazität. Ist halt auch irgendwann voll. Und was jetzt so ein AWS oder so ein Azure ist, das ist quasi die ganze Flotte. Also ich habe auf einmal nicht nur ein Schiff, sondern, und das Schiff lass mal sein, irgendwie quasi ein Server, ich habe auf einmal 100 Schiffe.
Und jetzt kann ich ganz dynamisch mir aussuchen, jetzt geht das Bild nicht mehr so gut, aber ich kann quasi diese Container beliebig verteilen auf diese Schiffe und quasi so ein Low-Balancing schaffen, das nie ein Schiff absäuft. Denn die Last, die die Schiffe tragen müssen, hat so ein bisschen zu tun mit der Last.
die der Nutzer reinbringt. Also wenn Spotify auf einmal, keine Ahnung, wenn alle von der Arbeit kommen und um 19 Uhr irgendwas anmachen, dann ist das schon so, dass da mehr Last ist. Und das muss halt irgendwie auch aufgeteilt und verteilt werden.
wirklich genug Server, Computer da sind, die diese Last übernehmen können. Und hier sprechen wir, das sind diese modernen Cloud-Technologien mit Cloud-Ballacing und so weiter. Und die können das nur, weil die quasi Container durch die Gegend schmeißen. Dafür ist das wichtig. Also du hast gemerkt, ich habe nicht zum allerersten Mal von Microservices und von Docker gehört.
Bin auch dankbar, dass du Kubernetes gleich mal rausgestrichen hast, wenn es nochmal kurz noch zurückgekommen ist. Also immer gerne so weitermachen. Und ja, möchte ich Danke sagen und freue mich dann. Oder würde mich freuen, wenn ihr Zuhörerinnen und Zuhörer was gelernt habt und würden uns dann freuen, euch in der nächsten. Vielen Dank fürs Hören in dieser Folge von Einfach Komplex.
Dir hat die Folge gefallen? Dann lass uns eine positive Bewertung da oder teile die Folge mit jemandem aus deinem Netzwerk. Möchtest du zusätzlich mit anderen Hörerinnen und Hörern sowie Burkhardt und mir in Kontakt kommen, um die aktuelle Episode und andere Themen rund um Software und IT zu diskutieren, dann tritt dem Heisenware Discord-Server bei. Den Link zum Server findest du in den Shownotes und auf heisenware.com.
Neue Folgen gibt es jeden Mittwoch. Abonniere jetzt unseren Podcast, um keine Folge mehr zu verpassen.