Ein bestehendes laufendes System ab einer gewissen Größe läßt sich nicht mehr in einem Zug komplett ersetzen. Martin Fowler nennt hierfür einige Beispiele.
Quelle: https://martinfowler.com/articles/patterns-legacy-displacement/
Je länger die Erneuerung des Systems dauert, um so mehr haben sich auch äußere Anforderungen geändert. Somit steht Systemgröße in einem Mißverhältnis zur Innovation -
Dennoch ist sie aber möglich!
Martin Fowler spricht über "displacing legacy systems":
Quelle: https://www.youtube.com/watch?v=lwP80OiKtXI -> (Zitat ab 2:00)
"Of course, the key to this is gradual process. You don't displace legacy systems all in one go. You do it over time. [...] It's a constant process."
Die Innovation muß also in einem konstanten, wandlungsfähigen Prozess stattfinden. Ein schlagendes Bild hierfür ist die "StranglerFigApplication".
Quelle: https://martinfowler.com/bliki/StranglerFigApplication.html
Die auf dem alten System entstehende Struktur muss nicht von Anfang an alle Features des Bestandssystems unterstützen, sondern arbeitet sich nach und nach vor.
Für diese Vorgehensweise finden sich bei Paul Hammant einige Fallbeispiele.
Quelle: https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
Paul Hammant nennt unter anderem die Option, "move from java to java". Die StranglerFigApplication verfügt also nicht notwendigerweise über einen komplett neuen Stack!
Die Grenze zum Bestandssystem ist nicht notwendigerweise "hart" / hat keinen festen Verlauf sondern kann im Laufe des Prozesses unter Umständen noch verschoben werden.
Sam Newman: Monolith to Microservices. Evolutionary Patterns to Transform Your Monolith.
Quelle: https://www.youtube.com/watch?v=GBTdnfD6s5Q -> (Zitat ab 5:10)
"What is the thing you think it's gonna give you?"
Es gibt Bereiche in denen tunlichst keine Microservices eingesetzt werden sollten. Sie sollten nur verwendet werden wenn sie eine Herausforderung konkret und gut lösen.
Die drei häufigsten Argumente für Microservices:
"zero downtime deployability"
Datenkapselung und deren gekapselte Verarbeitung
Die Struktur der Microservices spiegelt eine Organisationsstruktur wider
Risiko: Die Microservices hängen so stark voneinander ab, dass sie nur scheinbar unabhängig sind.
Microservices sollten nicht der default Weg sein, denn das deployment eines Monolithen ist weniger Aufwendig.
Wer dennoch denkt, dass microservices der richtige Weg sein könnten sollte es in einem einfachen Szenario ausprobieren und sehen was passiert.
Während des Prozesses ist mir folgendes aufgefallen:
-Alle entwickeln den code weiter, der gerade in ein anderes Framework wandert.
Das erzeugt overhead, jetzt geschrieben schon veraltet.
Grundsätzliche Frage, wie verhält sich der entstandene code zum bestehenden? Ab wann kann er eigenständig werden?
-Wie werden grundlegende Konzepte abgebildet?
Bei der Migration von java nach java können grundlegende Klassen plug&play übernommen werden.
-Der microservice verwendet eine datenbank auf dem bereits bestehenden server.
-Für nicht-triviale Entities, welche auf beiden Seiten (microservice und Monolith) verfügbar sein sollen, muss es ein Serialisierungskonzept geben.