Microservices

Microservices bedeutet, eine Anwendung in viele kleine Services zu zerlegen, von denen jeder ein Stück des Geschäfts verantwortet und jeder für sich deploybar ist. Statt eines Programms, in dem alles im selben Prozess läuft, bekommt man eine Flotte von Services, die über das Netzwerk miteinander reden. Das Versprechen ist echt: Teams können unabhängig liefern, man kann nur die Teile skalieren, die es brauchen, und ein Service kann ausfallen, ohne das ganze System mitzureißen.

Die Kosten sind ebenfalls echt und werden meist unterschätzt. In dem Moment, in dem aus Funktionsaufrufen Netzwerkaufrufe werden, hat man ein verteiltes System, und verteilte Systeme sind schwer. Man erbt Netzwerkausfälle, Latenz, über viele Datenbanken verstreute Daten ohne einfache Transaktionen, Versionierung zwischen Services und die Betriebslast, viele bewegliche Teile statt eines zu betreiben, zu überwachen und zu debuggen. Ein Bug, der früher ein Stacktrace war, ist jetzt eine Spur über fünf Services und drei Queues.

Die ehrliche Haltung: Die meisten Startups sollten mit einem Monolithen starten. Eine gut strukturierte einzelne Anwendung ist schneller zu bauen, weit einfacher zu debuggen und durchaus in der Lage, einen bis zu echtem Umsatz zu tragen. Man teilt in Microservices auf, wenn man einen konkreten Grund hat, ein Team groß genug, dass eine Codebasis ein Engpass ist, oder eine Last, die wirklich unabhängige Skalierung braucht, nicht weil Microservices die modische Antwort sind. Verfrühte Microservices sind die Art, wie kleine Teams aus einem schweren Problem zehn machen.

Polity lief auf sieben Microservices, und das war für seine Größe und Teamstruktur die richtige Entscheidung. Genau das ist der Punkt: Die Architektur sollte dem Problem und dem Organigramm folgen, nicht einem Konferenzvortrag. Wähle die Grenzen dort, wo sie die Kopplung tatsächlich reduzieren, und akzeptiere, dass jede Grenze, die du ziehst, ein Netzwerkaufruf ist, den du jetzt verteidigen musst.