Mitschrift
Klick auf einen Satz, um ab dort zu hören
Willkommen beim Marketing Techie Podcast, dem Podcast über die Technik hinter dem Online-Marketing. Verständlich erklärt, auch für Non-Techies. Mit Emilian Buza von trace5.co. In der heutigen Folge: Die Cloud. Was hinter dem schönsten Marketingbegriff der IT steckt.
33 Prozent. So viel von ihrer Monatsrechnung schrieb Microsoft im März 2012 vielen seiner Cloud-Kunden gut. Für einen Ausfall, der am 29. Februar passiert war. Und zwar allen Kunden der betroffenen Dienste. Auch denen, die davon gar nichts mitbekommen hatten.
Was war an diesem 29. Februar passiert? Kein Angriff. Kein kaputtes Kabel. Sondern eine Rechnung mit einem Datum.
Damals hieß Microsofts Cloud noch Windows Azure. Und darin lief ein Programm, das Zertifikate ausstellte. Jedes davon genau ein Jahr gültig.
Und diese Zertifikate brauchte Microsoft ständig. Immer wenn ein Kunde in der Cloud einen weiteren Server starten wollte, zum Beispiel weil seine Website plötzlich mehr Besucher hatte, musste das Programm vorher so ein Zertifikat ausstellen. Ohne Zertifikat kein neuer Server.
Auf jedes Zertifikat musste also ein Ablaufdatum. Und das rechnete das Programm so aus: Es übernahm Tag und Monat vom aktuellen Datum. Und dann zählte es bei der Jahreszahl eins dazu. Anders gesagt: Stellte das Programm am 3. Mai 2011 ein Zertifikat aus, schrieb es als Ablaufdatum den 3. Mai 2012 drauf. Gleicher Tag, gleicher Monat, ein Jahr später. Passt.
Und das funktionierte. Tag für Tag. Monat für Monat. Dann kam das Jahr 2012.
Und 2012 war ein Schaltjahr. Der Februar hatte also einen Tag mehr, den 29. Auch am 29. Februar 2012 sollte das Programm wieder Zertifikate ausstellen. Und es rechnete, wie immer. Tag: 29. Monat: Februar. Jahr: 2012 plus eins, also 2013.
Auf dem Zertifikat hätte also als Ablaufdatum stehen müssen: 29. Februar 2013. Nur: Diesen Tag gab es nicht. Anders als 2012 war 2013 kein Schaltjahr. Der Februar hatte im Jahr 2013 nur 28 Tage.
Ein Mensch hätte das sofort gemerkt. Das Programm nicht. Es konnte das Zertifikat nicht ausstellen. Und ohne Zertifikat startete kein neuer Server.
Um ein Uhr nachts deutscher Zeit begann der 29. Februar 2012. Überall in Microsofts Rechenzentren wollte das Programm jetzt Zertifikate ausstellen. Und überall scheiterte es.
Kunden konnten ihre Anwendungen nicht mehr wie gewohnt verwalten. Mehrere Dienste waren betroffen. Und all das nur wegen einer Rechenregel, die an diesem einen Tag nicht aufging.
Der Fehler blieb nicht lange unbemerkt. Um acht Uhr morgens hatten die Techniker bei Microsoft ihn gefunden und eine Korrektur gebaut. Kurz nach elf ging die Korrektur raus. Erst auf einen Teil der Cloud, dann auf immer mehr. Alles sah soweit gut aus.
Doch dann passierte der zweite Fehler. In sieben Bereichen der Cloud lief gerade ein anderes Update. Und die schnelle Korrektur passte nicht dazu.
Dort verloren Anwendungen, die die ganze Nacht über noch einwandfrei gelaufen waren, plötzlich ihre Netzwerkverbindung. Die Reparatur hatte den Ausfall dort also schlimmer gemacht.
Erst um halb drei nachmittags konnten die meisten Kunden ihre Dienste wieder verwalten. Und erst um fünf Uhr nachmittags liefen auch die sieben Bereiche mit dem Doppelfehler wieder weitgehend. Sechzehn Stunden voller Chaos. Wegen eines Datums, das es nie gab.
Und die Statusseite, auf der Kunden die ganze Zeit nachschauen wollten, was eigentlich los war? Die war zeitweise selbst nicht erreichbar. Weil zu viele gleichzeitig nachschauen wollten.
Es war ein Desaster. Und daher auch die 33 Prozent. Ein Drittel der Monatsrechnung, für jeden Kunden der betroffenen Dienste. Unangenehm für beide Seiten: für die Kunden und für Microsoft.
Doch genau das zeigt ziemlich gut, was die Cloud eigentlich ist. Kein Wölkchen irgendwo im Himmel. Sondern Programme auf Servern. In echten Rechenzentren. Geschrieben von Menschen, die manchmal etwas übersehen.
Und falls dir noch nicht ganz klar ist, was ‚Cloud‘ eigentlich meint, was sie ist und was sie vom klassischen Server unterscheidet, keine Sorge: In dieser Folge klären wir all diese Fragen. Vor allem aber klären wir, was die Cloud mit deiner Website und deinem Tracking zu tun hat. Legen wir los. „Das liegt in der Cloud.“
Den Satz hörst du ständig. Deine Fotos liegen in der Cloud. Dein CRM ist cloudbasiert. Und die Agentur sagt beim Server-Side Tracking: „Das hosten wir in der Cloud.“
Aber wenn du mal genauer nachfragst, wo genau das liegt … dann wird’s meistens still.
Fangen wir deshalb mit der einfachsten Frage an. Wo ist die Cloud?
Die Antwort ist ziemlich unspektakulär. Die Cloud steht in Rechenzentren. Große Hallen, voll mit Servern. Mit Kühlung, Notstrom und Sicherheitsleuten am Eingang. Amazon, Microsoft und Google haben zum Beispiel alle drei Rechenzentren im Raum Frankfurt am Main. Und warum heißt das dann Wolke?
Die verbreitetste Erklärung: Techniker haben das Internet in ihren Netzwerkplänen schon lange als Wolke gezeichnet. Alles, was außerhalb des eigenen Netzwerks lag und um das man sich nicht im Detail kümmern wollte, war einfach: die Wolke. Irgendwann ist der Name an den Diensten hängen geblieben, die dort draußen laufen.
In der IT gibt es dazu einen Spruch, den du vielleicht schon mal gehört hast: Die Cloud ist nur der Computer von jemand anderem.
Und der Spruch stimmt. Aber er erklärt nur die Hälfte. Denn einen Server von jemand anderem konntest du auch schon vor zwanzig Jahren mieten. Was ist also an der Cloud neu?
Um das zu verstehen, gehen wir einen Schritt zurück. Zu dem, was wir in Folge 2 besprochen haben: dem klassischen Server.
Nehmen wir an, du hast einen Onlineshop. Und der läuft auf einem Server, den du bei einem Hoster gemietet hast. Mit festem Prozessor, festem Arbeitsspeicher, fester Festplatte. Dafür zahlst du jeden Monat den gleichen Betrag. Das funktioniert. An normalen Tagen sogar richtig gut.
Und jetzt kommt der Black Friday. Deine Kampagnen laufen, und plötzlich sind zehnmal so viele Leute in deinem Shop wie sonst.
Was passiert? Dein Server muss zehnmal so viele Anfragen beantworten. Das schafft er nicht. Die Seiten laden immer langsamer. Irgendwann gar nicht mehr. Und deine teuer eingekauften Klicks landen auf einer Fehlerseite. Okay, sagst du, dann miete ich halt einen größeren Server.
Jepp, kannst du machen. Aber dann hast du zwei neue Probleme. Erstens: Den größeren Server bezahlst du jetzt jeden Monat. Auch im Februar, wenn nichts los ist. Du zahlst also das ganze Jahr für Leistung, die du nur an ein paar Tagen brauchst.
Und zweitens: So ein Wechsel geht beim klassischen Hoster nicht auf Knopfdruck. Da wird ein neuer Server bereitgestellt, eingerichtet, deine Daten müssen umziehen. Das dauert. Und selten genau dann, wenn du es brauchst.
Was du eigentlich willst, ist etwas ganz anderes. Du willst mehr Leistung genau dann, wenn du sie brauchst. Schnell. Und du willst nur für das bezahlen, was du tatsächlich nutzt. Und genau das ist der Kern der Cloud.
Einen Baustein dafür kennst du schon aus Folge 2: die Virtualisierung. Ein großer, echter Server wird per Software in viele kleinere, voneinander getrennte Server aufgeteilt. Jeder davon verhält sich wie ein eigener Rechner, existiert aber nur als Programm auf der echten Hardware. So ein Rechner heißt virtueller Server.
Aber Achtung: Virtuelle Server gab es auch schon bei klassischen Hostern. Das ist der VPS aus Folge 2. Virtualisierung allein macht also noch keine Cloud.
Neu ist, was die Cloud-Anbieter daraus gemacht haben. Und das hat vor allem drei Merkmale.
Das erste: Selbstbedienung. In der Cloud wartest du auf niemanden. Du klickst dir einen virtuellen Server in einer Weboberfläche zusammen, und ein paar Minuten später läuft er. Auf Hardware, die im Rechenzentrum schon bereitsteht.
Erinnerst du dich an die Geschichte vom Anfang? An die Kunden, die in Microsofts Cloud einen weiteren Server starten wollten? Die wollten genau das. Einen neuen virtuellen Server, auf Knopfdruck. Und nur weil das an diesem Tag nicht ging, war es ein Ausfall.
Und das Beste daran ist: Das Starten geht nicht nur per Klick. Es geht auch über eine API. Über die haben wir in der letzten Folge gesprochen. Ein Programm kann dem Cloud-Anbieter also sagen: Starte mir bitte zwei weitere Server. Ohne dass dafür irgendein Mensch etwas tun muss.
Das zweite Merkmal: automatische Skalierung. Skalierung heißt, die Leistung an den Bedarf anzupassen. Und weil das Starten von Servern auch automatisch über eine API geht, kann man es von Regeln abhängig machen. Zum Beispiel: Wenn die vorhandenen Server zu stark ausgelastet sind, starte zusätzliche. Und wenn der Ansturm vorbei ist, schalte sie wieder ab.
Wichtig: Das passiert nicht von selbst. Jemand muss natürlich diese Regeln einrichten. Aber wenn sie erst einmal eingerichtet sind, übersteht dein Shop den Black Friday, ohne dass um Mitternacht jemand nachhelfen muss.
Das dritte Merkmal: Abrechnung nach Verbrauch. Du zahlst keinen festen Monatspreis für einen bestimmten Rechner. Du zahlst dafür, wie lange ein Server gelaufen ist, teilweise sekundengenau. Wie viele Daten du gespeichert hast. Wie viele Daten rausgeschickt wurden. Läuft ein zusätzlicher Server am Black Friday nur zwölf Stunden, bezahlst du ihn auch nur zwölf Stunden.
Wenn man das alles auf einen Satz bringt, sieht es so aus: Beim klassischen Server mietest du einen bestimmten Rechner mit fester Größe zu einem festen Preis. In der Cloud holst du dir Rechenleistung selbst, in genau der Menge, die du gerade brauchst, und bezahlst nach Verbrauch.
Und das ist noch nicht alles. Denn du musst in der Cloud gar nicht unbedingt Server mieten.
Die Anbieter verkaufen ihre Leistung auf drei Ebenen. Und die Namen dafür begegnen dir früher oder später in einem Angebot.
Die unterste Ebene heißt Infrastructure as a Service. Kurz IaaS. Da mietest du die Grundbausteine: virtuelle Server, Speicher und Netzwerk.
Und jetzt denkst du vielleicht: Moment. Virtuelle Server, das ist doch der VPS? Der virtuelle Server, über den wir in Folge 2 gesprochen haben?
Und irgendwie stimmt das tatsächlich. Technisch ist es dasselbe.
Der Unterschied liegt in allem drumherum. Bei IaaS bekommst du den virtuellen Server per Selbstbedienung in Minuten, auch automatisch über eine API. Du kannst nach Regeln weitere dazuschalten und wieder abschalten. Und du zahlst nach Verbrauch. Dazu kannst du Speicher, Netzwerk und Server einzeln buchen und frei kombinieren, statt ein festes Paket zu mieten.
Die Grenze ist inzwischen allerdings fließend. Viele klassische Hoster bieten ihre VPS heute auch stundenweise und per API an. Ob man das dann Cloud nennt oder nicht, ist am Ende oft auch eine Frage des Marketings.
Was bei IaaS aber gleich bleibt wie beim VPS: Um alles, was auf dem Server läuft, kümmerst du dich selbst. Betriebssystem, Updates, Sicherheit, deine Software.
Die mittlere Ebene heißt Platform as a Service. Kurz PaaS. Da gibst du nur noch deine Anwendung ab, und der Anbieter kümmert sich um die Server darunter. Du siehst die Server gar nicht mehr. Der serverseitige Google Tag Manager aus Folge 4 läuft zum Beispiel häufig auf so einer Plattform. Bei Google heißt sie Cloud Run.
Und die oberste Ebene heißt Software as a Service. Kurz SaaS. Da mietest du fertige Software, die du einfach im Browser benutzt. Und die Ebene kennst du besser, als du denkst. GA4 ist SaaS. Dein CRM wahrscheinlich auch. Dein Newsletter-Tool. Shopify. Canva.
Je weiter oben du einsteigst, desto weniger musst du dich kümmern. Aber desto weniger kannst du auch selbst bestimmen. Okay, fassen wir kurz zusammen.
Du weißt jetzt also, was die Cloud ausmacht: Selbstbedienung, automatische Skalierung und Abrechnung nach Verbrauch.
Und du kennst die drei Ebenen der Cloud: Bei Infrastructure as a Service holst du dir Server, Speicher und Netzwerk selbst und kümmerst dich um alles, was darauf läuft. Bei Platform as a Service bringst du nur deine Anwendung mit, und um die Server darunter kümmert sich der Anbieter. Und bei Software as a Service benutzt du einfach fertige Software. Um Server, Betrieb und Updates kümmert sich komplett der Anbieter, du kümmerst dich nur noch um deine Daten und Einstellungen.
Über eine Sache müssen wir aber noch sprechen, weil sie für das Verständnis der Cloud entscheidend ist: den Standort.
Die großen Anbieter fassen ihre Rechenzentren in sogenannten Regionen zusammen. Eine Region ist ein geografisches Gebiet mit mehreren Rechenzentren, zum Beispiel Frankfurt, Irland oder Virginia in den USA. Und du entscheidest selbst, in welcher Region deine Server laufen. Das ist für dich aus zwei Gründen wichtig.
Erstens die Geschwindigkeit. Je näher der Server an deinen Besuchern steht, desto schneller kommen die Antworten an. Wenn deine Kunden in Deutschland sitzen, ist ein Server in Frankfurt schneller als einer in Virginia.
Und zweitens der Datenschutz. Wo deine Daten verarbeitet werden, spielt für die DSGVO eine Rolle. Und bei amerikanischen Anbietern kommt noch die Frage dazu, unter welchen Bedingungen Daten in die USA gelangen dürfen. Das ist ein eigenes, kompliziertes Thema. Und eins, das du mit deinem Datenschutzberater klären solltest, nicht mit deiner Agentur.
So. Das klingt jetzt alles ziemlich gut. Schnell, flexibel, nur zahlen, was man braucht.
Aber die Geschichte vom Anfang zeigt ja schon, dass die Cloud auch ihre Schattenseiten hat. Und die solltest du kennen.
Die erste: Die Cloud ist nicht automatisch billiger. Wer einen Server rund um die Uhr laufen lässt, zahlt dafür in der Cloud oft mehr als bei einem klassischen Hoster. Und dazu kommen Kosten, die man vorher leicht übersieht. Zum Beispiel für die Daten, die aus der Cloud rausgeschickt werden. Die Cloud lohnt sich vor allem dann, wenn dein Bedarf stark schwankt. Bei gleichmäßiger Last kann der klassische Server die günstigere Wahl sein.
Die zweite: Viele hängen an wenigen. Ein großer Teil des Internets läuft bei einer Handvoll Anbietern. Wenn bei einem davon in einer Region etwas ausfällt, fallen gleichzeitig unzählige Websites und Apps aus, die sonst nichts miteinander zu tun haben. Microsoft 2012 war kein Einzelfall. Solche Ausfälle gibt es bei allen großen Anbietern, immer wieder.
Und die dritte: Der Anbieter kümmert sich um die Hardware. Aber nicht um alles. Wer in der Cloud einen Server oder einen Speicher falsch einrichtet, zum Beispiel so, dass jeder darauf zugreifen kann, der hat ein Problem. Und das ist dann nicht das Problem des Anbieters, sondern seins. Und was heißt das jetzt alles für deine Website und dein Tracking? Ich würde dir drei Dinge mitgeben.
Erstens: Wenn du Server-Side Tracking einsetzt, läuft dein Server-Container in der Cloud. Und damit gilt alles, was wir heute besprochen haben. Er skaliert mit deinem Traffic, und genau so skalieren die Kosten. Mehr Besucher, mehr Anfragen, höhere Rechnung. Lass dir deshalb vorher sagen: In welcher Region läuft das? Wie viele Server laufen mindestens, auch nachts? Und mit welchen Kosten pro Monat muss ich bei meinem Traffic rechnen?
Zweitens: Fast dein gesamter Marketing-Stack ist SaaS. Wenn also deine Zahlen in GA4 oder in deinem CRM plötzlich merkwürdig aussehen, dann muss der Fehler nicht bei dir liegen. Bevor du stundenlang dein Setup auseinandernimmst, schau auf die Statusseite des Anbieters. Fast jeder große Anbieter hat eine.
Und drittens: Wenn dir jemand eine Lösung als „cloudbasiert“ verkauft, dann ist das erst mal keine Qualitätsaussage. Es heißt nur, dass sie auf den Rechnern von jemand anderem läuft. Frag nach: Bei welchem Anbieter? In welcher Region? Und was passiert, wenn dieser Anbieter mal ausfällt?
Und wenn du nach dieser Folge eine Sache konkret machen willst, dann diese.
Schreib dir die fünf Tools auf, ohne die dein Marketing nicht funktioniert. Dein Shop-System, dein Tracking, dein CRM, deine Werbekonten, dein Newsletter-Tool. Und dann such für jedes davon die Statusseite des Anbieters raus und speicher sie dir als Lesezeichen.
Das dauert eine Viertelstunde. Aber beim nächsten Ausfall weißt du in einer Minute, ob das Problem bei dir liegt oder in der Cloud.
Und falls du dann noch einen Schritt weitergehen willst: Bevor deine Tracking-Daten überhaupt in irgendeiner Cloud ankommen, entstehen sie im Browser deines Besuchers. Dort wird entschieden, ob eine Messung losgeschickt wird, was drinsteht und wohin sie geht. Genau das schauen wir uns in meinem Kurs „Was passiert im Browser?“ an. Du lernst, diese Anfragen in den Entwicklertools deines Browsers zu lesen und Fehler selbst einzugrenzen. Damit du weißt, ob ein Problem im Browser entsteht oder erst irgendwo dahinter. Den Link findest du in den Shownotes. Und damit fassen wir einmal zusammen, was du jetzt weißt.
Die Cloud steht in Rechenzentren, mit echten Servern, die per Virtualisierung in viele virtuelle Server aufgeteilt werden. Das allein gab es auch schon vorher. Neu ist: Du holst dir diese Server selbst, in Minuten, auch automatisch über eine API. Du kannst sie nach Regeln mit deinem Bedarf wachsen und schrumpfen lassen. Und du bezahlst nach Verbrauch. Dazu kannst du statt nackter Server auch fertige Plattformen oder fertige Software mieten. Und du entscheidest, in welcher Region das Ganze läuft.
Die Cloud ist also tatsächlich der Computer von jemand anderem. Aber einer, den du dir in genau der Größe holen kannst, die du gerade brauchst. Und der auch mal an einem 29. Februar stolpert. Das war’s für heute. Mach’s gut, und bis zur nächsten Folge.