Die richtige Architektur finden

Servus zusammen,

ich arbeite bei einem mittelstätigen Unternehmen, welches im Tankstellenbereicht tätig ist.

Eins unserer Projekte hat die Aufgabe bei verschiedenen Tankautomaten-Herstellern Konfigurationen der Tankautomaten abzurufen, oder diese zu setzen. Jeder Hersteller nutzt da logischweise einen anderen Kommunikationsansatz. Die einen eine Rest API, die anderen eine TCP Verbindung.

Da sich dieeses Projekt langsam zu einem alles könnenden Monolithen entwickelt und in nächster Zeit nun weitere Funktionen hinzu kommen werden, würde ich alles etwas umstrukturieren wollen und den Ansatz der Microservice-Architektur umsetzen. Beispielsweise ein Service kümmert sich um die ankommenden Konfigurationen und ein weiterer Service sendet neue Konfigurationen. Nennen wir sie mal "Bekomme-Konfiguration-Service" und "Sende-Konfiguration-Service". Beide Services würden aber weiterhin auf dem gleichen Server laufen.

Mein Stolperstein ist hier allerdings die TCP Geschichte. Unser aktueller Service dient als TCP Server, die Hersteller bauen also eine Verbindung zu uns auf und nur durch diese Verbindung kann ich neue Konfigurationen senden.

Wenn ich nun aber den TCP Server abkoppel und in den "Bekomme-Konfiguration-Service" stecke, wie komme ich dann im "Sende-Konfiguration-Service" an die Verbindung? Oder macht es da eher Sinn den TCP Server als dritten Service anzulegen. Die ankommenden Konfigurationen würden dann an den "Bekomme-Konfigurationen-Service" weiter geleitet werden und neue Konfigurationen vom "Sende-Konfigurationen_Service" werden dann zum TCP Service geleitet und dort gesendet. Aber, wie schon gefragt, wie komme ich von aussen an die richtige Verbindung?

Oder macht hier ein ganz anderer Ansatz mehr Sinn?

Vorweg: es gibt nicht die richtige Architektur. Es gibt immer mehrere Wege nach Rom.
Dazu verändert sich eine Architektur mit ihren Anforderungen.

Da sich dieeses Projekt langsam zu einem alles könnenden Monolithen entwickelt und in nächster Zeit nun weitere Funktionen hinzu kommen werden, würde ich alles etwas umstrukturieren wollen und den Ansatz der Microservice-Architektur umsetzen.

Das ist sehr wahrscheinlich der beste, schnellste und effizienteste Schritt, das Projekt gegen die Wand zu fahren.
Wer einen Monolithen nicht richtig im Griff hat, bekommt auch eine Microservice-Landschaft nicht in den Griff.

Ich bin großer Fan und Kritiker von Microservices gleichermaßen; und ich sehe sehr viele Firmen scheitern mit diesem Weg. Aktuell betreue ich mehrere Firmen sowohl beim Schritt zu Microservices (und das sind alles Firmen mit ü100 MA/Projekt) und auch Firmen, das wieder zurück zu bauen, weil sie sich übernommen haben und nun um Hilfe flehen.
Microservices haben für ganz gewisse Szenarien enorme Vorteile, kommen in 100% der Fälle aber immer mit Nachteilen, mit hohem technischen und organisatorischem Overhead und immer mit zusätzlichem Aufwand.
Du redest nur von Features: das ist keine Anforderung, die im Vergleich die Vorteile von Microservices sind.

Firmen, die von Microservices und dessen Vorteile wirklich profitieren, sind die wenigsten. Alle haben aber die Nachteile.
In meinem direkten Dunstkreis ist vor gar nicht all zu langer Zeit eine Firma u.a. aufgrund ihrer gescheiterten Fehlentscheidung auf Microservices und Kubernetes zu gehen Pleite gegangen. Mehrere hundert Mitarbeiter wurden arbeitslos und die Firma wurde/wird abgewickelt.
Grund: die Umstellung wurde enorm unterschätzt, die Verantwortlichen haben sowas noch nie gemacht und sich selbst überschätzt, IT-Systeme gingen monatelang nicht, Kunden sind abgesprungen, geschätzte Devs wegen hoher Unzufriedenheit gegangen.
Ich war zwar nicht direkt beteiligt, aber die Firma hatte zwei Beratungshäuser im Haus, die beide das Vorgehen nicht empfohlen haben. Die Firma hatte keine Not oder Gründe, auf eine solche Plattform zu wechseln. Es kam ein neuer CIO ins Haus (über Vitamin B), der meinte "Kubernetes und Microservices sparen Kosten" - was letzten Endes alles gegen die Wand gefahren und mehrere hundert Mitarbeiter eines >30 Jahre alten Unternehmens arbeitslos gemacht hat.
Und von Außen konnte man nur warnen und zuschauen.

Modulare Monolithen (kein zusammen geschusterter Schrott) haben ihre Vorteile; so viele Vorteile, dass Firmen ihre Microservices wieder abreißen (Amazon, Twitter, Twitch, Netflix...). 
Der Approach sollte immer sein: Monolith First.

As I hear stories about teams using a microservices architecture, I've noticed a common pattern.

1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up
2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

Microservices haben vor allem für riesige Teams mit großen Skalierungsanforderungen Vorteile. Teams mit erfolgreichen Microservices haben eine sehr hohe Professionalität, Team-Struktur und eine nahezu vollständige Automatisierung.
Aufgrund Deiner anderen Themen in der letzten Zeit, kann ich Dich in diese Gruppe nicht einordnen.

Geh nicht den Microservices-Schritt. Du wirst scheitern, wie viele andere.

Wenn ihr z.B. wegen Kompatibilität nicht den TCP Part wegsägen könnt, würde ich einen TCP Server vor den Service schalten.
Der Kunde arbeitet dann wie bisher gegen einen TCP server und der TCP Server kommuniziert dann mit dem eigentlichen Service.
Dadurch kann der Kunde wie bisher gegen einen TCP Endpunkt arbeitet, der dann gegen die eigentliche Schnittstelle in Form des Service arbeitet.

Nachtrag:
Abts Antwort fasst es auch gut zusammen.
Hab in den letzten Jahren auch den Wechsel hin zu Microservices und wieder weg beobachtet.
Hier müsst ihr natürlich vorab prüfen ob diese bei euch zielführend wären.
Z.B. muss man auch immer die einzelnen Latenzen, die sich durch die Microservices ergeben, bedenken.
Ebenfalls müsstet ihr prüfen ob das Konzept der Microservices hier einen Mehrwert bietet wie z.B. Skalierung oder Ausfallsicherheit duch Verteilung der Services auf mehrere Systeme.

T-Virus

Als Schlagwörter könnte man auch zu "Macroservices" oder "Modulithen" recherchieren (ändert aber wohl nichts Fundamentales an den vorigen Postings)

Sind leider auch wieder so Hype-Bezeichnungen für Click-Baits (damit SEO funktioniert), die fundamentale Wissensträger eher nicht verwenden.

Ok, ihr ratet mir also eher von Microservices ab, und empfehlt eher den Schritt zu gehen, das aktuelle Projekt zu optimieren, so dass weitere Features und Services ohne weiteres implementiert werden können?

Klar, es gibt nicht DIE Architektur, die auf alles passt, hätte nur gedacht, dass Microservices "alles etwas einfacher machen", aber es scheint eher das Gegenteil zu sein.

Dann auf jeden Fall vielen Dank für das Feedback!

Zitat von Kriz

Ok, ihr ratet mir also eher von Microservices ab, und empfehlt eher den Schritt zu gehen, das aktuelle Projekt zu optimieren, so dass weitere Features und Services ohne weiteres implementiert werden können?

Natürlich.

Allein die Frage zeigt, dass Du keine Zielgruppe dafür bist. Microservices sind ein deutlich komplexerer Architekturpattern als ein modularer Monolith.
Davon abgesehen, dass allein der organisatorische Faktor extrem auf Erfahrung aufbaut, hast Du eine technische Komplexität, dessen Du Dir offenbar nicht bewusst bist (sonst würdest nicht fragen, was okay ist).
Hast Du 0 Wissen dazu, wirst Du das nicht handlen können. Daher gern nochmal mein Ratschlag: "hast Du einen Monolithen nicht im griff, wirst Du einen Microservice erst recht nicht im Griff haben".
Das ist der Tod vieler Software-Produkte.

Klar, es gibt nicht DIE Architektur, die auf alles passt, hätte nur gedacht, dass Microservices "alles etwas einfacher machen", aber es scheint eher das Gegenteil zu sein.

Zeigt mir irgendwie aber auch, dass Du noch keine einzige Literatur dazu gelesen hast 😃

Egal welche: ne Architektur anzuwenden oder in Frage zu stellen, ohne sich je damit befasst zu haben, ist keine gute Idee.