OTTO goes AWS - Teil 2

Wie viel zentral braucht man noch?

Ein hehres Ziel des internen Migrationsteams war es möglichst viele der bisher zentral bei OTTO verwalteten Services zu dezentralisieren. Um dies zu erreichen und die Team-Autonomie so weiter zu stärken haben wir die Accountstruktur von Anfang an so gewählt, dass jedes Teams mindestens zwei AWS Accounts vollständig selbst verwaltet (einen für Live sowie einen für Nonlive) und darin Services deployen kann. Im Laufe des Projekts hat sich jedoch herausgestellt, dass eine vollständige Dezentralisierung nicht immer und überall sinnvoll ist. Was Datenbanken, VMs und Deployment Tools angeht war es einfach zu argumentieren, dass dies nun Sache der Entwicklungsteams ist. Zu unterschiedlich sind die Anforderungen und Vorlieben der Teams und es war zuletzt schon schwierig für die zentralen P-Teams den Wünschen der Entwickler gerecht zu werden. 

Bei anderen Services wie Verwaltung der DNS Root Zonen, Pflege und Weiterentwicklung von übergreifenden Prozessen (Accountanlage, Useranlage), Authentifizierungsserver, etc. ist es nach wie vor sinnvoll ein übergreifendes Team zu haben, was sich um solche Dinge kümmert. Diese Aufwände würden bei einer Dezentralisierung in jedem Team anfallen (es gibt keine abweichenden Anforderungen) und  kein Entwicklungsteam kann solche Aufgaben nebenher machen, bzw. damit verbundene Aufwände würden immer mit fachlichen Features in der Priorisierung konkurrieren. Somit ist bei uns im Rahmen des Projekts ein dediziertes Team 'Service Integration' entstanden. Ebenso gibt es ein Team das sich um übergreifende Sicherheitsaspekte kümmert, die anderen Teams bei diesen Themen berät und durch Checks in den Accounts (z.B. die CIS Benchmarks) sicherstellt, dass Grundregeln wie Verschlüsselung, Nicht-Erreichbarkeit interner Services von Außen, etc. sichergestellt sind.

 Auch wenn die Teams für den Betrieb und das damit verbundene Incident Management nun selbst verantwortlich sind, gibt es nach wie vor ein kleines zentrales Bereitschaftsteam bei dem die Alarmierung und Kommunikationsstränge im Falle eines technischen Problems zusammenlaufen. Für die Alarmierung selbst - das heißt die Einlieferung der Alarme oder Warnungen an ein zentrales Monitoring sind wiederum die Teams selbst verantwortlich. Ebenso für die Entstörung, da das Know-How über die Applikation und Infrastruktur in den Entwicklungsteams vorhanden ist.

Wie eng bindet mich das an den Cloud-Dienstleister?

Was die Nutzung der von AWS angebotenen Services betrifft, haben wir bei uns im Bereich eine bewusste Entscheidung getroffen. Anstatt unsere Anwendungen so zu bauen, dass man diese auch ohne große zusätzliche Migrationsaufwände in andere Clouds oder gar ein lokales Rechenzentrum verschieben könnte, haben wir uns dafür entschieden, die Vorteile der Cloud soweit es geht für uns zu nutzen und dort wo es sinnvoll erscheint auf verwaltete Services von AWS zurückzugreifen. 

Dem Schutz sensitiver Kundendaten oder strategischer Businessdaten sind wir mit konsequenter Verschlüsselung aller Daten sowohl im gespeicherten Zustand (‘at rest’) als auch beim Transfer ('in transit') selbst innerhalb der privaten Netzsegmente begegnetUm das Maximum aus der Cloud herauszuholen was Betrieb, Flexibilität und auch Kosten angeht sind wir daher die Bindung an den Dienstleister bewusst eingegangen. Eine eventuelle spätere Migration (ganz oder in Teilen) zu anderen Cloud Anbietern ist natürlich trotzdem weiterhin möglich, da diese ähnliche Konzepte und Services bieten und wir bereits mit dem Lhotse Projekt große Vorarbeit geleistet haben, indem wir unseren Monolithen in hunderte kleine schnell zu deployende Microservices zerlegt haben. Würde man jedoch seine Services im Vorhinein so bauen, dass man diese mit minimalem Migrationsaufwand überall betreiben könnte, müsste man auf selbst zu managende Abstraktionsebenen setzen (und damit die AWS nachbauen). Somit würden die (vor allem zentralen) Betriebsaufwände auf dem gleichen Level wie bisher sein. Ebenso schwindet die Flexibilität schnell mal was auszuprobieren - da die Services dafür zuerst von einem zentralen Team - was dadurch schnell zum Bottleneck werden kann - bereitgestellt werden müssten. 

Trotzdem haben wir unsere Anwendungen und besonders die Kommunikationswege zwischen unseren Anwendungen so aufgesetzt, dass wir auch andere Cloud-Services oder klassisch gehostete Services nahtlos integrieren können. Mehr dazu gibt es in einem der kommenden Blog-Artikel zum Thema ‘Inter-Backend Kommunikation’. Somit lassen sich trotz Ausnutzung der Vorteile der AWS weiterhin die Stärken verschiedener anderer Cloudanbieter nutzen.

Kulturelle Veränderungen

Abschließend bleibt festzuhalten, dass die größten Herausforderungen nicht technischer sondern eher kultureller und organisatorischer Natur waren. Dadurch dass die F-Teams nun nicht mehr abhängig von zentralen P-Teams sind, haben sie auch alle Freiheiten Services, die sie nutzen wollen, selbst auszuwählen. Auf der anderen Seite haben die F-Teams nun auch die Pflicht diese Services selbst zu betreiben. Auch wenn die Entwicklungsteams bei OTTO sehr ähnlich zusammengesetzt sind und technologisch und methodisch nach gleichen Prinzipien arbeiten war die Reaktion auf diese neuen Aufgaben sehr unterschiedlich. 

Eine der wesentlichen Aufgaben des zentralen Migrationsteams bei OTTO war daher die Teams auf diese neuen Aufgaben vorzubereiten und neben den Nachteilen, die oft als Erstes von den Mitarbeitern gesehen wurden auch die Vorteile aufzuzeigen. Durch die AWS Migration sind nun die Entwickler viel näher mit den Betriebskollegen zusammen gewachsen und haben diese in vielen Fällen in ihre F-Teams integriert. Dabei könnenbeide Seiten voneinander lernen und ihr Spektrum erweitern. Zu diesem spannenden Thema gibt es demnächst im dritten Teil dieser Serie mehr.

Fazit

Wenige Monate nach Abschluss der Migration kann man sagen, dass unser Experiment des dezentralen Betriebs zum großen Teil geglückt ist. Zwar haben wir es nicht geschafft den Betrieb vollständig zu dezentralisisieren, aber bis auf wenige zentrale Dienste managen die F-Teams nun selbstständig ihre Anwendungen von der Entwicklung bis zum Betrieb mit allem was dazu gehört. Was die Nutzung der angebotenen Cloud-Services angeht, gibt es wie erwartet ebenfalls Unterschiede. Die meisten Teams nutzen die angebotenen Managed Services der AWS und sparen dadurch Betriebsaufwände, wenige Teams mit Spezialanforderungen managen einen kleinen Teil ihrer Services selbst und nehmen dadurch höhere Betriebsaufwände in Kauf.