© Liashko/Shutterstock.com
Entwickler Magazin
Cloud Application Development

Microservice-Entwicklung erfordert Kompromisse

Im Enterprise-Umfeld können Microservices nicht mit allen Eigenschaften entwickelt werden, die die Evangelisten herausstellen. Stattdessen gilt es, eine Balance zwischen dem theoretisch Möglichen und dem praktisch Sinnvollen zu erzielen. Es reichen aber bereits wenige Kompromisse aus, um entscheidende Vorteile der Microservice-Philosophie ins Enterprise-Umfeld zu übertragen.

Michael Schäfer, Rafael Kansy, Mark Lubkowitz


Zerlegen Architekten und Entwickler die Fachlichkeiten eines Monolithen anhand des Microservice-Musters, sind sie mit hoher Komplexität konfrontiert. Können sie diese Komplexität allerdings bändigen, erhalten sie unter anderem beliebig skalierbare, hoch verfügbare und schnell veränderbare Teillösungen. Aus dem starren Monolithen wird so im Idealfall eine flexible Gesamtlösung, die sich in deutlich kürzeren Zyklen mit neuen Features und Fehlerkorrekturen bedienen lässt.

Was dabei nicht funktioniert: die Microservice-Ideologie sklavisch befolgen und in ihrer Gänze in den Unternehmenskontext pressen. Denn es treffen zwei unterschiedliche Philosophien aufeinander. Einerseits der Zentralismus der Unternehmen, der Standardisierung, Wirtschaftlichkeit und Effizienz zum Ziel hat. Andererseits der Individualismus von Microservices, der schnelle Lösungen verspricht, dies aber mit einer gewissen Laissez-faire-Haltung und hoher Eigenverantwortung erkauft.

Architekten und Entwickler müssen nun stets zwischen Zentralismus und Individualismus entscheiden und die Frage klären: „Wie stark muss die eine der beiden Philosophien nachgeben, damit die Vorteile die Nachteile überwiegen?“ Dieses Für und Wider ist von Unternehmen zu Unternehmen, Kunde zu Kunde und Projekt zu Projekt verschieden. Außerdem spielen innere und äußere Einflüsse wie Mitarbeiterwissen, Kundenvorgaben, Infrastruktur und Budget in die Frage hinein.

Für jeden Microservice ein Team

Für jeden Microservice, den das Unternehmen entwickeln muss, übernimmt jeweils ein Team die alleinige Verantwortung. Ein Team kann ebenso für mehrere Microservices verantwortlich sein. Auch für die eventuelle Entwicklung eines Shared UI, Shared Database und weiterer mehrfach verwendeter Bestandteile werden zuständige Teams berufen. Die Zusammensetzung der Teams ist nicht fix. Die Mitarbeiter dürfen mehreren Teams angehören und nach Bedarf disponiert werden.

Die Teams arbeiten grundsätzlich autonom und unabhängig voneinander. Sie verantworten im Sinne von DevOps ihren Microservice- oder Produktteil während seines gesamten Lebenszyklus und treffen eigenständig die Entscheidungen, die für Entwicklung, Bereitstellung und Betrieb notwendig sind.

Zentralisieren, was sich zentralisieren lässt

Damit aus den einzelnen Microservices ein funktionales Gesamtprodukt entsteht, müssen die Teams klassisch die Planungsphase initiieren und zuerst das Fach- und IT-Konzept der Microservices ausarbeiten. Die Dokumentation führt zu einer einheitlichen Pro...

Entwickler Magazin
Cloud Application Development

Microservice-Entwicklung erfordert Kompromisse

Im Enterprise-Umfeld können Microservices nicht mit allen Eigenschaften entwickelt werden, die die Evangelisten herausstellen. Stattdessen gilt es, eine Balance zwischen dem theoretisch Möglichen und dem praktisch Sinnvollen zu erzielen. Es reichen aber bereits wenige Kompromisse aus, um entscheidende Vorteile der Microservice-Philosophie ins Enterprise-Umfeld zu übertragen.

Michael Schäfer, Rafael Kansy, Mark Lubkowitz


Zerlegen Architekten und Entwickler die Fachlichkeiten eines Monolithen anhand des Microservice-Musters, sind sie mit hoher Komplexität konfrontiert. Können sie diese Komplexität allerdings bändigen, erhalten sie unter anderem beliebig skalierbare, hoch verfügbare und schnell veränderbare Teillösungen. Aus dem starren Monolithen wird so im Idealfall eine flexible Gesamtlösung, die sich in deutlich kürzeren Zyklen mit neuen Features und Fehlerkorrekturen bedienen lässt.

Was dabei nicht funktioniert: die Microservice-Ideologie sklavisch befolgen und in ihrer Gänze in den Unternehmenskontext pressen. Denn es treffen zwei unterschiedliche Philosophien aufeinander. Einerseits der Zentralismus der Unternehmen, der Standardisierung, Wirtschaftlichkeit und Effizienz zum Ziel hat. Andererseits der Individualismus von Microservices, der schnelle Lösungen verspricht, dies aber mit einer gewissen Laissez-faire-Haltung und hoher Eigenverantwortung erkauft.

Architekten und Entwickler müssen nun stets zwischen Zentralismus und Individualismus entscheiden und die Frage klären: „Wie stark muss die eine der beiden Philosophien nachgeben, damit die Vorteile die Nachteile überwiegen?“ Dieses Für und Wider ist von Unternehmen zu Unternehmen, Kunde zu Kunde und Projekt zu Projekt verschieden. Außerdem spielen innere und äußere Einflüsse wie Mitarbeiterwissen, Kundenvorgaben, Infrastruktur und Budget in die Frage hinein.

Für jeden Microservice ein Team

Für jeden Microservice, den das Unternehmen entwickeln muss, übernimmt jeweils ein Team die alleinige Verantwortung. Ein Team kann ebenso für mehrere Microservices verantwortlich sein. Auch für die eventuelle Entwicklung eines Shared UI, Shared Database und weiterer mehrfach verwendeter Bestandteile werden zuständige Teams berufen. Die Zusammensetzung der Teams ist nicht fix. Die Mitarbeiter dürfen mehreren Teams angehören und nach Bedarf disponiert werden.

Die Teams arbeiten grundsätzlich autonom und unabhängig voneinander. Sie verantworten im Sinne von DevOps ihren Microservice- oder Produktteil während seines gesamten Lebenszyklus und treffen eigenständig die Entscheidungen, die für Entwicklung, Bereitstellung und Betrieb notwendig sind.

Zentralisieren, was sich zentralisieren lässt

Damit aus den einzelnen Microservices ein funktionales Gesamtprodukt entsteht, müssen die Teams klassisch die Planungsphase initiieren und zuerst das Fach- und IT-Konzept der Microservices ausarbeiten. Die Dokumentation führt zu einer einheitlichen Pro...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang