Software Engineering

Microservices – Hype oder mehr?

Microservices werden seit geraumer Zeit vielfach diskutiert, doch was steckt eigentlich dahinter und wann lohnt sich der Einsatz von Microservices? Manche Vorträge und Blogposts zum Thema lassen die Vermutung zu, Microservices seien die nächste Silver Bullet der Software-Architektur. Ist dem wirklich so, sind Microservices nur eine besondere Form der service-orientierten Architektur (SOA) oder können Sie als eigener Architekturstil gelten?

Definitionsversuch

Wie in vielen anderen Bereichen, so ist auch in diesem Fall zu erkennen, dass keine allgemein gültige Definition des Begriffs existiert. Die Vielzahl von Konferenz-, Vortrags- und Blog-Beiträgen zum Thema ist ebenso heterogen, es gibt jedoch zwei primäre Ansichten. Einerseits werden Microservices als neuartiger Architekturstil präsentiert, der sich stark von anderen, insbesondere SOA unterscheiden soll, andererseits wird vielfach auch davon gesprochen, Microservices sei „service orientation done right“.

Nachfolgend werde ich versuchen die primären Merkmale von Microservices zusammenfassen. Aus meiner Sicht gibt es zwei Dimensionen, die dabei von Bedeutung sind: eine technische und eine organisatorische. Wird nur eine der beiden berücksichtigt, ist es sehr wahrscheinlich, dass die Prinzipien des Konzepts nicht oder nur unzureichend umgesetzt werden.

[section_separator divider_candy=“bottom“ icon=“fa-info-circle“ icon_color=“#81d742″ bordersize=“1px“ bordercolor=“#7a7a7a“ backgroundcolor=““ class=““ id=““]

Mehr im Web

[social_links icons_boxed=“no“ icons_boxed_radius=“6px“ icon_colors=“green“ box_colors=““ tooltip_placement=““ rss=““ facebook=““ twitter=“https://twitter.com/hashtag/microservices“ instagram=““ dribbble=““ google=““ linkedin=““ blogger=“http://www.heise.de/developer/artikel/Microservices-im-Zusammenspiel-mit-Continuous-Delivery-Teil-2-die-Ablaufumgebung-2423582.html“ tumblr=““ reddit=““ yahoo=““ deviantart=““ vimeo=““ youtube=“https://www.youtube.com/watch?v=DvLvHnHNT2w“ pinterest=““ digg=““ flickr=““ forrst=““ myspace=““ skype=““ paypal=““ dropbox=““ soundcloud=““ vk=““ email=““ show_custom=“no“ alignment=“center“ class=““ id=““]


[accordian divider_line=““ class=““ id=““][toggle title=“Mehr zu Microservices & SOA“ open=“no“]

Meiner Ansicht nach besteht in der Theorie kein Unterschied zu SOA (siehe GI). In der Praxis wird SOA oftmals mit der Implementierung von Diensten gleichgesetzt, die über einen Enterprise Service Bus (ESB) miteinander agieren. Zur Interaktion der Dienste wird vielfach auch die Business Process Execution Language (WS-BPEL) eingesetzt. Im Ergebnis entstehen Systeme die zwar auf einzelnen Diensten basieren, deren lose Kopplung aber durchbrochen wird. Schlimmstenfalls entstehen daraus nicht gewünschte Abhängigkeiten und die Änderung eines einzelnen Dienstes verursacht das erneute Ausrollen (Deployment) der ganzen Systemlogik (vieler Dienste). Da dies jedoch nicht mit der Theorie service-orientierte Systeme vereinbar ist, folge ich der Auffassung, dass Microservices als eine Variante der SOA oder eben einfach „SOA done right“ sind. Aufgrund der vorgenannten Probleme wird für die Implementierung von Microservices in der Regel davon abgesehen schwergewichtige Middleware-Produkte einzusetzen. Für den Nachrichtenaustausch zwischen den Diensten werden daher einfachere Kommunikationsmechanismen wie REST oder Messaging über eine leichtgewichtige, asynchrone Kommunikationsinfrastrukturen wie RabbitMQ oder Vert.x eingesetzt.

[/toggle][/accordian]

Technische Dimension

Der Microservice-Ansatz kann als Architekturstil für den Entwurf verteilter Softwaresysteme gesehen werden. Kurz gesagt, sind Microservices ein Ansatz für die Implementierung eines Systems durch eine größere Menge von kleinen Diensten (Services). Jeder dieser Dienste soll unabhängig ausgeführt (eigener Prozessraum) werden, seine eigenen Daten (Datenbank) nutzen und leichtgewichtige Kommunikationsmechanismen gegenüber anderen Diensten bieten (z.B. über HTTP oder HTTPS). Weiterhin wichtig ist, dass die Dienste ausschließlich Funktionalitäten beinhalten, die sich zur Umsetzung einer einzigen Geschäftsfunktion (Business Capability) identifizieren lassen. Die Dienste haben somit einen fachlich stark eingeschränkten Fokus, woraus in der Regel direkt die Grundprinzipien service-orientierter Architekturen umgesetzt werden, insbesondere werden die Paradigmen der losen Kopplung, starken Kohäsion und der Trennung unterschiedlicher Belange (Separation of Concerns) gefördert.

Im Endeffekt führt dies dazu, dass einzelne Dienste leicht gegen neue Implementierungen getauscht werden können und die Entwicklungsteams (besser) unabhängig voneinander arbeiten können. Hieraus ergeben sich dann auch die charakteristischen technischen Merkmale der Microservices:

  • Evolutionäres Design (Evolutionary Design)
  • Strenge Kapselung (Shared Nothing)
  • Intelligente Dienste und einfache Kommunikation (Smart Endpoints & Dumb Pipes)
  • Automatisierung der Infrastruktur (Build-, Test- und Deployment-Prozesse)

Aus der strengen Kapselung folgt praktisch unmittelbar, dass Änderungen jederzeit möglich sind und Dienste somit prinzipiell beliebig durch neue Implementierungen ersetzt werden können (Evolutionäres Design). Erreicht wird diese Kapselung durch das Shared Nothing Konzept. Abhängigkeiten im Sinne gemeinsamer Quell-Codes und gemeinsamer Datenquellen werden hierbei vermieden; stattdessen werden externe Quellcode-Bibliotheken genutzt (oftmals auch wenn ursprünglich eine interne Entwicklung vorlag) und jeder Dienst implementiert seine eigene Datenhaltung.

Die gewünschte, einfache Kommunikation (Smart Endpoints & Dumb Pipes) basiert auf dem bekannten Architekturmuster Pipes & Filters – man könnte dies daher auch als Dienste im Stil von UNIX bezeichnen. Die intelligente Verarbeitung von Nachrichten erfolgt dabei innerhalb der Dienste (Smart Endpoint), während die Kommunikation lediglich die einfache Verteilung von Nachrichten umsetzt (Dumb Pipe).

Organisatorische Dimension

Die Umsetzung von großen Systemen erfolgt zumeist durch spezialisierte Teams. Die Teams werden den Schichten der Softwarearchitektur entsprechend gebildetund sind dadurch je Anwendungsschicht auf einen technischen Aspekt spezialisiert (z.B. auf UI oder Middleware). Diese Organisation der Teams wird  sich üblicherweise in der Systemarchitektur widerspiegeln; dies ist ein Sachverhalt der bereits aus Conways Gesetz bekannt ist:

“Any organization that designs a system … will inevitably produce a design whose structure is a copy of the organization’s communication structure.” — M.E. Conway

Im Endeffekt wird sich der oben genannte Sachverhalt in der Bildung von starken Abhängigkeiten zwischen den Diensten einer Anwendungsschicht niederschlagen. Sobald das System eine gewisse Größe überschritten hat, bedeuten Änderungen der Logik dann oftmals einen hohen Aufwand. Wie bereits erwähnt fokussieren Dienste in einer Microservice-Architektur eine einzige Geschäftsfunktion. Zur Implementierung eines einzelnen Dienstes wird eine breite technologische Basis – einschließlich der Benutzerschnittstelle, der Datenhaltung und der externen Kommunikation – genutzt. Horizontale Abhängigkeiten sollen dadurch aufgebrochen werden, von daher fällt auch die Team-Organisation anders aus. Teams werden typischer Weise funktionsübergreifend organisiert, die Teammitglieder entstammen also unterschiedlichen Aufgabenbereichen und bringen verschiedene Expertisen ein.

Damit das Team seine Dienste schließlich nach Bedarf und mit geringer Verzögerung erneut bereitstellen kann, sobald eine Änderung erforderlich wird, kommen in der Regel Mechanismen zur vollautomatischen Bereitstellung von Änderungen zum Einsatz. Da die Änderung eines Dienstes auch das Gesamtsystem betrifft (andere Dienste somit ebenfalls betreffen können) übernehmen die Teams in der Regel auch die Verantwortung über den Betrieb ihrer Dienste (oft als DevOps bezeichnet). Hieraus entsteht dezentrale Governance, die durch umfangreiche Monitoring- und Recovery-Werkzeuge (wie bspw. Hysterix) ergänzt wird – ein Team muss schließlich bei Bedarf auch auf andere, geänderte oder neue Dienst reagieren können.

Fazit

Die Entwicklung von Anwendungen basierend auf Prinzipien des Microservice Architekturstils bringt einige Vorteile mit sich. Insbesondere die einfache Ersetzung bestehender Dienste verspricht langfristig und gut wartbare Gesamtsysteme. Einschränkend muss eingeräumt werden, dass der Architekturstil derzeit zwar verstärkt Anwendung findet, die exakten und langfristigen Auswirkungen sich jedoch erst in den nächsten Jahren zeigen können.

Eine der großen Herausforderungen in Bezug auf die Umsetzung von Microservice Architekturen, ist die Zerlegung des Systems, sodass in angemessener Weise zugeschnittene Dienste entstehen, daher werden auch hierzu verschiedene Strategien beschrieben. Zur Implementierung muss ferner eine deutlich stärker automatisierte technische Infrastruktur (insbesondere für Deployment und Monitoring) eingesetzt werden. Neben den technischen und plattformabhängigen Aspekten ist auch die Organisation der Entwicklungsteams entscheidend für die erfolgreiche Implementierung von Microservices.