© Liashko/Shutterstock.com
Entwickler Magazin
DevOps ist mehr als nur eine Organisationsform

Microservices: Architekturen für DevOps?

DevOps bedeutet, dass Entwicklung (Development) und Betrieb (Operations) zu einer Organisation (DevOps) zusammenwachsen. Das hat tief greifende Auswirkungen auf die Architektur der Software, denn nur mit einer optimal strukturierten Software kann aus DevOps der maximale Nutzen gezogen werden.

Eberhard Wolff


Gerade in letzter Zeit wird das Gesetz von Conway [1] immer wieder zitiert, das besagt, dass eine Organisation nur solche Architekturen umsetzen kann, die ihren Kommunikationsbeziehungen entspricht. Darum müssen die Organisationseinheiten in der Architektur Schnittstellen definieren, über deren Spezifikation sie miteinander sprechen müssen. Also entspricht ein Kommunikationskanal auf der Organisationsebene einer Schnittstelle in der Architektur. Daher ist eine bestimmte Organisation ohne eine dazu passende Architektur nicht umsetzbar. Das gilt genauso im umgekehrten Fall: Wenn eine bestimmte Architektur umgesetzt werden soll, muss die Organisation dazu passen.

DevOps bedeutet eine tiefgreifende Änderung in der Organisation. Statt einer getrennten Entwicklungs- und Betriebsmannschaft gibt es gemischte Teams, die beide Aufgabenbereiche abdecken. Eine solche Änderung ist nach dem Gesetz von Conway ohne passende Architektur der Software aber kaum sinnvoll umsetzbar.

Eine klassische Organisation für die Entwicklung von Software zeigt Abbildung 1. Die Entwicklung schreibt die Software. Dabei gibt es Experten für die Entwicklung der Oberfläche, der Logik und der Datenbank, die jeweils in eigenen Teams organisiert sind. Dementsprechend hat die Architektur drei Schichten und beachtet betriebliche Aspekte nicht sonderlich stark, da der Betrieb in einem eigenen Team organisiert ist.

Abb.1: Klassische Organisation ohne DevOps

Im Rahmen einer DevOps-Organisation muss diese Aufteilung ersetzt werden. Einfach alle Mitarbeiter in einem einzigen Team zusammenzufassen, ist jedoch nicht ausreichend, weil das Team dann zu groß wird. Jenseits einer bestimmten Grenze ist die Kommunikation innerhalb eines Teams so aufwändig, dass das Team weiter aufgeteilt werden muss. Das kann aber nicht mehr nach technischen Aspekten geschehen, denn dann entstehen wieder technische Silos, die DevOps gerade vermeiden und abbauen soll.

Eine Alternative zeigt Abbildung 2. Die Teams werden nach fachlichen Bereichen getrennt, die ursprünglich aus der E-Commerce-Domäne stammen. Jedes dieser Teams ist für die Entwicklung und für den Betrieb einer bestimmten Komponente zuständig. Das hat den Vorteil, dass für den Fachbereich klar ist, welches Team für eine bestimmte Funktionalität verantwortlich ist – und zwar nicht nur für die Entwicklung, sondern auch für den Betrieb. Unabhängig davon, ob ein neues Feature entwickelt werden soll oder es gerade ein Problem in der Produktion gibt, das gelöst werden muss...

Entwickler Magazin
DevOps ist mehr als nur eine Organisationsform

Microservices: Architekturen für DevOps?

DevOps bedeutet, dass Entwicklung (Development) und Betrieb (Operations) zu einer Organisation (DevOps) zusammenwachsen. Das hat tief greifende Auswirkungen auf die Architektur der Software, denn nur mit einer optimal strukturierten Software kann aus DevOps der maximale Nutzen gezogen werden.

Eberhard Wolff


Gerade in letzter Zeit wird das Gesetz von Conway [1] immer wieder zitiert, das besagt, dass eine Organisation nur solche Architekturen umsetzen kann, die ihren Kommunikationsbeziehungen entspricht. Darum müssen die Organisationseinheiten in der Architektur Schnittstellen definieren, über deren Spezifikation sie miteinander sprechen müssen. Also entspricht ein Kommunikationskanal auf der Organisationsebene einer Schnittstelle in der Architektur. Daher ist eine bestimmte Organisation ohne eine dazu passende Architektur nicht umsetzbar. Das gilt genauso im umgekehrten Fall: Wenn eine bestimmte Architektur umgesetzt werden soll, muss die Organisation dazu passen.

DevOps bedeutet eine tiefgreifende Änderung in der Organisation. Statt einer getrennten Entwicklungs- und Betriebsmannschaft gibt es gemischte Teams, die beide Aufgabenbereiche abdecken. Eine solche Änderung ist nach dem Gesetz von Conway ohne passende Architektur der Software aber kaum sinnvoll umsetzbar.

Eine klassische Organisation für die Entwicklung von Software zeigt Abbildung 1. Die Entwicklung schreibt die Software. Dabei gibt es Experten für die Entwicklung der Oberfläche, der Logik und der Datenbank, die jeweils in eigenen Teams organisiert sind. Dementsprechend hat die Architektur drei Schichten und beachtet betriebliche Aspekte nicht sonderlich stark, da der Betrieb in einem eigenen Team organisiert ist.

Abb.1: Klassische Organisation ohne DevOps

Im Rahmen einer DevOps-Organisation muss diese Aufteilung ersetzt werden. Einfach alle Mitarbeiter in einem einzigen Team zusammenzufassen, ist jedoch nicht ausreichend, weil das Team dann zu groß wird. Jenseits einer bestimmten Grenze ist die Kommunikation innerhalb eines Teams so aufwändig, dass das Team weiter aufgeteilt werden muss. Das kann aber nicht mehr nach technischen Aspekten geschehen, denn dann entstehen wieder technische Silos, die DevOps gerade vermeiden und abbauen soll.

Eine Alternative zeigt Abbildung 2. Die Teams werden nach fachlichen Bereichen getrennt, die ursprünglich aus der E-Commerce-Domäne stammen. Jedes dieser Teams ist für die Entwicklung und für den Betrieb einer bestimmten Komponente zuständig. Das hat den Vorteil, dass für den Fachbereich klar ist, welches Team für eine bestimmte Funktionalität verantwortlich ist – und zwar nicht nur für die Entwicklung, sondern auch für den Betrieb. Unabhängig davon, ob ein neues Feature entwickelt werden soll oder es gerade ein Problem in der Produktion gibt, das gelöst werden muss...

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