Backend-Entwickler benötigen eine einfachere Infrastrukturbereitstellung und -verwaltung, um einfache, wiederholbare Lösungen erstellen zu können. [...]
Mit der wachsenden Popularität von Infrastructure as Code, Devops und internen Plattformen sind Backend-Entwickler besser denn je gerüstet, um hoch belastbare, leistungsfähige und skalierbare serverseitige Anwendungen und Dienste zu entwickeln. Gleichzeitig droht ihnen aber auch der Sturz ins Bodenlose.
Die Komplexität moderner Anwendungen erfordert von Back-End-Entwicklern die Beherrschung einer wachsenden Anzahl von Tools, Technologien und Techniken, von den Grundlagen von Linux, Skriptsprachen, Protokollierung und Überwachung bis hin zu Cloud-basierten Netzwerken, Service-Meshes, Beobachtbarkeit, Kubernetes-Clustern und den gefürchteten YAML-Dateien.
Back-End-Entwickler könnten eine Pause gebrauchen – oder, genauer gesagt, eine bessere Entwicklererfahrung. Glücklicherweise beeilen sich die Toolhersteller, dies zu ermöglichen. Von der Senkung der Hürde für Infrastruktur als Code über die Vereinfachung von Kubernetes-Workflows und verteilten Anwendungsbereitstellungen bis hin zur Einrichtung von Entwickler-Workspaces in der Cloud auf Abruf – eine neue Welle von Projekten verspricht, den Entwicklern, die auf der Serverseite schuften, das Leben zu erleichtern.
Auch Backend-Entwickler haben Gefühle
In der heutigen Cloud-nativen Welt werden Entwickler aller Art natürlich zu Tools tendieren, die intuitiver und angenehmer zu bedienen sind, selbst wenn sie in einem Bereich arbeiten, der typischerweise nicht auf Einfachheit und Benutzerfreundlichkeit optimiert ist.
Während Unternehmen wie Vercel und Netlify viel Erfolg damit haben, sich auf die Erfahrung der Front-End-Entwickler zu konzentrieren und das Back-End zu abstrahieren, wollen viele Unternehmen immer noch eine gewisse Kontrolle über ihre Server-Infrastruktur haben. Aber auch die für das Backend verantwortlichen Entwickler wünschen sich ein besseres Erlebnis.
„Es ist nur natürlich, dass die Anbieter es den Entwicklern leichter machen, diese Dinge zu tun, und das ist der Punkt, an dem die Infrastruktur auf die Softwareentwicklung trifft“, so RedMonk-Analyst James Governor gegenüber InfoWorld. „Am Ende des Tages braucht man Plattformen, die es einem ermöglichen, produktiver zu sein, ohne sich manuell mit Helm-Diagrammen, Operatoren oder YAML auseinandersetzen zu müssen.“
Die Verbesserung der Backend-Entwicklererfahrung kann mehr als nur das Leben der Backend-Entwickler verbessern. Durch die Bereitstellung besserer, intuitiverer Tools können Back-End-Entwickler mehr erreichen und gleichzeitig die Hürden senken, damit eine größere Gruppe von Entwicklern ihre eigene Infrastruktur durch durchdachte Abstraktionen verwalten kann.
„Die Kontrolle der Entwickler über die Infrastruktur ist kein Alles-oder-Nichts-Vorschlag“, schreibt Gartner-Analystin Lydia Leong. „Die Verantwortung kann über den gesamten Lebenszyklus der Anwendung verteilt werden, so dass Sie von den Vorteilen von „you build it, you run it“ profitieren können, ohne dass Sie Ihre Entwickler zwangsläufig mit dem Fallschirm in eine ungezähmte und unbekannte Wildnis abwerfen und ihnen Glück beim Überleben wünschen müssen, da es sich nicht mehr um ein ‚Infrastruktur- und Betriebsteamproblem‘ handelt.
Mit anderen Worten: „Es ist völlig in Ordnung, Ihren Entwicklern vollen Self-Service-Zugang zu Entwicklungs- und Testumgebungen zu gewähren und ihnen die Möglichkeit zu geben, Infrastructure-as-Code-Templates für die Produktion zu erstellen, ohne ihnen die volle Verantwortung für die Produktion zu übertragen“, schreibt Leong.
Pulumi: Developer Experience neu gemacht
Ein Beispiel dafür ist Pulumi, das darauf abzielt, die Konfiguration der Infrastruktur zu einer Aufgabe zu machen, die jeder Entwickler in seiner bevorzugten Programmiersprache erledigen kann, anstatt etwas proprietäres wie CloudFormation für Amazon Web Services (AWS), Bicep für Microsoft Azure oder YAML für Kubernetes zu verwenden. Die Open-Source-Engine Pulumi konfiguriert dann die virtuelle Infrastruktur und die Endpunkte für den einzubringenden Code.
Pulumi ist im Grunde eine weitere Option für die Bereitstellung von Infrastruktur als Code, verspricht aber eine flachere Lernkurve als Tools wie CloudFormation oder Terraform von HashiCorp.
Joe Duffy, Gründer und CEO von Pulumi, hat über ein Jahrzehnt bei Microsoft an Entwickler-Tools gearbeitet und dabei festgestellt, dass „niemand dem Infrastrukturbereich die gleiche Sorgfalt und Liebe gewidmet hat wie der Front-End-Entwicklung“. „Die Cloud war ein langweiliger und unordentlicher Nachgedanke“, sagte er gegenüber InfoWorld.
„Die beste Technologie, die wir hatten, war Terraform, eine proprietäre Technologie, während ich einfach nur eine IDE wollte und meine Lieblingssprache verwenden wollte, aber trotzdem die Cloud in vollem Umfang nutzen wollte“, sagte Duffy.
Die Erfahrung der Entwickler ist für Pulumi das A und O“, so Duffy. „Wir wollen ein großartiges Entwicklererlebnis in einen Bereich bringen, in dem es bisher keins gab. Deshalb verwenden wir Allzwecksprachen“, sagte er. „Wir wollen, dass diese Erfahrung angenehm und nicht mühsam ist.
Für Infrastruktur-, Plattform- und Devops-Ingenieure, die in veralteten Umgebungen arbeiten, ermöglicht Pulumi die Einrichtung einer wiederverwendbaren Infrastruktur für Entwickler, komplett mit Richtlinien und Tests als Code. Pulumi hat kürzlich eine Business Critical Edition für Unternehmenskunden dieser Art angekündigt.
Für Entwickler, die in Greenfield– und Cloud-Native-Umgebungen arbeiten, ermöglicht Pulumi ein echtes Full-Stack-System, ohne dass sie neue Sprachen oder domänenspezifische Back-End-Kenntnisse erlernen müssen.
„Ich wollte eine Lösung finden, die es uns ermöglicht, die Infrastruktur zu modellieren, und zwar nicht durch das Schreiben von Konfigurationscode und das Ausführen eines Skripts, sondern als Softwareentwicklungsprozess, durch Code und einen Git-basierten Workflow“, so Andy Dang, ehemaliger leitender AWS-Ingenieur und Mitbegründer des Observability-Startups WhyLabs, gegenüber InfoWorld.
WhyLabs wandte sich an Pulumi, nachdem Dang bestehende Infrastructure-as-Code-Optionen wie CloudFormation und Terraform als zu komplex empfand und feststellte, dass insbesondere CloudFormation „nicht für den menschlichen Verzehr geschrieben ist“.
Stattdessen wollte Dang, dass die schlanken Devops- und Engineering-Teams bei WhyLabs in der Lage sind, „die Menge an infrastrukturspezifischem Wissen, das das Team benötigt, zu reduzieren, so dass sie sich am besten auf ihren spezifischen Teil des Stacks konzentrieren können“, sagte er.
HashiCorp Waypoint: Aufbau eines einheitlichen Workflow für Entwickler
Ein weiteres Unternehmen, das hier ins Spiel kommt, ist HashiCorp, Entwickler des beliebten Infrastruktur-as-Code-Tools Terraform. Mit dem Ziel, Entwicklern den Weg zur Erstellung und Bereitstellung ihrer Anwendungen auf Kubernetes und Amazons Elastic Container Service (ECS) zu ebnen, startete HashiCorp 2020 Waypoint.
„Wir glauben, dass Entwickler einfach nur deployen wollen“, so Chang Li, Director of Product Marketing bei HashiCorp, gegenüber InfoWorld.
Um ihnen dabei zu helfen, bietet Waypoint eine benutzerfreundliche Abstraktionsschicht und Schnittstelle sowohl für Entwickler als auch für Betreiber. Für Entwickler bedeutet dies eine einfache Ausführung von Build- und Release-Prozessen, während Betreiber die dringend benötigte Konsistenz und Standardisierung über verschiedene Umgebungen hinweg erhalten, und das alles mit einem einzigen Befehl: waypoint up.
„Unsere Hauptzielgruppe sind die Betreiber“, so Li. „Auf Unternehmensebene stehen die Betriebsteams unter dem Druck, einen Workflow zu standardisieren, der über mehrere Plattformen hinweg skalierbar ist. Traditionell verwenden sie CI/CD-Tools wie Jenkins oder Spinnaker und finden diese zu schwerfällig.“
Für HashiCorp „könnte Waypoint ein Ersatz für diese Manuskripte oder angepassten CI/CD-Workflows sein“, so Li. „Es sollte eine vereinfachte Erfahrung sein, ohne die komplexe Interaktion mit der zugrunde liegenden Infrastruktur.“
Es ist dieselbe Frustration mit bestehenden CI/CD-Tools, die den Docker-Gründer Solomon Hykes dazu gebracht hat, mit seinem Open-Source-Projekt Dagger zu versuchen, CI/CD entwicklerfreundlicher zu gestalten.
Render: Ein Patentrezept für Hosting-Optionen
Render wurde vom ehemaligen Risikomanager von Stripe, Anurag Goel, gegründet und möchte Entwicklern eine Mischung aus Hosting-Optionen bieten, die zwischen Plattformen mit hohem Meinungsdruck wie Heroku und der ungebundenen Komplexität von AWS liegen.
Nachdem er Stripe verlassen hatte, beschäftigte sich Goel in seiner Freizeit mit maschinellem Lernen. Während er lernte, Modelle für maschinelles Lernen zu erstellen, sah er, wie Datenwissenschaftler Tage damit verbrachten, ihre Jupyter Notebook-Umgebungen vorzubereiten. Stattdessen wollte Goel eine „Ein-Klick-Bereitstellung in der Cloud“ und eine Lösung, die der Integration von Zahlungen über die Stripe-API entsprach.
„Ich wurde immer wieder von der Infrastruktur und der Produktivität der Entwickler angezogen“, sagte er gegenüber InfoWorld. „Im Kern geht es bei Render um die Automatisierung von Devops.“
In der Praxis können Entwickler ihr GitHub- oder GitLab-Repository mit Render verbinden, das dann Befehle zum Erstellen und Starten ihrer Anwendung vorschlägt. Render ist ein proprietärer Dienst und läuft vorerst auf AWS und Google Cloud, Bare-Metal-Unterstützung wird in Kürze folgen.
„Die Leute kommen zu uns, weil sie denken, dass Kubernetes zu komplex ist, aber die Funktionen, die sie brauchen, sind in Render enthalten, weil wir auf Kubernetes aufgesetzt haben, so dass nur das sichtbar ist, was sie wollen“, so Goel.
Render unterscheidet sich von anderen Backend-as-a-Service (BaaS)-Hosting-Optionen dadurch, dass es keine Meinung darüber vertritt, wie man seine Anwendungen erstellt und ausführt, egal ob es sich um eine statische Website, einen Cron-Job oder einen Docker-Container handelt. „Wir drängen nicht auf eine bestimmte Ideologie, wie man Anwendungen erstellt“, sagte Goel.
Render ist mit seinem entwicklerzentrierten Ansatz für BaaS auch nicht allein. Das Open-Source-Projekt Appwrite beschäftigt sich mit einer selbst gehosteten Plattform, die es Entwicklern ermöglicht, Web-, Mobil- und Flutter-Anwendungen über eine Reihe kuratierter APIs einfach auszuführen.
Encore: Der Spotify-Backend-Ansatz für die breite Masse
Ein weiteres, neueres Open-Source-Projekt, das die Erfahrung von Entwicklern bei Back-End-Engineering-Aufgaben verbessern soll, ist Encore. Encore wurde in Go entwickelt und ist ein Back-End-Framework, das manuelle Konfigurationsaufgaben für Cloud-Umgebungen abstrahiert.
Encore zielt darauf ab, Entwicklern durch die Automatisierung manueller Konfigurationsschritte für die Bereitstellung der Cloud-Infrastruktur, die Generierung von Boilerplate-Code, die Instrumentierung der Anwendung und die Erstellung von Dokumentationen zu helfen, in einem reibungslosen Ablauf zu bleiben. Die Entwickler können dann auf AWS, Azure oder Google Cloud deployen.
Das Projekt wurde 2021 von den ehemaligen Spotify-Ingenieuren André Eriksson, Marcus Kohlberg und Horia Jurcu zusammen mit dem Ex-Monzo-Ingenieur Dominic Black und dem Ex-Google-Ingenieur Stefan Ekerfelt gegründet. Die Gründer sagen, dass Encore aus ihrer gemeinsamen Frustration über den Aufbau einer komplexen, verteilten Backend-Infrastruktur und die ständige Wiederholung bestimmter Backend-Aufgaben entstanden ist.
Encore strebt danach, „die guten Seiten der Cloud zu bewahren und zu ändern, woran Entwickler arbeiten, damit sie Produkte entwickeln können und nicht in den Sümpfen von YAML und Plumbing versinken“, so Eriksson gegenüber InfoWorld.
Das Startup hat eine 3-Millionen-Dollar-Startkapitalrunde unter der Leitung von Crane Venture Partners erhalten und seine Open-Source-Backend-Entwicklungsmaschine im April 2022 allgemein verfügbar gemacht.
Gitpod: On-demand-Entwicklerumgebungen
Und dann ist da noch Gitpod, ein Open-Source-Projekt, das sich mit dem sehr spezifischen Problem auseinandersetzt, Entwicklern ihre gewohnte lokale Entwicklungsumgebung zur Verfügung zu stellen, die jedoch in Sekundenschnelle in der Cloud einsatzbereit ist.
Während sich die Branche weitgehend auf die automatisierte Erstellung von Infrastrukturen und Deployment-Pipelines verlegt hat, hielt es Mitbegründer Johannes Landgraf für „irgendwie verrückt“, dass Entwickler immer noch „Entwicklungsumgebungen replizieren, die auf einzelnen Computern sitzen und deren Konfiguration sich ändert.“
Gitpod beginnt mit einer YAML-Datei, die beschreibt, wie die Entwicklerumgebung aussehen soll, von der IDE bis zur Datenbank, komplett mit Compilern, Sprachservern und dem Betriebssystem. „Alles, was sich auf dem lokalen Computer befindet, portieren wir in die Cloud mit der gleichen Erfahrung, die Entwickler gewohnt sind“, so Landgraf.
Gitpod lässt sich in GitHub, GitLab und Bitbucket integrieren und erstellt alle Projekte im Voraus, sobald Code in das Projektarchiv geladen wird, wie ein kontinuierlicher Integrationsserver. Wenn Entwickler eine Umgebung aufsetzen, ist alles bereits initialisiert und einsatzbereit. Sie müssen nicht darauf warten, dass die Dependencies geladen und die Skripte erstellt werden.
Die Erfahrung der Entwickler ist „Teil unserer Kern-DNA“, so Landgraf. „Unser Ziel ist es, so viele Hindernisse wie möglich aus dem Weg zu räumen, damit Entwickler das tun können, wofür sie bezahlt werden und was sie lieben, nämlich kreativ zu sein, Code zu schreiben und Mehrwert zu schaffen, anstatt sich mit Dingen herumzuschlagen, die sie ausbremsen.“
Das Open-Source-Projekt hat bereits großen Anklang gefunden, und GitHub wird bald nachziehen und 2021 seine eigene Cloud-basierte Entwicklungsumgebung namens Codespaces einführen.
Alle GitHub-Ingenieure arbeiten jetzt in Codespaces, wo „Entwicklungsumgebungen bei Bedarf für die jeweilige Aufgabe bereitgestellt werden“ und Entwickler „zuverlässige, vorkonfigurierte Codespaces erstellen können, die in 10 Sekunden für die Entwicklung auf GitHub.com bereit sind“, so Cory Wilkerson, Senior Director of Engineering bei GitHub.
Wie AWS, Azure und Google Cloud den Aufbau von Infrastrukturen vereinfachen
Die drei großen Cloud-Anbieter bieten nach wie vor eher primitive Lösungen als individuelle Tools an. Letztes Jahr hat AWS jedoch mit der Einführung von AWS Proton begonnen, Unternehmen die Möglichkeit zu geben, ihren eigenen Satz an wiederholbaren Umgebungsvorlagen zu konfigurieren. Dieses Self-Service-Tool ermöglicht Entwicklern die Bereitstellung in einer produktionsbereiten Infrastruktur, die bereits von einem spezialisierten Devops- oder Plattformteam erstellt und genehmigt wurde.
Proton unterscheidet sich von vollständig verwalteten Backend-Lösungen wie AWS App Runner oder AWS Amplify, die einen Schritt weiter gehen, indem sie die gesamte Konfiguration, das Netzwerk, den Lastausgleich und die Bereitstellungspipelines für Web-, Mobil- oder containerisierte Anwendungen verwalten, die in der Cloud laufen sollen.
Google und Microsoft bieten ähnliche Backend-Dienste wie Google Firebase und Azure App Service, aber nicht die Möglichkeit, unternehmensspezifische Umgebungsvorlagen zu erstellen, die Proton bietet.
Ermöglichung echter Self-Service-Entwicklung
Selbst wenn Entwickler immer mehr gute Möglichkeiten haben, ihre Backend-Entwicklungsaufgaben zu abstrahieren, wird es immer noch eine große Nachfrage nach Tools geben, die es Unternehmen ermöglichen, ihre eigene Infrastruktur bereitzustellen und zu verwalten und sie für Entwickler sauber zu katalogisieren.
„Es ist noch sehr früh für diese Tools, aber ich sehe eine schnelle Akzeptanz, weil sie zwei häufige Probleme lösen, die wir oft hören: Die Unternehmens-IT will Umgebungen abriegeln und Entwickler davon abhalten, unregulierte Dinge in die Organisation zu bringen“, sagte der ehemalige Gartner-Analyst Fintan Ryan gegenüber InfoWorld.
Wenn diese Tools auch noch in der Lage sind, die mit verschiedenen Backend-Engineering- und -Entwicklungsaufgaben verbundenen Mühen zu abstrahieren, dann werden sie nicht nur in den Kreis der Gewinner dieser aufstrebenden Kategorie aufgenommen, sondern auch in die Herzen und Köpfe der Entwickler von Backend-Anwendungen und -Diensten.
Dieser Beitrag basiert auf einem Artikel unserer Schwesterpublikation InfoWorld.
*Scott Carey ist leitender Redakteur für Nachrichten bei den fünf B2B-Marken von Foundry – Computerworld, CIO, CSO, Network World und InfoWorld.
Be the first to comment