8 things a developer should know about microservices (Wolf Schlegel, Laura Ionescu, Felix Hammerl)

1. How Big is a Microservice?

Die Größe eines Microservice kann variieren, wobei sowohl zu große als auch zu kleine Microservices Nachteile mit sich bringen. Als Startpunkt um die Größe festzulegen bietet sich der Domänenschnitt und Bounded Context an. Die letzendliche Festlegung der Microservices orientiert sich daran, wie hier sinnvolle Schnitte und Aufteilungen vorgenommen werden können, die einer losen Kopplung dienlich sind.

Faustregeln die beachtet werden sollten sind: Innerhalb weniger Wochen sollte jeder Microservice komplett neu geschrieben werden können. Always follow the Domain!

2. Incremential Releases

Es wird stark davon abgeraten, große, allumfassende Änderungen auf einen Schlag live gehen zu lassen. Ein solches Vorgehen wird als Big Bang Release bezeichnet.

Empfohlen wird stattdessen auf kleinere incrementielle Releases zurückzugreifen.

3. Microservice Templates

Es empfiehlt sich der Gebrauch von Microservice-Templates für Bestandteile von Microservices die wiedercerwendet werden. Beim Neuanlegen eines Microservices können Komponenten wie Monitoring, Logging und Persistence einheitlich importiert werden.

4. Component Security

Als Komponenten zählen in diesem Sinne bspw. der Kernel, Docker Images, Gradle, npm, etc.

Besonderes Augenmerk auf CVEs (common vulnerability and exposures). Dabei handelt es sich Sicherheitslücken von eingebundenen Komponenten, von denen dauerhafte Gefahr ausgeht.

Essentiell ist ein aggressives Updaten der Komponenten

Quick wins: 1. Version der genutzten Komponenten kennen 2. Wissen ob Komponenten angreifbar oder veraltet sind 3. Vulnerability-Scanning für Dependencies automatisieren 4. Update-Prozesse automatisieren 5. Kompatibilität von geupdateten/gepatchten Libraries testen 6. Komponentenkonfiguration sichern

5. Pull over Push

Services fordern exakt die Daten mittels _pull _an, die sie brauchen. Es wird nicht gezielt an andere Services gepusht. Dies ist insbesondere für Errorhandling vorteilhaft.

Events und Ressourcen sollten hierbei separiert werden und Protokolle sollten gegenüber Produkten priorisiert werden, um sich von letzteren nicht zu abhängig zu machen. Bei Events, die einzeln auftreten oder bei manueller Fehlerbehandlung kann trotzdem auf eine Pushstrategie zurückgegriffen werden.

6. Choreography over Orchestration

Die als Choreographie bezeichnete Kopplung zwischen Teams und hohe Selbstbestimmung der Teams ist wünschenswert und ein zentraler Bestandteil des Konzepts Microservice. Daher steuert keine zentrale Orchestrierung (wie bei SOA) die Microservicelandschaft.

Es ist auch denkbar, einen Mittelweg zwischen Choreographie zu wählen: High level orchestration and bilateral choreography

7. Secrets Management

Es ist zu empfehlen alle Geheimnisse, wie bspw. Passwörter, an zentraler Stelle verschlüsselt zu sichern. Beim Start eines Microservices muss dieser mit einem Token die benötigten Geheimnise erfragen. Die Geheimnisse dürfen nie in Klartext dauerhaft irgendwo gespeichert werden.

8. Consumer Driven Contacts

Consumer Driven Contacts sind High level Integration Test, die vom Consumer erstellt werden. Die Producer Teams können anhand dieser ihren Service verifizieren. Der Vorteil hiervon ist, dass die Producer bei Änderungen selber fehler erkennen können, bevor updates deployt werden.