Sam Newman über Microservices: "Die Umstellung ist kein Schalter"

Inhaltsverzeichnis

Sam Newman gilt als einer der führenden Köpfe im Bereich Microservices. Er ist als unabhängiger Berater tätig und hat zuvor unter anderem bei ThoughtWorks und einigen Start-ups gearbeitet. Heute ist er als selbstständiger Berater und Autor tätig. Sein Buch "Building Microservices" gilt als Standardwerk zu dem Thema, mit dem er sich seit gut fünf Jahren auseinandersetzt.

heise Developer sprach mit Sam Newman im Rahmen eines Trainings, das er Anfang Februar für die Lebensversicherung LV 1871 und deren Partner ARS, HUK und Datev veranstaltet hat.

heise Developer: Sam Newman, du bist einer der führenden Köpfe im Bereich Microservices. Wie bist du ursprünglich zu dem Thema gekommen?

Sam Newman: Ich war zur richtigen Zeit am richtigen Ort. Nachdem ich eine Weile als Entwickler gearbeitet hatte, kam ich 2004 zu ThoughtWorks. Zufälligerweise lag mein Fokus damals auf dem Bereich, den wir heute Continuous Delivery nennen. Damit waren Themen wie Pipeline- und Testautomatisierung verbunden. Auch die Cloud und das passende Deployment waren wichtige Themen.

Dabei habe ich bemerkt, dass häufig die Architektur einer Anwendung nicht zu den Anforderungen passte. Sie behinderte die Leute dabei, die Software so zu verwalten, wie sie es wollten. Zu der Zeit beschäftigte sich mein damaliger Kollege James Lewis mit einer neuen Form der Architektur, die er Micro Apps nannte.

Das führte zu der Überlegung, wie wir die Architektur so ändern können, dass sich Software schneller und zuverlässiger ausliefern lässt.

heise Developer: Was hat dich zu deinem ersten Buch über Microservices motiviert?

Newman: Ich wollte schon immer ein Buch schreiben – am liebsten für O'Reilly, denn das erste Programmierbuch, das ich mir selbst gekauft hatte, war von O'Reilly. Der Verlag kam mit einem anderen Thema auf mich zu [1]. Schließlich habe ich dann auch das Buch geschrieben, das seinerzeit das erste zum Thema Microservices war [2].

Mit dem Zeitpunkt hatte ich Glück, und die Leser mochten das Buch offenbar. Viele teilten ihre Erfahrungen mit mir. Zahlreiche Leser haben mir ihre Ideen geschickt. Es entstand ein fruchtbarer Kreislauf, und das Thema beschäftigt mich immer noch.

heise Developer: Haben die vielen Rückmeldungen Sie zum Schreiben des zweiten Buchs motiviert, das vier Jahre später erschienen ist?

Newman: Das erste Buch von 2014 behandelte vor allem die grundlegenden Konzepte und weniger spezifische Techniken. Der Vorteil daran ist: Die Konzepte sind im Gegensatz zu den Techniken nicht so schnell überholt.

Aber in einigen Bereichen ging es um explizite Techniken. Daher hatte ich das zweite Buch zunächst als eine aktualisierte Ausgabe des ersten geplant. Für die Arbeiten an Kapitel 5, das sich damit beschäftigt, wie man Systeme auseinanderbricht, habe ich einen Monat gebraucht. Aus den ursprünglich 5000 Wörtern wurden nach der Überarbeitung 30.000. Also habe ich ein Kapitel darüber, wie man etwas kleiner bekommt, viel größer gemacht – und zwar so groß, dass es ein eigenes Buch abgeben musste.

Statt einer zweiten Edition entstand somit ein frisches Buch [3]. "Building Microservices" war eine umfassende Abhandlung darüber, wie Microservices die Prozesse des Software Delivery ändern. Welchen Einfluss es auf Testing, Security und weitere Themen hat.

Dagegen taucht der Nachfolger "Monolith to Microservices" tief in den Umbau einer monolithischen zu einer Microservice-Architektur ein.

heise Developer: Möchtest du die zweite Edition trotzdem noch schreiben?

Newman: Die Techniken ändern sich nach wie vor in einem ungeheuren Tempo, und in der Tat arbeite ich gerade an einer aktualisierten Ausgabe von "Building Microservices". Derzeit sitze ich an dem Kapitel, das am meisten von technischen Änderungen betroffen ist: das Deployment.

Kubernetes muss ich natürlich ebenfalls in der Neufassung behandeln, weil es viele brennend interessiert und ich finde, dass es eine faszinierende Technik ist. Außerdem glaube ich, dass es die Probleme nicht so einfach löst, wie manche denken – auch darüber möchte ich schreiben.

Ein weiteres wichtiges jüngeres Thema sind Serverless-Architekturen beziehungsweise Function as a Service (FaaS). Andere Dinge kann ich dafür herausnehmen. Seinerzeit mussten sich Entwickler typischerweise mit Puppet-, Chef- oder Ansible-Skripten herumschlagen. Durch die fortschreitende Containerisierung ist vieles davon überflüssig. Auch andere Themen sind für Entwickler heute deutlich weniger relevant als vor fünf oder sechs Jahren.

heise Developer: Was ist für Unternehmen schwieriger beim Umstellen auf Microservices: der technische oder der kulturelle Wandel?

Newman: Gerald M. Weinberg, der Autor des großartigen Buchs "Das Gesetz der Himbeer-Marmelade – 103 Geheimnisse der Beratung" [4] ("Secrets of Consulting") hat den Satz "It's always a people problem" geprägt, es ist also immer ein Problem des Umgangs der Menschen untereinander.

Wir versuchen die Techniken durch die Technologiebrille zu betrachten, aber Menschen haben die Techniken entwickelt. Daher kann man nichts reparieren, wenn man es rein technisch betrachtet. Meiner Meinung nach kann man keinen kulturellen Wandel durch neue Techniken bewirken. Technologie kann den Wandel fördern oder behindern, aber nicht erzwingen.

Wer das Beste aus Microservices als Architektur herausholen möchte, muss auch die organisatorischen Strukturen berücksichtigen. James Lewis hat gesagt, dass Microservice-Architekturen eine Optimierung in Richtung Autonomie bringen. Der Architekturstil ermöglicht Organisationen, autonome Teams und autonome Arbeitsweisen zu etablieren.

Die Verantwortung wandert von einer zentralen Stelle in die einzelnen Teams. Zu Organisationen, die eine solche Arbeitsweise wünschen, passen Microservices als Konzept gut. Organisationen, die eine zentrale Befehls- und Kontrollebene beibehalten möchten und in denen eine kleine Gruppe von Menschen alle Änderungen steuert, werden kaum von den Vorteilen der Microservices profitieren.

Meiner Meinung nach muss daher der technische Wandel Hand in Hand mit dem kulturellen erfolgen. Allerdings ist eine technische Umstellung fast immer einfacher, als Leute dazu zu bringen, ihre Denk- oder Arbeitsweise zu ändern.