Keynote zur Eröffnung der BASTA! 2017

Microservices – zu klein und zu gut, um nur ein Hype zu sein
Keine Kommentare

Microservices gehören im IT-Buzzword-Bingo zu den Neuzugängen der letzten Jahre, und sie beweisen dabei eine ihrer Qualitäten: sie stehen nicht für eins, sondern vieles, manchmal schon fast für alles. Microservices sind ein fundamentaler Wandel. Sie haben eine strategische Komponente, die auf die Architektur, den Programmierstil, die Arbeitskultur, das Geschäftsmodell und die Technologie Auswirkungen hat.

In der Keynote zur Eröffnung der BASTA! 2017 haben Oliver Sturm (DevExpress), Rainer Stropek (software architects), Christian Weyer (Thinktecture AG) und Mirko Schrempp, BASTA! Program Chair, diese vielen Facetten von Microservices diskutiert, um den Blick für die Möglichkeiten und Chancen zu öffnen.

Microservices sind ein Buzzword Buzzword, denn DevOps, Container, Cloud, Plattform- und Sprachunabhängigkeit, Resilienz, Austauschbarkeit, Agilität, Serverless, bimodale IT, Continuous Delivery, APIs fallen gleich mit aus der Bingotrommel. Der Titel der Keynote „Microservices – zu klein und zu gut, um nur ein Hype zu sein“ deutet es schon an, denn das Fragezeichen fehlt aus gutem Grund: Microservices sind kein Hype! Die Keynote räumt mit den üblichen Missverständnissen rund um Microservices auf, skizziert typische Architekturpatterns, Technologieoptionen, Auswirkungen auf Organisationen und den Businessbezug.

Neue Strukturen auf allen Ebenen

Microservices treiben den Trend zur Modularisierung und Flexibilität auf die Spitze, denn für Microservices kauft man keinen kompletten Technologiestack, den man auspackt, auf den Server setzt und dann läuft alles. Microservices bilden ihre Form und Struktur über kleinteilige Dienste, die austauschbar sein sollten und in den Sprachen geschrieben werden können, die einem Team zur Verfügung stehen. Darin waren sich alle Keynote-Sprecher einig, ob nun C#, Java, Python, JavaScript oder irgendeine andere Sprache, jede ist dafür geeignet für einen Microservice genutzt zu werden. Rainer Stropek ist dabei der Auffassung, dass dies nicht nur ein technischer Vorteil ist, sondern angesichts des Arbeitsmarkts in der IT auch ein wirtschaftlicher. Wer für ein Projekt keine C#-Entwickler auf dem Markt findet, kann dann eben mit einem Python-Team das Ziel erreichen. Spätestens hier sieht man, dass Microservices nicht nur auf die Struktur von Softwarelösungen und die Technologiewahl Einfluss haben, sondern auch auf die Organisation von Teams und sogar Unternehmen. Teams werden in die Lage versetzt autonome Entscheidungen darüber zu fällen, welche Technologie eingesetzt wird, um das gewünschte Ziel zu erreichen. Dazu muss allerdings das Management Teile seiner Kompetenz abgeben und auf das Team übertragen.

Der Monolith ist nicht am Ende

Damit einzelne oder unzählige Microservices zusammenspielen können, ist von zentraler Bedeutung, dass Architekturüberlegungen immer mitspielen. Und das muss auf allen Eben passieren, denn für sich alleine hat ein Microservice nur begrenzten Wert. Erst im Zusammenspiel werden komplexere Geschäftsprobleme gelöst. Allerdings gibt es dabei keinen Zentralismus, denn dieser ist nicht schnell genug, das haben spätestens alle SOA-Experimente gezeigt. Microservices erlauben durch ihre dezentrale Struktur, unterschiedliche Innovationsgeschwindigkeiten in einer Technologiewelt, die sich immer schneller dreht. Sie sind damit aber nicht automatisch das Ende der Softwaremonolithen. Im Gegenteil, diese werden für die Zukunft anschlussfähig, und spätestens hier kommt die Cloud ins Spiel.

Moderne Cloud-Lösungen sind keine Monolithen mehr, in denen zwar alles harmonisch zusammenpasst, die man aber nur ganz oder gar nicht weiterentwickeln kann. Was, wenn sich ein Teil einer Softwarelösung schneller verändert als andere Teile? Wie soll ein Team rascher auf .NET Core umsteigen können, wenn die anderen aus irgendeinem Grund noch für einige Zeit im .NET Framework festhängen? Damit solche Probleme gelöst werden können, braucht man kleiner strukturierte Softwarearchitekturen. Microservices sind das Architekturmuster dafür. Viele relativ kleine Logikbausteine (z. B. Rechenlogiken, Workflows, Services für Datenzugriff etc.) werden von autonomen Teams entwickelt und betrieben. Die Microservices tauschen Daten und Events über plattformunabhängige RESTful Web-APIs, WebHooks oder über eine Messaging-Infrastruktur aus. Genau hier sieht Christian Weyer die Chance, für ISVs ihre Zukunft zu sichern, vor allem, wenn sie mit Start-ups in Konkurrenz stehen, die genau eine Sache gut oder besser können, die für den ISV wichtig ist. Sie können ihre Monolithen fachlich aufteilen, ggf. erst über APIs, und dann sauber aufspalten und in kleinere Bereiche einteilen und zur Verfügung stellen.

Kostenlos: Docker mit .NET auf einen Blick

Container unter Linux und Windows nutzen? Unser Cheatsheet zeigt Ihnen wie Sie: Container starten, analysieren und Docker.DotNet (in C#) verwenden. Jetzt kostenlos herunterladen!

Download for free

Dabei ist dann nicht wichtig, ob mit AWS, Azure, Docker oder sogar Serverless gearbeitet wird. Wichtiger ist, dass die gekapselten und isolierten Dienste sauber und sicher kommunizieren. Was das heißt, zeigt das Serverless-Konzept sehr deutlich: Die Idee von Serverless Computing ist es, Dienste anzubieten, ohne einen einzigen Gedanken an Maschinen, Container, Betriebssysteme, Softwareversionen oder Skalierung der Instanzen – horizontal wie vertikal – zu verschwenden. Und das ist auch das Versprechen der Plattformbetreiber: „100% managed and operated“. Serverless Computing bietet also die Umgebung, um sich nahezu ausschließlich auf die Implementierung von Businesslogik konzentrieren zu können. Dabei muss diese in sinnvolle kleine und autonome Teile zerlegt werden. Jeder Teil wird als eine separate Funktion zur Verfügung gestellt, ausgeführt und skaliert.

Das Große im Kleinen

Microservices ist also ein großes Wort, auch wenn es so klein klingt. Wie klein die sein sollen, ist eine Frage, die auch oft und gern gestellt wird und auf die es keine pauschale Antwort gibt. Microservices setzen auf Unabhängigkeit zwischen den Modulen eines Softwaresystems. Die Aufgaben eines Diensts sollen kurz und bündig definierbar sein; meistens denken wir dabei an eine einzelne Funktion mit einem API. Daraus ergeben sich weitreichende Freiheiten: Plattform, Programmiersprache und Hilfs-Libraries können womöglich pro Dienst neu definiert werden. Microservices stellen ein mächtiges und vielschichtiges Pattern dar, von dem beinahe jedes Anwendungssystem profitieren kann. Damit stellen sich der IT und den Unternehmen neue Aufgaben. Der vertraute Monolith wird anschlussfähig an die Zukunft, aber man sollte den Monolithen nicht mehr denken, wenn er nicht nötig ist. Architektur, Organisation und Fachlichkeit greifen Hand in Hand bzw. Dienst in Dienst und führen nicht mehr zu einem mächtigen Produkt aus einem Guss, sondern einem mächtigeren WIE aus einem Guss. Die Keynote zur Eröffnung der BASTA! 2017 zeigt dazu das große Bild, viele Sessions und Workshops der BASTA!-Konferenzen in den nächsten Jahren werden die Details dazu vorstellen.

Spannende und Informative Sessions zum Thema finden Sie im Microservices & APIs Track der BASTA!

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -