Schrittweise Änderungen und Anpassungen der Anforderungen an die Architektur müssen daher akzeptiert und umgesetzt werden können.
In neuen und teilweise auch in laufenden Software-Projekten wird darüber diskutiert, die Architektur auf Basis von Microservices aufzubauen. Diese Artikelserie geht den Fragen nach,
- welche Ziele eine Microservice-Architektur hat,
- was sie ausmacht,
- welche Auswirkungen sie hat,
- welche Vor- und Nachteile sie mit sich bringt und
- für welche Projekte sie sich lohnt und wo sie eher nicht angebracht ist.
Das Hauptziel der Microservice-Architektur ist es, das Konzept einer evolutionären Architektur zu unterstützen [Thoughtworks-3]. Schrittweise Änderungen ohne große Brüche und Verwerfungen (Evolution) zu ermöglichen, sind das grundsätzliche Prinzip dieser Architektur.
Eine Anwendung ist im Sinn von Microservices ein System kooperierender Services (Microservices). Services laufen in getrennten Prozessen und kommunizieren mit anderen Services über leichtgewichtige Verfahren (z.B. REST oder HTTP) [Fowler et al].
Wir sollten an dieser Stelle von Microservices Architecture Style oder Microservice-Architektur sprechen, denn Microservices gehen deutlich über eine Technologie oder ein Programmierparadigma hinaus. Aus der oben gegebenen Beschreibung ergeben sich eine Reihe von Implikationen, die in weite Bereiche der Anwendungsarchitektur, des Softwareentwicklungsprozesses und sogar in die Organisation von Teams bis hinein in den Betrieb wirken.
Modularität ist eine der Haupttaktiken der Microservice-Architektur, um das evolutionäre Prinzip zu unterstützen.
Grundpfeiler des Konzepts der Modularität ist die klare Abgrenzung der Services untereinander. Dies bedingt die Beschreibung einer öffentlichen Schnittstelle (public interface). Die Möglichkeit public interfaces zu definieren, ist in vielen Programmiersprachen (Java, JavaScript) nicht gegeben und daher kann dort das Konzept der öffentlichen Schnittstelle nur informell umgesetzt werden. Es ist entsprechend korrosionsanfällig und wird im Laufe des Lebenszyklus der Software immer mehr aufweichen. Durch die Forderungen nach getrennten Prozessen (und damit verbunden die Forderungen nach remote communication) erzwingen Microservices public interfaces und unterstützen daher per Konzept (und damit nur schwer zu umgehen) diese Grundvoraussetzung der Modularität. Damit wird die strukturelle Modularität der Software unterstützt. Auch public interfaces unterliegen dem evolutionären Gedanken und müssen so entworfen werden, dass sie leicht an neue Anforderungen angepasst werden können.
Da Microservices in getrennten Prozessen laufen, können sie unabhängig voneinander deployed, in Betrieb genommen und skaliert werden. Durch das Aufkommen der LightWeight-Container, insbesondere Docker, können einzelne Microservices wirklich weitgehend unabhängig voneinander deployed und betrieben werden.
Damit ist die Abhängigkeit der Microservices auf die Abhängigkeit der Schnittstellen reduziert. Änderungen eines Services haben marginale Auswirkungen auf den Rest des Systems und können unabhängig ausgerollt werden. Je besser der Entwurf des public interfaces sich auf dieses Konzept der Unabhängigkeit einstellt, desto geringer sind die Abhängigkeiten der Services untereinander.
In den nächsten Artikeln werden wir Microservices aus unterschiedlichen Aspekten beleuchten:
