Microservice Architekturen bestimmen die Zukunft der Softwareentwicklung

Jetzt den ELCA-Newsletter abonnieren Von Microservice Architektur spricht man, wenn eine Applikation nicht mehr als einzelner Monolith entwickelt wird, sondern als Folge in sich abgeschlossener, ineinander greifender Teile oder Services. Diese „Einzelteile“, die oft um Geschäftsvorgänge herum gebaut sind und von der Funktionalität her zusammengehören, werden gebündelt und über definierte Schnittstellen dem Gesamtsystem zur Verfügung gestellt bzw. implementiert. Die Services funktionieren als Teil der verteilten Applikation, in ihren eigenen Prozessen und kommunizieren untereinander. Fällt einer dieser Services aus oder wird er upgedatet, beeinträchtigt dies nicht gezwungenermassen die Funktionsfähigkeit des Gesamtsystems. Diese Art der Software(weiter)entwicklung wird höchstwahrscheinlich die Branche in den nächsten Jahren ziemlich verändern. Aber warum? Warum wird Microservice Architecture die Branche verändern? Das Mooresche Gesetz, 1965 bekannt gemacht, hat bis in die Gegenwart Bestand. Das bedeutete bisher auch, dass man sich bei der Prozessorleistung darauf verlassen konnte: „ Die CPU Leistungssteigerung wird’s schon richten“. Für die Softwareentwickler eigentlich eine schöne Sache: man musste das Rad nicht jedes Mal grundsätzlich neu erfinden, keine neuen Wege zu bekannten Zielen entdecken oder grundsätzlich neue Ansätze wählen. Aus einem kleinen Monolithen, betrieben auf einem kleinen Rechner wurde so eben ein grosser Monolith, betrieben auf einem grossen Rechner. Die Monolithen können inzwischen aber so komplex sein, dass Updates schwerfällig werden oder im Fehlerfall potentiell die ganze Anwendung ausfällt. Zudem ist der Betrieb grosser monolithischer Systeme kostenintensiv – sie brauchen leistungsstarke Rechner, und die sind auch heutzutage noch teuer. Hinzu kommt ein anderer Effekt: in den letzten 10 Jahren sind Unternehmen mit Millionen von Nutzern entstanden – z.B. Amazon, Google oder Facebook. Die bestehenden Nutzer müssen verwaltet werden, täglich kamen und kommen weitere hinzu. Alle erwarten Services rund um die Uhr und konstant schnelle Reaktionszeiten. Auch das zu verarbeitende Datenvolumen explodierte (und tut es immer noch, das Datenwachstum ist ungebrochen). Unternehmen, die einer derartigen Situation gegenüberstehen, bleibt gar nichts anderes übrig, als Wege zu finden, die Software weiter zu entwickeln und die Systeme zu skalieren, ohne ihr Geschäftsmodell lahmlegen zu müssen. Die ihnen dabei weltweit potentiell entgehenden Gewinne sind schon ein kräftiger Anreiz, einen Ausweg zu suchen. Ein Scheitern hätte derartige Geschäftsmodelle wahrscheinlich zum Erliegen gebracht – das durfte auf keinen Fall passieren. Was also tun, wenn der gebaute Monolith auf immer tönernen Füssen steht und gleichzeitig der Druck durch wachsende Kundenzahlen zunimmt? Die Antwort war so einfach wie genial: Unterteilung der Applikation in logisch/funktional zusammenhängende Teile oder Services, die autonom skaliert werden können – ganz nach Bedarf. Was können wir von Google & Co. lernen? Jetzt hat nicht jedes Unternehmen die gleichen Probleme wie ein internationaler Gigant – jedes kann aber von den Entwicklungen, die diese mit grossen Einsätzen vorangetrieben haben, profitieren. Dank ihrer Pionierarbeit und der daraus resultierenden Technologien, Muster und Werkzeuge können verteilte Softwareapplikationen heute auch in kleinerem Massstab effizienter entwickelt werden. Hier geht es dann eher um Digitalisierung, Flexibilität oder Hochverfügbarkeit in einer Welt, die nicht mehr schläft. Auch, wenn die grossen digitalen Unternehmen einen immensen Einfluss auf diese Entwicklung haben – ohne die Cloud gäbe es sie nicht; ihre Geschäftsmodelle sind durch die Cloud bedingt und treiben sie gleichzeitig voran – eine sehr enge Symbiose. Und die Unternehmen haben schnell begriffen, dass ihre Lösungen, aus der eigenen Not geboren, über die Cloud beliebig skalierbar sind. Kleine Teams konnten plötzlich Software entwickeln und warten, die insgesamt einen hohen Komplexitätsgrad hat, durch die „Unterteilung“ in einzelne Services aber beherrschbar bleibt – der economy of scale waren und sind fast keine Grenzen mehr gesetzt. Ein weiterer wichtiger Aspekt, der der Microservice Architektur mit zum Durchbruch verholfen hat und durch diese getrieben wurde, kommt aus dem Bereich der Datenverarbeitung. Gab es schon so viel verfügbare, verteilte Hardwarekapazität, dann sollte die Datenverarbeitung auch auf allen Maschinen erfolgen können - parallele Datenverarbeitung und Software, die damit umgehen konnte, waren ein Muss. Die klassische Software genügte hier oft nicht. Andere Ansätze (z.B. Stream-Processing) und Werkzeuge (z.B.: noSQL Datenbanken statt klassischen RDBMS Datenbanken) mussten gefunden werden, sollten Ansätze und Werkzeuge selbst mit der Microservice Architektur mithalten können. Software Container unterstützen die Verbreitung Wie aber werden einzelne Microservices einer verteilten Applikation aufeinander abgestimmt, integriert und verteilt? Software Container etablierten sich und boten die Möglichkeit, die Laufzeitumgebung für die Services zu definieren; durch die einfache Replizierbarkeit legten sie die Grundlagen für eine ebensolch einfache Skalierbarkeit – für Google & Co wahrscheinlich der einzig gangbare Weg. In der Entwicklung verteilter Applikationen hat sich auch an anderen Stellen eine Menge getan: Umgebungen wie Spring Cloud, Akka oder Vert.X erleichtern Softwareentwicklern die Arbeit, Hazelcast oder Redis bieten verteilte Chaches, die ebenfalls immer üblicher werden. Alle diese Innovationen sind die Väter und Mütter der sich immer stärker ausbreitenden Microservice Architektur. Dabei spielen nicht nur Aspekte der Skalierbarkeit oder Wartung, sondern auch der Fortsetzung der Entwicklung von Applikationen eine Rolle – oder einfach die Tatsache, dass es heute Werkzeuge gibt, um mit dieser Komplexität umgehen zu können. Das Internet der Dinge (IoT) und die daraus resultierenden Datenmengen werden verteilte Architekturen weiter fördern. Aber es gibt auch Opfer dieser Entwicklung. Eines wird der gute alte Application Server sein – sein Grundkonzept der Zentralisierung von Applikationen hat sich überholt, die Industrie entwickelt sich heute in die entgegengesetzte Richtung. Applikationskomponenten, die heute in Containern gepackt und verwaltet werden, sind autonome Einheiten. Unternehmen wie ELCA beziehen diese Entwicklungen schon heute in ihr Konzepte und Strategien ein. Wir prüfen in Projekten jeweils genau, welche Lösung adäquat ist: überwiegen die Vorteile der Gesamtlösung die gesteigerte Komplexität oder nicht? So können wir dem Kunden immer die Lösung vorschlagen, die für seine Situation die richtige ist – weder überdimensioniert, noch zu klein gedacht, weder unbedingt und zwingend mit neuesten Ansätzen, noch Festhalten am Überholten.