Olis bunte Welt der IT

Das richtige Werkzeug finden – sind Microservices der passende Hammer?
Kommentare

Als Junge besaß ich ein Schweizer Taschenmesser. Damit konnte man tolle Sachen machen: vom Zahnstocher bis zum Dosenöffner war da alles dran, was man je brauchte. Natürlich hatte ich zu dieser Zeit meines Lebens nicht viele Dosen zu öffnen oder Korken zu ziehen, aber die Vielfältigkeit des Werkzeugs fand ich beeindruckend.

Wenn irgendwo eine Schraube zu drehen war oder ein loser Faden abzuschneiden, war das Taschenmesser erste Wahl. Natürlich war das Ergebnis oft nicht besonders gut und ich wäre oft besser dran gewesen mit einem Schraubenzieher, einem richtigen Dosenöffner oder Korkenzieher oder einem Stück Zahnseide.

Es gibt ein Sprichwort, das gut zusammenfasst, was ich in meiner Jugend mit meinem Taschenmesser erlebt habe: „Wenn man einen guten Hammer hat, sieht jedes Problem wie ein Nagel aus.“ Nun hat sich mein Fokus im Laufe der Jahre verschoben, aber ich begegne auch in meiner heutigen Arbeit noch immer regelmäßig dem allmächtigen Hammer. Viele Menschen, die in Bereichen der Softwareentwicklung oder -architektur arbeiten, lieben ihre Hämmer und versuchen jahrelang, manchmal jahrzehntelang, jedes Problem gerade so zu betrachten, dass es mit ihrem Lieblingswerkzeug lösbar wird.

MVC als Allzweckwerkzeug?

Je komplexer das Problem, desto eher ist es eine Frage der Perspektive, wie einfach das gelingt. In monolithischen gedanklichen Ansätzen ist es einfacher, die Randbereiche zu ignorieren, zu übersehen oder einfach neu zu definieren, in denen die Lösung nach dem Hammerprinzip womöglich nicht perfekt ist. Als Jugendlicher fand ich, dass die schartige Kante, die sich nach anstrengender Arbeit am Rand meiner Fischdose zeigte, geradezu „cool“ aussah: Man konnte ihr ansehen, wie anstrengend es war, dieses Ergebnis zu erzielen. In vergleichbarer Weise sehen auch heute manche Entwickler eine Windows-Forms-Anwendung, mit ClickOnce verteilt, als Gipfel des ästhetischen Empfindens und übersehen gern die schartigen Kanten im Code- und Pflegeaufwand, der Verfügbarkeit und Skalierbarkeit oder der Inkompatibilität mit anderen Plattformen.

Natürlich wissen wir heute, dass der Bereich Softwareentwicklung sehr schnelllebig ist. Daher gibt es mittlerweile den neuen Trend, hin und wieder nach einem neuen Hammer Ausschau zu halten. Es gibt viele Beispiele für Technologien, die schon einmal auf breiter Front solch eine Rolle spielen mussten. Zu erwähnen ist etwa MVC auf der Serverseite, ein Konzept, das vor Jahren in bestimmten Bereichen eine gewisse Dominanz erreichte und sich inzwischen als Allzweckwerkzeug etabliert hat, was bereits zu einer gewissen Verschiebung des View-Begriffs, etwa im Bereich von Diensten, geführt hat.

ORM für Daten – was sonst?

Ein anderes Beispiel ist ORM zum Zwecke des Datenzugriffs. Noch vor wenigen Jahren war dieses Schema in der .NET-Welt nicht sehr verbreitet und wurde hauptsächlich von einigen Drittherstellern favorisiert, oft mit einem Blick zu den Ursprüngen mancher Libraries in Java. Wenn ich heute in meinen Workshops von CQRS spreche – einem Datenzugriffsprinzip, das Lese- und Schreiboperationen entkoppeln hilft –, stellen .NET-Entwickler gern die Frage: „Ich arbeite aber mit Entity Framework, wie mache ich denn da CQRS?“ Man betrachtet die Entscheidung für ORM bzw. für ein bestimmtes Produkt aus dem Bereich gern als gegeben und versucht, andere Entscheidungen für bestimmte Patterns oder architekturelle Strukturen davon abhängig zu machen.

Prioritäten für bestimmte Plattformen oder auch die allgemeinere Unterscheidung „Client“ oder „Web“ sind ebenfalls gute Beispiele für solche Sichtweisen. Wenn ich als Aussteller bei Veranstaltungen mit Programmierern rede, stelle ich immer wieder fest, dass diese sich gern als „Cliententwickler“ oder „Webentwickler“ einstufen. Damit ist eine Weltsicht definiert, eine philosophische Grundlage für die tägliche Arbeit. Oft geht das noch viel weiter: „Wir machen jetzt unternehmensweit alles nur noch mit Angular“ ist eine Aussage, die ich schon oft gehört habe.

Das SOA-Konzept

Schließlich finden sich Hämmer auch im Bereich der Architektur. Da gibt es etwa SOA, das besonders bei größeren Unternehmen und in gewissermaßen konservativen Industrien noch immer sehr gern erwähnt wird. Bereits 2005 schrieb Martin Fowler über die unterschiedlichen Auffassungen davon, was SOA bedeutet, und dass er das Konzept aufgrund dieser Definitionsschwierigkeiten für „nicht mehr zu retten“ hielt. Somit handelt es sich hier um ein Beispiel für ein Lieblingswerkzeug, das einfach gern beim Namen genannt wird, unabhängig von der detaillierten Bedeutung. Ein Buzzword, neudeutsch, das gemeinsam mit zusammenhängenden Technologien wie den WS-*-Standards oder XML schon deshalb hochgehalten wird, weil es dem Marketing der eigenen Dienstleistung hilft.

Wie Sie dem letzten Beispiel entnehmen können, sind die Gründe für Bevorzugung nach dem beschriebenen Muster vielfältig. Einfach nur „cool“ ist auch bei der technischen und geschäftlichen Entscheidungsfindung eine Eigenschaft, der regelmäßig großer Stellenwert eingeräumt wird. Wenn es um Technologie geht, spielen aber auch die eigenen Kenntnisse und die des Teams eine wichtige Rolle. Für ein Werkzeug, das Sie gar nicht kennen, können Sie sich natürlich nicht entscheiden. Von vielen Werkzeugen haben Sie vielleicht schon gehört, aber Sie kennen nicht genügend Details, um die Bedeutung richtig einzuschätzen und zu berücksichtigen.

Um effektiv mit einem neuen Ansatz arbeiten zu können, ist ein Lernaufwand erforderlich, der bei Berücksichtigung einer ganzen Gruppe von Mitarbeitern schnell auf einen beängstigenden Umfang anwachsen kann. Die Zukunftssicherheit jeder Entscheidung kommt ins Spiel, wenn es um diese Art der Investition geht, sowie die Überlegung, dass neue Mitarbeiter entweder bereits mit den entsprechenden Kenntnissen eingestellt oder ebenfalls geschult werden müssen.

Softwarelizensierung ist oft ein Grund, bei bestehenden Lösungen zu bleiben. Langfristige Verträge sind gerade in großen Unternehmen verbreitet und viele Produkte, die auf Servern als Komponenten von Architekturmodellen dienen, binden den Kunden stark durch die Verwendung proprietärer Formate und Protokolle.

Und wenn’s an anderen liegt …

Letztlich habe ich auch dies schon oft gehört: „Ich bin in der glücklichen Lage, dass meine Kunden selbst noch auf Windows Forms setzen. Für neue Plattformen müsste neue Hardware her, das wollen die sowieso nicht. Web? Danach hat noch niemand gefragt. Mobil auch nicht.“

Diese Argumentation finde ich besonders interessant, um das Verweilen bei der Technologie der Vergangenheit zu begründen. Es scheint offensichtlich, dass die Investitionssicherheit des eigenen Know-how und dem der Mitarbeiter damit direkt in den Händen besagter Kunden liegt. Es ist anzunehmen, dass es sich meist nicht um einen sehr großen Kundenstamm handelt, wenn alle Kunden gemeinsam eine so desinteressierte Haltung an aktuellen Entwicklungen einnehmen. Viel Glück der Firma, die darauf basierend die eigene Weiterentwicklung über Jahre hinweg vernachlässigt!

Kleine Dienste

Eine Entwicklung der letzten Jahre, die im Umgang mit Kundenprojekten mittlerweile recht regelmäßig beobachtet werden kann, ist die der Einführung von sogenannten Microservices-Architekturen. Dabei handelt es sich um einen Aufbau von Anwendungssystemen, der auf der Verwendung einzelner autonomer und vollständig entkoppelter Systeme basiert. Es gibt einige Parallelen zu SOA, zumindest zu den grundlegenden Ideen von SOA, wobei in der Realität meist mit weniger strikten, weniger formellen Spezifikationen von Protokollen oder Formaten gearbeitet wird als das bei SOA gemeinhin der Fall war und ist. Es gibt keine Definition von Microservices, sondern es handelt sich um ein evolutionär gewachsenes Schema.

Autonome und entkoppelte Dienste sind dabei voneinander unabhängig und interagieren über mehr oder weniger präzise definierte Schnittstellen, die typischerweise relativ grobe Granularität aufweisen. Mit Mechanismen der Toleranz und, wenn nötig, Versionierung, kann erreicht werden, dass die Schnittstellen stabil und gleichzeitig flexibel bleiben. Damit sind die einzelnen Dienste so eigenständig wie möglich.

Es gibt keine feste Regel, aber oft ist ein Team für einen Dienst zuständig. Die Größe eines Teams ist unterschiedlich, und auch ein Dienst kann – trotz der Bezeichnung – durchaus einen beträchtlichen Umfang an Verantwortung und Kompetenz besitzen. Einer der Vorteile von Microservices besteht darin, dass für jeden Dienst separat Entscheidungen über dessen Anforderungen sowie die besten technischen Mittel, diese zu garantieren, getroffen werden können. Ein Dienst kann in einer ganz anderen Programmiersprache geschrieben sein, auf einer anderen Plattform laufen oder eine andere Datenbank verwenden. In manchen Betrieben, wie etwa bei Amazon, wird dem Team, das einen Dienst programmiert, die Verantwortung zugewiesen, diesen Dienst auch zu betreiben und rund um die Uhr dafür verantwortlich zu sein. Ein spontan überzeugendes Konzept, das fraglos zu höherer Codequalität führt.

Schnell und überall: Datenzugriff mit Entity Framework Core 2.0

Dr. Holger Schwichtenberg (www.IT-Visions.de/5Minds IT-Solutions)

C# 7.0 – Neues im Detail

Christian Nagel (CN innovation)

Wegwerfprodukte

Die Freiheit, einen jeden Dienst so zu entwickeln, wie es sich am meisten anbietet, bringt offensichtlich Vor- und Nachteile mit sich. Theoretisch wird dadurch der Dienst effizienter, da die Wahl der richtigen Werkzeuge leichter fällt und besser auf die Anforderungen abgestimmt sein kann. Natürlich setzt dies voraus, dass das Team die fraglichen Werkzeuge gut genug kennt und korrekt einschätzt; andernfalls ist es möglich, dass eine Entwicklung in die falsche Richtung läuft und letztlich kein brauchbares Ergebnis vorzuzeigen ist. In dieser Gefahr steckt aber auch gleichzeitig ein wichtiger Vorteil des Konzepts: Komponenten des Gesamtsystems sind klar in ihrer Verantwortlichkeit definiert und somit einfach und ohne Auswirkungen auf andere Teile austauschbar. Was Microservices langfristig interessant macht, ist die Idee, von schnell entwickelten und womöglich kurzlebigen neuen Technologien profitieren zu können, ohne dasselbe Risiko in jeder Investition zu sehen, wie das bei der Entwicklung einer traditionelleren monolithischen Anwendung der Fall ist.

Wiederverwendbarkeit ist lange als eines der größten Nebenziele bei der Softwareentwicklung gesehen worden. Ich habe selbst oft erlebt, dass Kunden so sehr an bestehendem Code hängen, dass eine Neuentwicklung als völlig unmöglich angesehen wird. In manchen Fällen existiert eine Codebasis schon so lange, dass niemand mehr weiß, wie sie eigentlich funktioniert, und es gibt niemanden mehr, der den Code wirklich pflegen oder gar modifizieren kann. Es wäre falsch, der Schule der Microservices zu unterstellen, dass sie den Wert des Codes nicht schätzt. Jedoch versucht sie sehr erfolgreich, uns durch die extreme Form von Modularisierung, die sie favorisiert, die Angst vor dem Neuen zu nehmen.

Wer nun glaubt, dass Microservices eine tolle Lösung für das Hammerproblem sein sollten, der liegt natürlich zumindest teilweise richtig. Wenn sich Teams nach dieser Idee verhalten, durchlaufen sie mit einiger Regelmäßigkeit die Schritte, die zu einer objektiven Abwägung möglicher Problemlösungen notwendig sind. Es wird legitim, die Neuentwicklung von Teilen eines Anwendungssystems auf einer anderen Basis vorzuschlagen und in Betracht zu ziehen ‑ ehedem war es einer der größten Fehler von Beratern im Softwaregeschäft, solche Ideen anzusprechen. Damit wird die Bereitwilligkeit des einzelnen Mitarbeiters gefördert, sich für technische Alternativen zu interessieren und deren Anwendbarkeit im eigenen Kontext immer wieder zu evaluieren.

Hammer der Zukunft: Microservices?

Allerdings sollten wir im Kopf behalten, dass auch das Konzept Microservices zu einem Hammer werden könnte. Derzeit fehlt die Perspektive, um einzuschätzen, wie sich komplexe Dienstschnittstellen langfristig entwickeln. Die Eigenständigkeit der Teams und Dienste könnte ebenfalls zum Problem werden, wenn es an übergreifender Koordination mangelt. Wenn ein Team Schnittstellen definiert, die von einem anderen Team, das auf den Dienst zugreifen soll, als zu komplex eingeschätzt oder gar nicht verstanden werden, dann gibt es Konflikte, die im Laufe der Zeit zu Schwierigkeiten führen können.

Damit soll nicht gesagt sein, dass Microservices kein wichtiges und vermutlich zukunftsträchtiges Konzept darstellen. Der Punkt ist, dass wir nie vergessen sollten, dass wir uns für ein Schema entschieden haben, und warum, und was die anderen Möglichkeiten waren, die wir ebenfalls in Betracht gezogen haben. Dies ist eine grundlegende Idee der Entscheidungsfindung und meine allgemeine Empfehlung.

Die Qual der Wahl

Entscheidungen müssen getroffen werden, weil es Vielfalt gibt. Das ist eine gute Sache, denn sonst gäbe es keine Weiterentwicklung. Die Vielfalt will akzeptiert sein, und das bedeutet für jeden Entscheider, dass Optionen recherchiert und eingeschätzt werden müssen. Ich empfehle hier den Weg, der durch die Grundaussage der Pragmatik vorgegeben wird: jede Option sollte an der Gesamtheit ihrer Konsequenzen gemessen werden. In anderen Worten: Überlegen Sie für jede Option, die Sie in Betracht ziehen, im Detail, was die Konsequenzen einer potentiellen Entscheidung sind.

Eine weitere Empfehlung von mir: Machen Sie es sich zur Regel, immer mindestens zwei Optionen zu kennen. Damit sorgen Sie dafür, dass Sie Entscheidungen der Vergangenheit infrage stellen. Es sollte niemals legitim sein, eine Lösung nur deshalb zu akzeptieren, weil diese in der Vergangenheit schon einmal verwendet wurde. Wenn Sie sich für etwas entscheiden, sollten Sie immer auch wissen, wogegen Sie sich entscheiden. Sie entscheiden sich immer gleichzeitig gegen etwas, wenn Sie sich für etwas entscheiden, und Sie sollten wissen, was das ist.

Die Vielfalt in der Softwareentwicklung wächst. Die Komplexität der Umgebungen, in denen Software installiert und verwendet wird, wächst ebenfalls. Es ist nicht absehbar, dass sich dies ändern wird. Somit ist es wichtiger als je zuvor, auf dem Stand zu bleiben. Kein Betrieb ist letztlich dauerhaft konkurrenzfähig, wenn er sich die Möglichkeiten aktueller Technologie nicht zunutze macht. Aus dem Schema der Microservices können Sie lernen, dass Software so strukturiert werden kann, dass neue Entwicklungen mitgenommen werden dürfen, sodass der Umgang mit neuen Werkzeugen und Plattformen zur Gewohnheit wird.

„Gestern war alles besser“ ist eine Einstellung, die in der Softwareentwicklung nicht angebracht ist. Mein Rat: Vergessen Sie den Hammer und das Schweizer Taschenmesser und halten Sie die Augen offen. Die Welt ist nicht schwarz-weiß und wer nur eine Antwort kennt, hat die Frage nicht verstanden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -