Was sich bei der Microservice-Einführung bewährt hat Microservices – Ein Einstieg in die Praxis

Viele Unternehmen wollen monolithische Anwendungen umgestalten und Microservice-Architekturen für mehr Agilität und Skalierbarkeit aufbauen. Doch wie gelingt der Einstieg ins Thema Microservices? Nach welchen Prinzipien sollte man arbeiten? Was sind die Erfolgsfaktoren und wo liegen die Fallen? Ein Leitfaden liefert erste Anhaltspunkte.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Confluent Germany GmbH

CA Deutschland GmbH

Monolithische Anwendungen sind in der digitalen Wirtschaft von heute nicht flexibel genug. Die Development-Teams vieler Unternehmen haben bei großen Legacy-Anwendungen Probleme, die Vorgaben bezüglich Entwicklungszeit, Bereitstellung und Skalierbarkeit einzuhalten. Angesichts der Erfolge von DevOps-Frameworks und agiler Methoden sehen sich CIOs quasi gezwungen, nun auch komplexe Anwendungssilos in kleinere, flexible Codeblöcke zu zerlegen.

Definitionsgemäß ist ein Microservice eine unabhängig bereitstellbare Komponente mit begrenztem Umfang, die über eine nachrichtenbasierte Kommunikation Interoperabilität unterstützt. Haben wir also in einigen Jahren keine großen, monolithischen Lösungen mehr, sondern nur noch Microservices? Jein. Die Microservice-Architektur sind ein Ansatz, der zwar einige Probleme in der IT lösen kann, aber kein Allheilmittel.

Zum einen sind Microservices nicht alleine eine Frage der IT. Dezentralisierung heißt letztlich, dass die Arbeit im System nicht länger zentral gemanagt und kontrolliert wird – und das braucht Vertrauen. Zum anderen gibt es Lösungen, die in ihrer Spezialisierung durchaus monolithisch angelegt sein können, ohne die Agilität des Unternehmens zu beeinträchtigen. Es wäre also durchaus möglich, Microservices in manchen Bereichen eines Unternehmens umzusetzen, in anderen aber eher auf die traditionellen Methoden zu bauen.

Microservices – für wen und wie?

Grundsätzlich aber sind Microservices ein guter Weg, um Lösungen in großem Maße zugleich schneller und sicherer zu erstellen. Doch wo oder für wen? Prinzipiell gilt: Je agiler – desto Microservice! Setzt ein Unternehmen bereits auf agile Methoden und DevOps-Modelle, dann ist das eine ideale Voraussetzung.

Kleine Services für schnelle Ergebnisse

Microservices – Neue Geheimwaffe oder SOA-Remake?

Beide Ansätze sorgen für kürzere Innovationszyklen und schnellere Bereitstellung. Sie unterstützen eine dezentralisierte und verteilte Verwaltung von Software-Assets. Zerlegt man nun eine große Anwendung in Microservices, werden Updates und autonome Bereitstellungen noch flexibler. Es entfällt auch die Notwendigkeit immer anspruchsvollerer Architekturen zur Erhöhung der Skalierbarkeit, um große Nachfragen zu erfüllen.

Kurz: Unternehmen, die agile Methoden anwenden oder über DevOps nachdenken, sind auch bereit für Microservices. Doch auch für sie gibt es einige Erfolgsrezepte:

1. Nichts geht ohne eine Plattform

Prinzipien reichen nicht aus, man braucht Tools für die Umsetzung – also eine Plattform. Diese Plattformen sind meist sehr individuell, enthalten aber einige standardisierte Komponenten wie Container Technologie z.B. Docker, Regelunterstützung, Service-Orchestrierung oder Datenspeicherung. Auch Hardware, Datenbanktechnologien oder Software-basierte Infrastruktur werden als standardisierte, gemeinsame Infrastruktur definiert.

Ziel ist es, das Set-up von Hardware, aber auch das Aufspielen und Testen von Applikationscode zu automatisieren und die Orchestrierung mit möglichst vielen Teams zu teilen. Security und Policy-Services werden über eine Plattform zum Allgemeingut.

2. Selbständige Teams leisten mehr

Die effizientesten Development-Teams bestehen aus fünf bis zwölf Personen, die offen für Neues und einigermaßen Chaos-resistent sind. Diese kleineren Development-Teams sind dann am leistungsstärksten, wenn sie eigenverantwortlich für eine kleinere Teilmenge von Services/ APIs zuständig sind.

Dies begünstigt aus technischer Sicht auch die lose Kopplung und autonome Bereitstellung von Services. Ihr Job ist es, den Prozess des Roll-out, Monitoring und Verwaltens der Virtuellen Maschinen (VM) bzw. des Deployments zu automatisieren und die Auswirkungen des neuen Release auf das restliche System im kontrollierten Roll-out zu testen.

3. Bewährte Tools nutzen

Für mehr Effizienz könnte man Tools vorselektieren – am einfachsten populäre Werkzeuge wie die Konfigurationstools Decider von Twitter oder Gatekeeper von Facebook, Jenkins für die Automatisierung oder Entwicklungstools sowie Support Libraries.

Sehr nützlich sind Service Discovery Tools wie Apache Zookeeper, etcd von CoreOS oder Consul von HashiCorp, denn damit registrieren sich neue Services sofort bei einer zentralen Quelle, so dass andere Services sie über ihre exakte Adresse sofort ansprechen können. Doch nicht für alles gibt es das richtige Werkzeug und für manche Teams kann es durchaus ein Motivationsfaktor sein, ihre eigenen Tools zu entwickeln.

4. Behalten Sie den Überblick

Monitoring ist fast so wichtig wie die Entwicklung selbst. Natürlich gibt es auch hierfür Tools. So hilft Zipkin von Twitter dabei, die laufenden Instanzen, mitsamt ihrer Failure/Sucess-Raten, Engpässe auch in dynamischen verteilten Umgebungen im Blick zu behalten.

Andere Tools gehen noch einen Schritt weiter und greifen ein, wenn etwas schiefzugehen scheint, re-routen den Traffic und geben Alarm. Oder aber sie testen im laufenden Betrieb, wie Hystrix von Netflix, das mit dem „circuit breaker“ die Resilienz des laufenden Systems verbessern will.

Mikrodienste entwerfen und strukturieren

Best Practices zu Microservice-Design, Logik und APIs

Ein Erfolgsbeispiel aus der Praxis

Dass der Übergang von Monolithen auf Microservices funktionieren kann, zeigt das Beispiel Hootsuite. Mit dem rasanten Wachstum des Unternehmens wuchs auch die monolithische PHP-basierte Plattform. Um agil zu bleiben, stellte Hootsuite auf eine Microservice-Architektur um und brach Teil um Teil aus dem Monolithen, um ihn durch Services zu ersetzen.

API-Definitionen und damit verbundene Contracts beschrieben Umfang und Funktion der Services. Und schließlich wurden auch die Anwender involviert. API-Design Guidelines helfen, eine gemeinsame Sprache im Prozess zu finden.

Die Microservices wurden bei Hootsuite in drei Kategorien unterteilt:

• Data Services, die die wichtigsten Geschäftseinheiten umfassen und Skalierbarkeit garantieren.

• Funktionale Services, die Daten Services mit einer Geschäftslogik verbinden.

• Fassaden-Services, die Anwenderwünsche von der funktionalen Geschäftslogik trennen.

Zur Organisation gehören produktbezogene Teams, aber auch ein plattformübergreifendes Team für die Frameworks, das Tooling und das Monitoring/Controlling. Um gemeinsame Interessen wie APIs und Java Skript anzusprechen, wurden „Zünfte“ gegründet, in die jeder „eintreten“ konnte.

Um die Geschwindigkeit nicht zu limitieren, verzichtete Hootsuite auf Governance Checkpoints, die den Entwicklungsprozess unterbrechen könnten. Stattdessen definierte die Community Prinzipien und Tools. Eine neue Architektur-Gruppe aus technisch versierten Leitern kümmert sich um technologische Fragen, die keinen durchgreifenden Effekt auf die Organisation haben.

Das Toolset ist zielorientiert: Docker und Mesos für Adress Deployment, Consul und NGINX für Service Discovery. Scala, Akka und das Play Framework helfen bei der Erstellung individueller Services, http und Kafka für die Kommunikation zwischen den Services. Dynamische Systemvisualisierungen verbinden die Code-Repositories und operationale Dokumentation.

Georg Lauer

Nun besteht eine Microservice-Architektur unabhängig von Tools und Rahmenbedingungen vor allem aus einem: Microservices. Doch wie kann man diese Komponenten gut gestalten? Wie sieht gutes Microservice-Design aus? Das erfahren Sie in Teil 3 „Microservices – Service Design“ unserer Artikelserie.

* Georg Lauer ist als Senior Principal Business Technology Architect bei CA Technologies tätig.

(ID:45056668)