Microservices Governance

Leitprinzipien für Microservices Governance

Jedes Unternehmen sollte Leitprinzipien für die Microservices Governance festlegen. Nachdem diese Prinzipien definiert worden sind, müssen sie natürlich auch eingehalten werden. Deswegen sollte die Definition dieser Prinzipien noch vor der Etablierung der Microservices Governance als solche geschehen.

Im Folgenden finden Sie einige ausgewählte Leitprinzipien für eine erfolgreiche Microservices Governance.

Unabhängige Services: Microservices sind nicht von anderen Services abhängig. Diese Unabhängigkeit ermöglicht es Unternehmen, Services schneller zu entwickeln und zu deployen. Dafür ist sowohl Design- als auch Laufzeitunabhängigkeit erforderlich.

Einzelverantwortung: Fokussiert sich auf einen Microservice. Erfordert Business Capabilities, granulare Dekomposition.

Self-Contained Services: Microservices sind eigenständig und können in unabhängige Module aufgeteilt werden. Damit ein Microservice unabhängig sein kann, muss er alle für den Betrieb notwendigen Bausteine enthalten.

Richtlinien & Best practice: Einhaltung von Microservices Domain-Referenzarchitekturen, Governanceprozessen und Roadmap.

Microservices Governance: Das Team

Das Microservices-Architekturteam konzentriert sich in erster Linie auf die Verwaltung und Überwachung der Unternehmensaktivitäten, wozu auch die Gestaltung der Applikationen mithilfe von Microservices-Technologien zählt. Das Team bietet den Endbenutzern die richtigen Funktionen und den entsprechenden betrieblichen Support für die neue Architektur.

Microservices-Betriebsmodell

Bei der unternehmensweiten Einführung von Microservices spielen der Aufbau des Teams und ihre Fähigkeiten eine größere Rolle als die zugrunde liegenden Technologien. Flache Organisationsstrukturen, flexible Teams und funktionsübergreifende Fähigkeiten sind für eine erfolgreiche Einführung von Microservices von wesentlicher Bedeutung.

Die Bildung eines kompetenten Teams erfordert eine Neuausrichtung der Mitarbeiter auf die Funktionalität und nicht auf die Architektur.

Bevor sich Unternehmen in die Microservices-Welt begeben, ist die Entwicklung von DevOps-Praktiken empfehlenswert, da diese die Festlegung von Kommunikationsstrategien erleichtern.

Fähigkeiten & Kompetenzen 

In Microservices-Teams finden sich Personen mit den unterschiedlichsten Fähigkeiten und Kompetenzen. Das Team besteht meist aus Systemanalytikern, UX/UI-Designern, Backend- und Frontend-Entwicklern, etc., die für ihr spezifisches Microservices-Projekt vollumfänglich verantwortlich sind – von der Entwicklung und dem Deployment über den Betrieb bis hin zum Monitoring und Management.

Die Teamgröße wird durch die Unternehmensgröße und das zu entwickelnde Projekt bestimmt. Es hat sich jedoch gezeigt, dass ein Microservices-Team idealerweise aus acht bis zehn Mitgliedern besteht.

In Microservices-Architekturen skalieren die Microservices-Teams mit dem Geschäftswachstum. Jedes Team verfügt über eine kollaborative Plattform, um ihre jeweiligen Projektziele zu erreichen. Dadurch wird sichergestellt, dass Projektfristen eingehalten werden, was wiederum zu einem effizienteren Produkt-Launch führt.

Microservices-Strategie und -Roadmap

DevOps-Strategie: Die Verkürzung der Zykluszeit von der Entwicklung bis zum Deployment ist entscheidend. Anstatt eine Applikation zu implementieren, stellt das Team mehrere Services bereit.

Agile Umgebung: Services werden von Teams in inkrementellen Schritten entwickelt; durch die kurzen Phasen können die Teams Software häufig releasen, was sich positiv auf die Geschäftsentwicklung auswirkt. Zur Verbesserung der Resilienz sollten CI/CD-Workflows verfolgt werden.

Datenstrategie: Für die Datenverteilung ist eine ausgefeilte Strategie für das Stammdatenmanagement erforderlich. Die Nutzung der Stammdaten eines Unternehmens erfolgt durch mehrere Microservices, die in ihren lokalen Datenbanken gespeichert sind.

Microservices Governance: Die Technologien

Referenzarchitektur

Microservices sind weder ein Produkt noch ein Framework oder eine Plattform. Es handelt sich um eine Strategie für den Aufbau großer verteilter Unternehmenssysteme. Microservices-Architekturen bieten Unternehmen viele Vorteile, darunter die unabhängige Skalierung unterschiedlicher Applikationskomponenten zur schnelleren und einfachen Softwareentwicklung und -wartung. Die Größe von Microservices ist für das Design von qualitativ hochwertigen Services elementar. Microservices reduzieren die Abhängigkeit von einem bestimmten Anbieter und eliminieren langfristige Technologieverpflichtungen. Insgesamt helfen Microservices den Entscheidungsträgern bei der Auswahl der Tools, die für die Erreichung ihrer IT- und Geschäftsziele notwendig sind.

Microservices-Referenzarchitekur

Microservices-Referenzarchitekturen bieten eine sofort einsatzbereite Vorlage für die Entwicklung von Systemen, die auf Microservices basieren. Sie tragen somit zur Beschleunigung und Verbesserung der Entwicklung bei.

Erstellt eine Plattform für das Testen neuer Features – unabhängig davon, ob diese intern oder extern entwickelt worden sind.

Hilft Unternehmen dabei, Partnersysteme und -komponenten zu verstehen und einen holistischen Blick auf die Microservices-Umgebung zu erhalten.

Register

Wenn Unternehmen wachsen, kann die Überwachung von Microservices gerade aufgrund der kontinuierlichen Entwicklung zu einer großen Herausforderung werden. Um diese Hürde erfolgreich zu meistern, können sich Unternehmen dynamischer Register bedienen, die ihnen das Tracking der bereitgestellten Services erleichtern.

Tools

Wenn Unternehmen mithilfe von Microservices eine hoch skalierbare Architektur aufbauen möchten, brauchen sie Tools, um zusätzliche Services und Applikationskomponenten zu verwalten, darunter etwa:

• Service Discovery Tools (z.B. Kubernetes)
• Paketierungsstandards für containerisierte Applikationen (z.B. Docker) und Orchestrierungstools für die Replikation von Containern (z.B. Kubernetes) – Red Hats OpenShift umfasst beide genannten Open-Source-Technologien
• Tools zur Erstellung von CI-Umgebungen, Jenkins oder Shippable für Docker und Kubernetes
• Tools zur Identifizierung und Auflösung von Abhängigkeiten (z.B. Nexus)
• Failover- und Resiliency-Tools, einschließlich Bibliotheken wie Hystrix und Ribbon
• Monitoring-, Warnungs- und Event-Tools (z.B. ELK; ElasticSearch, LogStash, and Kibana)

Cloud & API

APIs werden genutzt, um die Interaktion zwischen Microservices zu ermöglichen und so zu gewährleisten, dass Applikationen richtig funktionieren. Darüber hinaus stellt der Versionskontrollmechanismus die Serviceschnittstelle zwischen neuen und alten Services her.

Infrastrukturmanagement

Infrastrukturmanagement befasst sich mit der Überwachung des Speicherplatzes, des CPU-Verbrauchs, des Speicherverbrauchs und der Hardware-Netzwerkeigenschaften für bereitgestellte Services. Infrastrukturservices werden von Nagois überwacht – bei der Verletzung von Services-Leveln löst die Monitoring-Software einen Alarm aus. Wenn ein Service auf einer IaaS- oder PaaS-Plattform deployed wird, dann werden die entsprechenden Cloud- oder Plattform-Management-Tools genutzt.

Service Monitoring

Service Monitoring überwacht den „Gesundheitszustand“ von Applikationen, sobald diese in der Produktionsumgebung deployed werden. Services können ihren Zustand per Pull-Mechanismen via JMX melden oder einen http-Link freigeben, mithilfe derer Software-Agenten Statistiken unter Zuhilfenahme von Spring Actuator Push-Mechanismus sammeln können.

Microservices Governance: Die Prozesse

Funktionsübergreifende Teams & DevOps

In Microservices-Umgebungen arbeiten Entwickler kontinuierlich an neuen Funktionalitäten oder entfernen diese wieder, falls sie sich als ineffektiv erwiesen haben. Diese Änderungen können entweder auf Codeebene durchgeführt werden oder den Austausch von Kernelementen einer Applikation beinhalten. Die Microservices entwickeln sich während dieser Änderungsprozesse kontinuierlich weiter. Eine Applikation wird in eine Vielzahl unabhängiger Services aufgeteilt. Aus großen, isolierten Teams werden kleine, funktionsübergreifende Teams. Das Team, das einen Microservice gebaut hat, ist auch für dessen Implementierung und Wartung verantwortlich. Von diesem Ansatz profitiert der Service sowohl in der Gegenwart als auch in der Zukunft.

Unabhängige Designzeit

Die Definition und Kontrolle der Gestaltung und Entwicklung von Services sowie der Implementierung von Service-Richtlinien.

Laufzeitunabhängigkeit

SLAs, Drosselung, Monitoring, allgemeine Sicherheitsanforderungen und Service Discovery werden nicht auf jeder Microservices-Ebene abgedeckt. API Gateway hilft bei der Realisierung von Runtime Governance auf einer dedizierten Komponentenebene.

Datenmanagement

Im Gegensatz zu serviceorientierten Architekturen (SOA) teilen Microservices keine Daten. Jeder Microservice hat einen eigenen physischen Datenspeicher und charakterisiert sich durch poylglotte Persistenz, sodass Microservices viele unterschiedliche Datenbanken nutzen können.

Die Pflege mehrerer Kopien einer Unternehmensdatenbank kann jedoch die Lizenzkosten und die Komplexität in die Höhe treiben.

Für die Datenvisualisierung kann auf allgemeine ETL-Tools (Extract, Transform and Load Tools) oder Datenvisualisierungstools zurückgegriffen werden. Event Sourcing ist ein bekanntes Designmuster, mit dem Datenspeicher so ausgerichtet werden können, dass sie sich an rückwirkende Änderungen anpassen.

Fazit

Microservices Governance erleichtert Teams die Entwicklung und das Deployment von Code, der nach individuellen Governance-Plänen erstellt worden ist. Das Ziel dezentraler Governance ist es, Entwicklungsteams mehr Freiraum einzuräumen, damit sie Entwicklungsprobleme zeitnah und selbstbestimmt lösen können. Für eine erfolgreiche Microservices Governance muss eine DevOps-Kultur in Unternehmen etabliert werden. Mit dieser Einstellung und dem neu gewonnenen Selbstverständnis erlangen Entwickler die Kontrolle über die Entwicklung und den Betrieb der Komponenten wieder, für die sie verantwortlich sind.