Foto: oxinoxi - shutterstock.com
Anwender von heute erwarten, dass ihnen das gesamte Internet zur Verfügung steht, egal wo sie sind oder welches Gerät sie benutzen. Bis vor kurzem fiel es App-Entwicklern allerdings noch schwer, diesen Ansprüchen zu genügen. In den letzten Jahren haben sich Smartphones, Browser und Embedded Devices aber so weit entwickelt, dass sie als weltweit verteilte, mobile Rich Clients funktionieren. Sie können unterwegs eine Benutzererfahrung liefern, die mit der Verwendung einer lokalen oder dedizierten Highspeed-Leitung vergleichbar ist.
Diese Errungenschaft ist zum Teil auf die zunehmende Verbreitung von Serverless-Architekturen, Microservices und Cloud-native-Diensten zurückzuführen - und die Art und Weise, wie sie es Entwicklern ermöglichen, skalierbare und an jedem Ort der Welt zuverlässig funktionierende Webanwendungen zu erstellen.
Ein neues Rich-Client-Paradigma für die App-Entwicklung
Mit diesem wachsenden Trend rückt ein neues Paradigma für vernetzte Internet-Anwendungen in den Vordergrund, bekannt als Client-Serverless Computing. Es liefert durchgängig dynamische, interaktive Anwendungserlebnisse von jedem Smartphone oder Edge-Gerät aus, unabhängig davon, wo sich ein Benutzer gerade befindet oder von wo aus die Ressourcen, auf die er zugreift, bereitgestellt werden.
Client-Serverless Computing stellt aber auch höhere Anforderungen an die Entwickler. Diese können nämlich nicht mehr davon ausgehen, dass ihr Programmcode primär auf Datenbanken, App-Server und Webserver zugreift, die sich in einem einzigen Rechenzentrum oder einer Cloud-Region befinden.
Stattdessen müssen sie serverseitige Business Logic und Markups erstellen, sowie auf Client-Seite mit Hilfe von JavaScript für die optimierte Darstellung auf unzähligen Client-Geräten sorgen. Sie müssen Anwendungen programmieren, die für anspruchsvolle, Browser-seitige Interaktion über Standardschnittstellen wie REST (für Remote-APIs) oder JSON (für Datenformate) optimiert sind.
- Produkt- & Projektmanager
Ganz generell schätzen es Entwickler nicht so besonders, wenn ihnen jemand erklären will, wie sie ihren Job zu machen haben. Weil Produkt- und Projektmanager aber oft Entwickler-Teams leiten, passiert genau das. Das kann zu Unstimmigkeiten führen. <br /><br /> Dazu hat auch David Fox von devRant eine Meinung: "Letztendlich ist es in den meisten Fällen so, dass Produkt- und Projektmanager in irgendeiner Art und Weise die 'Besitzer' von Projekten und Prozessen sind, ohne dabei die täglichen Herausforderungen und Probleme der Softwareentwickler zu kennen." - Chefs
Genau wie die Produkt- und Projektmanager sind auch Development oder Engineering Manager dafür zuständig, Teams von Entwicklern zu führen und sicherzustellen, dass Projekte rechtzeitig und unter Budget fertiggestellt werden. <br /><br /> "In einigen Unternehmen können Situationen entstehen, in denen der Chef gleichzeitig Mitglied des Entwicklerteams ist. Insbesondere wenn der Chef vorher selbst Entwickler war und nach einer Beförderung zum Chef wird, ist Konfliktpotenzial gegeben", merkt Fox an. - Recruiter
Softwareentwickler müssen gar nicht selbst aktiv nach einem Job suchen, um von Recruitern und Headhuntern belästigt zu werden - dem Fachkräftemangel sei Dank. Es dürfte sehr schwer sein, einen Developer zu finden, der noch nicht in die Fänge der Recruiter geraten ist. <br /><br /> David Fox sieht insbesondere die Hartnäckigkeit der Recruiter als Problem: "Sie rufen an, sie e-mailen und sie lassen Dich einfach nicht in Ruhe - selbst dann, wenn Du gar keinen Job suchst. Und selbst wenn man eine Anstellung sucht, neigen viele Recruiter dazu, irrelevante Jobangebote zu machen oder Stellen zu empfehlen, deren Profil überhaupt nicht passt - etwa einen Job am anderen Ende des Landes, obwohl man gar nicht bereit ist, umzuziehen." - Dokumentation
Gibt es keine Dokumentation, beschweren sich die Softwareentwickler. Wenn es zuviel ist, beschweren sie sich und wenn sie die Dokumentation selbst erledigen müssen, auch. Sogar über die Art und Weise, wie andere Leute die Dokumentationsaufgabe bewältigen, beschweren sich die Entwickler. <br /><br /> An dieser Stelle seien sich auch endlich einmal alle Entwickler einig, wie Fox betont: "Softwareentwickler wollen eine ausführliche, gut geschriebene und akkurate Dokumentation - aber selber machen wollen sie es nicht." - Meetings
Meetings sind nicht nur für alle anderen ein Problem, sondern auch für Softwareentwickler. Insbesondere dann, wenn es sich um völlig unnötige, zeitraubende und stinklangweilige Zusammenkünfte handelt. Wie Fox erzählt, sind inzwischen auch Devotionalien mit der Aufschrift 'I survived another meeting that should have been an email' erhältlich. - Coworking Spaces
Mit dem Aufstieg der Agilität sind flache Hierarchien, Collaboration und Teamwork zum Alltag in Unternehmen geworden - insbesondere für Software-Development-Teams. Gerade die können ihre Arbeit in einem Großraumbüro aber meist nur schwer oder gar nicht bewältigen - sagen zumindest die Zahlen von devRant. <br /><br /> David Fox erklärt: "Es gibt einfach zuviel Ablenkung: die Kollegen unterhalten sich, Meetings werden verpasst, Telefonanrufe überhört. Es gibt auch eine Vielzahl an Beschwerden über den Kaffee im Büro und andere Annehmlichkeiten - oder eben das Gegenteil davon." - Kollegen
Selbsterklärend: Jeder hat wohl einen Kollegen oder eine Kollegin, den beziehungsweise die er ganz besonders schätzt. Nicht. <br /><br /> Im Fall der Softwareentwickler ist die Abneigung gegenüber Kollegen meist entweder in der mangelnden Qualität ihrer Arbeit oder einem völlig aus dem Leim gegangenen Ego begründet, gibt David Fox preis. - Vorstellungsgespräche
Wenn ein Softwareentwickler auf Jobsuche ist und zum Bewerbungsgespräch geladen wird, gibt es danach meist auch etwas zu meckern: <br /><br /> "Dumme Fragen oder die Lösung von völlig praxisfernen Aufgaben im Bewerbungsgespräch stoßen den Developern ebenso sauer auf, wie ein Gesprächspartner, der überhaupt nicht weiß, was ein Entwickler eigentlich genau macht", so Fox. - Fehler & Bugs
Softwareentwickler haben tagein, tagaus mit Fehlern und Bugs zu tun. Deswegen glaubt devRant-Gründer Fox, dass Entwickler in dieser Sache anders ticken: <br /><br /> "Die meisten anderen Probleme erfahren keine positive Auflösung, aber Bugs und Fehler sind behebbar und das fühlt sich gut an." - Quality Assurance
Die Quality Assurance (QA) - oder Qualitätssicherung - ist ein kritischer Teil der Softwareentwicklung. Dennoch bemängeln Softwareentwickler an QA-Experten häufig dieselben Dinge wie an Produkt- und Projektmanagern, so Fox. <br /><br /> "Die Qualitätssicherung bekommt das Produkt oder Projekt in die Hände, wenn die Entwickler es abgeschlossen haben. Deswegen verstehen sie oft nicht, welche Hürden und Workarounds die Entwickler im Entstehungsprozess bewältigen mussten. Offensichtlich kommt es auch regelmäßig vor, dass QA-Leute die Entwickler bitten, Bereiche nochmals zu überarbeiten, die sie auch selbst bewältigen könnten."
Schnelle Entwicklung von Rich Cloud Apps
Die Ursprünge von Client-Serverless liegen in den altbewährten dreistufigen Anwendungsarchitekturen, die rund um PCs und lokale Netzwerke entstanden sind und eine Client-seitige GUI mit einer Backend-SQL-Datenbank verbanden. Dieses neue Paradigma eignet sich jedoch viel besser für Multicloud-Computing-Plattformen des 21. Jahrhunderts. Der Grund dafür liegt darin, dass Client-Serverless:
kombinierbare Funktionen bei geringer Latenzzeit über eine konsistente, sichere, Web-native API bereitstellt, die von jeder Client-Anwendung und auf einer Pay-as-you-go-Basis aufgerufen werden kann.
die einfache Bereitstellung, Zusammenstellung und On-Demand-Nutzung von Anwendungen ermöglicht - und das von jeder beliebigen Computerinfrastruktur aus.
es Entwicklern erlaubt, Funktionen schnell und skalierbar in Cloud-to-Edge-Umgebungen bereitzustellen.
sicherstellt, dass die App-Performance nicht nachlässt, auch wenn die zugrundeliegende Business-Logik weit verteilt ist.
die physischen Standorte und operativen Plattformen, von denen aus die Logik der Backend-Anwendung bedient wird, wegabstrahiert.
die Notwendigkeit für Programmierer eliminiert, die Logik für die Verwaltung von Containern, Virtual Machines und anderen Runtime Engines im Backend zu schreiben, denen die Ausführung der Anwendungslogik dynamisch zugewiesen wird.
die Dichte, Effizienz und Kapazitätsauslastung von CPU, Arbeitsspeicher, Speicher und anderer Hardware auf den Backend-Cloud-Plattformen steigert.
Keine Angst vor Lock-ins
Die Serverless-Komponente in diesem Ansatz bezieht sich auf ein Utility-Computing-Modell, bei dem der Cloud-Anbieter die Zuweisung von Maschinenressourcen im Backend für die Ausführung der Geschäftslogik in der Anwendung dynamisch verwaltet.
"Der Aufstieg der Jamstack-Architektur (JavaScript, APIs, Markup) hat sicherlich die Verwendung von Serverless-Apps vorangetrieben und es vielen zusätzlichen Entwicklern ermöglicht, solche zu bauen ", erklärt Evan Weaver, Chief Technology Officer bei Fauna, Anbieter einer Serverless-Transaktionsdatenbank. "Aber es gibt noch viele andere Architekturen, wie die explosionsartige Zunahme von Microservices zeigt, die ebenfalls von dieser neuen Art des Computing Gebrauch machen. Heute haben Entwickler mehr Optionen denn je, wenn sie Anwendungen erstellen wollen."
Die Client-Serverless-Infrastruktur und -Tools ermöglichen es Entwicklern, Client-Serverless-Cloud-Apps mit vielen günstigen Eigenschaften zu bauen. So sind diese Anwendungen im Allgemeinen:
Zusammensetzbar: Client-Serverless-Tools verwenden Internet-kompatible APIs, um Backend-Funktionen zu nutzen, auf die als Microservices in SaaS-Clouds zugegriffen wird.
Flexibel: Die Abstraktionsschichten von Client-Serverless können die Entwicklung von verteilten Cloud-Anwendungen beliebiger Größe, Komplexität und Funktionalität unterstützen. So sind Entwickler in der Lage, die Client-Logik als Microservices für Serveranwendungen, Workflow-Engines und andere Infrastrukturkomponenten bereitzustellen.
Robust: Client-Serverless-Umgebungen ermöglichen die Entwicklung von sicheren, zuverlässigen, zustandsabhängigen und transaktionskonsistenten Anwendungen. Zum Einsatz kommen sichere Datenbanken, die über Serverless-Daten-APIs überall in einer verteilten Umgebung verfügbar sind.
Dynamisch: Client-Serverless treibt die Einführung von Cloud-Infrastrukturen voran, die sich vom Managed-VM- und Containermodell mit seiner inhärenten statischen Bereitstellung, der Verschwendung von Ressourcen, dem operativen Overhead und den Sicherheitsproblemen wegentwickeln. Stattdessen bewegt sich die Cloud-Infrastruktur zu einem API-Modell hin, das dynamisch, unbegrenzt skalierbar und allgegenwärtig ist, ohne dass der Kunde mit Betriebskosten belastet wird. Mehr und mehr werden auch über API zugängliche Geschäftsfunktionen wie Stripe Payments oder Twilio-Messaging, in Client-Serverless-Umgebungen gebracht, ohne dass der Betrieb beeinträchtigt wird.
Rosige Wachstumsaussichten
Alles deutet darauf hin, dass Client-Serverless-Tools und -Plattformen im Jahr 2021 und darüber hinaus einen großen Einfluss auf die IT und die Welt der Anwendungsentwicklung haben werden. So beginnen immer mehr Unternehmen damit, auf anspruchsvolle Serverless-Datenplattformen, -Compute-Backends wie AWS Lambda und Cloudflare Workers, Serverless-Data-Warehousing-Angebote wie Snowflake und Serverless Development Frameworks wie Next.js und RedwoodJS umzusteigen.
Zwar haben reine Client-Serverless-Technologien wie Jamstack, GraphQL und die Fauna-Datenbank noch keine allgemeine Akzeptanz unter den Entwicklern in Unternehmen erreicht. Dennoch nutzen Unternehmen Serverless-Backends, um ihre Anwendungsinfrastruktur standortunabhängig und völlig entkoppelt von jeglicher physischer Infrastruktur zu skalieren.
Und mit der Beschleunigung der Client-Serverless-Revolution werden sich Serverless-Computing-Umgebungen weit über ihren bisherigen Fokus auf Rechenfunktionen hinaus in Richtung eines Client-fokussierten Schwerpunkts auf Rich-Mobile- und Edge-Anwendungen bewegen. Der Aufstieg von Client-Serverless-Umgebungen wird mit ziemlicher Sicherheit das nächste Uber oder Twitter hervorbringen, da kleine, aber fokussierte Entwicklungsteams das Transformationspotenzial dieses neuen Anwendungsparadigmas ausschöpfen werden. (mb)
Dieser Artikel basiert auf einem Beitrag der US-Schwesterpublikation Infoworld.