Kolumne: Stropek as a Service

Information Overload – die Cloud erweitert das Anforderungsprofil an Softwareentwickler
Keine Kommentare

Die Liste der Ankündigungen auf der Azure-Webseite war zu Beginn des Jahres bereits zweieinhalb Seiten lang. Security, Data Platform, Web APIs, IoT – das Themenspektrum der allein in den ersten beiden Monaten dieses Jahres neu erschienenen Azure-Komponenten ist enorm breit.

Dank DevOps ist es auch schwieriger geworden, gewisse Themenbereiche auszublenden. Schließlich arbeitet man in einem autonomen Team, das Technologieentscheidungen von Datenbank bis UI eigenständig treffen soll und auch für den Betrieb der Produktionsumgebung verantwortlich ist. Wer soll bei dieser Informationsflut und Innovationsgeschwindigkeit auf dem Laufenden bleiben? Man hat schließlich auch einen normalen Job in der Softwareentwicklung zu erledigen. Ich kann mich noch gut an Zeiten erinnern, in denen es ein oder zwei Mal im Jahr große Entwicklungskonferenzen gab. Dort wurden die wichtigsten Neuigkeiten vorgestellt. Man hat in einem klar abgegrenzten Bereich gearbeitet und konnte recht einfach Informationen über Neuerungen in relevant oder nicht relevant einteilen.

Als Softwareentwicklerinnen und -entwickler müssen wir Strategien finden, mit dieser „schönen“ neuen Welt umzugehen. Mit diesem Thema möchte ich mich in dieser Ausgabe meiner Kolumne beschäftigen.

Mut zur Lücke

Mein erster Tipp: Nur keine Panik. Auch in Zeiten von DevOps muss man nicht jedem Trend nachlaufen und nicht jeden neuen Cloud Service sofort in die eigene SaaS-Lösung einbauen. Jedes Team sollte eine technologische Ausrichtung haben und diese auch verfolgen. Es ist vollkommen ok, wenn man Neuerungen in anderen Bereichen ausblendet oder nur am Rande verfolgt. Wer seine Software ganz auf .NET aufbaut, muss nicht jede Ankündigung über neuen Java-Support in Serverless Functions im Detail lesen. Wer seine Strategie in Sachen Datenhaltung auf relationalen Datenbanken aufgebaut hat, braucht nicht jeden neue NoSQL-PaaS-Dienst sofort auszuprobieren.

Ich kenne viele Entwicklerinnen und Entwickler, die ein Problem damit haben, zuzugeben, dass sie gewisse Bereiche der Softwareentwicklung für sich ausblenden und davon wenig Ahnung haben. Sie versuchen, über alles auf dem Laufenden zu bleiben. Die Gefahr dabei ist, auszubrennen oder vor lauter Lesen, Recherchieren und Ausprobieren nicht mehr zur eigentlichen Arbeit zu kommen. Darüber hinaus darf man Konzeptwissen nicht mit echtem, tiefem Verständnis für eine Technologie verwechseln. Letzteres erreicht man nur durch praktischen Einsatz in nicht trivialen Projekten. Es liegt in der Natur der Sache, dass man das nur mit einer begrenzten Anzahl von Plattformen und Tools machen kann, da der Tag für uns alle nur 24 Stunden hat.

Historische Betrachtungen

Ich lerne bei meiner Arbeit als Berater in Sachen Cloud-Computing viele Leute kennen, die verwirrt sind angesichts der vielen Lösungen, die Cloud-Anbieter wie Microsoft für ein und dasselbe Problem anbieten. Nehmen wir das Thema Events zwischen Microservices. Man könnte auf HTTP basierende WebHooks, Service-Busse, Event Grids oder Event-Hubs setzen. In nicht wenigen Fällen lassen sich Argumente für jede der genannten Plattformen finden.

Anbieter wie Microsoft stellen in der Dokumentation Artikel zur Verfügung, in denen die Cloud-Angebote verglichen werden. Die Autoren versuchen darzustellen, wie sich die Dienste ergänzen und wie jeder seinen jeweiligen Schwerpunkt und seine Daseinsberechtigung hat. Um ehrlich zu sein, sehe ich das etwas anders. Oft überschneiden sich die Einsatzbereiche stark und aus heutiger Sicht macht es tatsächlich keinen Sinn, so viele Lösungen für das gleiche Problem zu haben. Warum gibt es sie dann? Die ehrliche Antwort ist, dass auch die riesigen Cloud-Plattformen historisch gewachsen sind und es parallel zu Lösungen, die vor ein paar Jahren noch perfekt erschienen sind, heute noch bessere gibt. Es macht keinen Sinn, sich in endlosen Meetings den Kopf zu zermartern, um objektive Auswahlkriterien zu finden, die eine eindeutige Entscheidung für die eine oder andere Lösung rechtfertigen. Nicht selten führen mehrere Wege zum Ziel.

Ich rate auch davon ab, sich von jeder Hochglanzankündigung neuer Cloud-Dienste verunsichern zu lassen. Die „Rising Stars“ haben ziemlich sicher Kinderkrankheiten, während die etablierten Dienste stabil und funktional ausgereift sind. Aus der Ferne betrachtet wirken neue Cloud-Dienste oft unwiderstehlich. Wenn man sich im Detail damit auseinandersetzt, haben auch sie ihre Ecken und Kanten.

Augen offenhalten

Bitte meine Argumente nicht falsch verstehen. Ich rede nicht von Ignoranz, ganz im Gegenteil. Ich persönlich nutze den Besuch auf Konferenzen oder Community-Meetups meist ganz gezielt, um etwas über Themen zu lernen, die außerhalb meines üblichen Arbeitsbereichs liegen. Dadurch kommt man auf Ideen und hinterfragt seinen eigenen Informationsfilter. Vielleicht lernt man einen neuen Ansatz kennen und entdeckt danach, dass es diesen auch im eigenen Technologieuniversum gibt, man ihn aber bisher nicht auf dem Radar hatte.

Ein großer Fehler ist, die Themen, die man für sich bewusst ignoriert oder nur am Rande verfolgt, als schlecht oder sinnlos abzutun. Man sollte vor sich selbst und vor anderen eingestehen, dass man gewisse Technologiebereiche nicht betrachtet, das aber nichts über deren Qualität aussagt.

Einfluss von DevOps

In Zeiten von DevOps ist es schwieriger als früher, sich als Softwareentwicklerin oder -entwickler einzuordnen. .NET, Java, Node.js, Go – Programmiersprachen und -plattformen sind nur mehr zum Teil relevant für die Auswahl der interessanten, technologischen Neuerungen. Durch DevOps kommen viele neue Aspekte zur Arbeit in Entwicklungsteams dazu, für die es früher getrennte, spezialisierte Teams gegeben hat. Netzwerksicherheit, Virtualisierung oder Systemüberwachung, im DevOps-Team ist man auch dafür verantwortlich und muss wissen, was sich in der jeweils ausgewählten Cloud-Plattform in diesen Bereichen tut. So wie man von jedem Mitglied in einem Entwicklungsteam voraussetzt, dass SQL halbwegs beherrscht wird, muss man in einem DevOps-Team davon ausgehen können, dass jede Entwicklerin und jeder Entwickler die Hausaufgaben bezüglich der Ops-Themen gemacht haben.

Wie soll man das neben den sonstigen Aufgaben schaffen? PaaS und Serverless sind aus meiner Sicht die Antwort auf diese Frage. Durch DevOps wächst das Themenspektrum, das man als Mitglied eines Entwicklungsteams abdecken muss. In der Cloud gibt es für viele der Themen aber fertige PaaS- und Serverless-Dienste. Dadurch ist es nicht mehr notwendig, sich mit allem bis ins letzte Detail auseinanderzusetzen. Ein gutes Beispiel ist der Azure App Service zum Betrieb von Web-Apps und Web-APIs. Früher war es nicht einfach, elastisch skalierende Webcluster aufzubauen. Mit App Service ist das ein Kinderspiel. Das macht Kapazität frei für neue Themen.

Architektur und strategische Partnerschaften

Meiner Ansicht nach kommt der Softwarearchitektur und strategischen Partnerschaften mit einem Cloud-Anbieter eine wichtige Rolle beim Bewältigen der Änderungsgeschwindigkeit in der Cloud zu. Sie sind Wegweiser durch die Vielfalt an Angeboten. Der Vergleich mit realer Architektur von Gebäuden passt recht gut. Die Architektur einer Software sollte die großen, wichtigen Designentscheidungen festhalten. In der realen Welt wären das das Grundstück, auf dem man sein Haus baut, die Entscheidung für einen Fertigteilhausanbieter oder die Anordnung der tragenden Wände. Solche Entscheidungen ändern sich nicht jeden Monat. Änderungen würden manchmal praktisch einen Neubau bedeuten.

Ein Team, das eine klare Vision von der Architektur seiner Cloud-Lösung hat, hat eine Orientierungshilfe in der verwirrenden Vielfalt von Diensten, die es heute in einer Cloud wie Azure gibt. Es wird nicht auf jeden Trend aufspringen, sondern architekturelle Änderungen gut durchdenken, mit Prototypen evaluieren und längerfristig planen. Ein solches Team hat kein Problem damit, dass rundherum ein Feuerwerk von Ankündigungen abgefeuert wird, da es ein klares Bild vom eigenen Weg hat.

Schwieriger ist die Sache, wenn man neue Projekte auf der grünen Wiese beginnt. Hier hat man tatsächlich die Qual der Wahl. In einer solchen Situation sollte man sich die Zeit nehmen, ausführlich alle Optionen grob kennenzulernen, die denkbaren herauszufiltern und bei ihnen tiefer einzusteigen. Hilfreich können hier auch Referenzarchitekturen der Hersteller sein. Aber Vorsicht, diese sind oft für sehr große Szenarien optimiert und müssen für kleine oder mittelgroße SaaS-Lösungen eventuell vereinfacht werden.

Teamwork

Trotz aller oben genannten Tipps muss ich aus eigener Erfahrung zugeben, dass es eine Herausforderung ist, mit den Entwicklungen in nur einer einzelnen Cloud wie Azure Schritt zu halten. Für mich persönlich wäre es undenkbar, tieferes Wissen über mehrere der großen Public Clouds aufzubauen und aktuell zu halten. Gleiches gilt bei tiefgehendem Wissen über spezifische Cloud-Dienste. Man kann nicht überall Expertin oder Experte sein.

Ein Lösungsansatz für dieses Dilemma ist aus meiner Sicht gutes Teamwork mit einer entsprechenden Kultur des Wissensaustauschs. Im DevOps-Team kann grundsätzlich jeder bei fast allen Themen einspringen. Das bedeutet nicht, dass es im DevOps-Team keine Spezialisierung geben darf. Man hilft sich gegenseitig, das Management sollte den Erfahrungsaustausch zwischen den Teams fördern, interne oder externe Consultants sollten bei Spezialfragen erreichbar sein, und es muss ausreichend Zeit und Budget für Weiterbildung und Recherche eingeplant werden. Moderne Unternehmen motivieren ihre Teams, über das eigene Unternehmen hinaus Erfahrungen auszutauschen und aktiv in entsprechenden IT-Communitys mitzuarbeiten.

Kombiniert man diese Maßnahmen mit Ansätzen wie den oben genannten, kann man nicht nur eine SaaS-Lösung initial erstellen, sondern sie langfristig wirtschaftlich erfolgreich betreiben und aktuell halten.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -