Читать книгу Vom Monolithen zu Microservices - Sam Newman - Страница 30

Stellen Sie sich einen einzelnen Prozess vor, der aus mehreren statisch verlinkten Modulen besteht. Es wird eine einzige Codezeile in einem der Module geändert, und wir wollen diese Änderung deployen. Dazu müssen wir den gesamten Monolithen deployen – auch die Module, die sich nicht geändert haben. Alles muss zusammen deployt werden, daher haben wir eine Deployment-Kopplung.

Deployment-Kopplung kann, wie in unserem Beispiel des statisch verlinkten Prozesses, erzwungenermaßen der Fall sein, aber es kann auch eine freie Entscheidung sein, die von Praktiken wie einem Release Train gesteuert wird. Bei einem Release Train werden Release-Zeitpläne vorgeplant – meist in einem sich wiederholenden Muster. Steht das Release an, werden alle Änderungen seit dem letzten Release Train deployt. Das kann für manche Menschen eine nützliche Technik sein, aber ich sehe sie weniger als das ultimative Ziel, sondern eher als einen Übergangsschritt hin zu ordentlichen Release-on-Demand-Techniken. Ich habe sogar schon in Organisationen gearbeitet, die alle Services in einem System als Teil des Release-Train-Prozesses auf einmal deployt haben, ohne darüber nachzudenken, ob diese Services überhaupt geändert werden mussten.

Ein Deployment bringt manchmal Risiken mit sich. Es gibt viele Möglichkeiten, diese Risiken zu verringern, und eine davon ist, nur das zu ändern, was geändert werden muss. Reduzieren wir die Deployment-Kopplung – vielleicht durch das Aufteilen großer Prozesse in unabhängig deploybare Microservices –, können wir das Risiko jedes Deployments verringern, indem wir dessen Scope verkleinern.

Kleinere Releases sorgen für geringere Risiken. Es kann weniger schiefgehen. Wenn etwas passiert, ist es leichter, den Verursacher herauszufinden und zu klären, wie man es behebt, weil wir weniger geändert haben. Wenn Sie Wege finden, die Größe von Releases zu reduzieren, gelangen Sie zum Kern des Continuous Delivery, was die Wichtigkeit von schnellem Feedback und Release-on-Demand-Methoden unterstreicht.⁹ Je kleiner der Scope des Release ist, desto leichter und sicherer lässt es sich ausrollen, und desto schneller erhalten wir Feedback. Mein eigenes Interesse an Microservices entstand aus meinem Fokus auf Continuous Delivery – ich suchte nach Architekturen, die das Umsetzen von Continuous Delivery erleichtern.

Für das Verringern des Deployment-Coupling sind natürlich keine Microservices erforderlich. Runtimes wie Erlang erlauben das Hot-Deployment neuer Modulversionen in einen laufenden Prozess. Nach und nach werden vielleicht immer mehr von uns Zugriff auf solche Möglichkeiten durch die Technologie-Stacks haben, die wir tagtäglich einsetzen.¹⁰