TL;DR: Vollautomatisierung hilft die Migration immer wieder zu testen

In der letzten Zeit habe ich diverse Workshops zum Thema Orchestration gegeben. Zusammen mit meinem geschätzten Kollegn Jan haben wir Gruppen von 3 bis max. 10 Leuten den umgang mit OpenStack Orchestration (Heat) nahe gebracht. Dabei haben wir uns ausschließlich auf Heat Orchestration Templates (HOT) konzentriert. Unsere Teilnehmer waren in einigen Fällen Admins oder DevOps (sie wurden als solche vorgestellt) und weitaus häufiger Software Engineers/Architects.

So viel erst einmal zur Situation. Heat verwende ich hier nur als Synonym für jedes x-beliebige Tool, mit dem eine verteilte Anwendung aufgesetzt werden kann. Ein weiteres Beispiel, dieses mal für Container, wäre Googles Kubernetes.

Was haben wir den Teilnehmern beigebracht? #

Nachdem wir die einzelnen OpenStack-Komponenten gezeigt haben, die sich mittels Heat steuern lassen, sind wir direkt zu Heat selber und HOT gegangen. Als einfaches Szenario hat immer eine Applikation mit mehreren Application-Servern, einem davor sitzenden Loadbalancer und einem Datenbank-Server gedient. Auf primitivste Weise haben wir ein Service-Discovery gebaut, so dass neue Application-Server ins LoadBalancing aufgenommen werden. Das zuletzt verwendete Beispiel findet sich im Github Repo example-projects.

Wir haben gezeigt wie mittels HOT eine Infrastruktur inklusive Netzwerk und Firewall ausgerollt werden kann. Innerhalb der VMs wird (wie auch bei AWS) cloud-init angestoßen. Mittels diesem werden die nötigen Anwendungen installiert, konfiguriert und gestartet. Mit diesen kleinen Automatisierungen ist es auch möglich beliebig viele Application-Server nachträglich einzuzufügen. Natürlich gehört in der Realität etwas mehr dazu VMs komplett zu provisionieren und eine Applikation zu deployen. Aber als Proof-of-Concept ist das immer ganz gut angekommen.

Wir wollen den Teilnehmern mehr mitgeben #

Zum einen zeigen wir, wie einfach es sein kann, eine komplett neue Infrastruktur mit allen Komponenten hoch zu ziehen. Viel wichtiger aber ist die sensibilisierung auf Cloud-Best-Practices. Siehe dazu The twelve-factor app, oder mein persönliches Fazit zu docker.

Für ein Projekt ergeben sich durch die vollständige Automatisierung gleich mehrere Vorteile. So können Entwickler und QA die Applikation quasi im Production-Environment testen. Dadurch wird die Automatisierung auch immer und immer wieder getestet. Man hat also immer Übung für den Ernstfall: Alles muss von Grund auf neu aufgebaut werden.

Das starten und provisionieren von neuen Instanzen wird durch die Automatisierung einfacher. Das bedeutet, dass kein dedizierter Personenkreis benötigt wird um die Application-Server hoch zu skalieren. Womit ich auf keinen Fall Admins als überflüssig erachte! Die können sich aber auf wichtige Dinge konzentrieren, statt Arbeit zu erledigen, die man auch einem Äffchen trainieren könnte. Nehmen wir einfach folgendes an. Der einzige Admin, der die Infrastruktur aufsetzen kann, ist vor dem Black Friday krank. Es müssen aber unbedingt noch mehr Application-Server. In unserem Szenario kein Problem. Im Endeffekt kann jeder(tm) einen Heat-Stack mit Application-Servern daneben stellen. Sicherlich gilt hier Faktoren wie die maximale Anzahl an Verbindungen auf dem DBMS zu beachten. Aber das führt hier zu weit.

Wie auch für das Beispiel des Black Fridays, kann ein neues Release der Applikation durch einen zusätzlichen Heat-Stack ausgerollt werden. Dabei werden einfach neue Instanzen mit der neuen Version gestartet und die alten einfach abgeschaltet.

Genau an dieser Stelle kommt häufig die Frage: Wie hilft uns Heat bei einer Datenmigration?

Wie hilft uns Heat bei einer Datenmigration? #

(Wobei als Datenmigration auf Nachfrage immer eine Änderung des SQL-Schemas war.)

Also… Heat bzw. jedes andere Orchestrationtool hilft in erster Linie genau gar nicht. Zu erst einmal sollte man wissen, dass ein ALTER TABLE in den meisten DBMS nicht um sonst ist (siehe z.B. Avoiding MySQL ALTER table downtime, Schema changes – what’s new in MySQL 5.6?). Gerade wenn eine Tabelle groß wird, sollte man wirklich einen geeigneten Migrations-Plan haben!

Auf jeden Fall gehört eine Migration nicht in den Code (schon gar nicht in den Startup-Code) eines neuen Releases! Keiner möchte eine Situation haben, in der ein neues Release installiert wird und gleich die laufende Production-Umgebung mit den Abgrund zieht (z.B. durch einen expliziten Lock durch ein ALTER TABLE). Die einfachste Möglichkeit Schema-Änderungen zu verhindern ist wohl IKEA Kloppe. Einfach mal damit bei dem entsprechenden Entwickler vorbeischauen.

Neben den möglichen Problemen bei einem ALTER TABLE, kann die vorherige Version der Applikation (App-1.0) mit dem neuen Schema nichts anfangen und daher in Fehler laufen. Im besten Falle hält man die Schema-Änderungen so klein, dass genau dies nicht passiert. Ein zusätzliches Feld wird einem ORM z.B. noch nicht weh tun. Ein Feld entfernen wird man dagegen erst wirklich wenn es nur noch Applikationen gibt, die ohne dieses Feld auskommen.

In jedem Fall sollte mit versionierten DB-Schemata gearbeitet werden, so dass App-2.0 auch mit dem Schema von App-1.0 arbeiten kann, dafür aber ggf. Features noch nicht freigeschaltet sind.

Bleibt die zu vermeidende Situation: Man benötigt ganz ganz ganhanz dringend ein anderes Schema und bricht dadurch App-1.0. Hier gilt es App-2.0 erst einmal überall auszurollen. Ggf. zuerst einmal mit reduziertem Feature-Set. Natürlich wird App-2.0 ohne Migration der DB an genau der selben Stelle fehlschlagen wie auch App-1.0. Doch lässt sich hier gezielt das neue Schema probieren, die Exception fangen und auf das alte Schema zurückfallen.

Vollautomatisierung hilft #

Natürlich stimmt meine Aussage von oben nicht. Orchestration und Vollautomatisierung hilft sehr wohl. Zwar gehört die Logik für dem Umgang mit Migrationen in die Applikation, also in den Kompetenzbereich der Entwickler, doch nicht die Migration selbst. Die Vollautomatisierung hilft einfach und schnell ein komplettes Setup aufzubauen und die Migration immer und immer wieder zu testen, so lange bis das Zero-Downtime-Deployment funktioniert. Ist die Änderung doch zu groß um diese ohne Downtime durchzuführen, kann wenigstens der zu erwartende Zeitraum abgeschätzt werden und entsprechende Maßnahmen treffen.