Um den Anforderungen in einem sich schnell entwickelnden Marktumfeld gerecht zu werden und die Erwartungshaltung verschiedener Nutzergruppen erfüllen zu können, steigt der Bedarf an der Umsetzung komplexer Business-Anwendungen mithilfe moderner Webtechnologien stetig.
Genau aus diesem Grund ist auch das Interesse an Microservices in den letzten Jahren stark gewachsen. Sie helfen dabei, komplexe Anwendungen in kleinere beherrschbare Komponenten zu zerlegen. Dies ermöglicht eine stärkere Separation und damit ein agileres Vorgehen.
Mehr Flexibilität durch Microservices für Web-Frontends
Während im Backend Microservices bereits seit Jahren zum Standardinventar gehören, um die Parallelisierung der Entwicklung durch mehrere Teams, Diversität in den eingesetzten Technologien und die flexible Verwendung von Anwendungsbestandteilen zu erlauben, verfolgen Web-Frontends oft noch einen monolithischen Ansatz.
Aufgrund der steigenden Anwendungskomplexität, dem Wunsch nach der Integration verschiedener Anwendungsfälle in eine einzelne Endnutzerapplikation und wegen des schnelllebigen Technologie-Stacks empfiehlt sich auch im Frontend eine ähnliche Herangehensweise wie im Backend.
Abbildung 1: Aufteilung des Frontends in unterschiedliche Domänen und Teams
Doch worin liegt der große Vorteil der sogenannten Microfrontends? Den meisten Projekten, in denen ein komplexes Frontend entwickelt wird, liegt auch ein komplexes Backend zugrunde, wodurch ein sehr heterogenes Projekt-Setup entsteht. Aus diesem Grund wird die Arbeit durch nur ein Entwicklungsteam immer schwieriger und oft auf verschiedene Teams aufgeteilt. Ein monolithischer Ansatz der Frontend-Entwicklung wirkt sich oft, aufgrund der technischen Komplexität und Abhängigkeiten, negativ auf die Wartbarkeit des Systems aus. Microfrontends erlauben nun auch in der Webentwicklung eine Parallelisierung und Diversität, die im Backend schon lange zum Standard gehört.
Der Ansatz zielt darauf ab, das Frontend in unterschiedliche Domänen zu trennen. So kann dieses auch durch verschiedene Teams und mit unterschiedlichen technologischen Ansätzen entwickelt werden. Bei Erweiterungen oder Änderungen muss nicht das gesamte Frontend neu deployt werden, sondern es können einzelne Teile ausgetauscht werden. Ziel ist es, dass der User das Gefühl von nur einer performanten Anwendung bekommt, auch wenn dieses technisch auf verschiedenen Systemen aufbaut.
Vortrag zum Online-Campus
In unserem Vortrag vom ersten Online-Campus der ZEISS Digital Innovation sprechen wir darüber, für wen sich der Monolith vielleicht immer noch lohnt und wer sich eine Architektur basierend auf Microfrontends vielleicht genauer anschauen sollte. Dabei gehen wir auf unterschiedlich komplexe Projekt-Setups und deren Vor- und Nachteile ein. Wir zeigen auch, welche Webtechnologien es gibt, welche die passende Technologie für das eigene Projekt ist und welche Möglichkeiten der Umsetzung es gibt.
Auch dieses Jahr war die Saxonia Systems AG (seit 03/2020 ZEISS Digital Innovation) wieder auf der Developer Week in Nürnberg vertreten. Mit insgesamt fünf Vorträgen und einer Abendveranstaltung widmeten wir uns Themen wie „agiles Testen“, „Testautomatisierung“ und „agilen Architekturen“. Zeitgleich haben wir die Chance genutzt, um ein aktuelles Meinungsbild der Besucher zu erhalten.
In diesem Zusammenhang haben von den mehr als 1600 Besuchern 131 Personen auf unsere Fragen geantwortet. Die Umfrage ist demnach nicht repräsentativ für die gesamte Branche, gibt aber eine gewisse Aussicht und Einschätzung innerhalb der Microsoft Community.
Unsere erste Frage lautete: „Entwickeln Sie Endkunden- oder Businesssoftware?“. Die Mehrheit der Befragten gab an, dass sie an Software für Geschäftskunden arbeitet.
Abbildung 1: Welche Art von Software entwickeln Sie?
Die nächste Frage lautete: „Wie lange besteht die Software, an der Sie arbeiten?“. Die Umfrage brachte folgende Ergebnisse:
Abbildung 2: Alter von Softwaresystemen
Anhand des Ergebnisses sieht man, dass bestehende Software meist bis zu 20 Jahre alt ist. 68% der Systeme besitzen ein maximales Alter von bis zu 10 Jahren. Dies kann zum einen damit zusammen hängen, dass Version 2.0 von .Net, welche den breiten Durchbruch einläutete, erst 2006 veröffentlicht wurde und somit das Gros der heute noch genutzten .Net Anwendungen kaum älter sein kann. Auch wenn nicht danach gefragt wurde, so zeigt sich in Gesprächen, dass viele der noch älteren Anwendungen ehemalige C++ Desktopanwendungen auf Basis von MFC sind, die nach und nach zu .Net migriert wurden.
Damit sind wir auch bei der nächsten Frage: Welche Art von Technologien verwenden Sie eher?
Abbildung 3: Welche Technologien verwenden Sie eher?
Hierbei ging es insbesondere darum, zwei Vermutungen auf den Grund zu gehen. Erstens sind Webanwendungen im Durchschnitt jünger als Desktopanwendungen und zweitens finden Desktopanwendungen mehr Einsatz im Geschäftskundenumfeld.
Auch wenn nur 33 der 48 befragten Webentwickler diese Frage beantworteten, so zeigt sich zumindest ein klarer Trend zu jüngerer Software im Web. Dies lässt sich natürlich leicht darauf zurückführen, dass die Nutzung des Webs vor 20 Jahren nicht ansatzweise dem heutigen Stand entsprach und somit auch nicht annähernd die Bedeutung innerhalb von Geschäftsprozessen hatte.
Abbildung 4: Alter von Webapplikationen
Um Vermutung zwei zu untersuchen, müssen wir nun die bisherigen Zahlen gegenüberstellen. Hierbei kann man, allein schon wegen der geringen Stichprobe, nicht von einem eindeutigen Trend sprechen. Wenig überraschend ist natürlich, dass man im Geschäftskundenumfeld eine Art Mischbetrieb eher verfolgt, als bei reiner Endkundensoftware. Ansonsten sind die Zahlen so nah beieinander, dass der Trend zumindest für Microsoft basierte Anwendungen nicht nachzuweisen ist.
Abbildung 5: Gegenüberstellung des Technologie-Stacks bei Business-Software und Endkunden-Software
Der weite Einsatz von Desktoptechnologien ist auch insofern verständlich, da Microsoft basierte Technologien ihre Ursprünge auf dem Desktop haben. Lange Zeit galt es daher als gesetzt, dass man Desktopanwendungen am besten mit Microsoft Tools entwickelt. Das Web wurde erst einige Jahre später in Angriff genommen und hier ist Microsofts Konkurrenz mit Java, Ruby oder PHP auch ungleich größer.
Wenn das Web nun aber so bedeutsam ist und die Desktopanwendungen vergleichbar alt sind, dann liegt der Schluss nahe, dass zukünftig auch vom Desktop in das Web migriert werden soll. Auf diesen Gedankengang zielte dann auch unsere nächste Frage ab.
Abbildung 6: Ist es geplant Desktoptechnologien auf Webtechnologien zu migrieren?
Eine so klare Aussage hat uns stark überrascht. Natürlich ist der Trend ins Web in aller Munde, immerhin schwächelt der Absatz des Desktops seit Jahren. Wenn nun aber bei 46 von 96 Entwicklern zukünftig die Desktopclients durch Webclients ersetzt werden sollen, ist dies ein mehr als deutliches Zeichen. Hier wird auch offensichtlich, wie wichtig Microsofts Trend zur Cloudplattform Azure ist, da die Akzeptanz ihres früheren Stammgeschäfts dramatisch sinkt.
Vergleichen wir nun noch die eingesetzten Sprachen, welche uns eventuell einen zukünftigen Trend aufzeigen könnten.
Abbildung 7: Eingesetzte Sprachen im aktuellen Hauptprojekt
Deutlich an erster Stelle und mit Nennung durch fast alle Teilnehmer ist die Sprache C#. Dies wundert nicht, wenn man die Bedeutung der Sprache für das Ökosystem kennt. Viel interessanter ist das schlechte Abschneiden von Visual Basic im Vergleich. Dies wird von noch weniger Personen eingesetzt als C++ und Java. Wobei deren geringe Nennung natürlich damit zu tun hat, dass es sich bei der Developer Week um eine Konferenz handelt, die einen sehr großen Anteil von Microsoftthemen besitzt. Auch der Einsatz von Javascript ist wenig verwunderlich, wohingegen die deutliche Nennung von Type Script als ein Ausblick auf dessen zukünftige Bedeutung darstellen könnte.
Hier könnten wir etwas in die Glaskugel schauen, denn aus den bisherigen Auswertungen lässt sich durchaus folgendes Szenario konstruieren: Während reine Desktopclients an Bedeutung verlieren, ziehen Webtechnologien mit Angular und der Laufzeitumgebung Electron durchaus auch auf dem Desktop ein. Angular wiederum bietet vieles von dem, was WPF einst einzigartig gemacht hat und weniger von dem, wodurch sich AngularJS 1 für Desktopentwickler doch vergleichsweise unangenehm angefühlt hat. Gerade auch mit der nahtlosen Integration von Type Script gewinnt Angular viele der Sicherheitsmechanismen, die skalierbare Großanwendungen benötigen. Es könnte also durchaus passieren, dass so mancher Desktop Client seinen Weg über das Web zurück auf den Desktop schafft, nur in neuem Gewand.
Abbildung 8: Gegenüberstellungen der Sprachen bei Business-Software und Endkunden-Software
Abschließend betrachten wir noch den Einsatz der verwendeten Frameworks. Auch hier muss man Vorsicht walten lassen, da die geringe Teilnehmerzahl natürlich eine deutliche Unschärfe bedeuten kann.
Abbildung 9: Eingesetzte Frameworks im Hauptprojekt
Nichtsdestotrotz ist dabei interessant, wie häufig Angular 2 bereits in Hauptprojekten eingesetzt wird und dass diese Zahl fast den 17 Personen entspricht, die Typescript als Sprache angegeben haben. Dem gegenüber haben im Web die ASP.Net WebForms im Verhältnis zu ASP.Net MVC weit deutlicher verloren, als es die Windows Forms gegenüber der WPF getan haben.
Auch hier zeigten sich in den Gesprächen auf der Konferenz einige deutliche Einschätzungen: WebFroms haben gegenüber MVC keine Vorteile, wohingegen WinForms gegenüber WPF eine geringere Lernkurve und eine höhere Performanz aufweisen. Dem gegenüber bietet die WPF wiederum ein schwerer zu meisterndes Architekturmuster, welches auf Dauer aber besser wartbare Software erlaubt. Darüber hinaus kann sie weitaus einfacher gestylt werden und ermöglicht eine bessere Parallelisierung innerhalb des Teams.
Genau hier könnte sich ein Hindernis für das Glaskugel-Szenario herauskristallisieren, denn gerade auch durch die Einbindung von Win32 Applikationen in die Universal App Plattform und durch den hohen Reifegrad der Desktopapplikationen, weisen sie Vorteile gegenüber den schnelllebigen Webtechnologien auf, welche in langfristig orientierten Umgebungen nicht einfach außer Acht gelassen werden können. Hinzu kommt noch, dass Angular 2 ebenfalls eine sehr steile Lernkurve aufweist, die erst einmal gemeistert werden möchte.
