Der Serverless-Lebenszyklus: Ist er wirklich so anders?

Einführung

In der heutigen Welt schreitet die technologische Innovation mit halsbrecherischer Geschwindigkeit voran. Es ist erst 15 Jahre her, dass wir Anwendungen auf Bare-Metal-Servern mit Disketten installiert haben. Seitdem sind wir zu virtuellen Maschinen, Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS) übergegangen. Und vor kurzem sind wir in eine Welt eingetreten, in der die Containertechnologie allmählich zum Mainstream wird. Der nächste Schritt ist das serverlose Computing. Oder, wie Martin Fowler es in seinem Blog beschreibt, Functions as a Service (FaaS) und Backend as a Service (BaaS). Dies ist ein weiterer "*aaS", den Sie bei der Auswahl Ihrer Hosting-Plattform im Auge behalten sollten. Und genau wie jede andere Anwendung erfordert eine serverlose Anwendung ein angemessenes Lebenszyklusmanagement. In diesem Artikel werden wir diesen serverlosen Lebenszyklus erörtern und sehen, worin er sich von "normalen" Anwendungen, die Sie alle kennen, unterscheidet.

Serverloses Rechnen

Was also ist serverloses Computing? Natürlich ist immer noch irgendwo ein Server im Spiel. Er wird nur nicht von Ihnen verwaltet, sondern von einem Cloud-Anbieter. Für eine ausführliche Erklärung lesen Sie bitte den Artikel Die (R)Evolution des Cloud Computing an anderer Stelle in diesem Magazin. Was diesen Artikel betrifft, so sind wir der Meinung, dass Serverless am besten als PaaS++ betrachtet werden kann.

Wenn es um FaaS geht, bieten sowohl Amazon als auch Microsoft cloudbasierte Lösungen an. Amazon Web Services (AWS) bietet AWS Lambda und Microsofts Azure bietet Azure Functions. Dieser Artikel konzentriert sich in erster Linie auf den Azure-Stack, aber er gilt auch für AWS.

Der Lebenszyklus von Serverless

Eine serverlose Anwendung ist in der Regel sehr klein, aber dennoch ist sie eine Anwendung. Und wie bereits erwähnt, hat jede Anwendung einen Lebenszyklus und dieser Lebenszyklus muss verwaltet werden. Die FaaS-Implementierung in Azure, Azure Functions, ist relativ neu und das Marketing rund um Azure Functions konzentriert sich stark auf die einfache und reibungslose Bearbeitung "im Browser". Das ist zwar sehr leistungsfähig, aber auch sehr gefährlich und bei einer Produktionsanwendung möglicherweise sogar unerwünscht. Genau wie die berüchtigte Funktion "Rechtsklick, Veröffentlichen" in Visual Studio können Sie damit Ihre Anwendung direkt in der Produktion veröffentlichen, ohne irgendeinen Prozess zu durchlaufen. Natürlich gibt es Rechte und Sicherheit, aber stellen Sie sich doch einmal vor, was passiert, wenn jemand "versehentlich" eine stark genutzte Produktionsfunktion bearbeitet.

 

Anforderungen

Werden sich die Anforderungen für serverlose Anwendungen ändern? Sicherlich hängt es davon ab, wie Sie Ihre Anforderungen definieren, aber Anforderungen sollten den funktionalen und nicht-funktionalen Teil einer Anwendung beschreiben und sich dabei von technischen Implementierungsdetails fernhalten. Eine serverlose Architektur befasst sich mit der technischen Umsetzung einer Anforderung. Der Prozess des Sammelns und Verfeinerns von Anforderungen selbst sollte sich nicht ändern.

Entwicklung

Die Auswirkungen auf Ihren Entwicklungszyklus sind wahrscheinlich größer. Im Vorfeld müssen viele Entscheidungen getroffen werden. Welche Sprache werden Sie verwenden? Azure Functions unterstützt viele Sprachen wie C#, Python, Node.JS, Powershell, PHP, usw. Und welche IDE werden Sie verwenden? Das Wichtigste ist, dass Sie im Voraus denken und Ihre Test-, Build- und Release-Strategie definieren, um eine gute Wahl zu treffen. Wenn Sie zum Beispiel Unit-Tests sowie eine Build- und Release-Pipeline benötigen, ist die Bearbeitung Ihres Codes direkt in einem Webbrowser wahrscheinlich nicht die beste Option. Werfen wir einen Blick auf unsere Entwicklungsstrategie und die Optionen, die Sie haben.

Was entwickeln wir?

Wenn Sie eine serverlose App erstellen, können Sie eine Projektvorlage in Visual Studio herunterladen und loslegen. In den meisten Fällen ist das jedoch nicht genug. Ihre Anwendung (oder sollten wir sagen Funktion) braucht wahrscheinlich ein Backend, einen Datenspeicher, Azure Blob Storage oder eine MongoDB. Sie können dies manuell erstellen und Ihre Funktion entsprechend konfigurieren, aber in der modernen DevOps-Welt sollten wir danach streben, alles zu automatisieren. Das bedeutet, dass Sie die Infrastruktur für Ihre Anwendung zusammen mit der Anwendung selbst entwickeln sollten, indem Sie das Infrastructure-as-Code-Paradigma verwenden, um eine vollständig automatisierte Bereitstellung zu ermöglichen. Ob Sie nun eine ARM-Vorlage auf Azure, CloudFormation auf AWS oder Docker-Container auf einem gehosteten Cluster verwenden, in jedem Fall müssen Sie sowohl den Anwendungscode als auch den Infrastrukturcode entwickeln.

 

Wie man entwickelt

Und dann ist da noch die Frage, wie Sie Ihren Code entwickeln werden. Wenn Sie sich auf Azure Functions als Plattform mit C# als Sprache Ihrer Wahl konzentrieren, haben Sie vier Optionen, um serverlose Anwendungen zu entwickeln.

Schreiben Sie Code direkt im Browser

Der schnellste Weg, eine Azure-Funktion zu erstellen, besteht darin, sie direkt im Browser zu schreiben, zu testen und zu überwachen. Die Benutzerfreundlichkeit hat jedoch ihren Preis. Sie haben keine Pipeline, keine Unit-Tests und nicht einmal ein unterstützendes Repository für die Versionskontrolle. Daher eignet sich diese Methode wahrscheinlich nicht für Ihre Unternehmensanwendung, bei der in der Regel ein höheres Maß an Rückverfolgbarkeit und Kontrolle erforderlich ist. Die Erstellung und Bearbeitung direkt im Browser eignet sich jedoch hervorragend für das schnelle Prototyping, das schnelle Ausprobieren einer Idee oder die Erstellung einer kleinen Anwendung, die Sie nur für sich selbst verwenden.

Verbinden Sie ein Repository mit Azure Functions

Mit Azure Functions können Sie ein bestehendes Repository mit Ihrer Azure Function verbinden und so das Problem der Versionskontrolle lösen. Sie haben verschiedene Optionen für die Art des Repositorys, das Sie verwenden möchten, zum Beispiel ein Repository in VSTS oder GitHub, aber auch Lösungen wie OneDrive und Dropbox sind eine Option.

Immer wenn eine Änderung im Repository übertragen oder gespeichert wird, wird diese automatisch bereitgestellt. Im Falle von OneDrive oder Dropbox geschieht dies jedes Mal, wenn jemand eine Datei ändert. Bei einem Git-Repository ist die Bereitstellung immer mit einem bestimmten Zweig (z.B. Master) verbunden. Dadurch haben Sie etwas mehr Kontrolle, da Sie mithilfe von Verzweigungsrichtlinien steuern können, welcher Code in diese Verzweigung zusammengeführt wird. Für größere Unternehmen, in denen eine Anwendung in der Regel verschiedene Test- und Abnahmestufen durchläuft, bevor sie in die Produktion geht, bietet dies jedoch nicht das erforderliche Maß an Kontrolle. Diese Art der Entwicklung und Bereitstellung eignet sich am besten für kleine Teams, die kleine Anwendungen schreiben und die zusätzlichen Überprüfungsschritte einer Build- und Release-Pipeline nicht benötigen.

Verwendung Ihrer bevorzugten IDE und ihrer Funktionen

Wenn Sie noch einen Schritt weiter gehen wollen, können Sie die Leistungsfähigkeit Ihrer bevorzugten IDE nutzen. Das bedeutet, dass Sie Ihre Azure-Funktionen lokal ausführen können, so dass Sie sie debuggen können. Und wenn Sie sie wie jede normale Anwendung entwickeln, können Sie vertraute Praktiken anwenden, um Dinge wie Rückverfolgbarkeit und kontrollierte Freigaben zu erreichen. Der Code wird in der Versionskontrolle gespeichert und Sie können eine Build & Release Pipeline erstellen (siehe Technische Einführung in Microsoft Azure Functions), um Ihre Funktionen auf Azure zu veröffentlichen. Wenn Sie Azure Functions in C# schreiben, sollten Sie mit den Visual Studio Tools für Azure Functions vertraut sein. Damit können Sie innerhalb von Visual Studio ein Azure Functions-Projekt erstellen, das bereits über einen schönen Boilerplate-Code verfügt. Die einzige Herausforderung, die in diesem Szenario bleibt, ist das Testen. Das Testen Ihrer Azure-Funktionen, die als C#-Skriptdatei (CSX) geschrieben wurden, ist recht begrenzt. Die Visual Studio Tools für Azure-Funktionen bieten Ihnen lokale Kompilier-, Build- und Debug-Erfahrung mit Dingen wie Haltepunkten, Watches usw. Allerdings ist es nicht möglich, Unit-Tests auf CSX-Dateien auszuführen. Das bedeutet, dass die meisten Ihrer lokalen Tests manuell durchgeführt werden, was in der heutigen Welt, in der der Schwerpunkt Ihrer Tests auf der Ebene der Unit-Tests liegen sollte(Konzept der Testpyramide), nicht tragbar ist. Aufgrund dieser Einschränkung empfehlen wir Ihnen, den Ansatz der vorkompilierten Assemblierung zu verwenden, wie im folgenden Absatz beschrieben.Azure Functions unterstützt jedoch eine ganze Reihe anderer Sprachen (wie Node.js und PHP), für die Unit-Tests sehr gut möglich sind. Wenn Sie eine dieser Sprachen verwenden, können Sie mit der Azure Functions CLI Ihre Azure Function lokal ausführen und debuggen. Mit diesem Ansatz können Sie mit Azure Functions unternehmenstaugliche Anwendungen entwickeln.

CSX-Dateien schreiben und eine C#-Klassenbibliothek referenzieren

 

Wenn Sie C# schreiben und nahe am üblichen Entwicklungsfluss bleiben wollen, ist die beste Alternative die Verwendung einer vorkompilierten Assembly, die Sie in Ihrer CSX-Datei referenzieren können, so dass Ihre CSX nichts weiter als ein Wrapper um eine "normale" Klassenbibliothek ist. Wenn Sie die Klassenbibliothek verwenden, können Sie das Standard-Toolset für Unit-Tests und alle anderen Funktionen nutzen, die Sie von Visual Studio gewohnt sind. Sie können Dinge in der Versionsverwaltung speichern, Builds und Releases erstellen und haben trotzdem eine hochmoderne serverlose Funktion. Die folgende Tabelle fasst die zuvor skizzierten Entwicklungsmöglichkeiten zusammen: Quellcodekontrolle Testen Bereitstellung Typische Anwendung Schreiben Sie Code direkt im Browser Keine Manuelle Tests mit z.B. Postman oder curl Code wird direkt veröffentlicht, wenn Sie auf "Speichern" klicken Rapid Prototyping Ein Repository mit Azure Functions verbinden Einfach (z.B. OneDrive) bis vollständig (z.B. Git) Möglich, aber keine Integration Direkt vom Repository in die Produktion Kleine Teams ohne Bedarf an einer Build & Release Pipeline Verwenden Sie Ihre bevorzugte IDE und deren Funktionen Vollständige C#/CSX: Keine Unit-Tests, andere Sprachen: vollständig Vollständige Build- & Release-Pipeline Anwendungen im Unternehmensmaßstab Schreiben Sie CSX-Dateien und referenzieren Sie eine C#-Klassenbibliothek Vollständig Vollständig Vollständige Build- & Release-Pipeline Anwendungen im Unternehmensmaßstab

Bauen Sie

Der Zweck einer Build-Pipeline besteht darin, Artefakte zu erzeugen, die in mehreren Umgebungen eingesetzt werden können. Wenn Sie beispielsweise eine normale Webanwendung erstellen, bauen Sie ein MSDeploy-Paket, das Sie mit den richtigen Werten für seine Parameter in Ihrer Release-Pipeline versehen. Oder wenn Sie Container verwenden, wird Ihre Build-Pipeline zu einer "Bakery", um einen Container zu erzeugen und ihn in einem Container-Repository zu veröffentlichen, so dass er auf jeder Hosting-Plattform verwendet werden kann, die Container unterstützt.Wenn es um Ihre serverlose Anwendung geht, wird Ihr Build das gleiche sein, was Sie gewohnt sind. Der Build erzeugt die Binärdateien und andere Dateien für Ihre Anwendung, die Artefakte zur Erstellung der zugrunde liegenden Infrastruktur und enthält einige Konfigurationseinstellungen, die während der Bereitstellung in Ihrer Release-Pipeline geändert werden können. Die Durchführung von Tests, für die keine laufende Anwendung erforderlich ist, ist in der Regel auch etwas, das Sie in Ihre Builds aufnehmen möchten. Zum Beispiel die Unit Tests und die ARM-Validierung für Ihren Infrastrukturcode.

Test

Die schwierigste Phase des Lebenszyklus einer Anwendung ist (wie bereits erwähnt) die Testphase. In einem kontinuierlichen Arbeitsablauf ist es von entscheidender Bedeutung, dass Sie während des gesamten Lebenszyklus Ihrer Anwendung kontinuierlich testen und Feedback zu den von Ihnen ausgeführten Schritten erhalten. Idealerweise sollten Sie den Aufwand für die Erstellung verschiedener Arten von Tests entsprechend der Testpyramide verteilen.

 

Wenn Sie einen Webservice oder eine API auf herkömmliche Weise erstellen, erstellen Sie Unit-Tests, um das Innenleben Ihrer Methoden zu testen (Unit-Ebene), und API-Tests, um die korrekte Implementierung der Schnittstelle zu validieren und sicherzustellen (Service-Ebene). In einem späteren Stadium sind Integrationstests erforderlich, um die Beziehungen zu anderen Komponenten oder Diensten zu testen (UI-Ebene). Schließlich benötigen Sie noch einige Lasttests, um zu überprüfen, ob Ihr Dienst auch unter Last funktioniert.Alle diese Testarten sind auch im serverlosen Kontext relevant. Bei der Erstellung einer serverlosen Anwendung stellt sich jedoch die Frage, ob alle Tests das gleiche Gewicht haben sollten, wie bei der Verwendung einer traditionellen Entwicklungsmethode für Ihre Anwendung. Auf der Unit-Ebene sollten Sie Ihre Funktionen in irgendeiner Form manuell testen. In der Dokumentation zu Azure Functions werden manuelle Tests mit einigen http-Clients wie Postman oder Curl beschrieben. Wie bereits erwähnt, ist dies einfach und leicht zu handhaben, aber nicht nachhaltig, wenn Sie eine große Anzahl von Funktionen haben, die getestet und gepflegt werden müssen. Für automatisierte Unit-Tests sollten Sie die Möglichkeiten Ihrer IDE nutzen, wie im vorherigen Kapitel beschrieben. Für API- und Integrationstests (auf Service- und UI-Ebene) muss Ihre Funktion ausgeführt werden und von außen zugänglich sein. Natürlich gibt es den Emulator, mit dem Sie Ihre Azure Function lokal ausführen können, aber irgendwann werden Sie Ihre Funktion in der "Realität" ausführen wollen. Dazu müssen Sie Ihre Funktion irgendwo bereitstellen und ausführen, wie in der Release-Phase beschrieben. Wenn es um Lasttests geht, ist es ziemlich einfach, diese Tests auf die übliche Weise durchzuführen. Aber die Frage, die wir uns wirklich stellen sollten, lautet: Ist dies noch erforderlich? Eine serverlose Anwendung zeichnet sich dadurch aus, dass sie klein ist und dass Sie sich nur auf die Funktionalität und nicht auf die zugrunde liegende Plattform konzentrieren. Ist es sinnvoll, Ihre Funktion unter Last zu testen? Was testen Sie wirklich - die Funktionalität oder die zugrunde liegende Plattform? In einigen Fällen sind Lasttests durchaus sinnvoll, z.B. wenn Sie testen möchten, ob gleichzeitige Aufrufe Auswirkungen auf gemeinsam genutzte Daten oder zugrunde liegende Datenspeicher haben. Skalierbarkeit und Verfügbarkeit der Anwendung sollten bei der Verwendung von Serverless jedoch eine Selbstverständlichkeit sein.

Freigabe

Während sich die Build-Pipeline für eine serverlose Anwendung wahrscheinlich nicht sonderlich unterscheidet, ist es bei der Release-Pipeline sehr wohl der Fall! Es gibt zwei Überlegungen, die Sie berücksichtigen sollten, wenn Sie Ihre Anwendung für die Produktion bereitstellen möchten. - Wie gehen Sie mit verschiedenen Testumgebungen um - Wie gehen Sie mit verschiedenen Versionen derselben Anwendung um

Unterschiedliche Umgebungen oder nur eine andere Version?

Das erste, was wir bei der Beantwortung dieser Frage entscheiden müssen, ist, ob wir wirklich eine separate Umgebung zum Testen unserer serverlosen Anwendung benötigen. Was ist, wenn wir "in der Produktion" mit einer neuen Version einer Funktion testen und diese noch nicht für die Öffentlichkeit freigeben? Wenn es um die serverlose Anwendung selbst geht, d.h. die Azure Function, spielt es eigentlich keine Rolle, wo Sie sie speichern. Es ist der Auslöser oder das Backend, das die Notwendigkeit einer anderen Umgebung mit sich bringt. Es gibt zwei Möglichkeiten, verschiedene Funktionen in Ihrer Funktion bereitzustellen: die Verwendung von Feature-Toggles oder die Bereitstellung in einer separaten Umgebung.

Funktionstasten verwenden

Feature-Toggles sind eine Möglichkeit, das Systemverhalten in einer laufenden Anwendung zu ändern. Wenn Sie Feature-Toggles verwenden, benötigen Sie einen Mechanismus zum Umschalten des Toggles. Eine Möglichkeit, dies zu tun, wäre, einige Feature Toggle Functions zu erstellen, die einen Wert für einen bestimmten Toggle aus einem Datenspeicher hinzufügen, aktualisieren oder abrufen können. Ihre App-Funktion (die die eigentliche Funktionalität implementiert) kann die Feature Toggle Functions verwenden, um den Wert für bestimmte Toggles abzurufen und ihr eigenes Verhalten entsprechend festzulegen. So können Sie die Funktionalität Ihrer App-Funktion zur Laufzeit aktualisieren (oder ändern).

 

Bereitstellen in einer separaten Umgebung

Wenn Sie es vorziehen, dass Ihre Funktionen immer dasselbe Verhalten zeigen, wäre es vielleicht besser, für jede "Umgebung" und Version eine andere Bereitstellung zu wählen und einen API-Manager zu verwenden, um den Datenverkehr zu den richtigen Endpunkten zu leiten. Wenn Sie bedenken, dass jede neue Version ein neues Deployment ist, das unter einer anderen URL läuft, können Sie sich wahrscheinlich vorstellen, dass dies schwer zu pflegen und mit den Nutzern Ihrer serverlosen App zu kommunizieren sein wird. Ein API-Manager wie Azure API Management kann Ihnen dabei helfen, Ihren Datenverkehr an die richtigen Endpunkte zu leiten.

 

Die leichtgewichtige Version davon ist Azure Function Proxies. Wenn ein Verbraucher nach Version 2 eines Dienstes fragt, leitet die API-Verwaltung ihn korrekt an die richtige Funktionsimplementierung weiter, ohne dass der Benutzer die ursprüngliche URL kennt. Wenn Sie dieses Konzept auf verschiedene Umgebungen (z.B. eine Testumgebung) ausweiten, können Sie die API-Verwaltung so konfigurieren, dass sie den Benutzer auf der Grundlage einer bestimmten Eigenschaft der Anfrage (z.B. einer Kopfzeile oder eines Anfrageparameters wie eines API-Schlüssels) zu einer bestimmten Umgebung umleitet. Dies ist für Endbenutzer völlig transparent und einfach zu konfigurieren. Sie können die API-Verwaltung sogar über ihre eigene API aktualisieren, so dass Sie automatisch neue Funktionen oder Versionen aus Ihrer Release-Pipeline heraus bereitstellen können. Natürlich müssen Sie für die Zugriffskontrolle auf die API-Verwaltung sorgen und sicherstellen, dass die richtigen Umgebungen aufgerufen werden, aber das Konzept ist klar und transparent. Die Release-Pipeline stellt die Bits nach wie vor in verschiedenen Umgebungen bereit, und die API-Verwaltung ist nur ein weiteres Artefakt, das innerhalb der Pipelines konfiguriert werden kann.

Bedienen und Überwachen

Die letzte Phase in unserem Lebenszyklus ist Betreiben und Überwachen. Wie bei jeder anderen Anwendung ist eine Überwachung erforderlich. Auch wenn die herkömmliche Betriebsüberwachung von Metriken wie CPU-, Speicher- und Festplattennutzung nicht erforderlich ist, haben Sie dennoch einige Pflichten, wenn Sie eine serverlose Funktion für die Welt freigeben. Zumindest müssen Sie sicherstellen, dass die Funktion noch wie vorgesehen läuft und keine Fehler erzeugt. Es ist auch sehr wertvoll zu überprüfen, ob die Funktion tatsächlich genutzt wird. Azure Functions bietet eine Reihe grundlegender Überwachungsfunktionen, auf die Sie über das Azure Portal oder die Azure Befehlszeile zugreifen können. Wenn Sie eine erweiterte Überwachung benötigen, können Sie Microsoft Application Insights implementieren, das zwischen vier Arten der Überwachung unterscheidet.

 

Der Gedanke bei der Verwendung einer serverlosen Plattform ist, dass Sie sich keine Gedanken über die Verfügbarkeit machen müssen, da sich die Plattform darum kümmert. In dieser Hinsicht kümmert sich die Plattform auch um die Leistung, außer in bestimmten Situationen. Außerdem sind Diagnose und Nutzung beide sehr wichtig. Sie möchten wissen, ob Ihre Funktion ordnungsgemäß funktioniert und wenn nicht, was die Ursache für den Ausfall ist. Nutzungsstatistiken sind wertvoll, weil Sie anhand dieser Metriken entscheiden können, ob Sie eine Funktion auslaufen lassen können oder welche Funktion ein Kandidat für eine Optimierung ist.

Fazit

Die Erstellung einer serverlosen Anwendung unterscheidet sich nicht wesentlich von der Erstellung jeder anderen Anwendung. Die Tools ermöglichen es Ihnen, und manchmal ermutigen sie Sie sogar dazu, es auf einfache Weise zu tun. In der Regel ist es jedoch ratsam, vorauszudenken und einige Entscheidungen im Voraus zu treffen. Wenn Sie in Erwägung ziehen, Ihre Anwendung in Produktion zu geben, behandeln Sie Ihre serverlose Anwendung genauso wie jede andere Produktionsanwendung. Nutzen Sie leistungsstarke Tools wie eine IDE, denken Sie über Ihre Teststrategien nach, erstellen Sie Build- und Release-Pipelines und sammeln Sie Metriken. Azure Functions bietet großartige Unterstützung für mehrere Sprachen und jede Sprache ist die richtige Wahl. Das richtige Management des Lebenszyklus Ihrer Anwendung macht den Unterschied!