Tach Leute,
heute erzähle ich euch was die aus Microservices und CQRS-Pattern gemacht haben. Microservices sind schon cool aber wie zu große Systeme Probleme mit sich bringen, tun diese auch Systeme, die aus zu vielen kleinen Komponenten bestehen. Ist eigentlich klar. CQRS-Pattern (Command-Query-Responsibility-Segregation) beduetet, eigentlich nur dass unterschiedliche "Systembestandteile" für lesende Zugriffe und für schreibende Zugriffe verwendet werden. Kann ja jeder im Internet lesen wer mehr dazu wissen möchte. Einfach optimiert für die jeweilige Aufgabe. Einer der Hauptgründe für beide Sachen ist die Skalierbarkeit. Im Lauf der Zeit habe ich immer mehr Last drauf, weil die Userzahlen wachsen. Dann kann ich die ohne Probleme auf extra Maschinen packen.
Jeder der sich mit dem Inernet etwas auskennt weiß dass die heutigen Datenbanksysteme locker mehrere Millionen User schaffen. Ein Premium-Hersteller von Kraftfahrzeugen verarbeitet alle Navigationsdaten seiner Fahrzeuge mit einem einzigen Oracle-Cluster.Ist man bei z.B. bei Amazon in der Cloud bucht mach einfach was auch immer dazu. Und hostet man das selber stellt man einfach ein paar Maschinen (auch virtuelle) dazu und passt.
Und die Super-Architekten haben den verantwortlichen voll verklickert, dass man sowas für ein paar hundert gleichzeitiger User braucht. Aber nun gut. Sagen wir mal o.k. Ist zwar in dem Kontext so sinnvoll wie ein Kropf aber gut. Die haben nun im Internet dazu etwas gelesen und noch Event-Sourcing dazu gepackt und folgendes ist rausgekommen.
Die haben für jede Datenbanktabelle drei Services gebaut. Einen der die Daten annimmt und die Validierung und Geschäftslogik macht. Dann haben die die Daten über eine total lansame Message-Queue an den zweiten Service geschickt der die Abspeichert und dann haben die die Daten wieder weiter geschickt um für das Lesen vorbereitet zu werden. Und weil die Event-Sourcing verwendet haben haben die für jedes einzelne Feld in jedem der drei Services ein Event geschrieben bzw. einen Event Handler. Und dann noch so Routing Klassen damit die die Message-Quer weiß welchen Service sie ansprechen soll. Und das für jedes Event.
Hatte man also ein Formular mit 15 Feldern musste man
ungefähr 15 Event-Klassen (15 Dateien), 15 Handler-Klassen (15 Dateien), 15 Routing-Klassen (15 Dateien), 15 Unit-Tests für die Handler (15 Dateien) und das für jeden der drei Services schreiben. Und so Sachen wie Validatoren, Services für Geschäftslogik usw. gar nicht mitgezählt. Also kam man bei so einer Sache auf über 200 Dateien. Nicht Zeilen Dateien die man schreiben musste nur um so ein verficktes, dämliches Formular abzuspeichern und die Daten wieder auszulesen. Und da war noch nicht mal dabei, dass man die dem User auch noch anzeigt.
Und die sind da rumgerannt und waren stolz wie Oscar, als hätten die gerade das Reisen mit Lichtgeschwindigkeit erfunden. 200 Dateien schreiben um ein Formular abzuspeichern. Hammer. Hahahaha und das geilste war ja. Das ist denen gar nicht aufgefalllen. Und anstatt sich mal zu fragen, hm, machen wir das richtig? Kann das sein dass wir so einen Aufwand machen um triviale Sachen zu erreichen. Haben die einfach sämtliche freien Programmierer der Welt aufgekauft. Jeden Inder den die bekommen konnten. Waren irgenwie 10 von 40 Leuten von hier. Ein Team komplett Ukraine. Anderes Team Nordafrika. Und dann haben die gesagt, ja das ist zwar mehr Aufwand aber dafür nachhaltig. Hahahaha, nachhaltig? Ja man sorgt dafür dass es nachhaltig Arbeit gibt. Irgenwie nach drei Monaten Arbeit war unser Team 4-6 Leute so weit 5 Formulare abzuspeichern, wenn das Frontend denn mal fertig wird. Hahahahah.
Ich wette, die tippen immer noch wie die bekloppten ihre Event-Klassen.
Keine Kommentare:
Kommentar veröffentlichen