Fotolia
Microservices, Lambda und Functional Computing im Vergleich
Entwickler, die die Unterschiede zwischen Functional Computing, Lambda und Microservices kennen, können eine verteilte Architektur besser implementieren.
Heute stoßen Entwickler inmitten der verteilten Entwicklung wahrscheinlich auf drei populäre Begriffe: Functional Computing, Lambdas und Microservices. Auch wenn die Unterschiede subtil erscheinen, kann das Verständnis hierfür die Fähigkeit einer Entwicklungsabteilung bestimmen, eine verteilte Architektur erfolgreich zu implementieren.
Alle drei können, je nach Kombination, dasselbe bedeuten oder aber verschiedene Dinge ausdrücken. Werfen wir einen Blick darauf, was diese Begriffe einzigartig macht, und warum sie miteinander verbunden sind.
Functional Computing verstehen
Der Begriff Functional Computing wird im Allgemeinen aus der Mathematik abgeleitet. Eine Funktion ist dort etwas, das bei der gleichen Eingabe immer das gleiche Ergebnis liefert. Man sagt, dass die Variable y eine Funktion der Variable x ist, geschrieben als y=f(x). Der springende Punkt ist dabei: Wenn der gleiche Eingabewert (x) immer den gleichen Ausgabewert (y) erzeugt, liefert jede Kopie der Funktion das gleiche Ergebnis – egal wie oft sie aufgerufen wird.
Lambda verstehen
In der Softwareentwicklung haben die meisten Funktionen Namen. Diese werden aufgerufen, wenn die Funktion verwendet wird. Ein Lambda ist eine Klasse anonymer Funktionen (nicht zu verwechseln mit AWS Lambda, der ereignisgesteuerten, serverlosen Computer-Plattform von Amazon).
Wenn ein Ereignis oder ein externer Stimulus eine Lambda-Funktion ausführt, bedeutet das, dass dafür kein Name benötigt wird, da dieser mit dem Ereignis oder dem Stimulus verknüpft ist, der ihn auslöst. Zum Beispiel kann man ein Lambda erzeugen, indem man sagt: Wenn ein Input-Stimulus auftritt, ist der Output gleich f(Input-Stimulus). Der Code, der die funktionale Arbeit erledigt, wird mit der Identifikation dessen versehen, was den Code aufruft. Mit anderen Worten, Lambdas werden nicht benannt, sie laufen einfach.
Microservices verstehen
Die allgemein anerkannte Definition von Microservices ist, dass es sich um kleine und zusammensetzbare logische Einheiten handelt, die zur Erstellung von Anwendungen verwendet werden. Diese Definition ist jedoch nicht präzise. Einige sagen, dass ein Microservice so etwas wie eine separat installierte Anwendungskomponente ist. Andere behaupten, dass ein Microservice nicht nur eine separat installierte Komponente ist, sondern auch eine Komponente, die man bei Bedarf einsetzen kann, um auf Änderungen der Arbeitslast zu reagieren. Mit anderen Worten: Man glaubt, dass ein Microservice einer Funktion ähnlich ist.
Eine Sache, die wir sicher über Microservices sagen können, ist, dass Microservice-Anwendungen nicht anonym sind. Microservices werden explizit über benannte APIs aufgerufen und in der Regel über einen API-Broker angesprochen. Dieser übernimmt auch die Instanz-Replikation und Load Balancing. Dies geschieht, da Microservices die Begriffe Software-Komponentisierung und Komponenten-Wiederverwendung auf die Spitze treiben. Skalierbarkeit ist in Lambdas integriert, so dass für deren Erstellung Microservice-Code erforderlich ist. Es ist diese Abhängigkeit von der Implementierung, die eine große Vielfalt an Interpretationen schafft, was Microservices sind. Es gibt keine spezifische Definition, da es keine spezifische Implementierung gibt.
Die Bedeutung des Zustandes
Nirgendwo ist der Unterschied zwischen Functional Computing, Lambda Computing und Microservices deutlicher als in der Art und Weise, wie sie sich dem Zustand (state) oder Kontext der Nutzung nähern. Dabei sollte man bedenken, dass Functional- und Lambda-Komponenten namenlos (nameless) und zustandslos (stateless) sind.
Theoretisch ist die zustandslose Implementierung von Microservices möglich. Aber auch eine vollständig zustandsabhängige (stateful) Implementierung ist möglich, wenn eine Form der Zustandskontrolle eingesetzt wird. Zustandslose Microservices sehen aus wie benannte Functional- oder Lambda-Elemente, und zustandsabhängige Microservices wie minimierte traditionelle Softwarekomponenten.
Die mittlere Kategorie der Zustandskontrolle wird in der Regel in Microservice-Implementierungen auf eine von zwei Arten gehandhabt: Erstens kann der Aufruf der Microservice-API beliebige Statusinformationen enthalten, die der Aufrufer berücksichtigen muss. Es ist nicht schwierig, für eine webbasierte Anwendung diese Art von Quellcode zu generieren, obwohl es mit Sensoreingaben, wie sie beim Internet der Dinge (IoT) üblich sind, schwieriger ist.
Der zweite Ansatz wird als Backend-Zustandskontrolle bezeichnet. Dazu gehört die Pflege einer Datenbank, in der Zustandsinformationen gespeichert sind, und die von einer Transaktions- oder Quellkennung referenziert wird. Wenn ein Aufruf an die Instanz eines Microservice erfolgt, enthält sie diese ID. Der Microservice (oder API-Broker) verwendet diese ID, um auf das Backend-Status-Repository zuzugreifen und die korrekten Statusinformationen zu erhalten.
Sie kommen alle zusammen
In gewisser Weise können Functional Computing, Lambda Computing und Microservices zu einem zustandsabhängige Verhalten zusammenwachsen. Amazon hat AWS Step Functions als Teil seiner AWS Serverless Platform eingeführt, die auch seinen Functional-Computing-Service AWS Lambda beinhaltet.
Step Functions erledigt zwei Dinge: Erstens bietet es die Möglichkeit, Funktions- und Lambda-Elemente in aufeinander abgestimmten Prozesse zu organisieren, indem es eine grafische Beziehung zwischen ihnen herstellt. Zweitens bietet es die Möglichkeit, Informationen weiterzugeben und sogar den Transaktionsstatus über mehrere Ereignisse hinweg aufrechtzuerhalten. Mit Step Functions lassen sich zwar nicht einfach Legacy-Komponenten in das Functional Computing einbinden, aber es erleichtert die Entwicklung funktionsbasierter Anwendungen und den Übergang zwischen funktionalen und Legacy-Anwendungselementen.
Microsoft geht noch weiter. Das Feature Durable Functions umfasst eine Reihe von Designmustern, die es Entwicklern ermöglichen, mehrere Funktionen in einer einzigen Anwendung zu orchestrieren. Dies ist ähnlich dem Ansatz, den Amazon verfolgt. Durable Functions können wirklich dauerhaft sein; sie können sich wie zustandsabhängige Komponenten verhalten, die kontinuierlich laufen und auf Ereignisse warten, anstatt von ihnen ausgelöst zu werden. Sie können auch mehrstufige Durable Functions schreiben, das heißt Funktionen, die genehmigt werden müssen, bevor sie weiter ausgeführt werden können. Dies kann sich schließlich in die Fähigkeit verwandeln, Microservices und andere zustandsabhängige Elemente in Functional- und Lambda-Modelle zu orchestrieren.
Google nennt sein funktionales und serverloses Computing Microservices, hält sich aber im Allgemeinen an das gleiche Functional- und Lambda-Modell wie Amazon und Microsoft. Google bietet keine mit seinen Wettbewerbern vergleichbare Zustandskontrolle. Tatsächlich gibt es Anzeichen dafür, dass Google sein serverloses Modell auf mobile Anwendungen konzentriert, anstatt sich mit den allgemeineren Möglichkeiten von Amazon und Microsoft zu messen.
Im Mittelpunkt von all dem steht dabei immer der Begriff des ereignisgesteuerten Computing (event-driven Computing) und der reaktiven Programmierung. Bei diesem Modell reagiert Software auf Bedingungen, anstatt sie zu erzeugen. Aufgrund der großen Softwarebasis und der Lernkurve, die für diesen neuen Ansatz erforderlich ist, ist es schwierig zu sagen, wie weit dieses Modell gehen oder wie schnell es sich verbreiten wird. Allerdings dürfte IoT ein massiver Treiber des Wandels sein. Fast jedes Unternehmen hat heute eine Anwendung für Functional, Lambda und Microservices Computing. Der Schlüssel wird sein, zu verstehen, was die Begriffe bedeuten, zu sehen, wie sie sich entwickeln und dann die Planung und Entwicklung in Einklang zu bringen.
Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!
