Irgendwas Mit Internet

Marina Dittrich / Daniel Meisen
Since 04/2025 3 Episoden

Episode 2: Das liegt alles in der Cloud

30.06.2025 77 min

Zusammenfassung & Show Notes

🎙️ Irgendwas mit Internet – Episode 02: Und es werde Internet

🕒 Dauer: 75:55 Minuten

🎧 Thema: Irgendwas mit Internet – Ein Unterhaltungspodcast zu Digitalthemen

In dieser Episode 02 „Irgendwas mit Internet“ sprechen wir – Marina und Daniel – über die Cloud. Was ist diese Cloud eigentlich? Woraus besteht sie und wie nutzt man sie?

🔍 Highlights der Episode:
• 00:00 - Introduction
• 00:31 - Vorstellung
• 01:16 - Digitale Souveränität
• 02:26 - Was ist diese Cloud eigentlich
• 03:36 - Cloud-Anbieter
• 05:37 - Was war vor der Cloud
• 09:31 - Verteilte Infrastruktur
• 12:17 - Der Slashdot Effekt
• 13:16 - Elastizität
• 15:03 - Virtualisierung
• 18:31 - Der Start von AWS - Storage und Compute
• 22:42 - Redundanz in der Cloud
• 35:31 - Demokratisierung der Infrastruktur
• 38:11 - Serverless Computing
• 43:54 - Maschinennahe Programmierung
• 57:40 - Die grossen Cloudanbieter


💬 Mitdiskutieren:
Schreib uns: podcast@irgendwasmitinternet.com

🔔 Abonnieren & Feedback:
Wenn dir die Folge gefallen hat, abonniere unseren Podcast und hinterlasse eine Bewertung.

Wir freuen uns auf dein Feedback!

Transkript

Sie vermitteln in anderen Wegen, aber sie wollen große Anteile von Informationen über das Internet vermitteln. Und wiederum, das Internet ist nicht etwas, das man einfach drücken kann. Es ist kein großer Truck, es ist eine Serie von Türen. Und wenn Sie diese Türen nicht verstehen, können sie gefüllt werden. Und wenn sie gefüllt sind, wenn Sie Ihren Message einlegen, wird er live. Ja, dann können wir starten. Was haben wir gesagt? Moin Daniel. Hallo Marina. Willkommen zu... Folge 3. Nein, Folge 2. Stimmt, wir haben bei 0 angefangen zu zählen. Wir haben bei 0 angefangen zu zählen, richtig. Folge 2. Folge 2. Irgendwas mit Internet. Yes. Yes. Worüber sprechen wir heute? Über die Cloud. Quasi ein Heimspiel für dich. Das finde ich hervorragend. Ja. Also ich habe mich echt ein bisschen reingenördert am Wochenende. Und habe ein paar Fragen vorbereitet. Und ja, die würde ich mal dir stellen. Und ich glaube, ich würde dann einhaken, wenn ich es nicht ganz verstehe. Weil ich glaube, dann verstehen es auch andere nicht. Das finde ich gut. Ja, genau. Und vielleicht erzählen wir noch, wie wir auf das Thema gekommen sind. Weil initial haben wir gesagt, wir wollen über das Thema digitale Souveränität sprechen. Und ja, mir ist aufgefallen, als ich darüber nachgedacht habe, dass das Thema wirklich sehr abstrakt ist. Und eigentlich mehr Fragen aufwirft, die sehr diffus sind. Wo ich jetzt gar nicht wusste, was ist das eigentlich für ein Gegenstand? Digitale Souveränität, warum kommt es jetzt auf? Und bin letztlich darauf gekommen, dass viel daran hängt, dass quasi die Cloud so allgegenwärtig ist. Und Cloud Computing dazu führt, dass die Verfügung über Daten eine verteilt ist. Und insofern sich die Frage stellt, wer verfügt eigentlich über die Daten? Wo liegen sie jetzt genau? Wo sind sie physisch? Und es ist mir auch aufgefallen, dass ich da selber nicht ganz so fit bin in dem Thema. Und insofern dachte ich, kann man die Folge mal nutzen, um das ein bisschen zu ändern zumindest. Und die erste Frage wäre dann direkt, die Cloud ist ja einerseits total allgegenwärtig. Alle benutzen sie und sprechen auch über die Cloud. Aber keiner weiß so richtig, was es eigentlich ist. Man hat die Apple Cloud und Daten liegen in der Cloud. Und das ist, glaube ich, ja auch so die Metapher für das Internet eigentlich. Also dieses diffuse Ding und eine Blackbox und was dahinter steht, versteht man nicht richtig. Und ja, da wäre die Frage, was ist eigentlich die Cloud? Beziehungsweise was ist Cloud Computing in einfachen Worten erklärt? In einfachen Worten erklärt? Also ich glaube, es macht schon Sinn, wenn man sich mal anguckt, wo diese Cloud eigentlich herkommt. Denn historisch, also ich meine, das Internet ist jetzt nicht mehr ganz neu. Aber nichtsdestotrotz hat es, glaube ich, Einzug in viele Haushalte erst mit so etwas wie dem Smartphone gehalten. Also sicherlich gab es auch in vielen deutschen Haushalten vorher schon irgendwie einen Internetanschluss. Und man hat irgendwie seine E-Mails gemacht und gesurft vielleicht und auch mal eine Reise gebucht online. Aber viel mehr Berührung mit dem Internet gab es in den meisten Haushalten, glaube ich, gar nicht, würde ich vorsichtig behaupten. Das heißt, das Aufkommen der Cloud als solches. Und wenn wir heute von der Cloud sprechen, dann sprechen wir eigentlich von ganz vielen unterschiedlichen Hyperscalern, also Anbietern von Rechenzentren, in denen man eben Cloud-Dienste oder Cloud-Infrastruktur buchen kann. Aber vor allem auch von ganz, ganz viel Software-as-a-Service-Anbietern. Also wenn ich zum Beispiel, das ist gerade irgendwie die iCloud genannt oder früher dann auch so Dienste wie Google Fotos oder Flickr. Also so ganz, ganz viele Dinge, die irgendwie nützlich waren, wo man als normaler Bürger sich irgendwie dann einen Account hat klicken können und dann die Cloud implizit und genutzt hat, weil die Anbieter haben die Daten ja in der Regel auch nicht in eigenen Rechenzentren bereitgestellt, sondern eben dann Infrastruktur benutzt, die ihnen nicht gehörte. So und jetzt kann man überlegen, wo fängt die Cloud an? Also gibt es die Cloud erst seit irgendwie Amazon Web Services, Azure, also von Microsoft das Cloud-Angebot oder eben die Google Cloud Plattform gibt? Und ich denke, die Antwort ist ganz klar Nein. Also sowas wie die Cloud gab es vorher schon. Aber es ist halt nicht ganz so Commodity gewesen, wie es heute eben der Fall ist. Und es gibt von der NIST, also von der amerikanischen Standardisierungsinstitut, gibt es glaube ich eine Cloud-Definition. Und das eine ist sicherlich sowas wie Self -Service. Also wir können Ihnen schon mal nachliefern. Ich habe sie glaube ich. Du hast es sogar vorrangig. Ja, ja, ich habe sie natürlich eingenördert. Also ich glaube es ist sowas wie Self -Service, Scalability. Also das muss irgendwie ein skalierendes Angebot sein. Es muss eben bestimmte Infrastruktur-Komponenten beinhalten. Also eben sowas wie virtuelles Compute und Storage und eben weitere Mehrwertdienste. Mist, ich habe sie nicht rauskopiert. Ich würde aber tatsächlich nochmal ein Stück zurück, weil als ich angefangen habe über die Cloud nachzudenken, habe ich so ganz an den Anfang zurückgeguckt und gesagt, okay, was ist der Status Quo, den ich noch verstehe? Software wird auf einer Maschine ausgeführt. Also wirklich komplett von Anbietern jetzt erstmal weg. Quasi was war die alte Welt? Was war vor der Cloud? Was ist die Konstante, die auch die Cloud nicht ändert, nur anders macht? Ist Code, also Software wird auf Maschinen ausgeführt, die einen Speicher haben, die einen Prozessor haben, die Compute durchführen. Diese Maschine ist lokal und man kann sich den Kasten vorstellen und die Software läuft darauf und ist insofern auch von der Performance ja auf die Maschine limitiert. Ja und nein, glaube ich. Also das hängt so ein bisschen davon ab, wie weit wir zurückgehen. Also wenn du eben so ein Stück Software baust, was irgendwie über das Internet oder einen Web Interface oder eine API, also eine Schnittstelle erreichbar sein soll, dann muss das irgendwo laufen. Also irgendwo muss dieses Stück Software installiert sein. Und jetzt kannst du sagen, okay, einfache Services kann ich auf meinem lokalen Linux Rechner einfach als Software laufen lassen. Ich kann über das Netzwerk Interface eben auch sowas wie ein Web-Angebot bereitstellen. Und in den Anfang des Internets, also als es sowas wie Mailboxen in Amiga-Zeiten gab, war das ja auch genauso. Also da liefen einfach bei Menschen auf ihren Computern zu Hause einfach Portale, an denen man sich anmelden konnte, über die man dann im einfachsten Falle Dateien ausgetauscht hat. Also Magazine, Musik, Filme, was auch immer. Programme damals auch vor allem. Und ich denke, also diese Metapher hat dann ein Stückchen weiter transportiert. Nicht jeder, der eben Software einer größeren Menge an Menschen bereitstellen will, ist in der Lage, selber die Infrastruktur dafür zu betreiben. Also wenn ich irgendwie ein Mittelständler bin und ich habe jetzt eine Applikation, nehmen wir irgendwie einen Reiseanbieter, der tatsächlich Reisen über das Internet verkaufen will, dann möchte er diese Buchungsstrecke natürlich allen Menschen super, super schnell anbieten können. Und das kann er in der Regel nicht oder nur schlechter, wenn das Rechenzentrum im Rostocker Keller ist beispielsweise. Das heißt, auch da hat man dann immer relativ früh schon versucht, natürlich näher an die Nutzer heranzukommen. Und das ist auch, glaube ich, so die ersten Dienste, die es dann gab, dass man gesagt hat... Warum ist das wichtig? Latenz. Also ich möchte im Prinzip die Dauer, die ich brauche, um so einen Buchungsvorgang abzuschließen, die will ich kurz halten. Weil je mehr Zeit ich im Prinzip jemandem gebe und je länger es dauert, desto wahrscheinlicher ist es, dass die Buchung dann am Ende nicht abgeschlossen wird, sondern dass ich abspringe. Das heißt, wenn ich bei jedem Knöpfchen drücken und bei jedem weiter irgendwie fünf Sekunden warte, verliere ich die Lust. Bin abgelenkt und am Ende buche ich die Reise nicht, weil es mich nervt. Ich glaube, man muss schon, das kann man nicht voraussetzen, dass, worüber wir ja schon reden, es gibt diese materielle Komponente. Auch wenn wir jetzt quasi über die Cloud und Wolkig und über Smartphone Anfragen stellen und dort eine Software angefragt wird, die Daten verarbeitet und zurückgibt. Also das läuft letztlich über Leitungen, weswegen Lokalität wichtig ist, weil die Strecke kürzer ist. Also eine Anfrage, die jetzt auf den Server in den USA geht, wird einfach eine längere Zeit brauchen, bis die Daten erstmal da sind, dann verarbeitet und wieder zurückgeschickt. Also das ist ja quasi, versuchen wir es so bildlich vorzustellen, es sind am Ende trotzdem Leitungen, es fliegt nicht durch die Luft. Bei der Cloud denken durchaus Leute, dass das irgendwie über Wellen übertragen wird, aber es ist ja nicht so. Am Ende sind es Leitungen und darüber werden diese Datenpakete geschickt und diese Software wird auf Rechnern ausgeführt. Und jetzt der Unterschied quasi zu, also es muss mich korrigieren, wie ich es verstanden habe, der Witz am Cloud Computing ist, ich habe verteilte Ressourcen. Ich habe eben nicht im Rostocker Keller eine Maschine stehen, sondern ich habe erstmal Rechenzentren, die verteilt sind auf der ganzen Welt. Aber abstrakt, ich habe lauter Maschinen, die sind auch anders aufgebaut als jetzt so ein stationärer Heimcomputer. Die haben aber trotzdem diese ganzen Komponenten, die jetzt ein Computer auch hat, die werden einen Speicher haben und so weiter. Die sind verbunden über Leitungen und der Witz ist, dass quasi diese verteilten Ressourcen, die natürlich extrem potenziert sind im Vergleich zu einem Gerät, was steht irgendwo lokal, auf diese ganzen Ressourcen wird quasi zugegriffen. Aber es wird nicht ausgehebelt, dass quasi diese Datenpakete über Leitungen geschickt werden und Anfragen zurückgeschickt werden müssen und so weiter. Genau, ich glaube, wo man vielleicht nochmal erklären müsste, warum das wichtig ist oder warum auch die Cloud-Anbieter am Ende so erfolgreich sind, wie sie gerade sind. Also ganz klassisch hast du angefangen, bleiben wir bei dem Beispiel der Buchungsstrecke. Natürlich kannst du selber dir ein Rechenzentrum in den Keller bauen, du kannst deine Server da hinstellen. Und im Zweifel, wenn du eben so ein Buchungsangebot für europäische oder deutsche Nutzerinnen anbietest, dann langweilen die sich in der Regel nachts, die Server, nämlich genau dann, wenn eben keiner Reisen bucht. Und du nutzt im Prinzip nicht die volle zur Verfügung stehende Leistung, sondern da läuft eine Anwendung auf einem Computer, der gehört dir. Das ist dein Computer und der ist natürlich über sowas wie eben ein Netzwerk und dann eben die Dienstanbieter oder die Internetanbieter zu Hause eben entsprechend verbunden und zugänglich. Aber es ist nicht verteilt, das heißt also in dem Moment, wo eben dann dein Rechenzentrum durch einen Wasserschaden oder durch einen Brand kaputt geht, ist im Prinzip auch dein Service nicht erreichbar. Also insofern macht es schon Sinn zu sagen, ich biete diesen Service eben nicht nur an einem Standort an, sondern ich nutze eben mindestens mal noch eine Co-Location, also irgendwie ein zweites Rechenzentrum, um eben a, die Last ein bisschen zu verteilen und b, eben auch einem Ausfall entgegenzuwirken. Also reines Risikomanagement. Technisch brauche ich das nicht. Technisch kann ich auch sagen, der Rechner in meinem Keller oder der Server in meinem Keller ist leistungsfähig genug, mehr brauche ich nicht. Genau, dann passiert halt das, was man, ich habe das bei so Konzerttickets, das habe ich mal erlebt von den Ärzten, dass der Ticketshop, der war schon, bevor der freigeschaltet wurde, war schon nicht mehr erreichbar. Ja. Wenn die gesagt haben, das wird reichen. Ja und manchmal, also früher, es gab also in Zeiten, heute gibt es das glaube ich gar nicht mehr, aber in Zeiten bevor es dann irgendwie Facebook und sowas wie Reddit oder sowas gab, gab es eben so ein Linkportal würde ich es mal nennen. Ja, das nannte sich Slashdot, war aber auch in, ich sag mal eher so in Nerd - und IT-Kreisen eher bekannt und das war halt ein ganz guter Weg, weil so ein ganz gutes Verzeichnis, um eben dann auf aktuellen Artikel oder eben auch andere interessante Inhalte im Internet zu kommen. Und Slashdot hat halt so eine hohe Beliebtheit erlangt, dass in dem Moment, wo dann ein Link auf Slashdot gelandet ist, die Dienste teilweise offline gegangen sind, weil sie eben geslashdottet wurden. Also dann sind plötzlich halt eben nicht nur die 10 Nutzer, die das Angebot sonst hatte, da irgendwie gleichzeitig draufgegangen, sondern halt plötzlich Tausende oder Hunderttausende. Und das ist tatsächlich auch glaube ich so ein, also eines der wesentlichen Merkmale von aktuellen Cloud-Angeboten, sowas wie Elastizität. Das heißt also in dem Moment, wo ich wirklich mein eigenes Rechenzentrum baue und plane, muss ich natürlich immer den maximal möglichen Nutzervolumen antizipieren. Also nehmen wir sowas wie Idealo oder auch irgendeine andere, also als Preisvergleichsmaschine oder auch einfach einen Anbieter von günstiger Hardware oder anderen Konsumgütern. Ja oder einfach Online-Shop, wo dann halt dieses Saisongeschäft, Weihnachtsgeschäft ist natürlich eine höhere Frequenz. Black Friday und du hast halt, also das sind Termine, die kennst du und du weißt im Prinzip, okay, da wird's mehr. Aber nichtsdestotrotz brauchst du ja auch eine Lösung für diese Tage im Jahr, wo du weißt, dass das eben mehr konsumiert wird und auch da machst du dann im Prinzip halt einen Großteil deines Umsatzes fürs restliche Jahr. Weil eben so Retail oder eben Konsum ist ein total saisonales Geschäft und ich denke, das ist halt auch was, wo man dann angefangen hat zu virtualisieren. Das heißt, man hat gesagt, okay, wir haben hier die Hardware und grundsätzlich möchten wir eben das gleiche Stück Hardware mehreren Nutzerinnen zur Verfügung machen, um einfach so Lastspitzen besser verteilen und auffangen zu können. Und das gab's auch, bevor es sowas wie die großen Cloud-Anbieter gab schon, dass man gesagt hat, ich kann mir bei so Anbietern wie, also in Deutschland war es dann vor allem sowas wie Hetzner beispielsweise oder eben auch große andere Rechenzentren. Ich kann mir da einen virtuellen Server mieten und das ist tatsächlich halt einfach nur ein virtuelles Betriebssystem, in dem ich meine Anwendung installieren kann, von dem halt mehrere auf der physischen Hardware laufen. Das heißt, es gibt eben einen physischen Server, auf dem dann virtuell in so einer Art Container mehrere Betriebssysteme laufen und somit mehrere virtuelle Server. Das heißt, man kann eben die darunterliegende Hardware einfach mehreren Nutzern lastabhängig zur Verfügung stellen. Man sagt, wir müssen jetzt hier nicht noch irgendwie sieben weitere Server ins Rack schieben, sondern wir können die Last so verteilen, dass es passt. Und dann ist es quasi Aufgabe des Dienstanbieters, also in dem Fall dann das Rechenzentrumsanbieter, dafür Sorge zu tragen, dass immer ausreichend physische Kapazität vorhanden ist, um diese virtuellen Server, also diese einzelnen Container tatsächlich auch performant betreiben zu können. Und auch da brauchen wir jetzt noch nicht groß über Geolokalität sprechen oder sowas. Das funktioniert auch innerhalb von einem Rechenzentrum noch gut. Spannend wird es tatsächlich bei so global funktionierenden Diensten. Also ich denke, einer der Vorreiter war Netflix beispielsweise. Als die angefangen haben, Streaming-Dienste massentauglich zu machen, hatten sie natürlich auch das Problem, dass eben sowas wie die Kapazitäten, die irgendwie Amazon oder andere Cloud-Anbieter angeboten haben, noch gar nicht in der Art regional verfügbar waren. Also sowas wie eigene Rechenzentren von AWS in der Schweiz beispielsweise oder auch in Deutschland teilweise gab es noch nicht. Und Netflix hat dann eine Zeit lang selber Hardware gebaut. Also die haben tatsächlich halt dann sogenannte Edge -Nodes gebaut. Also das waren halt einfach kleine Server, auf denen bestimmte Inhalte dann entsprechend gecached, also die Top-10-Serien oder Filme beispielsweise zur Verfügung standen. Und man konnte sich das dann ins Rechenzentrum seiner Wahl stellen lassen. Das heißt also, wenn bei mir zu Hause Netflix zu langsam war, dann konnte ich Netflix sagen, hey, das wäre total cool, wenn ihr hier bei mir in der Nähe mal noch so eine Edge-Node installieren würdet, damit mein Netflix zu Hause schneller ist. Und das war natürlich halt auch nur so eine Brückentechnologie, bis es dann eben entsprechend Rechenzentrums -Anbieter gibt, die eben global skalieren, um so einen Dienst überhaupt in der Form möglich zu machen. Ja, AWS hat es jetzt schon genannt und ich glaube, man braucht es ja auch nicht so anonym halten und gesagt haben, ja, dann ist man losgegangen und hat sich was überlegt. Also zumindest das, was ich nachgelesen habe, so in der quasi internationalisierten, professionellen, wirklich groß angelegten Form war es schon Amazon, die erstmal aus ihrem Bedarf darauf gekommen sind, sich so eine Infrastruktur aufzubauen. Weil internationaler Online-Shop, Saisongeschäft, ich habe irgendwo die Zahl gelesen, Faktor 10 war der Unterschied zwischen jetzt Heidi Ma, wenn irgendwelche Aktionen gefahren worden sind und der, ich sage mal, Normallast. Und das kann man sich ja vorstellen, was das für Anforderungen an letztlich einen Webshop sind. Kunden auf der ganzen Welt verteilt sollen dort, also es ist auch eine Bestellstrecke, die soll schnell abgewickelt werden. Und da diese Lastverteilung hinzukriegen und das ganze Ding einfach am Laufen zu halten, das erfordert schon eine sehr spezielle Art von Infrastruktur und die haben sich quasi aufgebaut. Und dann, ich weiß nicht in welchem Jahr wir da jetzt sind, aber irgendwann haben sie halt angefangen, das als Dienstleistung anzubieten. Ich denke mal, das muss irgendwie Anfang der 2000er gewesen sein, so um den Dreh. Also genau, Anfang der 2000er sind sie dann eben gestartet mit eben zwei recht einfachen Diensten, also einmal Storage und einmal Compute. Also die Anforderung an Storage ist sowas wie, ich möchte eben Daten global vorhalten. Ich möchte sie performant vorhalten, ohne dass ich mir eben selber darüber Gedanken machen muss, wo jetzt welcher Server wie viel Festplatten redundant zur Verfügung stellt. Sondern ich habe im Prinzip halt einfach einen Dienst, über den ich eine Datenhaltung realisieren kann, die beliebig skaliert. Das heißt... Jetzt musst du mal erklären, wie wir das machen, weil das habe ich tatsächlich überhaupt nicht verstanden, wie das funktioniert. S3? Ja. Also S3 ist tatsächlich, also es gibt Block Storage, das ist tatsächlich einfache Festplatten. Das heißt, ich kann sagen, ich hätte ganz gern einfach eine Festplatte, auf der meine Anwendungen und meine Daten liegen. Und die kann ich in einer bestimmten Größe bestellen und dann bezahle ich dafür auch. Also zum einen eben für das Lagern der Daten. Und wenn ich es dann beispielsweise als Backup nochmal redundant verfügbar haben will, auch dafür. Und da gibt es verschiedene Storage-Klassen. Wenn man sagt, es gibt zum Beispiel Daten, die müssen einfach sehr schnell zur Verfügung gestellt werden oder müssen sehr schnell abrufbar sein, sind auch veränderlich. Also einfach, weil der Dienst, den ich anbiete, zum Beispiel einfach Nutzerdaten erstellt. Also weil ich zum Beispiel eine Web-Anwendung habe, mit der ich Podcasts aufzeichnen kann oder sowas. Oder es ist tatsächlich halt einfach ein ganz stumpfer Dienst, wo ich, keine Ahnung, so in einem Archivstil als Personalbuchhaltungsanwendung die Lohnsteuerbescheinigung ablege. Und der Mitarbeiter ruft sich das Ding, wenn er organisiert ist, einmal im Monat. Wenn er nicht so organisiert ist, einmal im Jahr ab. Das heißt, das muss nicht besonders schnell sein. Das ist ja jetzt das Angebot quasi. Aber wie kriegen die das hin? Das wäre jetzt ein bisschen eine technischere Frage. Diese Verfügbarkeit, Redundanz. Also was machen die besser, was jetzt nicht quasi eine Festplatte zu Hause leisten könnte? Die Festplatte zu Hause ist, also A, oder andersrum, wenn wir bei S3 sind, dann ist es tatsächlich halt einfach ein riesengroßes Dateisystem, wenn du so willst. Das heißt, es ist die Festplatte, die du zu Hause hast, nur weltweit verteilt. Ohne, dass du dir als Anwender von diesem Dienst Gedanken darüber machen musst, ist die Festplatte voll? Ist sie zu langsam? Ist sie zu schnell? Geht sie kaputt? Also je nachdem, was für eine Technik das ist. Entweder es ist so ein SSD, also ein Festspeicher, oder es ist eine sich drehende Magnetplatte. Aber bei beiden können natürlich auch Fehler auftreten. Das heißt, einfach Daten können kaputt gehen. Und um all das musst du dir aber keine Gedanken machen als Nutzer von sowas wie einem, also S3 steht für Simple Storage, also für einen ganz einfachen Speicherdienst. Du kannst da deine Datei hochladen. Du kannst da bestimmte Rechte drauf definieren. Also kannst sagen, ich darf die lesen oder jeder, der im Prinzip einen Link darauf hat, vereinfacht gesagt, darf die Datei lesen oder schreiben. Das heißt also, da ist dann auch so ein Rechtemanagement noch mit involviert. Aber wie das technisch drunter realisiert ist, muss dich als Nutzer salopp gesagt nicht interessieren. Genau, aber wenn es mich jetzt interessiert. Wenn es dich interessiert. Also technisch ist es auch nichts anderes, als ABS ist organisiert in verschiedenen Rechenzentren. Also das sind wirklich einfach physische Rechenzentren, die in sogenannten Regions weltweit verteilt sind. Das heißt, es gibt in der Region US East oder US West gibt es ein Rechenzentrum. Das ist wirklich halt einfach eine große Halle voll mit Servern. Und weil ABS sagt, okay, also aufgrund verschiedener Compliance Anforderungen, aber auch rechtliche Anforderungen von bestimmten Kunden und auch aus einer Reihenrisiko Betrachtung heraus, reicht uns ein Rechenzentrum nicht aus. Weil da kann immer mal der Dieselgenerator kaputt gehen, die Glasfaserleitung durch einen Bagger durchtrennt sein oder, oder, oder. Und deswegen organisiert man diese Regionen in verschiedenen sogenannten Availability Zones. Das heißt, eine Region setzt sich immer aus drei unabhängigen Rechenzentren oder in der Regel aus drei unabhängigen Rechenzentren zusammen. Das heißt, wenn wir jetzt beispielsweise die Region Frankfurt nehmen, dann ist es für mich als Nutzer, lege ich meine Daten beispielsweise in Frankfurt ab. Und ob das jetzt in dem einen oder in dem anderen Rechenzentrum ist, muss mich erstmal nicht interessieren. Also das Hin- und Herschieben der Daten von 1 nach 2 kann je nach Dienst ABS auch für mich machen. Das heißt, da brauche ich mich nicht drum kümmern. Also quasi erstmal eine Art von Redundanz, wirklich in materieller Form, dass es mehrere Rechenzentren gibt. Also quasi einfach multipliziert und dadurch wird abgefangen, ja, letztlich. Ausfälle einzelner Rechenzentren. Also die sind tatsächlich so weit auseinander, dass in der Regel an unterschiedlichen Glasfaserleitungen sind, dass sie an unterschiedlichen Netzknotenpunkten, also ganz normalen Stromnetzknoten hängen. Sie sind so weit auseinander, dass eben auch so klassische. Wenn eins ausfällt, dann laufen die anderen beiden. Genau, also auch so Naturgefahren, also die Überschwemmungen, Hochwasser, Blitzeinschlag. Im schlimmsten Falle auch sowas wie ein Flugzeugabsturz oder sowas würde im Prinzip natürlich ein Rechenzentrum betreffen, aber nicht alle drei gleichzeitig. Und jetzt gibt es bestimmte Dienste und wir haben gerade von S3, also von diesem Simple Storage gesprochen, wo ich mir tatsächlich, also wo ich als Nutzer entscheiden muss, wo meine Daten liegen. Pro Rechenzentrum oder pro Region? Pro Rechenzentrum tatsächlich auch, weil ABS natürlich diese Redundanz sich auch bezahlen lässt. Und bei sowas wie S3 ist das eben nicht der Fall. Ich verstehe langsam, warum es Firmen gibt, die nur das machen. Genau. Und wenn ich natürlich jetzt, um wieder zu dem Anfangsbeispiel zu kommen, ein Stück Software auf einem Server installieren will, dann muss ich schon auswählen, wo dieser Server liegen soll. Das heißt, ich muss genau sagen, ich hätte gern ein Stück virtuellen Server und der soll eben in Frankfurt Availability Zone 1 sein. Weil auch ABS natürlich Software, die nicht dazu gedacht ist zu skalieren oder verteilt zu funktionieren, nicht einfach verteilen kann. Also es geht technisch salopp gesagt nicht. Das heißt, da musst du als Nutzer schon dafür Sorge tragen, dass diese Software eben in mehreren Rechenzentren parallel laufen kann. Das wusste ich zum Beispiel gar nicht. Das heißt, man spricht da so von klassischem Cold Standby. Also wenn ich sage, ich habe zum Beispiel, also nehmen wir wieder die Buchungsstrecke. Das heißt, an so einer Buchungsstrecke möchte ich mich als Nutzer anmelden. Ich möchte die Reisen angezeigt bekommen und ich möchte eine Reise buchen können. Das heißt, das System muss zu jedem Zeitpunkt eigentlich wissen, wer bin ich als Nutzer? Also was sind meine Nutzerdaten? Was ist mein Passwort? Was ist meine Rechnungsanschrift? Was für Reisen habe ich vielleicht schon mal gebucht? Und was ist auch das Angebot? Und jetzt kann man natürlich sagen, wir bieten das quasi parallel immer in zwei Rechenzentren an. Und wenn eins kaputt geht oder ausfällt, dann ist es wie so eine Weiche, die einfach auf das andere wechselt. Das heißt, im Hintergrund muss ich die Daten zwischen beiden synchronisieren. Das nennt man Cold Standby. Das ist quasi einfach ein zweites Stück System, was daneben steht, was aber nur dann benutzt wird, wenn das andere ausfällt. Oder man kann es tatsächlich auch so machen, dass man es elastisch verteilt. Das heißt, ich nehme einfach drei verschiedene Server in unterschiedlichen Regionen oder Verfügbarkeiten. Und davor gibt es einen sogenannten Load Balancer, also quasi ein Stück Weiche, was dann auf Basis bestimmter Regeln definiert, welcher Server jetzt eine bestimmte Anfrage beantwortet. Das kann sowas sein wie Last. Also wenn jetzt zum Beispiel Server 1 zu X Prozent ausgelastet ist, dann geht es automatisch an Server 2. Das kann Round Robin sein. Also quasi die erste Anfrage geht an Server 1, die zweite an 2, die dritte an 3 und dann wieder die vierte an 1. Also so immer frei um. Oder man kann es auch einfach an bestimmten Regeln festmachen, dass man sagt, Nutzer aus einer bestimmten Georegion landen immer da, weil das ist näher dran oder so. Okay, aber ich verstehe es jetzt so, dass quasi jetzt die AWS Cloud oder das Angebot, was Amazon da macht, die haben erstmal weltweit die physischen Kapazitäten aufgebaut, um überhaupt sowas machen zu können. Dass du überhaupt auf die ganze Welt zugeflastert hast mit Rechenzentren, die miteinander verbunden sind. Und sie müssen ja wahnsinnig komplexe Mechanismen haben, um sowas, was du jetzt gerade beschrieben hast, und wahrscheinlich noch viel, viel mehr möglich zu machen, um ganz granular entscheiden zu können. Also weil diese Redundanz ja immer unterstellt, es gibt einen Mechanismus, der die Daten erstmal redundant hält und auch wirklich in einer sehr kleinen Frequenz, sodass man quasi umschalten kann. Ja, okay, dann schaltet das Rechenzentrum halt aus. Scheißegal, auf einem anderen läuft es halt weiter und das quasi international gedacht. Also ohne da jetzt quasi weiter in die Details zu sehen, kann man sich glaube ich vorstellen, was das ja für wirklich eine Infrastruktur ist, die physisch einfach wahnsinnig umfangreich ist und auch wahnsinnig komplex. Also diese ganzen Fälle zu durchdenken, die passieren können. Also da müssen ja tatsächlich hergegangen sein oder hergehen. Was gibt es für Naturkatastrophen in welchen Regionen? Was ist da wie wahrscheinlich und wie kann man jetzt quasi darauf reagieren, um eigentlich eine Art komplette, also das Ideal ist ja, und es ist ja offensichtlich quasi erreicht, superschnelle Zugriffe, Software, die immer läuft und eine Art unbegrenzte Infrastruktur. Also das wäre jetzt auch gleich die nächste Frage, wo ich darauf gekommen bin, dass dir so ein Apparat unterstellt ist ja quasi eine komplette, technisch ist sie nicht unendlich, aber gefühlt Unendlichkeit von Ressourcen. Das heißt, die Software, die darauf läuft, muss eigentlich keine Rücksicht mehr so richtig nehmen auf, ich bin jetzt wieder bei dem Rechner Beispiel, der da irgendwie steht. Der Rechner hat halt irgendeinen Speicher, der ist irgendwann voll. Er hat eine begrenzte Prozessorleistung. Also da ist einfach irgendwann Schluss. Und so wie ich es verstanden habe, ist das durch die Cloud Infrastruktur einfach wahnsinnig skalierbar und so skalierbar, dass es quasi für die Programmierung ist ja diese Komponente komplett rausgeegst. Du machst dir keine Gedanken mehr darüber, ob es da irgendwelche Grenzen geben könnte, weil rein technisch könnte man das, es kostet Geld, aber man könnte sich das quasi ganz detailliert kaufen. Und ich habe mich gefragt, was das eigentlich mit der Softwareentwicklung macht. Also wir hatten ja ganz am Anfang auch gesagt, im Prinzip diese Cloud Infrastruktur.

2025 - Marina Dittrich / Daniel Meisen