Der Stand der Dinge
Microservices, Nanoservices, Serverless, Big Ball of Mud – oder doch Macroservices?
Warum es nicht um „entweder oder”,
sondern um „sowohl als auch” geht.
Microservices - Wie & Wann?
Reicht ein neues Framework oder steckt mehr dahinter?
Why Macro?
Unter welchen Umständen sind Macroservices sinnvoll?
Why Micro?
Welche Vorteile haben Services mit einem möglichst kleinen Schnitt?
Microfrontends
Dem Frontend-Monolithen den Kampf ansagen!
Size Matters - Ein Interview
Wenn klein zu klein und groß zu groß ist
mit Lars Winterhalter und Lukas Pradel
Alter Wein in neuen Schläuchen?
Eines der wichtigsten Architekturprinzipien lautet „Teile und Herrsche!“. Es geht um die Frage:
Wie können wir eine Anwendung in Form von (möglichst) unabhängigen Teil-Anwendungen realisieren?
Im Lauf der Jahre wurde dieses Thema unter Bezeichnungen wie „Komponentenbasierte Softwareentwicklung“, „Service-orientierte Architektur“ und „Microservices“ umgesetzt. Letztendlich sind dies verschiedene Ausprägungen unseres oben genannten Prinzips. Der Begriff „Macroservices“ stellt einen bewussten Kontrast zu „Microservices“ dar und will darauf hinweisen, dass in einer guten Unterteilung die Services nicht so „micro“ sind, wie der Begriff suggeriert. Man könnte auch sagen, wir sind auf der Suche nach „Right-sized services“.
Wir propagieren hier also kein Blueprint-Konzept für Macroservices. Wir möchten Ideen, Überlegungen und Heuristiken zu unterschiedlichsten Gesichtspunkten guten Service-Designs an die Hand geben. In Form von Artikeln, Diskussionen, Webinaren – fundiert, ausgewogen und regelmäßig aktualisiert.