Direkte Serverless-Tests in der Produktion

Tests sind bereits frühzeitig vor dem Launch unerlässlich, um das korrekte Funktionieren von Hardware, Software oder anderen Produkten in der Entwicklung sicherzustellen. Tests erhalten das Vertrauen des Teams, wenn eine vollständig getestete serverless Anwendung in die Außenwelt eingeführt wird. Analog zu jedem anderen System auf der Welt ist es unerlässlich, die serverless Anwendungen nach ihrer Erstellung zu testen und zu überwachen.

Angesichts der Nachteile einer nicht getesteten Anwendung, um sicherzustellen, dass die serverless Anwendungen so funktionieren, wie sie sollen, muss der Test von serverless Anwendungen die entsprechende Aufmerksamkeit erhalten, da es sich um komplexe Systeme handelt. Diese Komplexität nimmt mit fortschreitendem Code allmählich zu. Darüber hinaus bedeutet ein erfolgreiches Durchlaufen früherer Testphasen nicht, dass nichts schiefgehen kann, wenn die Anwendung in Produktion geht. 

In diesem Artikel steht das Serverless-Testing in der Produktion im Mittelpunkt. Wir werden die Techniken erörtern, die für ein erfolgreiches Management des Serverless-Testings in der Produktionsumgebung angewendet werden können. Aber lassen Sie uns zunächst einmal klären, was Serverless-Architektur ist.

Was ist Serverless-Architektur?

Der Begriff "Serverless" tauchte erstmals um das Jahr 2012 in dem Artikel "Why The Future Of Software And Apps Is Serverless" von Ken Fromm auf.

Serverless-Architekturen, auch als Serverless Computing oder Function as a Service (FaaS) bezeichnet, sind ereignisgesteuerte Anwendungsdesignmuster, die Backend as a Service (BaaS) von Drittanbietern integrieren und benutzerdefinierte Codes umfassen, die in verwalteten und temporären Containern auf einer FaaS-Plattform ausgeführt werden. Alles in allem entfällt die Notwendigkeit der traditionellen Serversoftware- und Hardwareverwaltung durch die Entwickler. Das Wort "Serverless" wurde erstmals in einem Artikel aus dem Jahr 2012 erwähnt: "Why the future of software and apps is serverless" von Ken Fromm.

Serverless verlagert den Fokus auf die Anwendungscodes einzelner Funktionen. Dienste wie Microsoft Azure Functions und AWS Lambda kümmern sich um die physische Hardware, das Betriebssystem der virtuellen Maschine und die Verwaltung des Webservers. Das Einzige, worum man sich kümmern muss, ist der Code. Serverless-Architekturen helfen bei der Reduzierung der Betriebskosten und der Vorlaufzeit im Engineering, allerdings auf Kosten erhöhter Abhängigkeiten von Anbietern und unvollständiger Serviceunterstützung.

In unserem umfassenden Leitfaden zu Serverless finden Sie ein detailliertes Verständnis

Serverless-Testphasen vor der Produktion

Ob es sich um das Schreiben eines neuen Codes, das Beheben eines Fehlers oder die Implementierung einer neuen Funktion in das Produkt handelt, es ist unerlässlich, dass der Code eine Liste von Testphasen durchläuft. Tests stellen sicher, dass der geschriebene Code wie erwartet funktioniert. 

Im Folgenden sind die Testphasen für Serverless aufgeführt, die durchgeführt werden müssen, bevor es in die Produktionsumgebung gelangt. 

Lokale Tests: In Übereinstimmung mit der Anwendung und dem Serverless-Anbieter kann das Testen der Serverless-App lokal erfolgen. Es ermöglicht beschleunigte Bestätigungen, die sicherstellen, dass die Serverless-Anwendung oder der Code wie geplant funktioniert. Der grundlegendste und wichtigste Schritt für das erstgenannte ist das Schreiben von immer mehr Unit-Tests.

Unit-Tests: Der Großteil der Komplexität in einer Serverless-Anwendung dreht sich darum, wie eine Funktion mit den externen Diensten verbunden ist, was zu der Tatsache führt, dass es weniger Bedarf an Unit-Tests der Anwendung gibt. Wenn eine komplexe Geschäftslogik auftaucht, wird das Platzieren der Logik in ein eigenes Modul als der beste Weg angesehen, um alles als separate Einheit zu testen. Jasmine, Jest, Mocha sind einige Unit-Testing-Frameworks, die den Unit-Testing-Prozess vereinfachen werden. 

Integrationstests: Wie der Name schon sagt, befassen sich Integrationstests in der Regel mit den Fehlern oder Problemen, die aufgrund der Interaktion von Code mit den externen Diensten auftreten. S3 oder DynamoDB werden gestubbed oder gemocked, um die Integrationstests voranzutreiben. 

Akzeptanztests: Die früheren Phasen des Serverless-Testings bringen die Probleme im Code ans Licht. Darüber hinaus kann es zu Fehlkonfigurationen kommen, z. B. keine Einrichtung der Identitäts- und Berechtigungsverwaltung für die Funktionen, keine gemeinsame Konfiguration der API-Gateway-Ereignisquelle, um nur einige zu nennen. Um ein flexibles und durchgängiges Funktionieren der Funktion zu gewährleisten, wird empfohlen, an den Funktionen zu arbeiten, nachdem sie bereitgestellt wurden.

UI-Tests: Die direkte Interaktion eines UI-Clients mit einer Serverless-Anwendung macht es unerlässlich, die Änderungen in der Anwendung gemäß den Bedürfnissen des Clients durchzuführen. Die meisten UI-Tests werden manuell durchgeführt. Bei der Automatisierung sind Frameworks wie Selenium am besten geeignet.  Außerdem verwendet das QA-Team AWS Device Farm, automatisierte visuelle Tests werden durchgeführt, um dem Kunden ein perfektes UI-Erlebnis zu bieten.

Serverless-Testing in der Produktion

Die frühen Testphasen garantieren nicht, dass es zum Zeitpunkt der Produktion nicht zu Problemen kommt. Es kann etwas geben, das zum Zeitpunkt der Produktion ein Unglück verursacht. So kann beispielsweise der Ausfall von AWS eine Serverless-Anwendung erheblich beeinträchtigen. Darüber hinaus kann die Abhängigkeit einer Serverless-Anwendung von vielen externen Diensten das reibungslose Funktionieren einer Serverless-Anwendung stören. Die unzulässige Last kann auch die Skalierung von Serverless in Frage stellen.

Um eine leistungsstarke Serverless-Anwendung zu entwickeln, muss alles in der Produktion mit größter Sorgfalt getestet werden. Eine Reihe von kontrollierten Managementpraktiken stellt das ordnungsgemäße Funktionieren einer Serverless-Anwendung sicher.

Fünf neue Techniken, die zur Verwaltung von Serverless-Tests in der Produktion eingesetzt werden können: 

Feature Flags "In Kraft" 

Mit Feature Flags kann ein Unternehmen das Datum für die Veröffentlichung festlegen, so dass der Code in die Produktion ausgeliefert werden kann. Es wird auch als "Feature Toggle" bezeichnet, das es ermöglicht, die Funktionen der Anwendung einfach ein- und auszuschalten. Die Absicht bei der Anwendung von Feature Flags ist es, die Benutzer der neuen, aktualisierten Funktion zu bestimmen. Es hilft herauszufinden, wer die neue Funktion nutzen soll, während sie vor dem Rest der Masse verborgen bleibt. Dies ermöglicht es den Entwicklern, alles vor dem großen Rollout zu testen. Darüber hinaus ermöglicht es ein effizientes Testen der von ihnen selbst vorgenommenen Änderungen in der Anwendung. LaunchDarkly verwendet Feature Flags effektiv in Vollzeit. Es wird empfohlen, ein Feature Flag mit einer Benutzeroberfläche zu erstellen, damit die interne Nutzbarkeit der internen Teams nicht eingeschränkt wird.

Bereitstellung mit den Kanarienvögeln

Die Kanarienvögel werden häufig in Verbindung mit Feature Flags verwendet. Mit Canary können die Teams die gestaffelten Rollout-Sitzungen verfolgen und Tests durchführen, bevor der Code in die Produktion ausgeliefert wird. Es geht darum, die Bereitstellung zu festigen, ohne zu wissen, was am Ende ablaufen wird. Unternehmen wie Nginx und Buoyant führen die Canary-Bereitstellung als Teil ihres Service Mesh durch. 

Gestaffelte Rollouts

Ähnlich wie in der Definition ist ein gestaffelter Rollout eine Art von Canarying mit einer gestaffelten Komponente, anstatt auf einen bestimmten räumlichen Teil bereitzustellen. Charity Majors, Mitbegründerin und CEO des plattformunabhängigen DevOps-Monitoring-Tools Honeycomb.io, erklärt, dass, wenn ein Canary auf 10 Prozent der gesamten Produktion eingestellt ist, eine Automatisierung durchgeführt wird, um die 10 Prozent mit dem Rest des Systems zu vergleichen. Keine Fehler bedeuten die Förderung der Bereitstellung auf 25 Prozent, und auf der Rückseite, wenn ein Problem auftritt, würde das System entweder auf die Vorbereitstellung zurückgreifen oder, ähnlich wie bei einem gestaffelten Rollout, den Rollout rückgängig machen. Sie fügt hinzu, dass bei geringen Bereitstellungsstufen nicht viele Probleme auftreten. Probleme treten bei der Skalierung der Anwendungen auf. 

Substanziell messen

Es ist eine Freude für die Teams, wenn sich der in die Produktion ausgelieferte Code wie erwartet verhält. Es wirft große Bedenken auf, wenn die Teams mit der Fehlfunktion der Anwendung des Codes konfrontiert werden. Daher ist es unerlässlich, die Leistung des Codes und des Systems häufiger zu überwachen, zu messen und zu erfassen. Organisationen gehen dazu über, umfassende Lösungen für die Instrumentierung anzubieten. In Anbetracht der Tatsache, dass die Größe und die Arbeitsabläufe von Serverless recht groß sind, so dass es für einen einzelnen Architekten nicht möglich ist, das gesamte System zu messen. Daher ist ein umfangreicheres Instrumentarium erforderlich, um die Produktionszeit zu verwalten.

Observability  "Ein Flaggschiff"

Dies ist das neu aufkommende Paradigma, das die testgetriebene Entwicklung in der Organisation sicherstellt. Dieses neue Paradigma wird als Observability-First-Paradigma bezeichnet, bei dem das Engineering-Team das Ergebnis der Funktion oder des Workflows, der Anwendung oder des gestaffelten Rollouts abbildet. Bevor mit der Programmierung begonnen wird, erstellt das Team ein Instrumentarium, um die Übereinstimmung der Entwicklung und Bereitstellung mit den ursprünglichen Zielen zu überwachen und zu messen. Wenn es grünes Licht gibt, wird der Prozess erst dann fortgesetzt. 

Verschiedene Tools zur Fehlersuche in Serverless-Anwendungen

Dashbird 

Dashbird ist ein weit verbreitetes Überwachungstool, das Lösungen für eine AWS Lambda-Anwendung bietet. Es erkennt hauptsächlich Lambda-spezifische Fehler, wie z. B. Speicherprobleme, Laufzeitfehler, Fehlkonfigurationen, Ausnahmen, um nur einige zu nennen. Es arbeitet mit AWS zusammen, um aufschlussreiche Metriken für Kostenoptimierung, Leistung und Ressourcen zu liefern. 

IOpipe

IOpipe bietet das vollständige Bild dessen, was eine AWs-Lambda-Anwendung tatsächlich tut, mit häufigen Benachrichtigungen, die auf Slack, E-Mail, Webhooks usw. erscheinen. Es bietet hochauflösende Echtzeitmetriken zusammen mit Alarmierung, Fehleraggregation, Profilerstellung und Tracing.

SignalFx

SignalFx ist ein Überwachungstool für AWS Lambda, Google Cloud und Azure Functions und bietet Echtzeit-Transparenz und -Leistung der Funktionen, Kostenoptimierung, Kalt-Erkennung, Speicherausführung und -nutzung, Metriken mit niedriger Latenz usw. 
 

Thundra

Thundra verfolgt und profiliert im Wesentlichen eine AWS Lambda-basierte Anwendung mit geringstem Overhead. Datenfiltration und erweiterte Suche, erweiterte Fehlersuche, detailliertes und konfigurierbares Tracing, dynamische Instrumentierung usw. sind einige der Funktionen von Thundra.
 

Amazon Cloudwatch

Das frei verfügbare Amazon Cloudwatch sammelt sowohl die grundlegenden als auch die benutzerdefinierten Lambda-Metriken. Es gewährleistet die einfache Erfassung aller AWS-Daten von einer einzigen Plattform aus und sorgt so für eine vollständige Transparenz der Ressourcen.

Informieren Sie sich über verschiedene Tools, die für Serverless-Implementierungen hilfreich sind

Fazit

Die Entwicklung oder Erstellung einer Serverless-Anwendung ist genauso wie die Entwicklung jeder anderen Anwendung. Daher wird empfohlen, sie zu testen, bevor sie in die Massenproduktion geht. Es ist immer ratsam, über die Testtechniken und -strategien nachzudenken, die beim Testen einer Serverless-Anwendung befolgt werden können. Wenn der Code in die Produktion geschickt wird, hört das Testen dort nicht auf. 

Auch wenn das Testen von Serverless unzählige Male durchgeführt wird, kann es sehr schlimm oder negativ werden, wenn es in die Produktion geschickt wird. Daher ist es unerlässlich, einige Taktiken, eine starke Überwachung und Fehlerberichterstattung für Ihre Anwendungen zu befolgen, um Serverless in der Produktionsumgebung erfolgreich zu testen.