© Liashko/Shutterstock.com
Entwickler Magazin
Wie Microservices die Teamstruktur beeinflussen

Microservices bei Europace

Es gibt viele technische Argumente, eine Architektur basierend auf Microservices zu gestalten. Nach unserer Erfahrung wirkt sich eine solche Architektur aber auch stark auf die Zusammenarbeit und die Kultur im Team aus. Manche dieser Effekte sind vielleicht sogar interessanter als die technischen Auswirkungen.

Jörg Müller


Bei der Europace AG entwickeln wir die größte deutsche Plattform für Immobilienfinanzierung [1]. Sie wird von über 300 Banken und Vertrieben genutzt, um für ihre Kunden die passende Finanzierung zu finden. Unser Produkt ist ein B2B-Produkt und hat dadurch bestimmte Eigenschaften; für uns sind z. B. das Bewältigen von hoher Last und ungewöhnlichen Lastspitzen selten ein Problem. Dafür führen viele individuelle Geschäftsprozesse bei unseren Kunden zu einer hohen Komplexität der Software selbst – dementsprechend haben wir unser Produkt von Anfang an stark modularisiert entwickelt. Das Deployment erfolgte jedoch gemeinsam, mit der Absicht, Integrationstests zu erleichtern. Über die Jahre hinweg merkten wir, dass diese Situation leider zu mehr Koppelung führte als ursprünglich erwünscht. Daher haben wir uns 2013 entschlossen, verstärkt auf Microservices zu setzen, die unabhängig von der Hauptanwendung deployt werden.

Aus anfänglichen Experimenten mit wenigen Services wurde mit der Zeit ein regelmäßiges Vorgehen. Wir bekamen mehr Übung im Anlegen neuer Services und schufen die dazu notwendige Infrastruktur. Mit der Zeit wurden Microservices die Lösung der Wahl. Bisher sind wir aber noch nicht den Schritt gegangen, auch die vorher bestehende Anwendung in kleine Services zu teilen. Diese Situation hat uns die Gelegenheit gegeben, über einen längeren Zeitraum beide Arbeitsweisen miteinander zu vergleichen. Dabei arbeiten dieselben Entwickler zeitweise in einer Microservices-Architektur und zeitweise in einer eher klassischen Architektur.

Drei Effekte auf unsere Kultur haben wir dabei beobachtet. Erstens gibt es eine Tendenz zu schnellerem Ausprobieren statt langem Planen. Zweitens kommt es zu einer ganz natürlichen Vermischung von Softwareentwicklung und Betrieb. Drittens hatte die Microservices-Architektur bei uns eine Ausstrahlung auf die Art und Weise, wie wir unsere Organisation gestalten.

Microservices fördern das Experimentieren

Die erste Beobachtung wird oft auch von vielen anderen Nutzern von Microservices bestätigt: Teams neigen bei Microservices viel stärker zum Experimentieren. Das zeigt sich beispielsweise durch den Einsatz unterschiedlicher Technologien. Jeder Microservice ist ein kleines „Greenfield“-Projekt; es fällt leicht, neue Technologien auszuprobieren. Dazu zählen neue Programmiersprachen genauso wie neue Frameworks oder Paradigmen. Es gibt deutlich weniger Beschränkungen durch bestehenden Code oder Infrastruktur. Dieser Effekt ist sicher auch e...

Entwickler Magazin
Wie Microservices die Teamstruktur beeinflussen

Microservices bei Europace

Es gibt viele technische Argumente, eine Architektur basierend auf Microservices zu gestalten. Nach unserer Erfahrung wirkt sich eine solche Architektur aber auch stark auf die Zusammenarbeit und die Kultur im Team aus. Manche dieser Effekte sind vielleicht sogar interessanter als die technischen Auswirkungen.

Jörg Müller


Bei der Europace AG entwickeln wir die größte deutsche Plattform für Immobilienfinanzierung [1]. Sie wird von über 300 Banken und Vertrieben genutzt, um für ihre Kunden die passende Finanzierung zu finden. Unser Produkt ist ein B2B-Produkt und hat dadurch bestimmte Eigenschaften; für uns sind z. B. das Bewältigen von hoher Last und ungewöhnlichen Lastspitzen selten ein Problem. Dafür führen viele individuelle Geschäftsprozesse bei unseren Kunden zu einer hohen Komplexität der Software selbst – dementsprechend haben wir unser Produkt von Anfang an stark modularisiert entwickelt. Das Deployment erfolgte jedoch gemeinsam, mit der Absicht, Integrationstests zu erleichtern. Über die Jahre hinweg merkten wir, dass diese Situation leider zu mehr Koppelung führte als ursprünglich erwünscht. Daher haben wir uns 2013 entschlossen, verstärkt auf Microservices zu setzen, die unabhängig von der Hauptanwendung deployt werden.

Aus anfänglichen Experimenten mit wenigen Services wurde mit der Zeit ein regelmäßiges Vorgehen. Wir bekamen mehr Übung im Anlegen neuer Services und schufen die dazu notwendige Infrastruktur. Mit der Zeit wurden Microservices die Lösung der Wahl. Bisher sind wir aber noch nicht den Schritt gegangen, auch die vorher bestehende Anwendung in kleine Services zu teilen. Diese Situation hat uns die Gelegenheit gegeben, über einen längeren Zeitraum beide Arbeitsweisen miteinander zu vergleichen. Dabei arbeiten dieselben Entwickler zeitweise in einer Microservices-Architektur und zeitweise in einer eher klassischen Architektur.

Drei Effekte auf unsere Kultur haben wir dabei beobachtet. Erstens gibt es eine Tendenz zu schnellerem Ausprobieren statt langem Planen. Zweitens kommt es zu einer ganz natürlichen Vermischung von Softwareentwicklung und Betrieb. Drittens hatte die Microservices-Architektur bei uns eine Ausstrahlung auf die Art und Weise, wie wir unsere Organisation gestalten.

Microservices fördern das Experimentieren

Die erste Beobachtung wird oft auch von vielen anderen Nutzern von Microservices bestätigt: Teams neigen bei Microservices viel stärker zum Experimentieren. Das zeigt sich beispielsweise durch den Einsatz unterschiedlicher Technologien. Jeder Microservice ist ein kleines „Greenfield“-Projekt; es fällt leicht, neue Technologien auszuprobieren. Dazu zählen neue Programmiersprachen genauso wie neue Frameworks oder Paradigmen. Es gibt deutlich weniger Beschränkungen durch bestehenden Code oder Infrastruktur. Dieser Effekt ist sicher auch e...

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