Nachhaltige Web-Architektur

Lucas: Hallo und herzlich Willkommen zu einer neuen Folge des INNOQ Podcasts. Heute wollen wir über nachhaltige Web Architektur sprechen und dafür habe ich mir den Daniel eingeladen. Hallo Daniel.

Daniel: Hallo Lucas.

Lucas: Daniel ist Senior Consultant bei INNOQ und die Leute, die vielleicht schon ein bisschen länger den Podcast hören, haben ihn auch schon beim Podcast gehört. Da haben wir nämlich schon mal über Nachhaltigkeit gesprochen. Magst du noch mal ganz kurz zusammenfassen, was wir damals in der Folge da besprochen haben?

Daniel: Ja, in dieser ersten Folge zu ökologisch nachhaltiger Softwareentwicklung haben wir im Prinzip eine Einführung in das Thema gegeben und die Prinzipien nachhaltiger Softwareentwicklung vorgestellt und auch mit ein paar Beispielen gezeigt, was das in der Praxis bedeuten kann. Und das sollte auch ein bisschen als Inspiration dienen, sich mal überhaupt mit dem Thema Green IT zu beschäftigen.

Lucas: Genau. Wir werden natürlich die Folge nochmal in den Shownotes verlinken. Die könnt ihr euch gerne noch mal anschauen oder auch durchlesen. Es gibt auch ein Transkript. Aber heute wollen wir uns ein bisschen fokussieren auf die Frage Web Architektur. Ich glaube das ist bei uns beiden das gleiche, dass wir eigentlich immer nur Webanwendungen bauen.

Daniel: Ja, es gibt eigentlich gar nichts anderes, oder?

Lucas: Genau. Ich würde fast sagen, das stimmt, außer man ist irgendwo im Automobilbereich oder so was. Aber unser Alltag besteht aus Web und wir sind beide sowohl in der Entwicklung als auch in der Architektur. Und da haben wir uns ein bisschen die Frage gestellt: Welchen Einfluss hat denn Nachhaltigkeit auf unsere Entscheidungen, die wir bei der Architektur von Webseiten oder Webanwendungen haben?

Daniel: Und auch, welche Konflikte es gibt mit anderen Architekturzielen und wo sich vielleicht ökologische Nachhaltigkeit auch mit anderen Zielen gut vereinbaren lässt, ist auch die Frage.

Lucas: Und das ist eben ein Thema. Was uns immer wieder begegnet, sind die Qualitätsziele, die eine Architektur hat. Da gibt es ganz verschiedene, da können wir gerne gleich auch noch mal drauf eingehen. Und die gilt es immer ein bisschen gegeneinander abzuwägen, weil das nicht immer so ist, dass alle davon erfüllt werden können. Aber manchmal ergänzen sie sich auch ganz gut und da wollen wir uns heute ein bisschen mit beschäftigen. Was sind denn noch mal Qualitätsziele? Und kannst du auch ein paar Beispiele für Qualitätsziele geben?

Daniel: Ja, ideal ist es natürlich, wenn eine Architekturentscheidung eben nicht einfach aus dem Bauch heraus getroffen wird, sondern aus dem Grund, dass sie auf ein oder mehrere dieser sogenannten Qualitätsziele einzahlen. Das sind Ziele, die von den Stakeholdern definiert und auch priorisiert werden in der Regel. Und Beispiele könnten sein: Performance, Kosteneffizienz, Wartbarkeit der Software, Verfügbarkeit, Anpassbarkeit, Datensicherheit oder auch Accessibility. Und oft muss man bei einer Architekturentscheidung abwägen, wie du schon gesagt hast, weil sie sich vielleicht positiv auf das Erreichen eines Ziels auswirkt aber zu Lasten eines anderen geht, das vielleicht den Stakeholdern genauso wichtig ist oder fast genauso wichtig.

Lucas: Und bei den Zielen. Das ist auch nicht nur in der Softwarearchitektur so, sondern allgemein ist es immer schön, ein Ziel zu haben. Aber die Frage, die sich dann immer stellt, ist: Habe ich das Ziel jetzt erreicht oder muss ich vielleicht noch mehr investieren? Kannst du dir vorstellen, wie man das eventuell mit dem Thema Nachhaltigkeit macht? Wie macht man das messbar?

Daniel: Ja, ökologische Nachhaltigkeit als Qualitätssiegel ist erst mal sehr allgemein gehalten, sehr breit. Vielleicht muss man es auch einfach ein bisschen enger definieren und sagen: Mein Ziel ist Carbon Effizienz zum Beispiel, also die Minimierung von Emissionen, von CO2 Äquivalenten, die durch den Betrieb und die Nutzung der Webanwendungen entstehen. Weil ökologische Nachhaltigkeit umfasst eigentlich noch viel mehr. Man könnte sich auch den Wasserverbrauch anschauen. Das wird auch von manchen Rechenzentren tatsächlich schon gemacht, dass sie auch dort versuchen, den zu minimieren. Carbon Effizienz ist aber das, was man am ehesten noch überhaupt messen kann. Da hatten wir in der vorherigen Folge auch schon ein bisschen was dazu gesagt. Das geht durch Netzwerkeffizienz. Je mehr Daten ich übertrage, desto weniger CO2 Emissionen verursache ich, aber natürlich auch je mehr Rechenoperationen ich zum Beispiel auf meinem Server bei einer Webanwendung durchführen muss, desto mehr Emissionen verursache ich auch.

Lucas: Und das ist das Interessante, auf das wir gleich noch mal zurück kommen. Es ist schon so, dass irgendwie weniger Daten zu übertragen und weniger CPU Load zu haben erst mal sich gut mit vielen Zielen vertragen. Aber wir werden auch gleich noch mal Punkte sehen, wo das vielleicht dann auch nicht der Fall ist, aber da kommen wir gleich darauf zurück. Bevor wir darauf eingehen, würde ich gerne noch mal auf die Frage eingehen: Siehst du das denn eigentlich auch in Projekten, dass sich die Kunden mit diesem Thema beschäftigen, dass wir das als Qualitätssiegel auf dem Schirm haben? Oder ist das eher was, was du nicht siehst?

Daniel: Leider sehe ich das bisher eigentlich gar nicht in unseren Projekten. Ich vermute mal, dass es vielen nicht bewusst ist, dass man, wenn man es wirklich drauf anlegt, die Carbon Effizienz einer Webanwendung auch deutlich optimieren kann im Vergleich zu dem, was vielleicht so eine durchschnittliche Webanwendung heute an Emissionen verursacht. Es gibt durchaus Firmen oder auch Organisationen, denen ökologische Nachhaltigkeit generell wichtig ist, die das auch umsetzen in Webanwendungen. In meinen Projekten habe ich das noch nicht gesehen. Selbst bei Kunden, wo man vielleicht sieht, dass sie eine grundsätzlich ökologische Nachhaltigkeit anstreben in ihren Produkten, haben die das eher weniger auf dem Schirm. Das heißt, dass man das im Prinzip nur durch Zufall erreichen kann. Carbon Effizienz. Du hast eben schon angedeutet, dass manche andere Qualitätsziele ganz gut damit harmonieren. Und manche Maßnahmen zahlen auf bestimmte andere Ziele ein und dann genauso auch auf die Carbon Effizienz.

Lucas: Das ist auch meine Beobachtung, wenn es um das Thema ging, dass ich auch merke, dass ich selbst hauptsächlich über die Performance schiele, darüber argumentiere, einfach versuche, diese Ziele zu erreichen, indem ich mit den Leuten darüber sprechen, dass bestimmte Sachen vielleicht einfach nicht performant sind. Insbesondere beim Daten übertragen klappt das sehr gut. Dann ist es eigentlich immer so, dass Datenvolumen sparen auch gleichzeitig eine positive Auswirkung auf Carbon Effizienz hat.

Daniel: Ja, das Problem ist natürlich, wenn jetzt Carbon Effizienz ein explizites und auch vom Stakeholder priorisiertes Qualitätsziel ist, dann muss es eigentlich irgendwo zwangsläufig den Kürzeren ziehen, weil es oft natürlich auch Maßnahmen gibt, die auf bestimmte andere Ziele einzahlen, sich aber dann sogar negativ auf die Carbon Effizienz auswirken. Und nur wenn ich die Carbon Effizienz als explizites Qualitätsziel habe. Dann kann ich es auch wirklich bei Architekturentscheidungen berücksichtigen. Und dann fällt man vielleicht eine bestimmte Architekturentscheidung so, dass sie eine bessere Carbon Effizienz bedeutet als Konsequenz. Oder aber man entscheidet sich dagegen und fällt eine Entscheidung auf Kosten der Carbon Effizienz. Aber dann hat man sich diesen Trade off auf jeden Fall bewusst gemacht, anstatt dass man es überhaupt nicht berücksichtigt.

Lucas: Dann lass uns doch direkt erst mal mit dem Thema Performance anfangen. Uns geht es jetzt ein bisschen darum zu prüfen, an welchen Stellen diese Ziele miteinander harmonieren und an welchen Stellen sie vielleicht nicht miteinander harmonieren. Ich glaube, bei der Performance gibt es erst mal viele Sachen, die gut zusammenpassen. Wenn ich zum Beispiel versuche zu cachen, vermeide ich Requests, vermeide ich Responses und vielleicht vermeide ich sogar Rechenzeit, weil ich eine Response gar nicht erst berechnen muss. Bei der Kompression übertrage ich weniger Daten. Das ist gut für die Schnelligkeit der Webseite. Das ist aber auch super für die Carbon Effizienz, weil ich weniger Daten übertragen habe. Genauso versuche ich meine Webseite so zu bauen, dass die Bilder, die ich ausliefere und auch vielleicht die Videos, die ich ausliefere, so groß sind, dass sie eben dazu passen und nicht zu groß. Responsive Images ist da das Thema. So passt das wirklich eins zu eins zusammen. Das können wir uns alle, glaube ich, gut vorstellen. Genauso wäre das, wenn man einen besseren Algorithmus findet, der schneller funktioniert, als der Algorithmus, den ich mir eigentlich ausgedacht habe. Aber wo siehst du denn da vielleicht auch Konflikte zwischen der Performance als Ziel und der Carbon Effizienz als Ziel?

Daniel: Ja, zunächst einmal zur Kompression: Da hast du wahrscheinlich in der Regel recht. Aber es gibt durchaus auch Bildformate, die sehr stark komprimieren, die dann aber viel Rechenleistung wieder brauchen, um es zu dekomprimieren und das Bild vernünftig zu rendern zum Beispiel. Das ist also nicht immer sichergestellt, dass es hier harmoniert. Aber meistens ist das glaube ich schon der Fall heutzutage. WebP ist glaube ich in der Hinsicht mittlerweile ziemlich gut aufgestellt zum Beispiel.

Lucas: Ja, definitiv.

Daniel: Ansonsten, ein Beispiel wäre aber, wo das im Konflikt stehen kann, sind schnelle Antworten, die man erreicht, indem man viele Ressourcen einsetzt. Ich verbessere dadurch die Performance, dass ich zum Beispiel mehrere Knoten einer verteilten Datenbankanfrage und dann die am schnellsten gelieferte Antwort verwende. Es ist eine Möglichkeit, sich eine bessere Performance zu erkaufen durch eine schlechtere Carbon Effizienz und auf eine schlechtere Kosteneffizienz natürlich. Ein anderes Beispiel sind CDNs, Content Delivery Networks. Da ist es ein bisschen unklar. Auf der einen Seite ist das eine Form von Shared Hosting, weil die Knoten von vielen verschiedenen Anwendungen geteilt werden, die auf diesen Knoten ihre Daten liegen haben. Auf der anderen Seite verteilen wir eine Anwendung oder ihre Daten auf ganz viele Knoten, die auf der ganzen Welt verteilt ist. Und oft kann es schon sein, dass ein Großteil davon aber nie Traffic bekommen wird, weil vielleicht die meisten Menschen, die unsere Anwendung aufrufen, aus Europa kommen, zum Beispiel. Hier spielt aber auch die Update Frequenz dieser Webanwendung eine Rolle. Es macht natürlich einen Unterschied, ob ich so eine Webanwendungen jetzt einmal pro Woche aktualisiere und dann die Daten auf alle diese CDN Knoten repliziere. Oder ob das vielleicht hunderte Male pro Tag geschieht und dann vielleicht ganz viele dieser Updates ausgespielt werden, aber nie aufgerufen werden. Das kann auch passieren.

Lucas: Ja, eine Sache, die mir da auch auf jeden Fall noch einfällt, wäre die Frage, ob es nicht auch deswegen sinnvoll sein kann, CDNs zu verwenden aus Carbon Effizienzgründen, weil dann die Daten einen viel kürzeren Weg übertragen werden. Wenn ich jetzt das Bild nicht von Europa nach Australien schicke, sondern von Australien nach Australien, dann ist da auch wesentlich weniger Energie, die dafür benötigt wird, die Daten zu transportieren, oder?

Daniel: Genau, wenn ich viele Leute habe, die aus Australien die Anwendungen aufrufen, dann lohnt es sich natürlich, dass die Daten auch in Australien in den CDN Knoten liegen. Wenn das aber nicht der Fall ist, dann war schon die Übertragung auf diesen australischen Knoten eigentlich Verschwendung. Allerdings ist die Frage, ob das so einen großen Unterschied ausmacht. Wir sprechen in der Regel von ein paar Dutzend Knoten in so einem CDN. Und wenn man es jetzt mal vergleicht mit der Anzahl der Aufrufe, die man aus verschiedenen Regionen der Welt vielleicht hat, sollte sich das in der Regel eigentlich schon schnell rentieren.

Lucas: Ich glaube, was ich ein bisschen in Frage stellen würde, ist, wenn man jetzt beispielsweise ein deutschsprachiges Webangebot hat. Ob es sich dann lohnt, ein globales CDN zu verwenden? Ich kenne das von den CDN Anbietern, die ich bisher benutzt habe nicht, dass man irgendwie sagen kann: Bitte spiele das jetzt nur in Europa aus oder so. Das wäre dann vielleicht sinnvoll, weil die Wahrscheinlichkeit, dass dann jemand aus Australien darauf zugreift, ziemlich gering ist. Aber das wäre vielleicht auch eine Option.

Daniel: Ja, das kenne ich leider auch nicht. Das würde ich mir eigentlich auch wünschen. Es gibt schon viele Arten von Anwendungen, wo eigentlich klar ist, dass die nur aus bestimmten Regionen aufgerufen werden oder dass es sehr wahrscheinlich ist. Sagen wir mal Behördenanwendungen oder sowas.

Lucas: Ja, da gibt es dann immer noch irgendwie der unter 1% Fall, wo dann wirklich jemand aus dem Urlaub oder vielleicht ist es ein Mensch, der ausgewandert ist oder was auch immer, der dann vielleicht darauf zugreifen muss, dass man wegen dieser einen Person dann tatsächlich ein bisschen länger warten muss, ist es vielleicht gar nicht so schlimm. Das wäre die Frage, die man sich da stellen muss. Aber zumindest die Sachen, die ich bisher benutzt habe, da gab es jetzt ein Regionenwähler, was eigentlich auch aus der Sicht des CDN Anbieters auch Sinn ergeben würde, weil die sparen sich auch was, wenn die einfach nur Ressourcen dahin legen, ohne dass es jemand benutzt.

Daniel: Ja, das ist auch nicht immer so, dass ich eine Anwendung, wenn ich sie neu deploye automatisch in einen CDN Knoten repliziere. Das passiert bei Architekturmodellen, wo alles im CDN liegt. Aber wenn ich noch ein Origin Server habe, dann ist es eigentlich sowieso lazy. Also wenn jemand die Anwendung aufruft, das erste Mal eine bestimmte URL aufruft, dann landet sie im HTTP Cache des CDN. Aber dann ist es meines Wissens so, dass in allen Knoten dann landen wird. Schlau wäre es vielleicht, wenn die Anwendung aufgerufen wird aus Deutschland, dass sie dann nur in den deutschen Cache Knoten auch landet. Aber ich vermute mal, das ist nicht der Fall.

Lucas: Ich vermute, dass da auch Optimierungen im CDD passieren, die wir als Nutzer und Nutzerinnen gar nicht richtig mitbekommen. Es kann sein, dass sich wirklich jede kleine Homepage auf allen CDN Locations nachher ausgespielt wird. Da wäre vielleicht auch ein bisschen Transparenz gar nicht so schlecht.

Daniel: Ja, das stimmt.

Lucas: Okay. Gut. Das ist das Thema Performance. Anderes Qualitätsziel ist das Thema Verfügbarkeit. Wenn ich jetzt dafür sorgen möchte, dass meine Seite immer erreichbar ist. Welchen Einfluss hat das denn auf meine Carbon Effizienz?

Daniel: Grundsätzlich verträgt sich das Ziel der Verfügbarkeit nicht so gut mit Carbon Effizienz, weil man generell eine hohe Verfügbarkeit meist durch Redundanz erreicht. Am Beispiel eines Webservers, selbst wenn ich jetzt mit einem einzelnen Server vielleicht auch bei Lastspitze problemlos alle Requests meiner Anwendung angemessen schnell beantworten kann, dann haben wir in der Regel mindestens zwei Webserver, damit beim Ausfall eines Servers noch ein anderer verfügbar ist. Oder bei einer verteilten Datenmenge ist es oft so, dass selbst wenn die Datenmenge, die wir speichern, auf einen Knoten passen würde, dann haben wir mindestens zwei Knoten in dieser Datenbank, in der Regel sogar drei, damit wir bei Netzwerkpartitionen noch diese Quorum-Fähigkeit beibehalten. Und wenn dann ein Knoten ausfällt, dann können die Daten von einem anderen Knoten ausgeliefert werden. Oder vielleicht eine veraltete Version der Daten, je nachdem was für eine Art von verteilter Datenbank das ist. Und diese Redundanz heißt natürlich eine schlechtere Energieeffizienz und damit natürlich auch eine schlechte Carbon Effizienz.

Lucas: Aber das Problem ist tatsächlich auch, dass selbst wenn es jetzt nicht um Ausfallsicherheit geht, geht es auch um die Frage: wie geht man mit Lastspitzen um? Wie sorgt man dafür, dass sagen wir jetzt mal, ich habe eine Webanwendung, die vor allem zu Geschäftszeiten verwendet wird, von morgens 7:00 bis abends 19:00 Uhr, aber außerhalb davon sehr wenig benutzt wird. Wie geht man mit der Menge der Hardware um, die man da zur Verfügung stellt? Das steht ein bisschen im Konflikt.

Daniel: Ja, das stimmt.

Lucas: Da ist dann immer die Frage, wie voraussehbar ist das? Gibt es Lastspitzen, die keiner voraussehen kann? Ich denke jetzt mal an einen Blog. Bei dem Blog ist es jetzt so, dass irgendeiner von diesen Blogposts bei Hacker News auf Platz 1 gelandet ist, auf einmal die Lastspitze kommt, die keiner erwartet hat.

Daniel: Ja, das stimmt. Auf das Thema werden wir uns, glaube ich, auch gleich noch mal, wenn es um die Kosteneffizienz geht, noch mal zurück kommen. Da geht es so ein bisschen Richtung Autoscaling. Wenn man jetzt kein Autoscaling macht, dann ist es in der Regel so, dass man im Grunde überprovisioniert, damit man verfügbar bleibt. Weil man eben sonst, wenn man einen Server jetzt vielleicht verliert und man hat nicht überprovisioniert, dann ist man zwar irgendwie noch verfügbar. Aber dann gehen alle Requests auf diese verbleibenden Server und für die wird die Last dann auch zu groß.

Lucas: Ich meine, das ist wirklich kein triviales Problem. Da muss man sich schon dann Gedanken darüber machen, wie man damit umgeht, dass man angemessen große Server hat. Da kommen wir beim Kostenteil noch mal drauf zurück. Aber das ist auf jeden Fall nicht einfach. Eine Frage, die mich auch ein bisschen beschäftigt hat in letzter Zeit, ist auch die Frage der Erwartungshaltung. Irgendwie ist es heutzutage so, dass in den Diskussionen über Verfügbarkeit man irgendwie über die Anzahl der Neunen redet. Es geht darum, dass man irgendwie 99, wie viele 9 % der Zeit verfügbar ist. Bei GitHub gibt es dann irgendwelche Reports, wie viel Verfügbarkeit hatten wir und so weiter und so fort. Und da frage ich mich auch, wie zeitgemäß das ist, diese Idee davon, dass wir alle unsere Anwendungen immer 100% verfügbar sein müssen. Ich glaube, diese Erwartungshaltung sollte man vielleicht auch noch mal in Frage stellen.

Daniel: Die ist nicht kompatibel mit dem Qualitätsziel der Carbon Effizienz. Weil ab einem bestimmten Verfügbarkeitslevel kann man das eigentlich nur noch sicherstellen, wenn man zu bestimmten Zeiten auch eine sehr hohe Carbon Intensität akzeptiert. Sei es nachts, wenn keine Sonne mehr scheint und besonders viel Kohle verstromt wird oder so.

Lucas: Absolut.

Daniel: Da gibt es durchaus auch Seiten, die das dann wirklich sagen: Jetzt sind wir nicht mehr verfügbar, weil die Carbon Effizienz zu hoch ist. Oder sie schränken halt ihre Funktionalität so ein, dass sie zum Beispiel weniger Daten übertragen. Das hatten wir in der ersten Folge auch schon mal kurz besprochen.

Lucas: Da hatten wir ein paar Beispiele dafür für Shops und so weiter, auch solarbetrieben. Da würde ich einfach auch noch mal im Hinterkopf diese Frage haben. Und das ist, glaube ich ein Thema, da wird man sehr schwer eine gute Balance finden, weil oft für viele Webseiten bedeutet jeder Ausfall Umsatz, der nicht passiert. Und diese Sorge, die wird, glaube ich, ein großes Thema sein für die Betreiber, für das Business. Und da müssen wir auch vielleicht auf einem gesellschaftlichen Level vielleicht noch mal fragen: Was bedeutet es eigentlich, wenn mal was langsam ist? Unsere Anforderungen daran, dass alles immer sofort verfügbar ist, sofort schnell ist, die wird immer größer. Das ist, glaube ich, das Dahinterstehende. Da kann vielleicht ein einzelnes Geschäft gar nicht so viel dran ändern. Sonst verlieren sie die Kunden an die anderen Leute, die ihnen das eben bieten. Das sehe ich als Konflikt.

Daniel: Ich glaube, das sind wirklich Shops, die eine Kundschaft haben, die Wert darauf legt, auf Nachhaltigkeit. Die können sich das erlauben, weil es im Gegenteil dann sogar positiv wirkt, dass sie darauf achten. Als Amazon Konkurrent könnte ich mir das wahrscheinlich nicht erlauben.

Lucas: Das befürchte ich auch. Okay, ein anderes Qualitätsziel, wo man jetzt vielleicht sogar noch mal vorschieben muss, dass es leider ein Ziel ist, was selten hoch auf der Prioritätenliste steht, was ich sehr schlecht finde. Das ist das Thema Accessibility. Wie viele Menschen können unsere Webanwendung benutzen? Können das auch Menschen benutzen, die zum Beispiel beim Sehen eingeschränkt sind oder die vielleicht nicht hören können? Da gibt es ganz viele verschiedene Arten von Accessibility. Wie siehst du denn das Ziel von Accessibility und Carbon Effizienz? Stehen die im Widerspruch oder spielen die zusammen?

Daniel: Im Widerspruch, würde ich sagen, stehen die auf keinen Fall. Aber eine Anwendung, die jetzt zum Beispiel Screenreader tauglich gemacht wird, hat trotzdem erstmal keinen direkten Zusammenhang zur Carbon Effizienz würde ich sagen. Weder positiv noch negativ. Aber es gibt auch noch andere Dimensionen von Accessibility. Wenn wir auf Netzwerkeffizienz optimieren, macht es die Anwendung auch besser nutzbar für Menschen in einer schlechten Netzanbindung oder mit veralteten Geräten oder auch mit teuren Datentarifen. Und gleichzeitig verbessert sich durch die Netzwerkeffizienz auch die Carbon Effizienz. Und ein anderes Beispiel wären Podcast Transkripte. Manche Menschen lesen den INNOQ Podcast statt ihn zu hören. Und das bedeutet natürlich auch weniger Datenvolumen. Und was den Mangel an Access Mobility als Qualitätsziel angeht und das wir das selten antreffen. In behördlichen Anwendungen ist das natürlich gesetzlich geregelt. Da ist Accessibility Pflicht. Schade, dass das außerhalb dieses Bereiches tatsächlich keine so große Rolle spielt. Aber ich könnte mir auch vorstellen, wenn man Accessibility in dem Bereich zur Pflicht macht, dass man auch Carbon Effizienz dort verpflichtend machen könnte.

Lucas: Ja, das kann ich mir auch gut vorstellen. Aber ich glaube auch, dass man sich einen Gefallen damit tut, wenn man diese beiden Ziele von Carbon Effizienz und Accessibility auch ein bisschen zusammen denkt. Gerade das Beispiel von weniger Datenvolumen ist etwas, das Leuten zugänglich macht, die eben weniger Geld haben, die vielleicht einfach in dem Bereich leben, der keine gute Infrastruktur hat. Das ist für mich auf jeden Fall auch ein wichtiges Accessibility Thema.

Daniel: Ja.

Lucas: Aber auch die Frage an welchen Stellen. Wenn ich mir jetzt eine Webseite anschaue und die arbeitet sehr stark mit Bildern, dann ist die Frage: Warum macht sie das? Ist das auch accessible? Würde ich auch als jemand, der diese Bilder nicht sehen kann, die Seite attraktiv finden? Und da kann auch ein Umdenken passieren, wo man vielleicht darüber nachdenkt, vielleicht den Text eher als den Focus von unserer Webseite zu sehen.

Daniel: Ja.

Lucas: Das ist eben auch wieder sowohl Accessibility als auch einfach Netzwerkeffizienz.

Daniel: Das stimmt, da hast du wohl recht. Wahrscheinlich reicht es nicht, einfach nur irgendwelche Alt Attribute zu setzen.

Lucas: Genau.

Daniel: Der Verzicht auf Bilder kann auf beide Ziele einzahlen. Sehr gut, das stimmt.

Lucas: Ja, oder die Frage von Video oder vielleicht Text. Oder statt Video drei, vier Bilder. Das ist auch schon wieder ein Unterschied, der da passiert. Und ich glaube, da gibt es natürlich keine universellen Antworten drauf. Aber ich finde es wichtig, die Frage zumindest mal zu stellen. Warum haben wir jetzt dieses Bild eingesetzt? Und gerade ist so ein Trend, den ich ein bisschen beobachte bei Blogs, die Bilder zu ihren Blogartikeln schreiben, die sie jetzt mit diesen neuen Machine Learning Tools da erzeugen. Mir fällt der Name gerade nicht ein, wo man jetzt einen Beschreibungstext schreibt und dieses Tool generiert einem ein Bild und dann wird das da rein gepasted. Da stelle ich mir dann auch die Frage: Wie relevant ist dieses Bild eigentlich für die Leute, die diese Seite lesen? Die laden jetzt ein Bild herunter. Wir haben vorher auch noch Energie benutzt, um dieses Bild zu erzeugen. Was haben wir jetzt gewonnen? Das würde ich auch noch mal in Frage stellen.

Daniel: Ja, es ist wahrscheinlich nicht viel nützlicher als ein beliebiges Stopper Bild.

Lucas: Das meine ich. Okay, das zum Thema Accessibility. Weiteres wichtiges Thema: Security. Wie gehen wir mit Sicherheitsmaßnahmen um? Stehen die im Widerspruch zur Carbon Effizienz?

Daniel: Die meisten Maßnahmen haben gar keinen oder nur einen kleinen Einfluss auf das Ziel der Carbon Effizienz. Krypto Algorithmen sind natürlich rechenintensiv. Aber insgesamt würde ich sagen, ist der Einfluss eher gering. Aber zum Beispiel statisch generierte Seiten sind eine Architekturentscheidung, die auf beide Ziele einzahlt. Weil die Angriffsfläche deutlich reduziert wird und gleichzeitig die Carbon Effizienz verbessert wird. Dadurch, dass ich die Seiten vorberechne und sie nicht jedes Mal neu erzeugen muss und dabei Datenbankabfragen machen muss.

Lucas: Wir meinen natürlich jetzt an dieser Stelle damit Kryptographie und nicht Krypto Currencies. Aber wenn man jetzt eine moderne Webseite mit TLS betreibt, ich persönlich würde auch sagen, das ist eine Maßnahme, auf die wir nicht verzichten können.

Daniel: Das ist nicht verhandelbar.

Lucas: Genau. Und ich glaube, der Einfluss ist auch klein genug, dass wir da auch kein schlechtes Gewissen haben müssen.

Daniel: Genau.

Lucas: Okay, aber dann ein Thema, das wir schon mal kurz angeschnitten haben. Aber wo wir jetzt auch noch mal kurz drauf eingehen wollen, ist die Kosteneffizienz. Wir wollen auch unsere Webanwendungen so bauen, dass sie im Betrieb und in der Erstellung möglichst wenig kosten. Oder zumindest wollen wir kein unnötiges Geld aus dem Fenster werfen. Das scheint jetzt erst mal miteinander zu harmonisieren, weil weniger Strom zu erzeugen, heißt, weniger Geld auszugeben. Weniger Hardware zu brauchen, heißt, weniger Geld auszugeben. Siehst du da irgendwie Widersprüche?

Daniel: Auf den ersten Blick passt das sehr gut zusammen. Und ich glaube auch, wenn man jetzt Stakeholder hat, denen Carbon Effizienz nicht wichtig ist, die das gar nicht auf dem Schirm haben, kann man wahrscheinlich trotzdem sehr viel erreichen, wenn Ihnen die Kosteneffizienz wichtig ist. Weil einfach jede Kilowattstunde Geld kostet. Und momentan auch: Tendenz steigend. Alle Architekturentscheidungen, die den Stromverbrauch senken, der jetzt beim Betrieb unserer Webanwendung entsteht, senken die Betriebskosten und auch die CO2 Emissionen. Und je höher der Preis pro Kilowattstunde, desto attraktiver ist es natürlich, den Stromverbrauch zu minimieren, indem ich vielleicht statische Seiten rendere, HTTP Caching nutze, Bilder komprimiere. Das ist auf jeden Fall so. Und mit einer vernünftigen Autoscaling Policy kann ich Verfügbarkeit, Performance, Kosteneffizienz und Carbon Effizienz in einem bestimmten Rahmen auch miteinander vereinen, aber nur eingeschränkt. Ich lasse die minimale Anzahl an Instanzen laufen, um unter Normal,ast meine gewünschte Performance zu erreichen. Oft kann das vielleicht nur eine Instanz sein, bei ganz vielen Anwendungen und bei Lastspitzen würde ich hochskalieren. Zumindest bei erwartbaren. Bei nicht erwartbaren, das hattest du eben auch schon mal angesprochen, ist es überhaupt nicht so leicht, rechtzeitig hoch zu skalieren. Jedenfalls würde ich dann hoch skalieren um die Performance nicht zu verletzen und auch weiterhin verfügbar zu bleiben. Aber wenn ich dabei keine Grenzen setze, dann explodieren dann nicht nur die Betriebskosten, sondern auch die CO2 Emissionen. Ich glaube Grenzen setzen sich die meisten Menschen heutzutage sowieso, aufgrund der Betriebskosten. Ich kenne niemanden, der beim Autoscaling sagen würde: Mir ist das völlig egal. Beliebig viele Instanzen. Im Zweifel ist dann die Verfügbarkeit dann doch nicht ganz so wichtig, wenn es zu teuer wird in der Regel. Und das gilt auch für die Emissionen.

Lucas: Aber das heißt also eigentlich, in einem bestimmten Radius ist es auf jeden Fall etwas, was irgendwie zusammenpasst. Siehst du denn irgendwas? Wo jetzt jemand sagt: Hey, damit sparen wir ganz viel Kosten, aber dafür erzeugt es trotzdem insgesamt mehr Carbon. Oder passiert das nicht?

Daniel: Das kann schon passieren. Ich könnte zum Beispiel teure Berechnungen auf den Browser auslagern. Dann spare ich mir die Stromlosten für die Berechnung auf meinen Servern und dafür wird die Berechnung auf den Endgeräten der Anwender durchgeführt. Im Zweifel dann sogar viel öfter, weil ich sie auf dem Server vielleicht nur einmal ausführen musste, wenn das eine Berechnung ist, die nicht personenbezogen ist, sondern global gültig ist. Und im Endeffekt haben wir dann mehr CO2 Emissionen verursacht, als wenn ich die Berechnung auf dem Server durchgeführt hätte. Aber ich habe meine eigenen Kosten gesenkt. Vielleicht messe ich sogar meine eigenen CO2 Emissionen und kann dann noch behaupten, dass ich viel besser dastehe, weil ich die Emissionen, die ich auf den Endgeräten verursacht habe, einfach ignoriere. Das sollte man natürlich nicht tun.

Lucas: Aber das führt uns auch so ein bisschen zu dieser Frage. Gibt es da auch andere Sachen? Ich finde, das ist eine von den großen Architekturentscheidungen, die man trifft im Web. Wo führe ich eigentlich meinen Code aus? Führe ich den eher bei mir auf dem Server aus, führe ich den auf den Clients aus? Führe ich ihn vielleicht auch den CDN Knoten aus. Da gibt es mittlerweile drei Möglichkeiten, die man da so hat. Jetzt neben dem Punkt, dass man vielleicht eine Berechnung nicht nur n-mal statt einmal ausführt, gibt es da auch noch andere Aspekte bei dieser Frage, wo der Code ausgeführt wird?

Daniel: Das ist auf jeden Fall oft ein Trade off. Ich versuche vielleicht, die Datenmenge zu reduzieren, die ich übertragen muss. Und das kann dann eben Berechnung auf dem Client als Konsequenz haben. Und dann ist die spannende Frage: Was ist jetzt günstiger? Das kommt vielleicht auch darauf an, wie viel kleiner die Daten dadurch geworden sind und wie oft ich sie übertragen muss und wie teuer ist es, mit den Daten im Browser noch was zu machen? SVG zum Beispiel ist oft kleiner als eine Rastergrafik, nicht immer, aber oft, muss dann aber noch vom Browser gerendert werden. Da muss man eigentlich ausrechnen, was jetzt der entscheidende Faktor ist. Ist es die Übertragung dieser Daten, wo ich viel eingespart habe? Oder ist die Berechnung auf Endgeräten dann der ausschlaggebende Faktor?

Lucas: Ich finde, bei SVG müsste man wahrscheinlich noch mal wesentlich mehr messen, wie viel mehr Energie das tatsächlich verbraucht als ein relativ hoch aufgelöstes WebP Bild oder so was.

Daniel: Genau, das kann ich jetzt auch nicht auf Anhieb sagen. Es kann durchaus sein, dass SVG zu rendern überhaupt nicht mehr Energie verbraucht als ein WebP Bild rendern, was auch erst mal dekomprimiert werden muss.

Lucas: Ein Aspekt, der mir da auf jeden Fall noch einfällt, ist die Frage, ob man etwas vielleicht eher in CSS löst oder in JavaScript. Weil in modernen Browsern ist es so, dass viele von den CSS Berechnungen relativ optimiert auf der GPU laufen, statt auf der CPU. Was natürlich nicht heißen soll, dass im GPU kein Stromverbrauch ist, das ist klar, dass sie auch Strom verbraucht, aber wenn das effizienter passiert, als das über die CPU auszurechnen. Das merkt man auch schon an dem Akku. Wenn man irgendwas hat, wo man merkt: Okay, da wird irgendwie noch viel mit Animation und dies und das gemacht, da geht auf einmal der Akku schneller leer, als wenn man irgendwie eine ganz einfache Webseite hat. Da würde ich auf jeden Fall auch noch mal darauf schauen, wenn man die Möglichkeit hat, bestimmte Sachen mit einem Browser Standard eingebaut zu machen, anstatt sie irgendwie selbst zu bauen oder mit einer Library, dann kann man da sowohl übertragene Daten in den meisten Fällen sparen, als auch Effizienzgewinne dadurch, dass das einfach viel schneller berechnet ist als diese ganzen JavaScript Animations Frameworks, die man vielleicht auch früher intensiver benutzt hat.

Daniel: Ja, das stimmt. Und im gleichen Konflitfeld kann man auch noch die Frage sehen, ob es vielleicht für die Carbon Effizienz besser ist, wenn der Browser vom Server Daten jetzt im JSON Format erhält und dann den HTML Baum erzeugt oder wenn er ein direkt vom Server gerendertes HTML bekommt. Das muss dann natürlich auch noch angezeigt werden, ist aber in der Regel weniger Arbeit im Browser zu verrichten, als wenn ich erst mal JSON noch verarbeiten muss.

Lucas: Ich glaube, da kann man schon relativ sicher sagen, dass das Parsen von HTML schneller gehen wird als das Parsen von JSON. Danach in JavaScript den DOM von Hand zu erzeugen quasi. Das sind einfach mehr Arbeitsschritte, das kann nur ineffizienter sein. Und gerade dadurch, dass die modernen HTML Engines auch hoch optimiert sind, um möglichst schnell zu sein und nicht in JavaScript geschrieben sind, sondern eher in sowas wie C++ oder Rust, die sind dann einfach wesentlich schneller fertig oder brauchen weniger CPU.

Daniel: Genau. Und das gilt natürlich besonders dann, wenn der Server auch nur mit HTML Snippets oder Fragmenten antworten kann, die dann eingefügt werden. Aber vielleicht gilt es auch dann, wenn ich trotzdem komplette Seiten zurück schicke. Wie das auch bei Turbo Links möglich ist, wo eigentlich eine ganze Seite zurückgeschickt wird, aber nur ein Teil davon dann auch in den DOM Baum eingefügt wird. Da ist dann aber natürlich wieder die Frage: Wie groß ist die komplette geschickte Seite, die noch übertragen werden muss? Klar ist die größer als das HTML Snippet, aber es kann natürlich sein, dass es nicht relevant ist. Das kann man aber wirklich sehr schwierig messen.

Lucas: Das stimmt.

Daniel: Klar kann ich berechnen wie viel CO2 Emissionen die Übertragung einer kompletten HTML Seite verursacht im Vergleich zum Beispiel mit einer kleinen JSON Payload oder einem HTML Snippet. Aber zusätzlich muss ich noch den Unterschied im Browser berechnen. Ob ich jetzt erst noch das JSON Parsing machen muss oder das nicht tun muss.

Lucas: Das hatten wir uns auch im Vorfeld mal angeschaut. Webseiten, die da irgendwie sehr auf JavaScript setzen im Client und die Webseiten, die eher auf quasi statisches HTML setzen. Wie viel mehr Millisekunden CPU Zeit das erzeugt.

Daniel: Ja. Hast du die Zahlen noch parat? Ich habe sie gerade gefunden.

Lucas: Ich habe sie gerade nicht parat.

Daniel: Ja, wir hatten tatsächlich natürlich unsere eigene Seite als leuchtendes Beispiel. innoq.com, haben wir verglichen mit angular.io, wo viel JavaScript verwendet wird. Und bei innoq.com haben wir 13 Millisekunden Scripting gemessen und bei angular.io 264 Millisekunden. Und die Rendering Zeiten waren bei beiden dann ungefähr gleich 21 und 24 Millisekunden und Painting jeweils 4 Millisekunden.

Lucas: Ich fand das wirklich erstaunlich, weil wir hatten in der Vorbereitung darüber ein bisschen gesprochen und das war mehr eine spontane Idee, das mal kurz zu vergleichen. Vor allem ist es erstaunlich, wenn ihr euch diese Seiten mal anschaut, das ist jetzt nicht so, die eine ist ein komplexes 3D Spiel und die andere ist irgendwie ein Wikipedia Eintrag, sondern wenn man die beiden Seiten vergleicht, dann würde ich auch behaupten, dass auf der innoq.com Seite zum einen mehr Inhalt steht und zum anderen auch irgendwie mehr passiert. Mehr Bilder und verschiedene Fonts und so weiter. Und diese angular.io Seite ist doch relativ einfach, würde ich jetzt mal behaupten.

Daniel: Ja, sie sieht fast aus wie so eine typische Bootstrap Dokumentationsseite.

Lucas: [Genau, wie so eine Willkommensseite für Dokumentationen. Darum geht es hier. Ich hatte erwartet, dass es da vielleicht einen Unterschied gibt, aber dass der so immens ist, hätte ich persönlich jetzt nicht erwartet. Das hat mich auf jeden Fall noch mal nachdenklich gemacht, dass das tatsächlich so viel CPU kostet, um das darzustellen. Und da muss man natürlich auch fair sein und dann noch mal überlegen, was ist, wenn man jetzt über mehrere Seiten hinweg navigiert? Man geht meistens nicht nur auf eine Startseite und bleibt dann da und macht sie danach zu. Ich navigiere über die Seite, das müsste man dann auch noch mal vergleichen, das fair zu machen. Aber vielleicht sollte man zumindest das mal vergleichen, wenn man sich mit dem Thema beschäftigt: Wie viel investieren wir hier eigentlich an CPU und wie viel investieren wir an Browserzeiten? Und da sind in den modernen Browser. Wir haben das jetzt mit Chrome gemessen, da sind solche Tools mit eingebaut, wo man sehen kann, wie viel Zeit gerade der Browser da investiert hat, dass man das einfach noch mal macht und noch mal schaut, wie entwickelt sich das vielleicht auch über die Zeit? Wenn man unsere Webseite heute anschaut und dann noch mal in ein paar Monaten, ist die Zeit hochgegangen oder ist die runtergegangen? Das wäre im besten Falle so, dass es immer weiter runtergeht. Okay, gut, das ist jetzt der eine Aspekt, spielen wir es auf dem Client aus. Aber es gibt auch noch andere Orte, wo wir Code ausführen können. Wir könnten es auf dem Server ausführen, auf dem CDN Knoten oder vielleicht auch einen Reverse Proxy. Wie würdest du denn das einschätzen?

Daniel: Man müsste natürlich zuerst mal berechnen, was ich eben auch schon gesagt habe, ob die übertragenen Datenmengen oder die Berechnungen der entscheidende Faktor sind, um den optimalen Ort herauszufinden. Ein bisschen ist man natürlich auch eingeschränkt dadurch, ob es jetzt User bezogene Daten sind oder nicht. User bezogene Daten sind wahrscheinlich in dem Reverse Proxy nicht so leicht zu berechnen. Man könnte meinen, im CDN Knoten ist das auch nicht so leicht. Aber es gibt mittlerweile auch CDNs, die eigene Identity Lösungen usw. haben, wo man im Grunde auch einen User Kontext zur Verfügung hat. Es ist fast alles eigentlich auch möglich mit einem CDN Knoten zu machen. Aber bei Daten, die für alle User gleich sind, kann es sich schon lohnen, diese nur einmal auf jeden Fall zu berechnen. Sei es jetzt auf dem Server oder dem Reverse Proxy oder auch im CDN. Bei personalisierten Daten, die für jeden User unterschiedlich sind, kann die Berechnung im Grunde auch im Browser erfolgen, wenn dadurch die Datenmenge, die übertragen werden muss, deutlich reduziert wird. Ich glaube, das ist aber selten der Fall. Meistens würde man dann viele Daten übertragen, die dann im Browser noch gefiltert oder aggregiert werden oder was auch immer. Was oft gar nicht notwendig ist. Dann würde man eher die Daten auf dem Server berechnen. Das ganze kann natürlich auch mit Browser Caching kombiniert werden. Generell ist es heute so, dass gerne Logil in den Browser verlagert wird, gerade von Single Page Applications. Und oft werden dann mehr Daten übertragen, als wenn die Berechnungen auf dem Server stattfinden und gleichzeitig aber auch mehr Berechnungen in den Browser verlagert. Dadurch, dass die Logik dort liegt.

Lucas: Ja, ich finde, da muss man auch noch ein bisschen auf seine Use Cases schauen. Aber ich kann mir durchaus vorstellen, dass es Fälle gibt, in denen man mit einer Single Page Application sogar Carbon effizienter sein kann. Wenn ich mir jetzt eine Anwendung vorstelle, die einen relativ statischen Datensatz hat, auf dem viele verschiedene Sachen dargestellt werden müssen, könnte ich mir vorstellen, dass so eine offline fähige App, die die Daten einmal bekommt und dann super viel darauf operiert, dass die tatsächlich dann effizienter ist als eine, die dann für jedes Mal für jede Filteroption wieder an den Server gehen muss. Aber ich glaube das ist sehr abhängig von dem Use Case, den man hat. Bei den meisten Fällen ist die gesamte Datenmenge so groß, dass man sie niemals vollständig auf den Client übertragen könnte. Und es steht dann immer noch das große Fragezeichen dran: Wie kriege ich es dann hin, dass diese Daten auch aktualisiert werden, wenn sie sich ändern auf dem Server? Aber zumindest kann ich mir vorstellen, dass es Anwendungen gibt, in denen das tatsächlich effizienter wäre, das auf dem Client zu lösen.

Daniel: Ja, das denke ich auch. Ich glaube, wichtig ist einfach die Botschaft, dass es nicht die eine Lösung gibt, die immer Carbon effizienter ist als eine andere.

Lucas: Ja, das denke ich auch.

Daniel: Es gilt bei anderen Qualitätszielen genauso, dass zwar oft bestimmte Maßnahmen eine Tendenz haben, auf ein bestimmtes Ziel einzuzahlen, aber was natürlich oft nicht allgemeingültig ist, dass man immer den einen Weg hat, mit dem man das Ziel erreicht.

Lucas: Ich glaube, das ist auch ein gutes Schlusswort. Ich glaube, wir müssen einfach, wenn wir das ernst nehmen, einfach anfangen, das als Ziel zu formulieren und einfach darüber nachdenken. Es geht jetzt nicht darum, dass wir jetzt in dieser Folge hier irgendwie die Carbon effiziente Architektur vorstellen.

Daniel: Nein, genau.

Lucas: Vielleicht eines Tages mal für zumindest manche Fälle. Aber ich glaube, das ist aktuell noch gar nicht möglich, sondern einfach bewusster damit umzugehen mit dem Energieverbrauch, der an verschiedenen Stellen passiert, in so einer modernen Webanwendung, die einfach verteilt läuft.

Daniel: Genau.

Lucas: Gut, Daniel, dann danke ich dir sehr herzlich für deine Zeit und dafür, dass du dich so viel mit diesem Thema beschäftigst.

Daniel: Nichts zu danken.

Lucas: Wir werden bestimmt noch mal auf diesen Themenkomplex zurück kommen. Und da werde ich dich auch wieder einladen.

Daniel: Ich freue mich drauf.

Lucas: Alles klar. Gut, dann sage ich mal den Hörerinnen und Hörern, bis zum nächsten Mal. Und noch einen schönen Tag. Bis dann.

Daniel: Tschüß.