Herausforderung Software Architektur

Die Herausforderungen in der Software Architektur von heute sind hoch komplex.

BK: Dieser Beitrag richtet sich an Unternehmen mit komplexen Software Lösungen mit Frontends und Backends sowie dedizierten Deployment Prozessen.

Im Fokus stehen dabei sowohl alle Beteiligten, wie auch die Trends und vor allem eine breite Übersicht über die Technologien, die für eine Software Architektur in Frage kommen.

Software Architektur sollte meiner Ansicht nach heute nahe am Management angegliedert sein, genauso wie das Marketing, um Architekturentscheide von oben zu tragen. Dafür braucht es auch auf der obersten Führungsebene ein gewisses Verständnis für Technologie.

Ein/e Software Architekt/in steht heute in einer Schnittstellen Position.

• Sie/er soll die Fähigkeiten und den Markt der Entwickler einschätzen können, da dies direkte Auswirkungen auf die Kosten hat.

• Sie/er soll das Know-How der Entwickler, Projektleiter, Betriebsmitarbeiter und DevOps Verantwortlichen abholen, um die Architektur zu bauen.

• Sie/er soll die Use Cases, die durch die Kunden entstehen abholen und verstehen.

• Sie/er soll Entscheidungen zu Technologien für den Einsatz in der Architektur herbeiführen, um Mehrheiten für Ideen zu gewinnen.

• Sie/er soll für eine Lösung begeistern können.

• Sie/er muss die Lösung aus verschiedenen Perspektiven und Ebenen der Betrachtung visualisieren können.

• Sie/er braucht genauso ein Verständnis für Security wie für die Lifecycles, denen die Software Hersteller unterworfen sind.

• Sie/er soll die Stakeholder (CIO, CTO, COO, CFO, CEO und Projektleiter) informieren und vom Sinn und von Notwendigkeiten überzeugen können.

Die Herausforderung

Ich sehe die grösste Herausforderung darin, dass Software Architekten im Normalfall Entwickler sind und damit in erster Linie technisch denken. Das Business ist da meist weit entfernt und vor allem auch die Kundenorientierung. Entwickler sind normalerweise eher introvertierte Persönlichkeiten, die wenig Verständnis für Marketing und Sales mitbringen.

Marketing und Software Architektur sind jedoch heute treibende Kräfte jedes Unternehmens und sollten Hand in Hand arbeiten.

Sobald Software intern geschrieben wird, sind die Prozesse heute sehr anspruchsvoll, da bei allen modernen Sprachen heute Build- und Deployment Prozesse involviert sind.

Als Beispiel diene eine Applikation mit einem Java Backend und einem modernen Frontend.

Eine solche Applikation verlangt normalerweise nach dem Einsatz von 15-30 verschiedenen Technologien, die perfekt zusammenspielen müssen.

Version Control: Git
Infrastruktur: AWS
Entwicklungsumgebung: IntelliJ
Backend Sprache: Java
Backend Framework: Java Spring
Backend Build System: Maven
Backend Deployment Container: Docker
Daten Übertragung: JSON
Daten Übertragung Protokoll: https (get/post)
Backend Datenbank: MySql
Frontend Umgebung: Node.js
Aufbau Frontend: Angular CLI
Sprache Frontend: Typescript
Frontend Build System: Webpack
Frontend Seiten Struktur: HTML5
Frontend Seiten Darstellung: CSS3
Webserver: Apache

Alle diese Teile der Applikation müssen ebenfalls in mindestens 3 Versionen als DEV, TEST, PROD Umgebungen bestehen. Gleichzeitig wird je nach Wahl des Architektur Ansatzes jeder einzelne Teil der Liste beliebig komplex. Wenn beispielsweise mit Microservices auf der Backend Seite gearbeitet wird, wird der Build Prozess der Java Komponenten zu einer eigenen Wissenschaft, genauso wie der Bau benötigter Datenbank Instanzen.

Jede der gelisteten Technologien wird von anderen Herstellern betrieben. Vielfach gibt es verschiedene Hersteller mit verschiedenen Distributionen. Teile sind Open Source, andere Teile sind kommerziell vertrieben, so dass komplexe Lizenzmodelle im Einsatz sind.

Was aus Sicht der Entwickler oftmals etwas vernachlässigt wird, ist, dass ein System sich im Betrieb dadurch auszeichnet, dass es effizient überwacht werden kann. Dies verlangt nach einem homogenen und verständlichen Logmechanismus genauso wie einem durchdachten Monitoring System.

Dies ist die Welt der Software Architektur von heute!

3 Typen von Software Architekturen

Ich bin kein Purist! Entsprechend sehe ich die Herausforderung in der Software Architektur darin, eine sinnvolle Mischung aus den verschiedenen Ansätzen zu schaffen, die grösstmögliche Effizienz im Umgang mit der Lösung ergibt.

Monolith

Dieser Ansatz widerspiegelt die alte Welt der Software Architektur, in der nach wie vor verschiedene ältere Software Lösungen leben, die jedoch immer mehr abgelöst werden.

Die vollständige Software Lösung wird dabei nach Wasserfall Methode entwickelt. Wasserfall steht bezeichnend dafür, dass die Software Lösung als vollständige Distribution ausgeliefert wird. Dies bedeutet keinen Einsatz von Agilität. Sobald die ganze Lösung fertig ist, wird sie deployed und getestet, Korrekturen werden eingepflegt und es folgt im besten Fall das Deployment in die Produktion.

Viele Lösungen, die in der Vergangenheit so entwickelt wurden, erreichten niemals den produktiven Einsatz, da Mängel im produktiven Umfeld nicht behoben werden konnten, oder schlicht irgendwann die Entwicklungskosten nicht mehr tragbar waren.

Im Falle der Weiterentwicklung eines Monoliths können keine einzelnen Komponenten getestet und deployed werden. Für eine neue Version muss erneut die ganze Applikation für einen Release vorbereitet werden.

Positiv auswirken kann sich bei diesem Vorgehen, wenn eine hochstabile Lösung entsteht, da alle Teile perfekt aufeinander abgestimmt sind.

Negativ wirkt sich beim monolithischen Ansatz aus, dass Release Zyklen träge sind. Weiter besteht keine Möglichkeit zum dynamischen Skalieren einer solchen Software. Entsprechend ist diese direkt an die Hardware gebunden, wo Server physisch ausgebaut werden müssen, um eine grössere Last abzudecken.

Nur weil dieser Ansatz nicht hoch modern ist, heisst es nicht, dass er nicht in einzelnen Fällen sinnvoll ist.

SOA – Service Oriented Architecture

Die Service Orientierte Software Architektur ist ein Schritt weg vom Monolith in der Evolution der Software Architektur.

Verschiedene Teile der Software Architektur werden in einzelne Services aufgeteilt, die bestenfalls eigenständig deployed und getestet werden können. In einer SOA wird der Austausch von Informationen meist über XML (Extended Markup Language) organisiert, wo über die XSLT Stylesheets ein Vertrag zwischen den Services definiert wird, die an der Schnittstelle beteiligt sind.

SOA eignen sich für eine agile Entwicklung, die einzelnen Services sind jedoch meist nicht vollkommen eigenständig.

Eine SOA kann sehr effizient und sinnvoll sein, je nach Anforderung und Einsatzgebiet. Trotzdem passt sie vor allem mit dem Serverles Services Ansatz, der weiter unten beschrieben wird nicht optimal zusammen, da in der Praxis die Deployment Prozesse meist sehr genau aufeinander abgestimmt werden müssen, um alle Verträge unter den Services zu erfüllen.

Als Nachteil betrachte ich, dass die Services nicht vollkommen eigenständig sind, so dass diese nach wie vor nicht total unabhängig voneinander weiterentwickelt und deployed werden können.

SOA’s sind nach wie vor sehr verbreitet in der Software Industrie und dieser Ansatz einer Architektur hat auch seine ganz klare Existenzberechtigung. Ich tendiere dazu, in verschiedenen Fällen einzelne der unten beschriebenen Microservices selbst als SOA zu abstrahieren.

Microservices

Microservices sind der modernste Ansatz in der Software Architektur.

In purer Form sind diese vollständig unabhängig und erfüllen alle einen genau definierten Zweck. Der Informationsaustausch unter den Services findet ausschliesslich über REST Schnittstellen statt und die Idee ist, wo auch immer möglich auf Abhängigkeiten zu verzichten. Im Fall von asynchronen Anforderungen werden zudem sinnvollerweise Message Queues verwendet, von denen aber jede ihre Tücken mit sich bringt.

Die Schwierigkeit in der Arbeit und Software Architektur mit Micro Services liegt primär darin, wie fein diese definiert werden, bzw. wie puristisch die Konzepte dieser Architektur eingesetzt werden.

2 Szenarien sind dabei genau zu betrachten:

• Da die Services in einer Micro Services Architektur nach mehr Kommunikationswegen verlangen, können Verzögerungen in diesen die Applikation lahm legen. Es braucht entsprechend Mechanismen, um diese Verzögerungen im Austausch abzufangen, oder sie wenn möglich aus Sicht des Designs von vornherein auszuschliessen.

• Der Deployment Prozess kann sehr komplex werden, so dass die gewonnene Optimierung in der Entwicklung im Verteilprozess wieder zunichte gemacht wird.

Micro Services sind vor allem in Anbetracht der Entwicklung der weiter unten beschriebenen Infrastrukturen ohne konkrete Server den anderen beiden Architektur Ansätzen wenn möglich vorzuziehen.

Jeder der 3 Ansätze hat seine Vor- und Nachteile, die im Detail genau abzuwägen sind. Aus meiner Sicht sollte in einem sich schnell entwickelnden Umfeld immer darauf geachtet werden, möglichst progressive Modelle zu verfolgen. Alternativ setzt man sich dem Risiko aus, dass Applikationen alle 2 Jahre vollständig neu designed und geschrieben werden müssen, was grosse Kosten mit sich bringt und ein Unternehmen in die Knie zwingen kann.

Lösungen auf der Basis von Technologien zu betreiben, die vom Hersteller nicht weiter auf den neuesten Stand gebracht werden, sehe ich als fahrlässig an, da sie ernsthafte Sicherheitslücken schaffen können. Diese können von Hackern zur Spionage verwendet werden, um in den internen Bereich eines Unternehmens vorzudringen und so grossen Schaden anzurichten.

Wer eigene Software Lösungen betreibt begibt sich in eine verantwortungsvolle Position und sollte sich immer wieder ein klares Bewusstsein schaffen, was dies im Moment der Betrachtung für das Unternehmen bedeutet.

Aus Sicht der Security gilt, dass jeder Micro Service für seine eigene Security verantwortlich sein soll. Enstprechend sollen speziell die Endpunkte für die Interaktion an den Schnittstellen abgesichert werden. Speziell mit Ausblick auf die Serverles Services Architekturen sollte jeder Micro Service so programmiert werden, dass er immer im freien Internet abgesichert ist, auch wenn er hinter einer Firewall zum Einsatz kommt.

Dies ist nicht immer einfach zu bewerkstelligen und es bleibt zu bemerken, dass es die volle Sicherheit nicht gibt. Moderne Programmiersprachen verwenden diverse Module und viele dieser Module weisen Security Leaks auf, die dynamisch von den Entwicklerteams der Herstellerseite geschlossen werden. Leider haben die Entwickler nur begrenzt Einfluss auf diese, so dass der Erfolg von Hacker Attacken nicht ausgeschlossen werden kann.

Auch hier übernimmt die Software Architektur eine zentrale Rolle in der Abklärung des zum Einsatz kommenden Sicherheits Levels.

DevOps

Development und Operations wachsen immer näher zusammen und Software Architekten sollten mit beiden Bereichen in nahem Kontakt stehen.

Bei vielen Architektur Entscheidungen sind Informationen aus beiden Bereichen nötig und speziell bei serverlosen Architekturen bieten die Anbieter der Cloud Infrastrukuren zahlreiche Services an, die nicht mehr neu programmiert werden müssen. Das DevOps Team weiss zu diesen meist besser Bescheid als die Entwickler und ein Austausch zwischen diesen Bereichen kann unnötige Kosten verhindern.

Server Basierende Infrastrukur

In der alten Welt werden dedizierte Server Infrastrukturen für die Software gebaut, wobei sich diese in den letzten Jahren von eigener Hardware in Datencenter verlagerten, wo Virtual Machines VM’s gemietet werden. In Datencentern werden grosse Mengen an Computern zusammen zu Clustern verbunden, auf denen ein spezielles Betriebssystem läuft. Dieses ermöglicht die dynamische Aufteilung der Leistung und der Speicherkapazität von Clustern auf einzelne VM’s.

Auch wenn Datencenter durch die Clusterlösungen mehr Möglichkeiten der Skalierung bieten, sind diese nach wie vor an einen Ort und eine maximale Hardware Zusammensetzung gebunden.

Ich sehe nicht, dass die Hosting Provider, die diese Datencenter betreiben in naher Zukunft mit den grossen Anbietern der Cloud Infrastrukturen mithalten können.

Serverless Services

Serverles Infrastrucures sind wirkliche Cloud Infrastrukturen wie Amazon AWS, Microsoft Azure, Google Cloud, Alibaba Cloud und einige weitere.

Diese Infrastrukturen sind nicht an physische Hardware gebunden und können verteilt auf der ganzen Welt skaliert werden. Es handelt sich um einen neuen Ansatz, der von Amazon 2006 vorgestellt wurde und sich immer mehr durchsetzt.

Klarer Marktführer ist nach wie vor Amazon AWS doch bringt jeder der grossen Anbieter spezielle Dienstleistungen auf den Markt.

Was diese neue Form der Computer Power charakterisiert, ist, dass Rechenleistung und Dienste dynamisch von den Kunden eingekauft werden können. Die klassischen Datencenter können mit den Pricings der Tech Giganten nicht mithalten. Google stellt in seinen Cloud Diensten auch eine Infrastruktur für AI und Machine Learning zur Verfügung. Möglicherweise werden analog in Zukunft auch Dienste auf der Quant Infrastructure von Google zugänglich gemacht.

Auch wenn verschiedene Konzepte wie bewährte relationale Datenbanken e.g. MySql auf den Cloud Infrastrukturen installiert werden können, sollte trotzdem in erster Linie mit den zur Verfügung gestellten Tools der Plattform nach Lösungen gesucht werden.

Migration von veralteten Lösungen

Software Lösungen veralten!

Aus meiner Sicht gilt es zwischen 2 Szenarien abzuwägen:

• Migration in Schritten

Wenn eine Migration in Schritten geplant wird, ist es sinnvoll zwischen der Bereitstellung der Infrastruktur und der wirklichen Entwicklung der Applikation zu unterscheiden.

Teile können gleichzeitig in beiden Bereichen vorbereitet werden, um den Entwicklungsprozess zu beschleunigen.

Es bleibt zu beachten, dass neue Micro Services nicht in Abhängigkeit zum bestehenden System deployed werden, um klar trennen zu können.

• Vollständiges neu Programmieren

Ich ziehe bei der Ablösung von veralteten Lösungen das Neuprogrammieren vor. Damit kann sicher gestellt werden, dass alte Paradigmen und Ansätze nicht überleben und nicht weiterhin im neuen System herumgeistern.

Die Diskussion der anfallenden Kosten steht immer im Raum, doch speziell wenn die Entwickler, die das System ursprünglich entworfen haben nicht mehr da sind, geht viel Zeit im Wissensaufbau um die Programmlogik verloren. Gleichwohl ist nach mindestens 3 Jahren Betrieb zu erwarten, dass vollkommen neue Arten zu programmieren sich in der Zwischenzeit etablierten und Framework Trends sich stark verschoben haben.

Fazit und Anmerkungen

Die Entwicklung von Micro Services auf Serverles Services Infrastrukturen hat gerade erst begonnen. Trotzdem ist sie wohl nicht mehr aufzuhalten und man tut gut daran, auf den fahrenden Zug aufzuspringen!

Der Artikel basiert grösstenteils auf meinen eigenen Erfahrungen in der Entwicklung und der intensiven Auseinandersetzung mit der theoretischen Seite durch verschiedene online Quellen.

Für detaillierte Ausführungen zu Micro Services empfehle ich den Einstieg über den Youtube Kanal von Mark Richards.