Ja oder nein? Entscheidungshilfen pro und contra Microservices (Microservices, Teil 6)

Microservices helfen, schnell auf neue Anforderungen zu reagieren. Zum einen, weil die Software strukturell modular aufgebaut ist und die einzelnen Microservices unabhängig voneinander deployed werden können.

Diese verlockenden Versprechungen der Microservices sind natürlich nicht umsonst zu haben. Microservices erfordern eine technologisch komplexe Infrastruktur (PaaS, s.o.), basieren auf einer an Services ausgerichteten Facharchitektur, bedingen eine Ausrichtung zu DevOps und können sogar Auswirkungen auf ihre Organisationsstruktur haben.

Falls Sie darüber nachdenken, ob Microservice-Architektur für Sie eine grundsätzliche Option (und vor allem in welchem Umfang) ist, stellt sich die Frage, inwieweit Ihre Organisation in der Lage ist, die einzelnen oben beschriebenen Facetten der Microservice-Architektur aufzunehmen. Im besten Fall sollten Sie bereits Kompetenzen in dynamischen Infrastrukturen und Entwicklungsprozessen auf Basis von Continuous Delivery besitzen.

Insbesondere ist es nicht sinnvoll, Microservices-Architektur einzusetzen, aber diese nicht mit einer konsequenten auf Services basierenden Facharchitektur zu unterfüttern.

Microservices sind eine strategische (Neu-)Ausrichtung in Ihrer IT. Sie müssen die Vorteile und Chancen gegen die Investitionen in neue Technologien und Verfahren abwägen. Je besser Ihre Organisation bereits die Neuerungen adaptiert hat, desto weniger müssen Sie investieren.

Pro und Contra Microservices
Abbildung 2: Die Chancen sollten schwerer wiegen als die Investitionen

Wenn Sie sich für Microservice-Architektur entschieden haben, beschäftigen Sie sich mit dem Thema der Einführung. Eine Einführung weniger Microservices gibt Ihnen ein Gefühl für die Herausforderungen an Entwicklung, Architektur und Infrastruktur. Eventuelle Irrwege lassen sich so korrigieren [Thoughtworks-1].

Wichtig ist die Entscheidung für Ihre Cloud-Strategie (private oder public cloud) sowie die passende PaaS und ggfs. den passenden Anbieter.

Erfahrungsgemäß kommt zu Anfang der Impuls, sich mit dem Thema Microservices zu beschäftigen, aus der Softwareentwicklung und der Fokus liegt auf der Technologie. Es ist in dieser Phase sinnvoll in Pilotprojekten zu starten, um Erfahrungen mit den Technologien und Infrastruktur zu sammeln.

Dieser durch die Technik getriebene Ansatz sollte aber spätestens nach erfolgreicher Erfahrungen auch auf die Bereiche Facharchitektur und Betrieb ausgeweitet werden. Spätestens jetzt verlässt dieses Thema den Kokon der Technologie und betrifft alle Bereiche der Softwareentwicklung. Auch in den Bereichen Facharchitektur und IT-Infrastruktur müssen Erfahrungen gesammelt werden.

Soll das Thema der Modularisierung nur für die Struktur der Software gelöst werden, ohne auch den DevOps-Ansatz zu forcieren, so ist es möglich auf OSGi zu setzen. Services laufen innerhalb eines geschützten Containers, welcher die Laufzeit-Infrastruktur wie Deployment oder Service-Discovery bereitstellt.

Auch der Einsatz von Continuous Delivery oder Domain Driven Design ist nicht an eine MicroserviceArchitektur gebunden.

Anderseits sind Microservices kein Allheilmittel für jede Form von Softwaresystemen. Microservice-Architektur richtet sich an komplexe Systeme, denn erst für diese Systeme zahlt sich die erhöhte Investition in die Infrastruktur aus.
So ist kann es durchaus sinnvoll sein, sich gegen die Microservice-Architektur und für eine herkömmliche Architektur zu entscheiden [Fowler-4]. Desktop-Anwendungen für private Endkunden sind keine guten Kandidaten für eine Microservices-Architektur (strukturelle Modularität ist dagegen sehr wohl wünschenswert). Unabhängig, ob Ihre Organisation Microservices-Architektur grundsätzlich unterstützt, ist für jedes System zu entscheiden, ob dieser Ansatz der richtige ist.

Falls Microservices nicht die richtige Wahl für Sie sind, sollten Sie sich dennoch mit den Themen wie Modularisierung, Domain Driven Design, Continuous Delivery und Agilität beschäftigen. Diese grundlegenden Techniken und Technologien werden auch außerhalb des Kontextes der Microservice-Architektur nachhaltigen positiven Einfluss auf Ihre Systeme und Ihren Softwareentwicklungsprozess haben.

So können Sie schon jetzt ohne Microservices von den Vorteilen moderner Softwareentwicklung profitieren. Gleichzeitig legen Sie die Grundlagen für einen späteren Umstieg auf eine Microservices-Architektur.

Artikelserie "Microservices"

Was ist eine Microservice-Architektur? (Microservices, Teil 1)
Microservices aus Sicht der Technologie (Microservices, Teil 2)
Microservices aus Sicht der Software- und Facharchitektur (Microservices, Teil 3)
Microservices aus Sicht des Teams und der Organisation (Microservices, Teil 4)
Testverfahren für Microservices (Microservices, Teil 5)
Ja oder nein? Entscheidungshilfen pro und contra Microservices (Microservices, Teil 6)

Alle Referenzen (Teil 1 bis Teil 6) im Überblick

[Evans] Evans - Domain Driven Design
[Fowler et al] martinfowler.com/articles/Microservices.html
[Fowler-1] http://martinfowler.com/bliki/MicroservicePrerequisites.html
[Fowler-2] http://martinfowler.com/articles/nonDeterminism.htm
[Fowler-3] http://www.martinfowler.com/articles/consumerDrivenContracts.html
[Fowler-4] http://martinfowler.com/bliki/MicroservicePremium.html
[Fowler5] http://martinfowler.com/bliki/IntegrationContractTest.html
[Foxwell] https://blogs.oracle.com/hjfphd/entry/the_9th_fallacy_of_distributed
[Ford et al] https://www.thoughtworks.com/insights/blog/Microservices-evolutionary-architecture
[InfoWorld] http://www.infoworld.com/article/3075880/application-development/microservice-architecture-is-agile-software-architecture.html
[Morris] Kief Morris – Infrastructure as Code
[Netflix-1] https://dzone.com/articles/adopting-Microservices-netflix
[Netflix-2] https://netflix.github.io/
[Newman] Sam Newman - Building Microservices
[Nginx] https://www.nginx.com/blog/introduction-to-Microservices/
[Nygard] Michael Nygard – Release It!
[Pact] http://techblog.newsweaver.com/why-should-you-use-consumer-driven-contracts-for-microservices-integration-tests/hhttp://techblog.newsweaver.com/why-should-you-use-consumer-driven-contracts-for-microservices-integration-tests/
[Pacto] http://thoughtworks.github.io/pacto/
[Peinel] http://www.sigs-datacom.de/uploads/tx_dmjournals/peinl_OTS_Microservices_Docker_16.pdf
[Sequoia] http://de.slideshare.net/SequoiaCapital/sequoia-Microservices-summit-best-practices
[Thoughtworks-1] https://www.thoughtworks.com/radar/techniques/Microservice-envy
[Thoughtworks-2] https://www.thoughtworks.com/insights/blog/architecting-continuous-delivery
[Thoughtworks-3] https://www.thoughtworks.com/insights/blog/Microservices-evolutionary-architecture

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.