Wow, da hat sich jemand einen Wolf geschrieben!!
cdonat schrieb am 10.01.2020 18:02:
1. Microservices > Java.
Ein Vorteil von Microservices ist ja, dass man einzelne Komponenten mit Tools implementieren kann, die für diese konkrete Funktionalität geeignet sind. Wenn man z.B.
ernsthafte Numerik braucht, macht man einen Service mit Python und numpy. Wenn man
ernsthafte Numerik braucht, macht man einen Service mit Python und numpy. Wenn man Numbercrunching betreibe, macht man einen Service in C++. Vielleicht hat man noch einen Service in Java und alles arbeitet zusammen und bildet eine grössere Anwendung.
Diesen babylonischen Blödsinn haben damals die .NET Fan zur Kunst hervorgehoben haben. So etwas ist typisch für IT Messies, die gerne im Chaos leben. Tatsache ist, dass der Gewinn marginal ist, und man sich als Projektverantwortlicher damit nur Risiken einkauft.
Du brauchst also JAVA, SQL und weitere Entwickler, die zudem andere Sprachen und Frameworks zudem beherrschen. Eine solche Maßnahme produziert Kosten und schafft Risiken, dass etwaige Probleme durch zu wenige Entwickler mit Spezialwissen für ein Framework/Sprache gelöst werden können. Das ist das Babylon Syndom!
Ein guter Manager hält die Anzahl Sprachen und Tools gering. Noch ein weiteres Tools für den Fool bläht den Softwarestack auf, schafft unnötige Lernhürden, Risiken.
So etwas schlagen nur IT Greenhorns vor!
2. Microservices < kein Monolith
Der Text erweckt den Eindruck, als wäre alles, was kein Monolith ist, eine Microservice Architektur. Es fällt mir schwer, den Einstieg in eine Erläuterung zu finden, warum das falsch ist. Es ist auf so viele Weisen falsch, dass man es kaum mehr erklären kann. Leider gibt es genug Leute da draussen, die so einen Unfug dann für bare Münze nehmen.
Jetzt machen es sich die Microservice Protagonisten sehr leicht, in dem sie die gescheiterten Prohjekt als nicht MC Architekturen umdefinieren, GEIL!
Ist ja keine MC Architektur, denn schlecht geschnitten, bä bä
Aus meiner verblendeten Sicht gibt es nachfolgende absteigende Kompetenztreppe. Wir fangen mal ganz oben an:
- Es gibt aus dem Host-Umfeld (CICS) inspirierte JavaEE Technologie, die Kommunikation möglichst vermeidet und dank den häufig verschmähten und missverstandenen EJB's eine Aufteilung einer Fachanwendung in Dömänen/Komponenten unterstützt. Hier steht die Transaktionssicherheit im Vordergrund, die in 2-Phasen-Commit Steuerung unterstützt und mittels Connectoren (JCA) verschiedene Legacy-Systeme (nicht nur Datenbanken) zusammenbindet.
- Der erste infantile Abstieg stellt die Verwendung des Spring Framework dar. Transaktionen sind hier unwichtig geworden, da eh nur Datenbanken Transaktionen beherrschen und damit dort auch verbleiben sollten. Zur Kommunikation verschiedener Systeme reichen Webservice oder REST Zugriffe, wobei man gerne ausblendet, hier spätestens die Transaktionsklammer verloren geht und Klartext Serialisierungen (XML, JSON) teuer sind.
- Die totale Idiotie erreicht man bei den Vertretern der Microservice Architekturen. Entweder sind die Burschen zu Jung oder die Herren zu degeneriert, als das man aus den Fehlern der C/S Systeme die richtigen Schlüsse gezogen hat. Transaktionen und Datenkonsistenz wird negiert und damit verweigert, da man ja nur richtig schneiden muss.
Dabei wird gerne übersehen, dass das Schneiden nach Domänen häufig unvereinbar mit den Vorgaben der Fachabteilungen in Einklang zu bringen sind, die aus gutem Grund gerne fachliche Funktionen über Domänengrenzen hinweg verlangt und natürlich erwartet, dass:
- die umzusetzende fachliche Funktion in einer Transaktion stattfindet
- und schnell abgearbeitet wird.
Diese Erwartungshaltung kann der Micoservice-Ansatz natürlich nicht erfüllen.
3. Microservice != mehrere kleine Webservices
Das steht nicht direkt im Text, lässt sich aber aus den "klagen" zusammen mit meiner Erfahrung in verschiedenen Unternehmen herauslesen. Viele kleine Webservices sind viele kleine Webservices. Schlimmstenfalls hängen die noch voneinander ab,
.... oder verursachen Timeouts, weil der Entwickler einer tief verschachtelt aufgerufenden SQL Abfrage Bockmist gebaut hat und länger als erwartet braucht. Auf verschiedenen Tiefen des Call-Stacks laufen dann wg. unterschiedlicher Timeouts dann Abrüche auf. Der arme Operator kriegt einen Anfalls und sucht sich einen Bär.
4. Microservices ~ schnell
Es geht bei Microservices nicht in erster Linie darum, dass es schnell ist. Das kann nur, je nach Deployment, ein Effekt einer Microservicearchitektur sein.
Microservices ~ schnell ... noch alle Nadeln am Tannenbaum? Wie kann etwas, dass auf viele Message-Passing Calls beruht schnell sein????
.....
Es geht aber bei Microservices auch um Ausfallsicherheit. Wenn man von einem Service mehrere Instanzen laufen lässt, kann man entweder die Zuständigkeit für bestimmte
Dieses Argument ist der Gipfel der Unwissenheit. Die Zuverlässigkeit eines Gesamtsystems ist das Produkt der Zuverlässigkeit jeder Teilkomponente (also Schnittstellen oder auch Kode). Das ein gesamte auf Microservice basierende Fachanwendung nicht alleine durch die erforderliche Kommunikation aufgeblähter ist (Stacktrace-Dump) ist ein Microservice automatisch unzuverlässiger als ein Monolyth.
Die Zuverlässigkeit berechnet sich so:
- die Zuverlässigkeit eines Teilsystems/Komponenten, Bibliothek oder Schnittstelle, also ein Wert aus dem einseitig offenen Intervall
[0 1[ also 0=geht immer schief bis 0,99...9 sehr zuverlässig.
- die Gesamtzuverlässigkeit eines Businesscall ergebit sich durch den Durchstig aller verbundenden Teilsysteme und damit deren Produkt:
Vges = Vcompo1 * Vcompo2 ....
Man erkennt dass die Zunahme an Komponenten/Schichten automatisch die Gesamtzuverlässigkeit absenkt. Zu berücksichtigen ist hier besonders der Umstand, das das schwächste Glied (= Netzwerkkommunikation, Timeouts etc) im Microservice-Umfeld besonders häufig verwendet wird.
Man muß keine Mathegenie sein, um zu erkennen, dass die Microservice Architektur damit sich zum IT-Hirnschuss des Jahrhunderts gekürt hat.
Ach übrigens: Redundanz in einem JavaEE Cluster zur
ja und JavaEE Cluster mit n-identischen Knoten gibt es auch schon länger. Gähn. Man hatte mit JGroups so richtig flotte Eisen damit aufgebaut, indem man den Verbund mit einem intra-Broadcast Netz versehen hatte, um gemeinsam verwendete Speicherbereiche zu synchronisieren (etwa bei den wenigen aber wichtigen Stateful-EJBs) oder Cache-Invalidierungen durchzuführen).
Die Administation eines solchen Verbundes gibt simpel, das Deployen übrigens auch. Einige bessere Anbieter (nicht IBM ;-) ) boten einen Scripting-Zugang und erlaubten mit SNMP auch, die Knoten zu überwachen.
Es gab damals vieles schon, was heute dank Grafana/kubernetes auch möglich bzw dringend notwendig geworden ist.
Liebe Leser mit Resthirnfunktion: Habt Ihr nicht auch den Eindruck, dass die Protagonisten der Microservice-Architekturen erst vor kurzer Zeit den Uni-Abschluss gemacht haben müssen ... ich mein in Fach BWL.
Das Posting wurde vom Benutzer editiert (12.01.2020 08:16).