von Redaktion IT-A…
Lesezeit
2 Minuten
Seite 2 - Microservices aus Admin-Sicht
Vor- und Nachteile der Infrastrukturansätze
Die wichtigsten Vorteile von Microservice-Architekturen ergeben sich direkt aus der Modularität. So lassen sich einzelne Funktionen aktualisieren, deployen oder skalieren, ohne dafür andere Teile des Systems anfassen zu müssen. Das ist besonders praktisch bei Systemen, die stetigem Wandel unterliegen oder sich den regelmäßig verändernden Geschäftsanforderungen anpassen müssen.
Durch das separate Deployment lassen sich Anwendungskomponenten innerhalb kürzerer Zeit implementieren oder modifizieren, da unterschiedliche Entwicklungsteams parallel arbeiten, ohne dass die Änderungen das Gesamtsystem tangieren. So können neue Features schnell und effizient parallel zum Live-Betrieb der Applikation entwickelt beziehungsweise bestehende Features aktualisiert werden.
Damit einher geht die Resilienz des Systems. Kommt es zu einer Störung oder einem Ausfall bei einem der Services, kann die Anwendung in der Regel problemlos weiterarbeiten. Anders ist dies bei monolithischen Strukturen. Störungen oder Ausfälle einzelner Anwendungen legen hier schnell das gesamte System lahm, bis diese wieder behoben sind. Eingeschlossen sind hier auch Fehlfunktionen, die vom Provider ausgehen können.
Die Separierung von Komponenten und Kommunikation über APIs ermöglicht Unternehmen mit Microservices wesentlich freier in der Technologiewahl zu sein. Die Abhängigkeit von einer zentralen Codebasis und der entsprechenden Programmiersprache beziehungsweise einem Softwareanbieter, die häufig bei monolithischen Strukturen besteht, entfällt dadurch. Zudem lassen sich Microservices theoretisch unbegrenzt skalieren. Der gewünschte Dienst lässt sich dabei über multiple Server oder Infrastrukturen hinweg flexibel deployen. Bei monolithischen Architekturen müsste dafür das gesamte System auf einer zusätzlichen Infrastruktur implementiert werden.
Microservices richtig betreiben
Im Gegensatz zu monolithischen Systemen, in denen meist nur eine Komponente auszurollen und zu betreiben ist, sind bei Microservice-Architekturen multiples Deployment und der Betrieb diverser modularer Elemente erforderlich. Daraus ergeben sich für Unternehmen einige Herausforderungen, in der Entwicklung und vor allem im Betrieb.
Da ist zum einen die Einführung neuer Technologien, die in der Regel mit dem Umstieg auf Microservices einhergeht. Setzen die unterschiedlichen Komponenten beziehungsweise Systeme auf verschiedene Technologien, erzeugt die Schaffung von Konsistenz unter Umständen einen Mehraufwand. Zudem setzen diverse Technologien Fachkenntnisse voraus, die nicht in jedem Unternehmen vorhanden sind. Dieser Mehraufwand lässt sich durch die der Form geschuldeten Einheitlichkeit monolithischer Systeme entsprechend umgehen.
Zum anderen handelt es sich bei Microservices um dezentrale Komponenten, was ein hohes Maß an Kommunikation zwischen den einzelnen Anwendungen mit sich bringt. Das erfordert in der Regel zusätzliche Netzwerkressourcen und resultiert, verglichen mit monolithischen Systemen, oft in höheren Latenzen. Zudem müssen für verteilte Anwendungen die Lasttests und das Monitoring überarbeitet werden, um gleichmäßigen Ressourcenverbrauch zu gewährleisten.
Der Aufwand bei der Einführung von Microservice-Architekturen ist in den meisten Fällen erheblich. Zudem ist eine Anpassung bestehender Kommunikationswege dringend erforderlich. Verantwortliche sollten daher genau nachhalten, ob dieser erhöhte Zeit- und Ressourcenaufwand zu einer nachhaltigen Verbesserung der eigenen Systeme führt.
Dann lohnt sich die Investition
Microservice-Architekturen setzen dedizierte Experten mit konkretem Fachwissen voraus. Zudem müssen Unternehmen bereit sein, bei der Technologieauswahl, Entwicklungsentscheidungen und Verantwortlichkeiten auf die Entwicklungsteams zu vertrauen. Eine zentralisierte Hierarchie mit strikten Vorgaben steht der Idee eines schnellen und unabhängigen Deployments entgegen. Halten Administration und Teams an alten Strukturen fest, besteht die Möglichkeit, dass sich ein "De-Facto-Monolith" entwickelt, bei dem zwar Microservices zum Einsatz kommen, die dann aber zu festgelegten Intervallen alle auf einmal ausgerollt werden. So erhalten Unternehmen das Schlechteste aus beiden Welten.
Sind die Ressourcen für die Entwicklung und Orchestrierung gegeben, empfehlen sich Microservice-Architekturen definitiv für Projekte beziehungsweise Anwendungen, die zum einen komplex sind und zum anderen hochgradig skalierbar sein sollen. Dabei müssen Unternehmen Projekte nicht zwingend vollständig intern abbilden. Microservice-Architekturen erlauben die einfache Einbindung externer Partner zur Entwicklung neuer Features, ohne dass der Dienstleister Zugriff auf das gesamte System erhalten muss.
Fazit
Der Mensch ist ein entscheidender Faktor, wenn es darum geht, eine erfolgreiche Microservices-Infrastruktur zu implementieren. Schaffen es IT-Teams, die Verantwortung für die eigenen Projekte zu übernehmen und IT-Administratoren entsprechend loszulassen und auf die Eigenverantwortung im Team zu vertrauen, entstehen nicht nur erfolgreiche Projekte, sondern auch ein besserer Austausch und eine engere Zusammenarbeit aller Instanzen. Teams bekommen so ein besseres Verständnis für die Aufgabenstellung der Administration und es entsteht ein neues Vertrauensverhältnis, mit dem sich nach und nach neue und größere Projekte umsetzen lassen.
Seite 1: Das unterscheidet Monolithen von Microservices
Seite 2: Microservices richtig betreiben
ln/Bernd Alter, Co-CTO bei Turbine Kreuzberg
Die wichtigsten Vorteile von Microservice-Architekturen ergeben sich direkt aus der Modularität. So lassen sich einzelne Funktionen aktualisieren, deployen oder skalieren, ohne dafür andere Teile des Systems anfassen zu müssen. Das ist besonders praktisch bei Systemen, die stetigem Wandel unterliegen oder sich den regelmäßig verändernden Geschäftsanforderungen anpassen müssen.
Durch das separate Deployment lassen sich Anwendungskomponenten innerhalb kürzerer Zeit implementieren oder modifizieren, da unterschiedliche Entwicklungsteams parallel arbeiten, ohne dass die Änderungen das Gesamtsystem tangieren. So können neue Features schnell und effizient parallel zum Live-Betrieb der Applikation entwickelt beziehungsweise bestehende Features aktualisiert werden.
Damit einher geht die Resilienz des Systems. Kommt es zu einer Störung oder einem Ausfall bei einem der Services, kann die Anwendung in der Regel problemlos weiterarbeiten. Anders ist dies bei monolithischen Strukturen. Störungen oder Ausfälle einzelner Anwendungen legen hier schnell das gesamte System lahm, bis diese wieder behoben sind. Eingeschlossen sind hier auch Fehlfunktionen, die vom Provider ausgehen können.
Die Separierung von Komponenten und Kommunikation über APIs ermöglicht Unternehmen mit Microservices wesentlich freier in der Technologiewahl zu sein. Die Abhängigkeit von einer zentralen Codebasis und der entsprechenden Programmiersprache beziehungsweise einem Softwareanbieter, die häufig bei monolithischen Strukturen besteht, entfällt dadurch. Zudem lassen sich Microservices theoretisch unbegrenzt skalieren. Der gewünschte Dienst lässt sich dabei über multiple Server oder Infrastrukturen hinweg flexibel deployen. Bei monolithischen Architekturen müsste dafür das gesamte System auf einer zusätzlichen Infrastruktur implementiert werden.
Microservices richtig betreiben
Im Gegensatz zu monolithischen Systemen, in denen meist nur eine Komponente auszurollen und zu betreiben ist, sind bei Microservice-Architekturen multiples Deployment und der Betrieb diverser modularer Elemente erforderlich. Daraus ergeben sich für Unternehmen einige Herausforderungen, in der Entwicklung und vor allem im Betrieb.
Da ist zum einen die Einführung neuer Technologien, die in der Regel mit dem Umstieg auf Microservices einhergeht. Setzen die unterschiedlichen Komponenten beziehungsweise Systeme auf verschiedene Technologien, erzeugt die Schaffung von Konsistenz unter Umständen einen Mehraufwand. Zudem setzen diverse Technologien Fachkenntnisse voraus, die nicht in jedem Unternehmen vorhanden sind. Dieser Mehraufwand lässt sich durch die der Form geschuldeten Einheitlichkeit monolithischer Systeme entsprechend umgehen.
Zum anderen handelt es sich bei Microservices um dezentrale Komponenten, was ein hohes Maß an Kommunikation zwischen den einzelnen Anwendungen mit sich bringt. Das erfordert in der Regel zusätzliche Netzwerkressourcen und resultiert, verglichen mit monolithischen Systemen, oft in höheren Latenzen. Zudem müssen für verteilte Anwendungen die Lasttests und das Monitoring überarbeitet werden, um gleichmäßigen Ressourcenverbrauch zu gewährleisten.
Der Aufwand bei der Einführung von Microservice-Architekturen ist in den meisten Fällen erheblich. Zudem ist eine Anpassung bestehender Kommunikationswege dringend erforderlich. Verantwortliche sollten daher genau nachhalten, ob dieser erhöhte Zeit- und Ressourcenaufwand zu einer nachhaltigen Verbesserung der eigenen Systeme führt.
Dann lohnt sich die Investition
Microservice-Architekturen setzen dedizierte Experten mit konkretem Fachwissen voraus. Zudem müssen Unternehmen bereit sein, bei der Technologieauswahl, Entwicklungsentscheidungen und Verantwortlichkeiten auf die Entwicklungsteams zu vertrauen. Eine zentralisierte Hierarchie mit strikten Vorgaben steht der Idee eines schnellen und unabhängigen Deployments entgegen. Halten Administration und Teams an alten Strukturen fest, besteht die Möglichkeit, dass sich ein "De-Facto-Monolith" entwickelt, bei dem zwar Microservices zum Einsatz kommen, die dann aber zu festgelegten Intervallen alle auf einmal ausgerollt werden. So erhalten Unternehmen das Schlechteste aus beiden Welten.
Sind die Ressourcen für die Entwicklung und Orchestrierung gegeben, empfehlen sich Microservice-Architekturen definitiv für Projekte beziehungsweise Anwendungen, die zum einen komplex sind und zum anderen hochgradig skalierbar sein sollen. Dabei müssen Unternehmen Projekte nicht zwingend vollständig intern abbilden. Microservice-Architekturen erlauben die einfache Einbindung externer Partner zur Entwicklung neuer Features, ohne dass der Dienstleister Zugriff auf das gesamte System erhalten muss.
Fazit
Der Mensch ist ein entscheidender Faktor, wenn es darum geht, eine erfolgreiche Microservices-Infrastruktur zu implementieren. Schaffen es IT-Teams, die Verantwortung für die eigenen Projekte zu übernehmen und IT-Administratoren entsprechend loszulassen und auf die Eigenverantwortung im Team zu vertrauen, entstehen nicht nur erfolgreiche Projekte, sondern auch ein besserer Austausch und eine engere Zusammenarbeit aller Instanzen. Teams bekommen so ein besseres Verständnis für die Aufgabenstellung der Administration und es entsteht ein neues Vertrauensverhältnis, mit dem sich nach und nach neue und größere Projekte umsetzen lassen.
Seite 2: Microservices richtig betreiben
| << Vorherige Seite | Seite 2 von 2 |
ln/Bernd Alter, Co-CTO bei Turbine Kreuzberg
