von Redaktion IT-A…
Lesezeit
2 Minuten
Microservices aus Admin-Sicht
Das Thema Microservices ist aus der aktuellen Debatte rund um die Modernisierung der Unternehmens-IT kaum noch wegzudenken. Während sich Führungskreise und Verantwortliche auf Produktebene mehr Agilität und Flexibilität erhoffen, fürchtet die IT-Abteilung eine Zunahme der Komplexität bei der Verwaltung und beim Betrieb. Unser Beitrag beschreibt durch die Admin-Brille, ob an diesen Sorgen etwas dran ist und was die Voraussetzungen sind, um effizient mit Microservices arbeiten zu können.
Microservices gelten als das Wundermittel schlechthin, wenn es darum geht, die Unternehmens-IT zu modernisieren. "Monolithische Systeme" erscheinen in der Regel als die schlechte oder klobige Option, während Microservices strukturell gesehen als Erfolg angesehen werden, da sie leichter zu erweitern sind und sich kleine Funktionalitäten auf jede beliebige Weise implementieren lassen.
Unternehmen unterschätzen jedoch oftmals die Komplexität der Orchestrierung von Microservices. Hier sind Administration und Teams gleichermaßen gefragt, denn nur wenn beide Bereiche bereit sind, neue Aufgaben zu übernehmen und alte Strukturen zu überwinden, ist ein Microservices-Ansatz erfolgreich umsetzbar. Diese Umstellung kann zu einer echten Herausforderung für Unternehmen und Angestellte werden.
Das unterscheidet Monolithen von Microservices
Um zu verstehen, welche unterschiedlichen Anforderungen die Architekturansätze an die eigene Infrastruktur stellen und für welche Anwendungen sie überhaupt geeignet sind, ist es wichtig, den unterschiedlichen Aufbau zu betrachten. Grundsätzlich gilt: Egal welchen Ansatz ein Unternehmen wählt, eine Umstellung ist generell zu jedem Zeitpunkt möglich, bedeutet allerdings einen erhöhten Ressourcen- und Zeitaufwand. Die Wahl zwischen monolithischer Struktur und Microservices ist also eine, die IT-Entscheider mit Weitblick auf die Anwendung treffen sollten.
Bei einer monolithisch aufgebauten Applikation wird die Anwendung mit all ihren Funktionen innerhalb der Architektur zentral verortet und verwaltet. Grundlage ist in der Regel eine einzelne, umfassende Codebasis, die alle Elemente und Schnittstellen beschreibt. Diese geschlossenen Entwicklungseinheiten, etwa WAR-Dateien, enthalten dabei den gesamten Source Code der Applikation.
Bei Microservice-Architekturen erfolgt eine Unterteilung der einzelnen Komponenten in kleine Einheiten, die jeweils einen bestimmten Prozess der Anwendung als Service bereitstellen. Die Funktionalität lässt sich dadurch in verteilte Module separieren, die über APIs miteinander kommunizieren und sich weitestgehend unabhängig voneinander deployen lassen.
Unterschiedliche Anforderungen an Teamgrößen, Expertise und Technik
Vor der Frage der Vor- und Nachteile der einzelnen Applikationsansätze steht die Frage der generellen Umsetzbarkeit im Unternehmen. Hierbei gilt es besonders, das vorhandene Personal in die Entwicklungen mit einzubeziehen.
Da monolithische Architekturen bisher immer noch der Standard sind, bringen die meisten Entwickler wesentlich mehr Erfahrung in der Programmierung und Wartung dieser mit. Arbeitsabläufe sind hier meist eingespielt und durch die gemeinsame Arbeit am Code auch von kleinen Teams abbildbar. Allerdings setzt die enge Zusammenarbeit an einer Mainline eine hohe Fachkompetenz der einzelnen Teammitglieder in unterschiedlichsten Bereichen voraus sowie den Willen, mehr administrative Aufgaben zu übernehmen.
Die Arbeit mit Microservices bietet die Möglichkeit, Spezialisten gezielt einzusetzen und unabhängig voneinander an einzelnen Funktionen arbeiten zu lassen. Zwar muss auch hier ein gewisser Grad an Koordination zwischen den einzelnen Entwicklern bestehen, allerdings können diese wesentlich autonomer agieren. Der IT-Administrator gibt hier einen Großteil der eigenen Verantwortung ins Team ab und übernimmt vermehrt die Aufgabe einer Supervision, die mehr im Bereich der Führung und Krisen-Handling tätig ist.
Unterschiedliche Voraussetzungen finden sich oftmals auch beim Thema Datenhaltung. In monolithischen Strukturen sind Daten häufig eher zentralisiert an einer Stelle gespeichert. Zwar kann das bei Microservices ebenso der Fall sein, beispielsweise in Form eines neutralen Datenlayers, muss es aber nicht. Jeder Microservice kann potenziell seine eigenen Daten selbst separat speichern und verwalten. Dabei ist allerdings darauf zu achten, dass diese sich nicht unabhängig vom restlichen Konstrukt betrachten lässt. Auch hier sollten IT-Verantwortliche darauf achten, dass eine Kommunikation zwischen allen Anwendungen erfolgen kann, die auf Daten anderer Applikationen angewiesen sind.
Seite 1: Das unterscheidet Monolithen von Microservices
ln/Bernd Alter, Co-CTO bei Turbine Kreuzberg
Unternehmen unterschätzen jedoch oftmals die Komplexität der Orchestrierung von Microservices. Hier sind Administration und Teams gleichermaßen gefragt, denn nur wenn beide Bereiche bereit sind, neue Aufgaben zu übernehmen und alte Strukturen zu überwinden, ist ein Microservices-Ansatz erfolgreich umsetzbar. Diese Umstellung kann zu einer echten Herausforderung für Unternehmen und Angestellte werden.
Das unterscheidet Monolithen von Microservices
Um zu verstehen, welche unterschiedlichen Anforderungen die Architekturansätze an die eigene Infrastruktur stellen und für welche Anwendungen sie überhaupt geeignet sind, ist es wichtig, den unterschiedlichen Aufbau zu betrachten. Grundsätzlich gilt: Egal welchen Ansatz ein Unternehmen wählt, eine Umstellung ist generell zu jedem Zeitpunkt möglich, bedeutet allerdings einen erhöhten Ressourcen- und Zeitaufwand. Die Wahl zwischen monolithischer Struktur und Microservices ist also eine, die IT-Entscheider mit Weitblick auf die Anwendung treffen sollten.
Bei einer monolithisch aufgebauten Applikation wird die Anwendung mit all ihren Funktionen innerhalb der Architektur zentral verortet und verwaltet. Grundlage ist in der Regel eine einzelne, umfassende Codebasis, die alle Elemente und Schnittstellen beschreibt. Diese geschlossenen Entwicklungseinheiten, etwa WAR-Dateien, enthalten dabei den gesamten Source Code der Applikation.
Bei Microservice-Architekturen erfolgt eine Unterteilung der einzelnen Komponenten in kleine Einheiten, die jeweils einen bestimmten Prozess der Anwendung als Service bereitstellen. Die Funktionalität lässt sich dadurch in verteilte Module separieren, die über APIs miteinander kommunizieren und sich weitestgehend unabhängig voneinander deployen lassen.
Unterschiedliche Anforderungen an Teamgrößen, Expertise und Technik
Vor der Frage der Vor- und Nachteile der einzelnen Applikationsansätze steht die Frage der generellen Umsetzbarkeit im Unternehmen. Hierbei gilt es besonders, das vorhandene Personal in die Entwicklungen mit einzubeziehen.
Da monolithische Architekturen bisher immer noch der Standard sind, bringen die meisten Entwickler wesentlich mehr Erfahrung in der Programmierung und Wartung dieser mit. Arbeitsabläufe sind hier meist eingespielt und durch die gemeinsame Arbeit am Code auch von kleinen Teams abbildbar. Allerdings setzt die enge Zusammenarbeit an einer Mainline eine hohe Fachkompetenz der einzelnen Teammitglieder in unterschiedlichsten Bereichen voraus sowie den Willen, mehr administrative Aufgaben zu übernehmen.
Die Arbeit mit Microservices bietet die Möglichkeit, Spezialisten gezielt einzusetzen und unabhängig voneinander an einzelnen Funktionen arbeiten zu lassen. Zwar muss auch hier ein gewisser Grad an Koordination zwischen den einzelnen Entwicklern bestehen, allerdings können diese wesentlich autonomer agieren. Der IT-Administrator gibt hier einen Großteil der eigenen Verantwortung ins Team ab und übernimmt vermehrt die Aufgabe einer Supervision, die mehr im Bereich der Führung und Krisen-Handling tätig ist.
Unterschiedliche Voraussetzungen finden sich oftmals auch beim Thema Datenhaltung. In monolithischen Strukturen sind Daten häufig eher zentralisiert an einer Stelle gespeichert. Zwar kann das bei Microservices ebenso der Fall sein, beispielsweise in Form eines neutralen Datenlayers, muss es aber nicht. Jeder Microservice kann potenziell seine eigenen Daten selbst separat speichern und verwalten. Dabei ist allerdings darauf zu achten, dass diese sich nicht unabhängig vom restlichen Konstrukt betrachten lässt. Auch hier sollten IT-Verantwortliche darauf achten, dass eine Kommunikation zwischen allen Anwendungen erfolgen kann, die auf Daten anderer Applikationen angewiesen sind.
| Seite 1 von 2 | Nächste Seite >> |
ln/Bernd Alter, Co-CTO bei Turbine Kreuzberg
