Die Debatte zwischen Microservices und monolithischer Architektur ist so alt wie die Softwareentwicklung selbst -- zumindest fühlt es sich so an. In Wahrheit sind Microservices ein relativ junges Konzept, das erst durch Cloud-Computing und Container-Technologien praktikabel geworden ist. Doch welche Architektur ist die richtige für Ihr Projekt? Die Antwort lautet, wie so oft in der IT: Es kommt darauf an.
Ein Monolith ist nicht per se schlecht. Für kleine bis mittlere Anwendungen mit einem überschaubaren Team bietet eine monolithische Architektur erhebliche Vorteile: einfacheres Debugging, einfachere Deployments, keine Netzwerk-Latenz zwischen Services und geringere operationale Komplexität. Viele erfolgreiche Unternehmen sind mit Monolithen gestartet und haben erst später, als die Anwendung gewachsen ist, zu Microservices migriert. Shopify beispielsweise betreibt einen der größten Ruby-on-Rails-Monolithen der Welt.
Microservices entfalten ihre Stärken vor allem bei großen, komplexen Anwendungen mit mehreren Entwicklungsteams. Jedes Team kann seinen Service unabhängig entwickeln, testen und deployen. Unterschiedliche Services können unterschiedliche Technologien verwenden. Die Skalierung erfolgt gezielt für die Services, die es brauchen. Allerdings bringt diese Architektur auch Herausforderungen mit sich: verteilte Transaktionen, Service-Discovery, Netzwerk-Resilienz und ein deutlich höherer operativer Aufwand.
Bei bionic code verfolgen wir einen pragmatischen Ansatz. Wir beginnen oft mit einem gut strukturierten Monolithen, der bereits in Module aufgeteilt ist. Diese Module können später, wenn der Bedarf entsteht, als eigenständige Services herausgelöst werden. Dieser Ansatz -- manchmal als "Modular Monolith" bezeichnet -- vereint die Einfachheit eines Monolithen mit der Flexibilität einer service-orientierten Architektur. So vermeiden wir vorzeitige Optimierung und können trotzdem schnell skalieren, wenn es nötig wird.