Klassische Webanwendungen wurden lange in einer monolithischen Architektur umgesetzt: Ausgehend von einem Asp.Net-Projekt wurde die Business-Logik angebunden. Um die Wartbarkeit zu verbessern teilten die Entwickler die Anwendung in verschiedene Schichten auf. Mit dem Aufkommen von Single Page Applications wurde die Präsentationssicht abgetrennt, dadurch entstand noch eine Applikationsschicht (zum Beispiel basierend auf Asp.Net Web API).

Trotz all dieser guten Ansätze stieg bei vielen Anwendungen der Wartungsaufwand. Da jedes Entwicklerteam nur eine bestimmte Codemenge überblicken kann, wurde die Anwendung bereits durch ihre Größe schwieriger beherrschbar. Durch die gemeinsame Datenhaltung ist die Versuchung groß, dass ein Modul direkt auf Daten aus einem anderen Modul zugreift - trotz Verwendung von Repositories oder CQRS. Ein weiterer Nachteil liegt in der begrenzten Möglichkeit, eine Anwendung auf eine neue technische Basis zu stellen, da die komplette Anwendung auf einen Schlag aktualisiert werden müsste.

Kleine, unabhängige Services

Als Alternative zur monolithischen Architektur wird nun die Microservice-Architektur immer beliebter. Microservice-Architekturen bestehen aus kleinen Services, die weitgehend unabhängig voneinander aufgebaut sind. Hierzu müssen die Kontextgrenzen (Bounded Context) gut gewählt sein, da sonst viele Queraufrufe notwendig sind. Ein Microservice sollte nur so groß sein, dass er von einem Entwicklerteam leicht verstanden werden kann.

Ebenfalls sollte jeder Service die Daten unabhängig vom anderen Service speichern. Jeder Service einer Microservice-Architektur kann mit einer anderen Technologie und/oder Programmiersprache entwickelt werden. Das ermöglicht zum Beispiel, eine Anwendung "Service für Service" von .Net nach .Net Core umzustellen. Wichtig für Microservice-Architekturen sind auch Aspekte wie Prozessunabhängigkeit, automatisches und unabhängiges Deployment. Viele dieser Ideen sind überhaupt nicht neu. Eine alternative Definition von Microservices lautet daher auch: "SOA done right": Best Practices aus SOA und Domain Driven Design (DDD) werden zusammengeführt.

Problem: Höhere Komplexität

Gerade die kleinen Services und die Möglichkeit, einfach neue Technologien einzuführen, versprechen eine Architektur, die besser zu pflegen und zu aktualisieren ist. Aber wie alles im Leben haben auch Microservices ihren Preis. Zum einen müssen diverse Anforderungen erfüllt sein, zum anderen erhöht sich aufgrund der Verteilung auf verschiedene Services die Komplexität der Gesamtanwendung.

Für .Net-Entwickler gibt es in der AWS- bzw. Microsoft-Cloud mehrere Angebote die für Entwicklung und Betrieb von Microservices verwendet werden können. Dazu gehören etwa Azure Functions, AWS Lambda, Docker, Azure Service Fabric und andere.

Functions as a Service

Mit Azure Functions können kleine Services in verschiedenen Programmiersprachen, darunter auch C#, geschrieben werden. Aufgerufen werden diese Services über einen http-Endpoint oder ein Ereignis. Ein ähnliches Produkt bietet auch Amazon mit AWS Lambda an. Seit Dezember 2016 können Azure Lambda-Funktionen auch mit C# (.Net Core) geschrieben werden. Nach der Installation des AWS-Toolkits werden in Visual Studio entsprechende Projektvorlagen angeboten. Neben einem Aufruf über einen http-Endpunkt können die Funktionen auch durch verschiedene Ereignisse (zum Beispiel: Datensatz wurde in Datenbank eingefügt) ausgelöst werden.

Sowohl bei Azure Functions als auch bei AWS Lambda handelt sich um "Function-as-a-Service"-Produkte. Der Hauptvorteil von FaaS liegt in der automatischen Skalierung und dass nur für die Rechenzeit bezahlt werden muss. Die maximale Laufzeit einer Funktion ist standardmäßig auf fünf Minuten ausgelegt - danach wird die Funktion abgebrochen. Von der Gesamtarchitektur und dem Entwickler-Support her sind beide Plattformen mehr für kleinere Funktionen geeignet.

Docker fordert den Entwickler

Für die Entwicklung von Microservices, die in Docker-Containern betrieben werden sollen, stehen C#-Entwicklern alle Möglichkeiten (und Bibliotheken) offen. Somit lassen sich auch komplexe Anforderungen umsetzen. Auch von der DevOps-Seite her gesehen wird der Entwickler perfekt unterstützt. Selbst ein Continous Delivery ist mit TFS umsetzbar. Herausfordernd ist, dass sich der Entwickler die einzelnen Komponenten einer Microservice-Anwendung (Loadbalancer, API-Management, Data Storage, Skalierung etc.) selbst zusammenstellen, entwickeln und betreiben muss.

Azure Service Fabric

Service Fabric - ein Produkt aus der Kategorie Platform as a Service - wird von Microsoft in einer Vielzahl von Azure-Produkten selbst verwendet, zum Beispiel für Cortana oder IoT-Hub. Microservices können sowohl direkt als auch in Docker-Containern betrieben und skaliert werden. Zusätzlich stehen den Services auch zwei APIs zur Verfügung: Reliable Services und Reliable Actors. Diese können von verschiedenen Programmiersprachen aus genutzt werden, etwa in C# (.Net, .Net Core) oder auch in Java und in NodeJs. Mit ihrer Hilfe können die Services unter anderem Daten partitioniert speichern. Die Daten werden zwischen den verschiedenen Instanzen eines Service automatisch synchronisiert. Auch eine Aufteilung in Aktoren wird unterstützt. Selbstverständlich kann die Anwendung auch über den TFS in das Cluster deployt werden. Service Fabric-Cluster (Windows, bald Linux) können auch ohne Azure betrieben werden.

Fazit

Mit einer Microservice-Architektur lässt sich die Komplexität einer Anwendung deutlich reduzieren: je nach der Größe (und Vielzahl) der einzelnen Services bieten sich verschiedene Produkte an. Während AWS Lambda und Azure Function mit der automatischen Skalierung punkten, überzeugt Service Fabric durch die Vielzahl an Funktionen und unterstützten Technologien.