Microservices - sie sind schon länger in aller Munde und gelten heutzutage als der defacto Industriestandard für verteilte, skalierbare und wartbare Architekturen. Das sind große Versprechen für einen so kleinen Service und dabei sieht die Realität oft ganz anders aus. Besonders in größeren und komplexeren Systemen ist man häufig mit Fragen wie: „Welcher Microervice war hierfür doch gleich verantwortlich?“ oder „Ist mein Team überhaupt für diesen Service verantwortlich? konfrontiert. Eine Aussage wie : Das neue Feature betrifft doch noch weitere Services“ erschüttert das Fundament einer jeden Microservice Architektur . Damit wird klar, die eigentliche Herausforderung liegt zumeist nicht in der Implementierung, sondern darin den idealen Funktionsumfang und die richtige Domäne für einen Microservice zu identifizieren.
Erfreulicherweise gibt es noch alternative Architektur Ansätze . Ansätze die vergleichbare Vorteile bieten, dabei aber die architektonischen Hürden für Teams gering er halten . In diesem Artikel möchten wir euch „Aktoren“ und das Aktor Modell vorstellen. Aktoren sind ein Konzept, welches bereits im Jahre 1973 verwendet wurde, um verteilte Systeme jeglicher Art zu realisieren. Man könnte sagen: „alt und bewährt“ in der Praxis hatten Aktoren bis vor ein paar Jahren jedoch nur wenig Einfluss in der Branche. Die steigenden Anforderungen an das Internet of Things brachte n dem Aktoren Konzept jedoch eine Renaissance Als idealer Lösungsansatz für beinahe alle Herausforderungen rund um das Internet of Things veröffentlicht e Microsoft das Aktoren Framework Orleans ein Cloud Ready Aktor en Framework welches dem Konzept aus dem Jahr 19 73 neues Leben einhaucht. Nun stellt sich unweigerlich die Frage: Was sind diese Aktoren? Ein Aktor kann als eigenständige und unabhängige Einheit betrachtet werden, welche...
• eine eigene Mailbox (eine Art FIFO Message Queue)
• einen sequenziell en Code , welcher beschreibt wie eine Nachricht in der Mailbox zu bearbeiten ist
• sowie einen optional en Zustand
…besitzt.
Natürlich kann ein Aktor auch Nachrichten an die Mailbox eines weiteren Aktor s in einem komplexen System aus Aktoren schicken. Der empfangende Aktor, kann falls notwendig (asynchron) darauf antworten. Dieses Nachrichten Pattern ermöglicht eine einfache Verwaltung paralleler Vorgänge in verteilten Systemen . Durch die synchrone Bearbeitung einer jeden Nachricht ist somit auch zu jedem Zeitpunkt ein deterministischer Zustand des Gesamtsystems gegeben . Dadurch sind Race-Conditions sowie die Notwendigkeit Locking-Mechanismen (wie Mutexes und Semaphoren) zu implementieren , um sie zu vermeiden ein Ding der Vergangenheit.
Conclusio:
Ein Aktor hat wesentlich weniger Funktionsumfang als ein Microservice und stellt damit die kleinste atomare Einheit in einem System aus Aktoren dar. Hier kommt die Idee des Nanoservices in das Spiel. Anstatt mit Hilfsmittel wie DDD (Domain Driven Design) den Funktionsumfang eines Services zu bestimmen , incentiviert das Aktor System per Definition den Funktionsumfang eines Aktors so klein wie möglich (und so groß wie nötig) zu halten. Damit sind viele Aktoren notwendig, um eine vergleich bare Funktionalität eines Microservices zu erbringen. Die Vorteile liegen auf der Hand verbesserte Testbarkeit, Skalierbarkeit , einfachere Verständlichkeit und flexibleres Systemdesign , sowie agilere Möglichkeiten eine bestehende Aktoren Architektur neuen Anforderungen anzupassen.
Wer also auf der Suche nach einem tollen Architektur Pattern ist, sollte auf alle Fälle auch Aktoren in Betracht ziehen. Es muss nicht immer Micro sein es darf auch gerne Nano sein!
Weiterführende
Links:
https://learn.microsoft.com/en-us/dotnet/orleans/overview
https://github.com/dotnet/orleans
https://en.wikipedia.org/wiki/Orleans_(software_framework)
https://getakka.net/index.html
