Doch das ist zu kurz gedacht: Entscheidungen in Sachen Code haben einen gewaltigen Einfluss auf die Kosten und damit das Geschäftsergebniss eines Unternehmens. Schwerfälliger Code ist langsamer, erfordert mehr Cloud-Ressourcen und kostet damit mehr Geld. Bei der Auswahl von Algorithmen und qualitativ hochwertigem Code geht es jedoch um mehr als nur Geschwindigkeit, denn dieser kann auch geringere Betriebskosten aufwerfen.

Dieser Zusammenhang erschließt sich Entwicklern nicht immer. Modernes Cloud ComputingCloud Computing zeichnet sich dadurch aus, dass es die Ressourcennutzung in eine Einzelpostenrechnung aufsplittet. Gute Cloud-Entwickler wissen dabei um ihre Möglichkeiten. Wir haben zwölf Tipps zusammengetragen, mit denen Sie Ihren Code schlanker, schneller und kostengünstiger machen. Alles zu Cloud Computing auf CIO.de

1. Schnelleren Code schreiben

Die meisten Entwickler verbringen nicht viel Zeit damit, ihren Code zu optimieren. Wenn das Programm auf ihrem Laptop läuft, merken sie gar nicht, wenn es mit der Zeit 20, 30 oder sogar 300 Prozent langsamer läuft. Das Programm reagiert immer noch in Sekundenbruchteilen.

Aber diese Unterschiede summieren sich, wenn sie millionenfach auf dem Server auftreten. Eine sorgfältige Profilierung kann die langsamen Teile im Code identifizieren. Werden diese in der Folge umgeschrieben oder angepasst, kann das die Anzahl der Instanzen verringern, die für die Applikation nötig sind.

2. RAM-Footprint verringern

Die Menge des von der Anwendung verwendeten Arbeitsspeichers ist ein wichtiger Parameter bei der Preisgestaltung von Cloud-Instanzen. In vielen Fällen führt eine Verdoppelung des Arbeitsspeichers auch dazu, dass die Kosten um 100 Prozent steigen.

Programmierer können ihren RAM-Fußabdruck verringern, indem sie vermeiden, Daten im Speicher zu halten. Einige Streaming-Algorithmen, wie etwa die Stream-Klassen von Java, sind darauf ausgelegt, mit großen Datenmengen zu hantieren, ohne sie alle in den Speicher zu laden. Auch das Apache-DataSketches-Projekt generiert Antworten aus komplexen Big-Data-Statistiken, ohne dafür den gesamten Speicher zu belegen. Positiver Nebeneffekt: Eine gewissenhafte RAM-Nutzung kann auch Ihre Algorithmen beschleunigen.

Manchmal lagert auch das Betriebssystem Daten über den virtuellen Speicher auf die Festplatte aus. Das verhindert zwar einen Absturz, kann aber Ihre Programme drastisch verlangsamen.

3. Geringere Auflösung nutzen

Die Verwendung von Bildern und Videos mit geringerer Auflösung kann sich in mehrfacher Hinsicht auszahlen. Erstens kommt es günstiger, sie zu speichern. Zweitens sind die Kosten für eine eventuelle Datenexfiltration geringer. Drittens präsentiert sich die Anwendung den Usern deutlich flotter.

Alle statischen Bilder sollten daher von Anfang an minimiert werden. Das Ausmaß der Minimierung ist leider nicht ganz einfach, denn ab einem gewissen Punkt verschlechtert sich die visuelle Qualität so stark, dass das für den Benutzer sichtbar wird. Den richtigen Kompromiss zu finden, ist eine Design-Entscheidung, auf die manche Programmierer nicht vorbereitet sind.

Einige Anwendungen, die hochgeladene Bilder verwenden, können auch kleinere Miniaturansichten und Versionen mit geringerer Auflösung erstellen, nachdem sie das Bild erhalten haben. Toolkits wie ImageMagik und Formate wie WebP wurden speziell für diesen Zweck entwickelt.

4. Unnötigen Datenballast abwerfen

Viele Entwickler sind sammelwütig und speichern Informationen nur für den Fall, weil man sie eines Tages einmal brauchen könnte. So entstehen endlose Tabellen die nie gelöscht oder konsolidiert werden. Diese zusätzlichen Daten kosten aber nur dann nichts, wenn das Unternehmen die Hardware besitzt und das Laufwerk genügend Platz bietet.

In der Cloud hingegen ist alles kostenpflichtig. Sie sollten sich deshalb klar darüber werden, welche Daten in Zukunft wirklich gebraucht werden und anschließend nicht benötigte entsorgen. So sparen Sie Geld für StorageStorage und Datenexfiltration. Alles zu Storage auf CIO.de

5. Festplattenspeicher begrenzen

Die Nutzung der lokalen Festplatte auf Cloud-Instanzen ist nicht nur gefährlich, sondern kann auch teuer werden. Viele Entwickler erstellen ihren Code auf einem persönlichen Rechner mit einem oder sogar mehreren Terabyte Speicherplatz - schließlich sind Festplatten und SSDs für den eigenen Hausgebrauch erschwinglich.

Speicherplatz auf Cloud-Rechnern ist jedoch selten so günstig oder leicht verfügbar, sondern wird oft direkt nach Größe abgerechnet - Tag für Tag, Woche für Woche, Monat für Monat. Es empfiehlt sich deshalb, so wenig Speicherplatz wie möglich zu verwenden. Überlegen Sie, wie Sie nicht nur die temporären Dateien, die Ihre Anwendung erstellt, sondern auch die erforderlichen Systembibliotheken und Softwarepakete minimieren können.

6. Logs bereinigen

Protokolldateien sind hervorragend geeignet, um Probleme zu erkennen und Software in der Entwicklungsphase zu debuggen. Sobald der Code jedoch in Produktion ist, müssen Sie nicht mehr alle Logs aufbewahren. All die zusätzlichen Informationen verstopfen entweder die lokale Festplatte oder den Objektspeicher. Wenn Sie das Protokollierungssystem entwerfen, konfigurieren Sie es so, dass die Protokolle aufgeräumt und nicht mehr benötigte Informationen entfernt werden.

Viele Protokollierungspakete wie Log4j lassen sich so konfigurieren, dass sie nur eine minimale Anzahl von Protokollen aufbewahren und diese in regelmäßigen Abständen löschen.

7. Serverless arbeiten

Im Fall von Serverless-Architekturen laufen nur dann Kosten auf, wenn Ihr Code ausgeführt wird. Das kann bei unregelmäßiger Auslastung viel Geld sparen. Selbst Anwendungen, die einen konstanten Nutzerstrom aufwerfen, haben mehr Leerlauf, als Sie vielleicht erwarten.

Viele Serverless-Tarife belohnen sorgfältige Codierung und gute Performance mit minimalem RAM-Verbrauch. Die Abrechnungsformel zählt die Reaktionszeit in Millisekunden und berechnet nur die Zeit, in der der Prozessor belegt ist. Als Entwickler erhalten Sie sofortiges Feedback, da Sie die Reaktionszeit direkt verfolgen und sehen können, wie sich Ihre Code-Änderungen darauf auswirken.

Der Serverless-Ansatz ist ideal für kleinere oder experimentelle Projekte - die Rechnung beträgt in vielen Fällen oft nur ein paar Cent pro Monat. Wenn Ihre Anwendung nur gelegentlich einige Funktionen ausführt, kann sich ein Umstieg auf Serverless lohnen.

8. Alte Daten archivieren

Je älter die Daten werden, desto weniger häufig wird auf sie zugegriffen. Indem Sie Ihre Anwendung so einrichten, dass ältere Daten an einen günstigeren Speicherort migriert werden, können sie kostenmäßig gegensteuern.

Einige Clouds berechnen viel weniger für den so genannten "cold storage", bei dem es Minuten oder sogar Stunden dauern kann, bis die Bits geliefert werden. Andere Clouds wie Wasabi oder Backblaze sind auf die Archivierung von Amazon-S3-Objekten spezialisiert und berechnen deutlich weniger als die großen Cloud-Provider - in manchen Fällen entfallen sogar die Gebühren für die Datenexfiltration. Daten auszulagern, sobald sie nicht mehr stark nachgefragt werden, kann äußerst kosteneffizient sein.

9. CSS-Layouts vereinfachen

Wenn Sie sich die HTML-Tags ansehen, die von einigen Frameworks generiert werden, bekommen Sie eine Ahnung davon, welche lächerlichen Layouts daraus entstehen können: Solche, die eigentlich nur aus DIV-Tags bestehen, die in weiteren DIV-Tags verschachtelt sind. Das kostet Geld - sowohl bei der Erstellung als auch der Bereitstellung.

Ein einfacheres Layout mit vernünftigem CSS-Einsatz kann Ihre Bandbreitenrechnung um bis zu 30 Prozent senken.

10. Statische Webseiten erstellen

Einige Frameworks wie React benötigen mehr Rechenleistung, insbesondere wenn sie Funktionen wie serverseitiges Rendering verwenden. Das kann die monatliche Cloud-Rechnung in die Höhe treiben. Die entgegengesetzte Philosophie: Statische Webseiten erstellen, die aus unveränderlichen HTML-, CSS- und JavaScript-Blöcken aufgebaut sind und wortwörtlich aus einem Cache abgerufen werden. Die Verwendung eines Content-Delivery-Netzwerks kann die Bereitstellung sogar noch weiter beschleunigen, da die Caches näher an den Benutzer heranrücken.

Verschiedene Frameworks machen sich diese statische Philosophie zu eigen. Jekyll, Hugo, Gridsome und Pelican sind nur einige Tools, die Ihren gesamten Inhalt in kompakte, unveränderliche Dateien packen. Sie können die Seiten immer noch mit AJAX-Aufrufen personalisieren, aber der Großteil der Website belastet die Server kaum.

11. Computation und Storage auslagern

Da Browser immer leistungsfähiger werden, machen es einige Frameworks einfach, mehr Berechnungen direkt auf den Client zu verlagern. Guter JavaScript- oder WebAssembly-Code kann einen größeren Teil der Last auf den Rechner des Benutzers verlagern und Ihre Cloud-Server entlasten. Einige Entwickler reduzieren ihre Cloud-Schicht auf wenig mehr als eine Datenbank mit ein wenig Business-Logik für die Authentifizierung.

Browser bieten auch ausgefeiltere Optionen, um Informationen lokal zu speichern - etwa den HTML-Web-Storage-Standard oder die W3C Indexed Database API. Dabei geht es nicht mehr nur um kurze Strings und Cookies: Diese Daten sind schneller verfügbar, da sie nicht über das Internet übertragen werden und es beruhigt die Benutzer, wenn ihre Daten nicht in einer zentralisierten, hackbaren Datenbank gespeichert sind. Warum für die Datenspeicherung und -exfiltration bezahlen, wenn sie auf dem Rechner des Nutzers kostenlos gespeichert werden können?

12. Cost Engineer einsetzen

Manche Entwickler sind auf die Pflege von Datenbanken spezialisiert. Andere mögen es, mit einem gut gestalteten Frontend einen schönen ersten Eindruck zu hinterlassen. Jetzt, da die Cloud-Kosten so flexibel sind, ernennen einige Teams offiziell "Kosteningenieure", die sich um die Verwaltung von Code-Kosten und -Effizienz kümmern.

Das Hauptaugenmerk eines Cost Engineer liegt dabei darauf, den Anwendungscode sauberer, schneller, leichter und letztendlich kostengünstiger zu machen. Allein die Existenz dieser Rolle verdeutlicht, dass die Verwaltung von Cloud-Kosten eine Aufgabe ist, die sehr wohl auch in der Verantwortung des Entwicklungsteams liegt. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.