Entwicklerhandbuch zum Erstellen von Apps ohne Infrastrukturbelastung

Die meisten Anwendungsentwickler verbringen einen Großteil ihrer Zeit mit Aufgaben, die nichts mit der Entwicklung von Features zu tun haben. Sprint 0 verschwindet in Jenkins-Dateien und Terraform-Konfigurationen. Neue Umgebungen erfordern Tickets an mehrere Teams und eine Wartezeit von ein bis zwei Wochen. Laufzeit-Upgrades ziehen sich zu monatelangen Projekten hin.

Dies ist die Infrastruktursteuer, und sie summiert sich. Jede Stunde, die mit der Fehlerbehebung von IAM-Berechtigungen oder dem Warten auf die Bereitstellung der Umgebung verbracht wird, ist eine Stunde, die nicht für das Produkt aufgewendet wird. Die für Infrastrukturspezialisten entwickelten Tools (Terraform, Kubernetes, Raw-Cloud-Konfigurationen) sind zu Standardanforderungen für Anwendungsentwickler geworden, die sich nie für diese Arbeit gemeldet haben.

Es gibt eine klarere Trennung zwischen dem, was Entwickler selbst übernehmen sollten, und dem, was automatisiert werden sollte. Die richtige Trennung verändert die Art und Weise, wie Teams planen, entwickeln und liefern.

Was „keine Infrastrukturlast tragen” tatsächlich bedeutet

Lassen Sie uns klarstellen, was wir nicht vorschlagen: alle Infrastrukturkenntnisse aufzugeben oder so zu tun, als sei die Bereitstellung unwichtig. Das Ziel ist es, das, was Sie benötigen, von der Art und Weise, wie es bereitgestellt wird, zu trennen.

Die Infrastruktur sollte eine Abhängigkeit Ihrer Anwendung sein, genau wie jede andere Abhängigkeit in Ihrer Codebasis. Sie deklarieren, was Sie benötigen (eine PostgreSQL-Datenbank, einen Redis-Cache, eine Node.js-Laufzeitumgebung), und die Plattform kümmert sich um den Rest. Über den Vertrag zwischen Ihrem Anwendungscode und einer Abhängigkeit hinaus sollten Sie sich keine Gedanken darüber machen müssen, wie diese Abhängigkeit ausgeführt wird.

In der Praxis bedeutet dies, dass Sie keine Terraform-Module mehr schreiben müssen, um verwaltete Datenbanken bereitzustellen. Sie müssen nicht mehr Kubernetes YAML debuggen, wenn Ihr Pod nicht geplant wird. Sie müssen nicht mehr zwischen Ihrer IDE und den Konsolen Ihres cloud-Anbieters hin- und herwechseln, um herauszufinden, warum IAM-Berechtigungen Ihre Bereitstellung blockieren.

Sie programmieren. Sie pushen es zu Git. Ihre Anwendung läuft.

Infrastrukturabstraktion: Was Entwickler unter Kontrolle behalten sollten

Nicht alles sollte abstrahiert werden. Einige Infrastrukturentscheidungen wirken sich direkt auf das Verhalten Ihrer Anwendung aus und gehören in den Zuständigkeitsbereich des Entwicklungsteams.

• Entscheidungen zur Anwendungsarchitektur bleiben Ihnen vorbehalten. Kann Ihre Anwendung in einer Multi-Node-Konfiguration ordnungsgemäß ausgeführt werden? Kann sie horizontale Skalierung problemlos bewältigen? Diese Fragen erfordern ein Verständnis Ihres Codes, nicht Ihres cloud-Anbieters.
• Die Auswahl der Dienste bleibt Ihnen überlassen. Sie wissen, ob Ihre Workload PostgreSQL oder MySQL benötigt, ob Redis für Ihre Caching-Strategie sinnvoll ist und ob Elasticsearch Ihren Suchanforderungen entspricht. Die Plattform sollte diese Dienste sofort verfügbar machen, aber die Wahl liegt bei Ihnen.
• Die Performance-Anforderungen liegen in Ihrem Zuständigkeitsbereich. Wie viel CPU und Arbeitsspeicher benötigt Ihre Anwendung? Welche Reaktionszeiten erwarten Ihre Benutzer? Sie verstehen diese Einschränkungen besser als jedes Infrastrukturteam.
• Die Geschäftslogik und der Datenfluss bleiben natürlich bei Ihnen. Wie Ihre Anwendung Anfragen verarbeitet, Daten speichert und Fehler behandelt, ist eine zentrale Aufgabe der Entwicklung.

Was sollte abstrahiert werden?

Alles andere. Insbesondere alles, was spezielle Infrastrukturkenntnisse erfordert, aber nichts an der Funktionsweise Ihres Programms ändert.

• Die Bereitstellung der Umgebung sollte nicht Ihren Sprint 0 in Anspruch nehmen. Wenn eine Plattform dies automatisch übernimmt, gelangen Sie innerhalb von Minuten statt Tagen oder Wochen vom Programmieren zum Laufen der Umgebung. Jeder Git-Zweig kann eine vollständige Umgebung mit derselben Konfiguration, denselben Diensten, demselben Routing und optionalen Produktionsdaten generieren.
• Die Netzwerk- und Routing-Konfiguration sollte unsichtbar sein. TLS-Zertifikate, Lastenausgleich, DNS-Verwaltung und Service Discovery können alle von der Plattform übernommen werden. Sie sollten keine Kenntnisse über VPCs oder Sicherheitsgruppen benötigen, um eine Webanwendung bereitzustellen.
• Laufzeit- und Service-Updates sollten keine monatelangen Projekte sein. Als Entwickler sollten Sie sich nicht um Unterversionen Ihrer Laufzeit oder Ihres Services kümmern müssen. Sie sollten sich nicht mit deren Aktualisierung befassen müssen, da dies nicht Ihr Schwerpunkt ist. Ihr Schwerpunkt sollte auf der Schaffung neuer Werte oder der Wartung Ihrer Anwendung liegen.
• Bei der Infrastruktursicherheit sollten Leitplanken die Entscheidungsfindung vollständig ersetzen. Schreibgeschützte Produktionsdateisysteme, automatisierte TLS-Zertifikate, strenge Umgebungsisolierung: Diese sollten integriert und nicht konfiguriert werden.

Wie reduzierter Infrastruktur-Overhead die Entwicklungsgeschwindigkeit verändert

Wenn Sie die Infrastruktur aus Ihrem kritischen Pfad entfernen, beschleunigt sich die Entwicklung.

• Schnellere Feedback-Schleifen werden zur Norm. Wenn die Erstellung einer Testumgebung nur Sekunden dauert, anstatt Tickets auszufüllen, testen Sie häufiger. Sie erkennen Probleme früher. Sie liefern mit mehr Vertrauen aus.
• Feature-Branches werden zu realen Umgebungen. Jeder Branch, den Sie pushen, kann zu einer vollständig unabhängigen Umgebung werden, komplett mit Ihrem Anwendungscode, einer Kopie Ihrer Datenbank und allen unterstützenden Diensten. Die automatisch generierte URL kann an Stakeholder oder CI-Systeme gesendet werden. Es ist wirklich jedes Mal so, als würde man sich fragen: „Wie würde meine Website aussehen, wenn ich dies in der Produktivumgebung übernehmen würde?“
• Die Sprint-Planung ändert sich. Ohne Sprint-0-Infrastrukturarbeiten beginnen Sie am ersten Tag mit der Entwicklung von features. Ohne Verzögerungen bei der Bereitstellung der Umgebung müssen Sie Ihre Schätzungen nicht mehr mit „Infrastrukturzeit“ auffüllen. Sie planen auf der Grundlage der Komplexität der Entwicklung und nicht des Betriebsaufwands.
• Der Bereitschaftsdienst wird weniger stressig. Wenn die Infrastruktur vorhersehbar und Rollbacks zuverlässig sind, schläft man besser. Im Ernst.

Häufige Befürchtungen hinsichtlich des Verzichts auf Low-Level-Kontrolle

Teams zögern oft, standardisierte Umgebungen einzuführen, weil sie befürchten, an Flexibilität zu verlieren. Lassen Sie uns die häufigsten Bedenken ansprechen.

• „Was ist, wenn ich eine benutzerdefinierte Konfiguration benötige?“ Standardisiert bedeutet nicht starr. Eine gut konzipierte Plattform legt die Konfiguration offen, wo es darauf ankommt (Ressourcenzuweisung, Serviceauswahl, Umgebungsvariablen usw.), während sie die Komplexität dort verbirgt, wo es nicht darauf ankommt (Netzwerk, IAM, Skalierungsmechanismen).
• „Was ist mit der Bindung an einen Anbieter?“ Ihr Programm ändert sich nicht. Ihre Datenbankschemata bleiben unverändert. Ihre APIs bleiben identisch. Die Portabilität, auf die es ankommt, nämlich Ihre eigentliche Anwendung, bleibt erhalten.
• „Wie kann ich Probleme in der Produktivumgebung debuggen?“ Wahrscheinlich besser als bisher. Wenn alle Umgebungen identisch sind (gleiche Konfiguration, gleiche Dienste, gleiche Datenstruktur), verschwinden Probleme beim Debuggen, die „auf meinem Rechner funktionieren“. Mit vollständigen Klonen der Produktivumgebung in wenigen Minuten können Sie unter realen Bedingungen testen, ohne Live-Systeme zu berühren.
• „Was ist mit Compliance- und Sicherheitsanforderungen?“ Die integrierte Compliance (SOC 2, ISO 27001, PCI-DSS) übertrifft oft das, was Teams mit DIY-Setups erreichen. Wenn Sicherheit in die Plattform integriert ist, erben Sie sie automatisch.

Was schafft Vertrauen, wenn die Infrastruktur automatisiert ist?

Vertrauen entsteht durch Vorhersehbarkeit. Wenn Sie genau wissen, was bei jeder Bereitstellung passieren wird, sinkt die Angst.

• Git wird zur einzigen Quelle der Wahrheit. Ihre Infrastrukturkonfiguration befindet sich zusammen mit Ihrem Code in einer einfachen YAML-Datei. Infrastrukturänderungen durchlaufen Pull-Anfragen mit dem gleichen Überprüfungsprozess wie Codeänderungen. Jede Bereitstellung ist deterministisch und basiert auf Git-Commits. Ein Rollback bedeutet die Rücknahme von Commits.
• Konfigurationsstabilität über einen längeren Zeitraum. Eine Herausforderung bei Terraform sind Versions-Upgrades und Syntaxänderungen zwischen den Versionen. Das Upgraden von Terraform ist oft mit erheblichem Aufwand verbunden. Bei standardisierten Plattformen funktioniert eine Konfigurationsdatei von vor Jahren auch heute noch.
• Die Parität der Umgebungen ist gewährleistet. Die gleiche Konfiguration wird in der Entwicklung, Staging und der Produktivumgebung eingesetzt. Umgebungsbezogene Unterschiede werden durch Variablen und nicht durch unterschiedliche Konfigurationen behandelt. Abweichungen zwischen den Umgebungen kommen einfach nicht vor.

Erste Schritte

Der Weg nach vorne erfordert weder eine Neuprogrammierung Ihrer Anwendung noch die Aufgabe all Ihrer bisherigen Kenntnisse. Beginnen Sie mit einem nicht kritischen Projekt. Erstellen Sie eine einfache Konfigurationsdatei. Pushen Sie sie zu Git. Beobachten Sie die Bereitstellung Ihrer Anwendung.

Wenn Sie sehen, wie schnell diese Feedbackschleife sein kann, wenn Sie erleben, wie Sie in Sekundenschnelle eine komplette Umgebung aus einem Branch erstellen können, wird die Infrastrukturlast zu einem Problem, das der Vergangenheit angehört.

Sie sind Entwickler geworden, um Dinge zu erschaffen. Es ist an der Zeit, sich wieder darauf zu konzentrieren.

Erfahren Sie mehr

• Was ist Upsun?
  Verstehen Sie die Kernkonzepte hinter der Git-gesteuerten Infrastruktur und wie Upsun die Komplexität des Betriebs abstrahiert.
• Git-gesteuerte Infrastruktur: Warum Configuration as Code besser ist als Click-and-Deploy.
  Ein genauerer Blick darauf, warum YAML-gesteuerte Bereitstellungen manuelle Bereitstellungen für wartbare, skalierbare Anwendungen übertreffen.
• Richten Sie Ihre lokale Entwicklungsumgebung ein.
  Verbinden Sie Ihren lokalen Workflow über DDEV- oder SSH-Tunnel mit Upsun, um schneller zu iterieren, ohne jede Änderung zu pushen.
• Befehlszeilenschnittstelle (CLI)
  Verwalten Sie Projekte, Umgebungen und Bereitstellungen direkt von Ihrem Terminal aus mit der Upsun-CLI.
• Verwalten Sie Upsun-Umgebungen.
  Erfahren Sie, wie Sie Umgebungen erstellen, verzweigen, synchronisieren und zusammenführen können, die mit Ihrem Git-Workflow verknüpft sind.