Datacenter
Der kalkulierte Kontrollverlust
Fortsetzung des Artikels von Teil 2
Auswirkungen auf die Organisationsstruktur
Durch diesen Architekturansatz können weitestgehend autonome Teams erreicht werden. Das gilt natürlich nur, wenn im Team alle notwendigen Rollen vertreten sind, bei Scrum sind das beispielsweise der Scrum Master, der Product Owner und die Entwickler. Oberste Priorität ist, dass das Team sein Ziel erreichen kann, ohne dabei von anderen abhängig zu sein. Das bezieht sich nicht nur auf Entwicklung und Test der Software, sondern auch auf das Ausrollen in Produktion. An dieser Stelle kommt “DevOps” ins Spiel. Im Gegensatz zum landläufig verbreiteten Vorurteil ist DevOps keine Rolle, sondern eher das Mindset und die organisatorische Ausrichtung, die notwendig sind, um Entwicklung und Betrieb tief miteinander zu verzahnen. Der Fokus liegt auf Reproduzierbarkeit von Resultaten und Automatisierung.
Viele klassische IT-Administratoren befürchten, dass sie überflüssig werden, wenn die Entwickler ihre Software selbst in Produktion bringen können. In den allermeisten Fällen stellt sich diese Befürchtung als unwahr heraus: Die Administratoren werden nicht arbeitslos, sondern ihre Tätigkeit ändert sich. Der IT-Betrieb kann sich stärker auf Dinge wie Automatisierung mit den dazugehörigen Tests oder innovative Infrastruktur fokussieren. In Teams, die nach DevOps-Prinzipien arbeiten, lernen beide Seiten voneinander. DevOps und Microservices ergänzen sich ideal, Teams übernehmen die Verantwortung vom Design einer Softwarekomponente bis zum Betrieb. Oft ist dabei zu beobachten, dass die Softwarequalität über die Zeit signifikant besser wird. Der Grund: Die Teams haben in der Regel ein starkes Interesse daran, dass ihre Software möglichst fehlerfrei läuft.
Partieller Kontrollverlust
DevOps und Microservices bedeuten viele Änderungen für Organisationen, weshalb viele Unternehmen die Schritte noch scheuen. Es ist die Angst vor dem Kontrollverlust: Entwickler können jederzeit neue Versionen ihrer Software in das Produktivsystem deployen, es gibt keine festen Termine mehr für neue Version der Software, sondern es werden kontinuierlich Änderungen an den produktiven Systemen vorgenommen. Dieses Prinzip nennt sich “Continuous Delivery”, die früheren “Big-Bang-Releases” gehören der Vergangenheit an.
Damit jedoch das Risiko dieses Ansatzes minimiert wird, können feste, automatisiert überprüfbare Kriterien definiert werden. Beispielsweise ist die Testabdeckung der Software eine gern genutzte Metrik: Falls die Testabdeckung unter einem gewissen Schwellwert sinkt, kann die Software nicht mehr im Produktivsystem ausgerollt werden. Darüber hinaus können noch Deployment-Fenster definiert werden – keine Deployments am Montagmorgen oder Freitagnachmittag. Bei sinkender Codequalität sind keine Deployments mehr möglich. Jedes Team hat Rufbereitschaft, falls es nachts zu Problemen kommt, et cetera. Es sind viele automatisiert überprüfbare Kriterien denkbar, die über die Zeit dafür sorgen, dass die Qualität der Software und die Stabilität des Gesamtsystems steigen.
Der Autor Sascha Möllering ist Solutions Architect bei Amazon Web Services.
- Der kalkulierte Kontrollverlust
- Vorteile von Microservices
- Auswirkungen auf die Organisationsstruktur
- Kommentar AWS: Mut zur Veränderung
Lesen Sie mehr zum Thema
