Was sich bei der Microservice-Einführung bewährt hat

Microservices – Ein Einstieg in die Praxis

| Autor / Redakteur: Georg Lauer * / Stephan Augsten

Hin und wieder wirken Software-Monolithen zu mächtig, als dass sie sich in kleinere Fragmente aufsplitten ließen. Doch der Umbruch kann gelingen.
Hin und wieder wirken Software-Monolithen zu mächtig, als dass sie sich in kleinere Fragmente aufsplitten ließen. Doch der Umbruch kann gelingen. (Bild: Dawn Armfield - Unsplash.com / CC0)

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.

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.

Microservices – Neue Geheimwaffe oder SOA-Remake?

Kleine Services für schnelle Ergebnisse

Microservices – Neue Geheimwaffe oder SOA-Remake?

05.12.17 - Microservices – der Programmieransatz wird als Geheimwaffe gehandelt, die Software schneller und flexibler macht. Kleine Codeblöcke – Microservices – statt komplexer Anwendungssilos klingt gut. Doch wie? Und … hatten wir das nicht schon mal? lesen

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.

Best Practices zu Microservice-Design, Logik und APIs

Mikrodienste entwerfen und strukturieren

Best Practices zu Microservice-Design, Logik und APIs

01.02.18 - Wie sieht gutes Microservice-Design aus? Wenn Micro klein ist – wie klein sind dann die Services? Wie können APIs und Frameworks dafür aussehen? Was kann eine lose Kopplung gefährden? Und wie stellt man Datenpersistenz sicher? Ein Blick auf die Entwicklung aus einer System-Perspektive. lesen

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
Georg Lauer (Bild: CA Technologies)

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.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45056668 / Microservices)