text: Software ist mittlerweile in praktisch allen Wirtschaftsbereichen zentraler Teil der Wertschöpfung. Also sollte Software auch Innovationen ermöglichen. Die Frage ist, wie Software dazu beschaffen sein muss.
  Die Implementierung von Microservices stellt im Vergleich zu monolithischen Anwendungen Entwickler vor einige Herausforderungen. Spezialisierte Technologien wie Spring Boot unterstützen die Umsetzung von Microservices und machen so den Projekten das Leben leichter.
  Bereits in 1 haben Stefan Tilkov und ich beschrieben, dass es sinnvoll ist, große Systeme in Teilsysteme zu zerlegen, und erstmals erläutert, was wir im Allgemeinen unter Mikro- und Makro-Architektur verstehen. Aus verschiedenen Vorträgen, Experimenten und Projekten kristallisierte sich irgendwann der Name für solche Teilsysteme in einem komplexen Gesamtsystem heraus: Self-Contained Systems.
  Beim Deployment von Microservices verschwimmen die Grenzen zwischen Mikro- und Makroarchitektur. Während das Team die Mikroarchitektur für jeden Service individuell entscheiden kann, muss man sich bei Makroarchitektur-Themen mit anderen Teams zusammensetzen, um die beste Lösung für Themen zu finden, die mehrere Services betreffen. In diesem Artikel wollen wir uns ansehen, welche Entscheidungen ein Team für sich treffen kann und welche mit anderen Teams abgestimmt werden müssen. Zu diesem Zweck möchte ich beispielhaft den Lernprozess beschreiben, den ich in Teams erleben durfte, die “einfach mal” mit Microservices angefangen haben.
  Microservices 1 dienen eigentlich „nur“ zur Modularisierung von Software. Für Modularisierung gibt es aber unzählige Ansätze: Klassen, Packages oder JARs dienen in der Java-Welt beispielsweise diesem Ziel. Nur so können auch große Projekte in kleine Einheiten aufgeteilt werden und bleiben dadurch erweiterbar und wartbar.
  Der ursprüngliche Artikel 1 hat mehrere Gründe aufgeführt, warum Application Server keine zeitgemäße Plattform mehr darstellen. Kurz zusammengefasst:
  Interview mit Stefan Tilkov: “Ich bin keinesfalls der Meinung, dass man immer Microservices einsetzen sollte”
  Heutzutage gewinnt man leicht den Eindruck, dass es für moderne Webanwendungen nur einen einzig wahren Architekturansatz gibt: REST und Single-Page-Anwendungen (SPAs). Doch ist alles, was REST genannt wird, wirklich REST? Sind REST und SPAs immer die beste Lösung? Um diese Fragen beantworten zu können, sollte man sich anschauen, was REST eigentlich ist, wofür es gedacht ist und ob es möglicherweise auch Alternativen zu SPAs gibt; insbesondere mit dem Blick auf Nachhaltigkeit, also Wartbarkeit und Erweiterbarkeit.