Microservices sind nicht klein
Gleich zu Beginn möchten wir den wahrscheinlich häufigsten Irrtum klarstellen: Microservices sind nicht klein, denn „Micro“ sagt hier nichts über die Größe eines Service im Sinne des Serviceschnitts aus. Ein vernünftiger Service in einer SOA ist auch in einer Microservice Architektur ein vernünftiger Service. Tatsächlich haben eine SOA und eine Microservice Architektur unterschiedliche Betrachtungsgegenstände: Es sind zwar beides sogenannte Modularisierungsansätze, aber während es bei der SOA darum geht, die Fähigkeiten eines Systems in Form von standardisierten Services zur Verfügung zu stellen, möchte eine Microservice Architektur Hinweise zur Gestaltung der eigentlichen Providersysteme geben – d.h. hier geht es tatsächlich um die Implementierung eines Systems, wohingegen eine SOA dazu ja gar nichts sagt.
Eine Microservice Architektur hingegen betrachtet die Summe aus Service und Implementierung und macht dazu Aussagen: „Micro“ bezieht sich daher tatsächlich auf die maximale Größe der Komponente an sich. Eine Faustregel hierzu ist, dass diese noch durch ein (agiles) Team wartbar sein muss – also 6-9 Personen.
Eine weitere Eigenschaft von Microservices ist, dass die jeweiligen Komponenten sauber gekapselt und eigenständig deploybar sein sollen. Ein großes Ziel dieser Architektur ist es, die Komponenten so zusammen wirken zu lassen, dass man jederzeit in der Lage ist, einzelne Komponenten neu zu deployen oder gar auszutauschen, ohne das Zusammenspiel des Gesamtsystems zu gefährden.
Sehr lesenswerte Grundsätze dazu findet man hier.
Microservices in der Anwendungslandschaft
Ist das Thema Microservices also ein Thema für unsere Anwendungslandschaft? Auf jeden Fall! Wir sind schon seit einiger Zeit dabei, neue Funktionalitäten in eigenen Komponenten bereit zu stellen, die jeweils einen dedizierten Zweck erfüllen, möglichst unabhängig von anderen Systemen sind und ihre Fähigkeit über Services exponieren. Siehe VIM, AIM, ELOG oder auch die OAMs.
Wir werden auch versuchen unsere großen Monolithen ICIS, COR und SVIS zu entschlacken, indem wir sinnvolle eigenständige Funktionalitäten in eigene, eigenständig deploybare Komponenten verlagern.
