Eine Übersetzung des Artikels wurde für Studenten des DevOps Practices and Tools- Kurses im OTUS- Bildungsprojekt erstellt.

Als die ersten Tutorials 2015 mit AWS Lambda und der Gateway-API begannen, war es nicht verwunderlich, dass sie sich hauptsächlich auf das Kopieren der Microservice-Architektur konzentrierten. Für diejenigen, die AWS Lambda in großem Umfang verwendeten, wurde im Laufe der Zeit klar, dass die Anwendung des Microservice-Ansatzes auf AWS Lambda ... Zumindest gab es Einschränkungen, was die meisten Menschen unter dem richtigen Aufbau von Mikrodiensten verstanden.

Lassen Sie uns über das Warum für Microservices sprechen

Microservices traten hauptsächlich aufgrund der Frustration bei monolithischen Anwendungen auf. Monolith ist eine Anwendung, bei der sich die gesamte Logik in einer logischen Codebasis befindet.

Es gab Zeiten, in denen es aufgrund der hohen Serverkosten üblich war, die gesamte Anwendung auf einem einzigen Server bereitzustellen. Das Bereitstellen eines Monolithen bedeutete, dass Sie auf dem Server einen Teil oder die gesamte Anwendung bereitstellten.

Die Bereitstellung eines Monolithen bedeutete auch, dass Sie sicher sein mussten, dass Sie nichts kaputt machen. Sehr oft führen kleine Änderungen zum Ausfall des gesamten Servers und der gesamten Anwendung.

Als Wolken mit der Fähigkeit auftauchten, Instanzen mit einem Klick innerhalb von Minuten (anstatt Tagen oder Wochen) bereitzustellen, wurde die Möglichkeit einer Aufgabentrennung deutlich.
Die Zerstörung des Monolithen wurde zu einer offensichtlichen Idee, und die Idee der Mikrodienste wurde geboren.

Anstatt einen Monolithen mit der gesamten Logik auf einem Server / einer Instanz zu erstellen, können Sie Teile der Anwendung auf verschiedenen Servern platzieren und sie mithilfe eines einfachen Protokolls miteinander verbinden - normalerweise einer HTTP-API.

Daher hat sich die Anwendungsarchitektur von Monolithen zu Microservices entwickelt.

Obwohl ich mich frage warum? Der Wert dieses Ansatzes besteht darin, dass Sie beim Bearbeiten des Codes die Codebasis nicht der gesamten Anwendung, sondern des Microservices ändern - nur des Bestandteils der Anwendung. Dies bedeutet, dass Sie nicht die gesamte Anwendung brechen können.

Dies ist zwar nur theoretisch, aber diese Theorie ist besser als ein Monolith, obwohl sie nicht ideal ist.

Ein Schlüsselelement für jeden Service ist ...

Serviceschnittstelle

Dies ist häufig eine Form der HTTP-Schnittstelle (zumindest ist dies der häufigste Ansatz). In der Regel ist dies kein Problem, es sei denn, Sie haben eine große Anzahl von Diensten und es liegt möglicherweise ein Problem bei deren Koordination vor.

Auf dem Weg zur serverlosen Architektur

Daher war der ursprüngliche Ansatz zum Erstellen von Anwendungen ohne Server auf AWS "Erstellen wir Microservices" ...

Dies bedeutete, eine Gateway-API mit der dahinter stehenden Lambda-Funktion und einer switch-Anweisung zu erstellen, die als Router fungiert.

Jede Gateway-API wurde zu einer Dienstschnittstelle, und das schien logisch.

Sie können mehrere Dienste erstellen, die getrennt voneinander skaliert werden. Dies kann in einigen Fällen sehr wichtig sein.

Abgesehen davon, dass es keinen Sinn macht, wenn Sie feststellen, dass die Funktionen AWS Lambda und FaaS im Allgemeinen nicht als Instanz / Server betrachtet werden sollten.

Denn obwohl sie Server unter der Haube haben (hey, es gibt Server unter den meisten Dingen, die im Internet funktionieren, aber niemand sagt "S3 hat noch Server" oder "BigTable hat noch Server" oder "Azure Active Directory alle" hat immer noch Server “...), es gibt eine Meinung, dass Sie die FaaS-Funktion genauso behandeln sollten wie den Dienst ...„ Minilith “, wie manche es nennen.

Das Problem ist, dass hier fehlt, was meiner Meinung nach der Schlüssel zur serverlosen Architektur ist:

Bei der serverlosen Architektur dreht sich alles um Ereignisse

Serverlose Architektur, Ereignisse und Trigger

Serverlose Systeme sind von Natur aus ereignisgesteuerte Systeme und daher Vertreter der ereignisgesteuerten Architektur. Es ändert Ihre Herangehensweise an Design, Management und Architektur.

Im Fall von Microservices besteht das Endergebnis darin, auf eine Schnittstelle zu reagieren - dies ist der Hauptmechanismus für die Interaktion mit Logik.

Bei der Lösung ohne Server geht es darum, auf Ereignisse zu reagieren, und die API ist eigentlich nur ein Mechanismus zum Generieren von Ereignissen.

Als Teil des AWS-Ökosystems, der ausgereiftesten serverlosen Lösung, wird die API nicht als primäre Schnittstelle angesehen. Ereignisse sind viel wichtiger.

Aus diesem Grund gibt es ungefähr 50 Ereignisse, die die Lambda-Funktion von anderen AWS-Diensten auslösen können.

Der Tipp lautet: Wenn Sie die Lambda-Funktion ausführen können, ohne die Gateway-API zu durchlaufen, ist sie viel schneller und effizienter als die Verwendung der Gateway-API, insbesondere wenn Sie sie über eine andere AWS-Schnittstelle ausführen.

Werfen Sie einen Blick auf Serverless Best Practices . Sie werden eine Reihe von Punkten sehen, die sich von der Anzahl der Design-Microservices unterscheiden.

Zunächst unidirektionale Funktionen. Die meisten Microservices verwenden normalerweise eine Request-Respone-Architektur, da die meisten Webanwendungen auf diese Weise funktionieren. Funktionen in einer Anwendung ohne Server sind in der Regel unidirektional, und Warteschlangen werden als „Leistungsschalter“ verwendet, sodass die Antwort auf Anfragen seltener wird.

Die Datenschicht wird auch auf unterschiedliche Weise verwaltet und verstanden. Es wird empfohlen, mehrere Funktionen anstelle einer Proxy-Funktion mit einer switch-Anweisung zu verwenden.

Die Idee mehrerer Funktionen bietet auch zusätzliche Vorteile gegenüber Microservices. Wenn eine Funktion einen Fehler auslöst, wirkt sich dies nur auf diese Funktion aus und nicht auf den Rest der Anwendung, da die Funktion keinen Status hat (zumindest sollte dies der Fall sein!). Und das ist ein sehr guter Grund, keinen „Minilith“ zu machen!

Obwohl die Erfahrung beim Aufbau von Microservices Ihnen einige Vorteile beim Entwerfen von Lösungen ohne Server bietet, können Sie in der Realität das meiste übersehen, was Anwendungen ohne Server wertvoll macht.

Microservices unterscheiden sich in mehreren Punkten von einer gut konzipierten Anwendung ohne Server. Dies bedeutet, dass es zwar möglich ist, Microservices mit einem serverlosen Backend zu erstellen, in Wirklichkeit jedoch keinen direkten Pfad von Microservices zu einer serverlosen Architektur gibt.

Der Weg von Microservices zur serverlosen Architektur

Was ist der Weg von Microservices zu serverlosen Lösungen? Gibt es eine schnelle Möglichkeit, die Grundlagen zu erlernen, um den Übergang von einem zum anderen zu vereinfachen, da Microservices weit verbreitet sind?

Ich denke, das ist es, worüber die Welt ohne Server rätselt. Vor kurzem gab es eine große Diskussion auf Twitter, in der wir über dieses Thema gesprochen haben. Hier lohnt es sich, darauf zu verweisen, wenn auch nur, um zu sehen, wovon die Community spricht (sehen Sie sich die verschiedenen Antworten an und Sie werden zahlreiche Meinungen zu diesem Thema sehen, obwohl niemand Microservices direkt erwähnt).

Sie sprechen über einige Tools, die die Erstellung von Anwendungen ohne Server erleichtern sollen, aber am Ende werden sie zur Plattform, auf der Sie alles aufbauen müssen. Ich denke nicht, dass es jemandem zugute kommt oder ihm hilft, den architektonischen Stil besser zu verstehen.

Als Community verstehen wir, dass serverlose Architektur die Zukunft ist. Der Übergang von alten Architekturstilen wird jedoch nicht immer einfach sein, selbst wenn die Architektur ohne Server die richtige (und manchmal auch nicht die richtige) Wahl ist.

Dafür gibt es einen Grund. Es ist nicht so einfach, das Denken einer Person zu ändern. Es ist einfach, eine Lambda-Funktion zu erstellen. Das Erstellen einer gut gestalteten serverlosen Anwendung ist jedoch nicht einfach. Weil es ein Umdenken erfordert und relativ schwierig ist.

Und wie ich schon mehrmals gesagt habe, müssen wir aufhören, den Menschen „Hallo Welt“ -Anwendungen beizubringen, und damit aufhören, weil viele Leute denken, dass dies für sie ausreichen wird.

Der Grund, warum ich Best Practices für Serverless geschrieben habe, war, den Leuten zu helfen, zu verstehen, dass sie keine Annahmen darüber treffen sollten, wie Serverless-Anwendungen auf der Grundlage des aktuellen Wissens erstellt werden sollen.

Die Tools, mit denen wir jetzt serverlose Lösungen erstellen, sind dieselben Tools, die wir zum Erstellen von Cloud 1.0-Anwendungen verwenden, sind jedoch für diese Zwecke nicht vollständig geeignet. Diese Werkzeuge sind nicht perfekt, aber wir versuchen sie zu erklären und so gut wie möglich zu machen.

Was brauchen wir von dir?

Ich denke, dass die Community in der Tat sehr offen ist, Menschen bei der Schulung und Entwicklung bei der Erstellung serverloser Lösungen zu helfen.

Deshalb brauchen wir als Gemeinschaft Ihre Fragen:
- Was sind deine Schwierigkeiten?
- Wo sind die Lücken?
- Welche Tutorials fehlen?

Und so ähnlich.

Ich bin bereit, Unternehmen bei diesem Übergang zu unterstützen. Ich habe mit der Geschäftsleitung, CTOs und CEOs zusammengearbeitet, um herauszufinden, welchen Wert ein Unternehmen mithilfe eines Ansatzes ohne Server schafft, und ich bin glücklich, anderen Unternehmen zu helfen.

Ich helfe sehr gerne. Kontaktieren Sie LinkedIn hier .