Was Prozessoren und die Frequenzwand mit der Cloud zu tun haben
Seit bald 20 Jahren werden die CPU-Kerne für Computer nicht mehr schneller. Trotzdem werden neue Prozessoren verkauft. Und der Trend geht in die Cloud. Wie das zusammenhängt.
Was Prozessoren und die Frequenzwand mit der Cloud zu tun haben
Seit bald 20 Jahren werden die CPU-Kerne für Computer nicht mehr schneller. Trotzdem werden neue Prozessoren verkauft. Und der Trend geht in die Cloud. Wie das zusammenhängt.
Im Economist erschien im September eine Grafik, die mir die Entwicklung der Prozessoren in den Computern in den 5 Jahrzehnten wieder in Erinnerung rief. Da sie hinter einer Paywall steckt, habe ich eine ähnliche Grafik gebaut, die auf denselben frei verfügbaren Daten aufbaut, die auch der Economist genutzt hat: Logarithmische Darstellung der Prozessorentwicklung, d.h. zwischen zwei Marken auf der Y-Achse steht jeweils ein Faktor 10. Wir sehen, dass ab ca. 2005 die Frequenz kaum mehr zugenommen hat, dafür die Anzahl logischer Cores («Teilprozessoren») die innerhalb eines Chips vorhanden sind. Leistung nimmt nur noch langsam zu, sowohl was die Rechenleistung eines Programmthreads betrifft als auch den Stromverbrauch. Die Entwicklung der Anzahl Transistoren liess sich vom Jahr 2005 nicht einschüchtern und wächst in unveränderter Geschwindigkeit. (Datenquelle, Inspiration, Englische Version) Es fällt sofort auf, dass die meisten Trendlinien um 2005 herum einen markanten Knick machen, abgesehen von der Transistorzahl, die ungebrochen ca. alle 7 Jahre um den Faktor 10 (eine Y-Skaleneinheit) wachsen. Was ist da passiert?
Heutige Computerchips bestehen aus Milliarden von Transistoren. Durch jeden einzelnen Transistor fliessen bei jedem Ein- oder Ausschalten Strom, um diese Änderung den nachfolgenden Transistoren mitzuteilen. (Wenn sich nichts ändert, fliesst so gut wie kein Strom. Ja, das funktioniert anders als bei den heimischen Lampen, liegt aber an der Art der eingesetzten Transistoren.)
Daraus ergibt sich auch, dass mehr Schaltvorgänge an einem Transistor auch mehr Stromverbrauch (und damit Abwärme) bedeuten. Je schneller also die Taktfrequenz eines Chips ist, desto mehr Energie verbraucht jeder Transistor. Und wenn die Transistoren sehr eng gepackt sind, dann wird dieser kleine, nur wenige mm² grosse Chip sehr schnell warm und heiss. Energie von einem kleinen Objekt wegzuführen, bevor es zu heiss wird, ist gar nicht so einfach.
Problem 2: Die Lichtgeschwindigkeit
Licht bewegt sich unheimlich schnell, im Vakuum mit rund 300’000 km pro Sekunde. Pro Sekunde also gut 7x um den Erdball oder in etwas über 8 Minuten von der rund 150 Millionen km entfernten Sonne bis zu uns. Oder etwa eine Tausendstelsekunde (Millisekunde, ms) für die knapp 300 km von St. Gallen bis Genf.
Gleich schnell bewegt sich auch ein Funksignal, sei es beim Radiosender oder beim WLAN.
Nur etwa ⅔ so schnell sind aber Signale in Brillengläsern oder Glasfasern (Grund dafür ist der Brechungsindex). D.h. auch wenn man eine Glasfaser querfeldein ohne Umweg zwischen St. Gallen und Genf verlegen würde, das Datenpaket bräuchte in der Glasfaser statt einer neu 1½ ms. (Glasfaser ist für die schnelle Internetanbindung trotzdem besser, da die einzelnen Datenbits viel, viel näher zusammengepackt werden können. Funkverbindungen sind dafür viel flexibler.)
Ein Datenpaket mit einer Anfrage von St. Gallen nach Genf ist also in frühestens 2*1½ ms = 3 ms beantwortet. Aber wir schweifen ab.
Auch in der Kupferleitung sind elektrische Impulse nur etwa 200’000 km/s schnell.
Bei den heute üblichen Taktfrequenzen von rund 2 GHz ist die Zeit zwischen zwei Takten nur ½ Nanosekunde (ns), eine halbe Millionstelsekunde. In dieser Zeit kommt ein elektrischer Impuls maximal 10 cm weit. D.h. ein Chip muss viel kleiner sein als 10 cm, um überhaupt mit 2 GHz getakten werden zu können. (Infolge vieler, z.T. hintereinandergeschalteter Transistoren und verschiedener weiterer elektrisch-physikalischer Komplikationen ist das in der Praxis nochmals weit weniger.)
Chips heute
Unter anderem aus diesen beiden Gründen werden Chips in der Praxis nicht schneller als mit 2 GHz getaktet. Wenn aber die 20 Jahre alten Chips aus 2005 gleich schnell wären wie die heutigen, würde ja niemand neue Chips kaufen.
Mehr statt schneller
Unter anderem deshalb haben die Chiphersteller vor rund 20 Jahren begonnen, zuerst 2, dann 4 und später noch mehr Recheneinheiten («Cores») auf einen Chip zu packen. Mit nur wenig mehr Fertigungskosten konnte so doppelt so viel Leistung verkauft werden.
Exkurs: Wer programmiert sowas?
Bis dahin waren sich die meisten Programmierer gewöhnt, dass der Prozessor immer ein Schritt nach dem anderen ausführte. Mit den vielen Cores konnte man aber nur schneller werden, wenn man die Aufgabe in mehrere Teilprobleme zerlegte, die dann (in sogenannten «Threads», Ablauffäden, parallel zueinander ausgeführt wurden.
Wenn die unterschiedlichen Threads auf die gleichen Daten zugreifen (und mindestens einer davon sie auch ändert), müssen sich diese Threads zuerst koordinieren («Synchronisation»). Wenn das vergessen wird, kommt es zu Programmfehlern, -abstürzen oder Sicherheitsproblemen.
Was hat das aber mit der Cloud zu tun?
Ein einzelner Nutzer und die meisten Programme können diese modernen Chips gar nicht mehr alleine auslasten. Deshalb warten sie die grösste Zeit. Das klingt aber nach Verschwendung, also versucht man das auch zu nutzen.
Dadurch kommt man dann automatisch dazu, dass man zuerst verschiedene Applikationen aus demselben Haus darauf laufen lässt. Oder später dann auch darüber nachdenkt, die brachliegende Hardware zu vermieten und auch noch über fremde Applikationen auf der eigenen Hardware nachdenkt. Und schon war die Cloud geboren.
Wir haben zu viele Transistoren pro Chip. Die Hersteller von Chips wissen nicht, was sie damit tun sollen. Du bekommst absurde Features (KI-Inferenz, Dutzende FPUs, bla) in den P-Cores, oder ganze SoC (RAM, NVME-Controller, Grafik und Inferenz-Beschleuniger) in den Consumer Chips wie bei Apple.
Wir haben daher zu viele Cores pro Socket (E-Cores -> 128-256 Cores pro Socket)
Als Kunde habe ich dadurch das Problem, daß die Dichte so groß wird, daß ich kein Bare Metal mehr fahren kann, sondern eine Layer zum Kleinschneiden der Scheiße brauche: K8s oder ein Virtualisierer.
Als Kunde habe ich dadurch ein Blast-Radius-Problem. Wenn Du ein Hobel umfällt, dann nimmt er den ganzen Laden mit.
Als Kunde will ich mich also mit mehreren Kunden zusammentun und dann nutzt jeder Kunde ein Stück von jedem Rechner, sodaß bei einem umfallenden Hoben alle Kunden ein bischen leiden, aber keiner ganz tot geht. Ich gehe also zu einem Dienstleister und miete da eine VM in passender Zahl und Größe UND brauche keine Hardware-Kundigen mehr.
Als Anbieter von so etwas kann ich den Rechner veredeln, durch Bla-as-a-Service. Als Kunde brauch ich damit keine Bla-Kundigen mehr, und kann die zusammen mit den Rechner-Hardware-Kundigen in die Hölle schicken.
Als Kunde von so einem Anbieter habe ich nun reine Entwcikler, die in komplett abstrakten Layers Dinge zusammenstecken, low-code und nahe an Business Problemen. Dadurch habe ich niemanden nirgendwo mehr, der auch nur einen Hauch einer Ahnung hat, was das alles bedeutet, lastmäßig und ob der getriebene Aufwand dem Problem angemessen ist. Ich kann einen weiteren Dienstleister wie Corey Quinn dafür bezahlen mir zu erklaren wie Scheiße ich bin.
Das Bruttosozialprodukt steigt, weil das ja jetzt alles Exchanges zwischen Firmen sind, statt innerhalb einer Firma.
Zum oben beschriebenen «Blast-Radius»-Problem: Ab 2-3 Rechnern, besser aber 4+, kann man diese übrigens so einrichten, dass bei einem Ausfall des einen seine Kollegen seine Arbeit übernehmen. Wenn es zu mehreren Ausfällen kommt und dadurch sehr knapp wird, gibt es meist irgendwelche Systeme, die nicht so wichtig sind und pausiert werden können. Dazu gehören zum Beispiel Test-Systeme, die zu viel vorgehalten werden.
Mehr zu Prozessoren
Gewisse Sicherheitsprobleme sind dadurch entstanden, dass die Prozessorhersteller die Ausführung von Code auf den Prozessoren möglichst beschleunigen mussten (und gewisse Sicherheitstests dann nicht oder zu spät erfolgen). Wie beispielsweise die ganze Familie von Spectre, Meltdown und ihren unzähligen Nachfahren:
Andere Probleme beruhen aber auf der Tatsache, dass so viele unabhängige Programme von unabhängigen Teams (oder gar unabhängigen Firmen) sich dieselbe Hardware (Prozessor, Speicher, …) teilen.
Oder auch nur ein Programm, welches nicht mit kritischen Daten arbeitet (und deshalb weniger Sicherheitschecks bekommen hat) mit einem anderen Programm auf der gleichen Hardware arbeiten muss.
Christos Kozyrakis, Aman Kansal, Sriram Sankar, Kushagra Vaid: Server Engineering Insights for Large-Scale Online Services (PDF, local copy), IEEE Micro, July/August 2010. Die älteste Kopie der ursprünglichen Grafik, den ich finden konnte. Enthält auch Einblicke in die Interaktion zwischen Prozessoren, Rechenzentren und einigen grossen Applikationen wie Hotmail und Bing.
Karl Rupp: Microprocessor Trend Data, GitHub, lebendes Repository (letztes Update: 2022-02-22). Die Daten plus die Plotwerkzeuge, zusammen mit den erzeugten Grafiken. Auf dieser Version beruht meine Grafik.
Ich hatte das Gefühl, dass der automatische Upload auf Android unzuverlässig sei, konnte das aber nicht richtig festmachen. Jetzt weiss ich wieso und was dabei hilft.
Die Revision der «Verordnung über die Überwachung des Post- und Fernmeldeverkehrs» (VÜPF) schreckte die Schweiz spät auf. Am Wochenende publizierte die NZZ ein Streitgespräch zum VÜPF. Darin findet sich vor allem ein Absatz des VÜPF-Verschärfungs-Befürworters… VÜPF: Staatliche Überwachungsfantasien im Realitätscheck weiterlesen
Spam und Phishingversuche auf Schweizerdeutsch scheinen beliebter zu werden. Wieso nutzen Spammer denn diese Nischensprache? Schauen wir in dieser kleinen Weiterbildung in Sachen Spam und Phishing zuerst hinter die Kulissen der Betrüger, um ihre Methoden… Phishing-Trend Schweizerdeutsch weiterlesen
Meta – Zuckerbergs Imperium hinter Facebook, WhatsApp, Instagram, Threads etc. – hat angekündigt, ab 27. Mai die persönlichen Daten seiner Nutzer:innen in Europa für KI-Training zu verwenden. Dazu gehören alle Beiträge (auch die zutiefst persönlichen),… Persönliche Daten für Facebook-KI weiterlesen
Bert Hubert, niederländischer Internetpionier und Hansdampf-in-allen-Gassen, hat einen grossartigen Artikel geschrieben, in dem er die Verwirrung rund um «in die Cloud gehen» auflöst. Ich habe ihn für DNIP auf Deutsch übersetzt.
Vor ein paar Wochen hat die NZZ einen Artikel veröffentlicht, in dem Petra Gössi das NZZ-Team erschreckte, weil via KI-Chatbot angeblich «beinahe der gesamte Inhalt des Artikels […] in der Antwort von Perplexity zu lesen»… Können KI-Systeme Artikel klauen? weiterlesen
Seit bald 20 Jahren werden die CPU-Kerne für Computer nicht mehr schneller. Trotzdem werden neue Prozessoren verkauft. Und der Trend geht in die Cloud. Wie das zusammenhängt. Im Economist erschien im September eine Grafik, die mir… Was Prozessoren und die Frequenzwand mit der Cloud zu tun haben weiterlesen
«Täderlät» die KI? Vor ein paar Wochen fragte mich jemand besorgt, ob man denn gar nichts in Chatbot-Fenster eingeben könne, was man nicht auch öffentlich teilen würde. Während der Erklärung fiel mir auf, dass ganz… Was verraten KI-Chatbots? weiterlesen
Wir kennen «1984» nicht, weil es eine technische, objektive Abhandlung war. Wir erinnern uns, weil es eine packende, düstere, verstörende Erzählung ist.
In der EU wird seit vergangenem Mittwoch wieder über die sogenannte «Chatkontrolle» verhandelt. Worum geht es da? Und welche Auswirkungen hat das auf die Schweiz?
In den 1½ Wochen seit Publikation der ersten beiden Teile hat sich einiges getan. Microsoft liess es sich nicht nehmen, die Schuld am Vorfall der EU in die Schuhe zu schieben, wie das Apple mit… CrowdStrike, die Dritte weiterlesen
Ich habe die letzten Wochen viele Informationen zu CrowdStrike zusammengetragen und bei DNIP veröffentlicht. Hier ein paar Punkte, die bei DNIP nicht gepasst hätten. Einiges davon ist sinnvolles Hintergrundwissen, einiges taugt eher als Anekdote für… Unnützes Wissen zu CrowdStrike weiterlesen
Beim Pendeln hatte ich viel Zeit. Auch um Mails aus dem Spamordner zu lesen. Hier ein paar Dinge, die man daraus lernen kann. Um sich und sein Umfeld zu schützen.
Die andauernden CookieBanner nerven. Aber noch viel mehr nervt es, wenn in der Liste von „800 sorgfältig ausgewählten Werbepartnern (oder so)“ einige Schalter fix auf „diese Werbe-/Datenmarketingplattform darf immer Cookies setzen, so sehr ihr euch… Die NZZ liefert Daten an Microsoft — und Nein sagen ist nicht weiterlesen
Am Freitag standen in weiten Teilen der Welt Millionen von Windows-Rechnern still: Bancomaten, Lebensmittelgeschäfte, Flughäfen, Spitäler uvam. waren lahmgelegt. Die Schweiz blieb weitgehend nur verschont, weil sie noch schlief. Ich schaue hinter die Kulissen und… «CrowdStrike»: Ausfälle verstehen und vermeiden weiterlesen
Ich habe bisher immer Firefox empfohlen, weil seine Standardeinstellungen aus Sicht der Privatsphäre sehr gut waren, im Vergleich zu den anderen „grossen Browsern“. Das hat sich geändert. Leider. Was wir jetzt tun sollten.
Letzten August fand an der Hackerkonferenz DEFCON eine Veranstaltung der Election Integrity Foundation statt. Sie fasste mit einem hochkarätigen Podium wesentliche Kritikpunkte rund um eVoting zusammen.
Ich habe vor Kurzem das Buch «QualityLand» von Marc-Uwe Kling von 2017 in meinem Büchergestell gefunden. Und war erstaunt, wie akkurat es die Gegenwart erklärt. Eine Leseempfehlung.
Vor 50 Jahren erfand Ken Thompson die «unentdeckbare Sicherheitslücke». Vor gut 40 Jahren präsentierte er sie als Vortrag unter dem Titel «Reflections on Trusting Trust» anlässlich der Verleihung des Turing-Awards, des «Nobelpreises der Informatik». Hier… 50 Jahre «unentdeckbare Sicherheitslücke» weiterlesen
Eines der Argumente für eVoting ist die Erhöhung der Stimmbeteiligung. Stimmbeteiligung—nur für sich alleine gesehen—ist keine ausreichende Metrik für die Beurteilung der Funktionsfähigkeit einer Demokratie, trotzdem spielt sie eine wichtige Rolle. Die «Vote électronique», wie… Stimmbeteiligung erhöhen ohne eVoting weiterlesen
Die Demokratie ist unter Beschuss, neuerdings auch durch Fake News, Trollfabriken und KI. «Vote éléctronique», so heisst die elektronische Abstimmung im Bundesjargon, ist angetreten, um die Demokratie zu retten. Am Mittwochabend geht Marcel Waldvogel der… 🧑🏫 «eVoting: Rettung der Demokratie oder Todesstoss?» weiterlesen
Ich habe versucht, dem mutmasslich grössten Hack der Geschichte etwas auf den Grund zu gehen. Daraus ist eine spannende Spurensuche geworden, die ich gerne mit euch teilen möchte.
Aktuell laufen wieder Spamwellen durchs Land. Eine bot einen angeblichen Schweizer Bitcoin-ETF an, mit zuverlässiger Firma und offizieller Zulassung dahinter. Doch schon nach wenigen Klicks war klar: Da stimmt ganz vieles nicht.
Huch, waren das spannende Ostern, aus IT-Sicht! Es wurde die potenziell schlimmste IT-Sicherheitskatastrophe durch puren Zufall noch rechtzeitig abgewendet. Ansonsten hätte ein Angreifer Millionen von Servern weltweit im Nu unter seine Kontrolle bringen können.
Heute in 14 Jahren endet die Zeit, so wie sie noch viele Computer kennen. Vor allem Computer, die in anderen Geräten eingebaut sind (vom Backofen bis zur Heizungssteuerung) dürften davon betroffen sein.
Computer sind geprägt von Limiten: Maximale Textlängen, maximale Zahlengrössen. Nicht erstaunlich, wenn man ihre Vorfahren kennt, die Kästchenfelder und Milchbüchlein mit einer eigenen Spalte für jede Ziffer.
The rapid growth of online services in the last decade has led to the development of large data centers to host these workloads. These large-scale online, user-facing services have unique engineering and capacity provisioning design requirements.
Rein vom Vergleich “Cores” vs. “Cores” oder “RAM” vs, “RAM” ist zum Beispiel EC2 etwa 6x teurer als B’s eigenes RZ (Preise von 2019) gewesen. Wenn es Datenbank-Instanzen sind, ist Cloud 10x teurer als RDS gewesen.
Allerdings hatte B auch einen Stab von Leuten, die deren Bare Metal in eine programmierbare Bare Metal Cloud mit API umgewandelt haben und die Verwaltung dieser Rechner automatisiert haben. So etwas kann man offenbar als Produkt nicht kaufen, schon gar nicht hersteller-unabhängig.
Das heißt, Du mußt die Gehälter von core.infra bei B auf den B- Preis drauf schlagen, siehe Preise bei levels.fyi.
12-18 Leute in DBA Team (für knapp 10k Datenbank-Instanzen, keine Caches, weil ein Host ein Host ist und es gleich teuer ist, da memcached oder eine Datenbank drauf zu klatschen).
Am Ende hat sich B für Cloud entscheiden, weil Operations dann jemand anderes Problem ist und sie nicht nur die Leute los sind als Personal, sondern auch das Staffing. Das war ein totaler No-Brainer, selbst bei 10x.
Hardware Kosten
Preise für eine Dell oder HP Blade mit 2x Xeon Silber 4110, 128 GB RAM, 1.92 TB Micron (800k IOPS) und 10 GBit/s Interface zu einem Leaf-and-Spine Fabric ohne Oversubscription: 120 Euro/Monat incl. Abschreibung, Betriebskosten, RZ-Space und Netzwerkanteil, gerechnet auf 5 Jahre. 150 Euro/Monat bei größerer Platte. Das alles aber ohne Personal, das kommt kostenmäßig noch oben drauf.
Auch oben drauf kommt der Aufwand, dieses Personal zu finden und zu halten, und so zu steuern, daß die was sinnvolles bauen. Das sind nicht notwendig Geldkosten, aber es ist Load auf der Org.
Allgemeiner gesagt
Damit Du eine Firma haben kannst, die in 2024 eigene Hardware am Laufen hat, hast Du die folgenden Probleme zu lösen:
Du mußt groß genug sein, damit Du mit Deinem Laden genug Rechner voll machst.
Idealerweise kauft man aus Kostengründen immer die zweigrößte Sorte Rechner, die es gibt (man kann das genau ausrechnen, aber man landet immer bei der zweitgrößten oder drittgrößten CPU).
Das ist heute also irgendwas mit einem oder gar zwei Sockets, und dann circa 128 Cores mal Hyperthreading pro Socket. Das muß balanced sein, das heißt RAM und Netz müssen zu den Cores passen. Meist ist es 4 GB oder 8 GB pro Core und 100 MBit/s bis 300 MBit/s pro Core.
Wir landen bei 128 GB * 8 =1.024 GB und bei 128 * 200 MBit/s =25.600 Mbit/s = 25 GBit/s für eine Ein-Socket EPYC oder ähnlich und bei dem doppelten für den Dual-Socket-Eimer.
Du kannnst Java-Enterprise-Dreck in der Regel auf 8 Cores und 16 GB RAM skalieren, danach haucht eine JVM ihr Leben aus, genauer gesagt verreckt der Garbage Collector. Sind also 16-32 Instanzen (Anwendungen) pro Socket.
Du willst aus HA-Gründen natürlich nicht eine Kiste haben, auch wenn Deine ganze Firma auf eine solche Kiste paßt, sondern so 3 oder mehr.
Das heißt aber, daß Du weit mehr Kisten hast als Dein Laden braucht – nicht, daß das sehr teuer wäre, aber Firmen wollen ja “sparen”.
In einer Public Cloud kriegst Du VMs in der notwendigen Größe (8 Cores, 16 GB, …) nach Wunsch und Bedarf gemietet, UND sie werden antiaffin gescheduled, laufen also auf unterschiedlichen Hosts in unterschiedlichen Racks.
Dadurch geht Dir bei einer Störung die kleiner als ein RZ ist eine Instanz verloren (und vielen anderen Kunden auch) statt einem Kunden alle Instanzen (weil sie im selben Rack oder auf demselben Host waren).
Klingt erst mal verlockend.
On Premises hast Du jetzt 3 Rechner in drei ansonsten weitgehend leeren Racks, und jetzt brauchst Du einen Hypervisor, um das Ding in brauchbare Scheiben zu schneiden.
Du hast die Wahl zwischen VMware und Openstack, also lebenslanger Schuldknechtschaft oder drei Spezialisten, die das Openstack für Dich fahren.
Nun kannst Du VMs provisionieren.
Aber Du hast noch keine Dienste – keine Datenbank, keine Event Queue, kein Mail, keinen Kalender, keinen Fileserver, und was immer Deine Butze sonst noch so braucht.
Du hast also die Wahl, erschreckend kostengünstige Hardware, die viel zu groß für alles ist zu kaufen und dann Leute zu finden und anzustellen, die dann vielleicht in der Lage sind oder vielleicht nicht, daraus eine brauchbare Plattform zu bauen, oder lebenslang dem Bezos Kohle in den Rachen zu schaufeln.
Die Antwort ist für wirklich jede Firma mit weniger als einer dreistelligen Anzahl von Rechnern absolut offensichtlich und besteht nicht darin, Hardware zu kaufen – das Staffing, die lokale Betriebs-Entwicklung und den ganzen Kram will sich niemand ans Bein binden.
Du findest in der Folge inzwischen auch keine Leute mehr, die so etwas verstehen oder machen können. Du findest aber für 60k-75k im Jahr Dutzende von Leuten, die Dir Instanzen mit Diensten bei AWS klicken können.
Die ganze Logik-Kaskade:
Wir haben zu viele Transistoren pro Chip. Die Hersteller von Chips wissen nicht, was sie damit tun sollen. Du bekommst absurde Features (KI-Inferenz, Dutzende FPUs, bla) in den P-Cores, oder ganze SoC (RAM, NVME-Controller, Grafik und Inferenz-Beschleuniger) in den Consumer Chips wie bei Apple.
Wir haben daher zu viele Cores pro Socket (E-Cores -> 128-256 Cores pro Socket)
Als Kunde habe ich dadurch das Problem, daß die Dichte so groß wird, daß ich kein Bare Metal mehr fahren kann, sondern eine Layer zum Kleinschneiden der Scheiße brauche: K8s oder ein Virtualisierer.
Als Kunde habe ich dadurch ein Blast-Radius-Problem. Wenn Du ein Hobel umfällt, dann nimmt er den ganzen Laden mit.
Als Kunde will ich mich also mit mehreren Kunden zusammentun und dann nutzt jeder Kunde ein Stück von jedem Rechner, sodaß bei einem umfallenden Hoben alle Kunden ein bischen leiden, aber keiner ganz tot geht. Ich gehe also zu einem Dienstleister und miete da eine VM in passender Zahl und Größe UND brauche keine Hardware-Kundigen mehr.
Als Anbieter von so etwas kann ich den Rechner veredeln, durch Bla-as-a-Service. Als Kunde brauch ich damit keine Bla-Kundigen mehr, und kann die zusammen mit den Rechner-Hardware-Kundigen in die Hölle schicken.
Als Kunde von so einem Anbieter habe ich nun reine Entwcikler, die in komplett abstrakten Layers Dinge zusammenstecken, low-code und nahe an Business Problemen. Dadurch habe ich niemanden nirgendwo mehr, der auch nur einen Hauch einer Ahnung hat, was das alles bedeutet, lastmäßig und ob der getriebene Aufwand dem Problem angemessen ist. Ich kann einen weiteren Dienstleister wie Corey Quinn dafür bezahlen mir zu erklaren wie Scheiße ich bin.
Das Bruttosozialprodukt steigt, weil das ja jetzt alles Exchanges zwischen Firmen sind, statt innerhalb einer Firma.
Und am Ende spielen die Kosten im Vergleich keine Rolle mehr, weil andere, größere Vektoren auf die Firmen einwirken.
Regulierungsverpflichtungen kommen ja noch oben drauf.
