Was zur Hölle soll ein Microservice sein?



  • Alter Schwede, was für ein Haufen Bullshit.
    Ah, sehr interessant. Dinge auf möglichst kleine Prozesse aufzuteilen ist also auf magische Weise besser als das nur zu tun, wenn es notwendig ist.

    Ich glaube, ich verstehe jetzt. Hier treffen zwei Entwicklungen aufeinander:

    - Entwicklungsabteilungen werden immer größer. Alles muss um jeden Preis im Team gemacht werden. Teams sind zu groß und deswegen nur mit sich selbst beschäftigt. Der einzelne hat einfach nicht die Zeit auch noch mit Mitarbeitern aus anderen Teams zu sprechen. Das Management ist zu sehr damit beschäftigt noch mehr Leute einzustellen, "damit es schneller voran geht". Weil man so viele Mitarbeiter hat, hat man keine Zeit mehr sich mit Kunden und realen Bedürfnissen zu beschäftigen. Dafür wäre zwischen den ganzen Scrum-Meetings sowieso keine Zeit. Seitdem Informatik wieder cool ist, sind menschliche Köpfe wieder billiger als Niedergeschriebenes. Zehn Leute, die Fehler beheben, sind einfacher zu managen als einer, der Fehler vermeidet. Am Ende sieht der noch schlauer aus als man selbst.

    - Software wird immer ineffizienter. Hardware wird nicht mehr großartig schneller. Zwei Server sehen schicker aus als ein einzelner, der dreimal so schnell ist, aber nur das doppelte kostet. Extrem ineffiziente Technologien sind immer gut genug, weil man dann noch mehr schicke Server hinstellen kann. Smarte Software braucht eben Platz. Wohin sollte man sonst skalieren? Worse is better! Die Kunden haben ja Zeit. Und die Cloud! Wir hätten hier fast die CLOUD vergessen! Die heilige Cloud, die gute, alte, neue Cloud. Wir würden ihr Unrecht tun, wenn wir Software schrieben, die keine größere Cloud als letztes Jahr bräuchte. Cloud, Cloud, Cloud, Cloud, Cloud, Cloud, Cloud, Cloud, Cloud, Cloud, Cloud, Cloud, Cloud, Cloud, Cloud, Cloud. Wir zwar am Ende doch irgendwie alles von Hand zusammengefrickelt und Pets gepflegt, aber muss ja gut sein weil Technologie und so.

    Schlangenölverkäufer wie Martin Fowler erkennen solche Entwicklungen und entwickeln neue Buzzwords, um ihre Dienstleistungen besser verkaufen zu können.



  • Nein.

    Du willst es offensichtlich nicht verstehen, dann wirst du es natürlich auch nicht verstehen. Bloss... wieso fragst du dann?



  • Weil ich meine Gedanken immer wieder mit dem Rest der Welt abgleichen muss. Mir wird sowieso niemand vernünftig das Thema erklären, also komme ich am weitesten mit Rubberducking. Das geht besonders gut in einem öffentlichen Forum, wo ich zumindest ein bisschen Rückmeldung bekomme.

    Ich habe schon gelernt, wo und warum jemand Microservices benutzt. Ich glaube sogar, dass das in bestimmten Umgebungen sinnvoll sein kann. Technisch gesehen ist das absoluter Unfug, aber ich verstehe Microservices als soziales Konstrukt. Wie Fowler schon sagt, es ist das bewusste Anwenden von Conway's Law. Er nimmt dabei an, dass Conway's Law unterstützt werden sollte. Ich sehe das überhaupt nicht so. Man muss dem aktiv entgegenwirken, weil es sonst zu Stagnation kommt. Stagnation ist langfristig schädlich für das Geschäft. Letztendlich ist das wieder der Konflikt zwischen kurzfristigem und langfristigem Denken. Ich stehe eher auf langfristiges Denken. Daher mein Problem mit Microservices.



  • TyRoXx schrieb:

    Es kursiert seit einiger Zeit ein neues Buzzword, das sogar schon in diesem Forum mindestens einmal erwähnt worden ist.

    Von mir heute? Würde mich freuen, einen Leser zu haben. 😋

    TyRoXx schrieb:

    Kann mir das mal jemand erklären, damit sogar ich es verstehe?

    Ich heute noch nicht.

    Es ist extrem bullshittig, ja! Ich schaue mir jede Woche drei bis vier Talks darüber an und habe das Problem, daß die jedesmal die Refrenten offenbar nichts an der Tastatur können. Das merkt man zum Beispiel daran, daß sie ganz über den Wolken schweben und niemals auch nur ein wenig konkret werden können.

    TyRoXx schrieb:

    Ich fasse zusammen, was ich gelernt habe: Microservices ersetzen eine effiziente Aufrufkonvention durch teure Netzwerkaufrufe, die nötig sind, damit man Dienste unabhängig voneinander austauschen kann, damit Entwickler sich an kein geregeltes Deployment-Konzept halten oder -Gott bewahre- mit anderen Teams zusammenarbeiten müssen, weil die Organisation mit ihren Silos so etwas nicht zuließe. Wenn man in so etwas arbeitet, hört sich das bestimmt total sinnvoll an.

    Das trifft es gut. Da will ich aber nicht die Grenzen ziehen. Sagen wir mal lieber anhand von zwei Beispielen:

    Mitschriften: Alle anderen Module können was ins Log schreiben. Log-Messages müssen eh serialsisiert werden. Mutex um die Zeilen und Sockets/Files vom BS nehmen und 10 Mio Zeilen pro Sekunde wird man packen. Im Gegensatz zur bisherigen Lösung, die warumauchimmer eher bei 10k oder drunter ist. "Microservices" ist hier das Buzzword, um der Geschäftsleitung zu verkaufen, daß man endlich den bis zu 35 Jahre alten Code wegschmeißt (darin ist logrotation einstellbar, helau, aber erst per Datenbank beim Benutzeranmelstestatus mal schauen, welches loglevel er wünscht, helau2).

    Anmelden: Alle anderen Module können fragen, ob der User überhaupt gültig ist und ob der dieses Modul benutzen darf, die Lizenz nicht abgelaufen ist. Einfach fragen. Im Gegensatz zur bisherigen Lösung, die zwar auch nur einfach fragt, aber dazu muss jedes Mudul gegen die Dlls/Libs Logging/Interprocesshandling/Accounts/Database/Alert/UserExit/... gelinkt sein. Zu jedem denkbaren Zeitpunkt hat mindestens eine von denen einen Compilerfehler. Das liegt aber ausnahmsweise nicht an den schlechten Pr0ggern, sondern an der traditionellen Geschäftsführung, wo 250 Pr0gger auf dem selben Code arbeiten.

    TyRoXx schrieb:

    Technisch gesehen ist das absoluter Unfug

    TyRoXx schrieb:

    Ich stehe eher auf langfristiges Denken.

    Genau mein Ding. Ich hätte NIEMALS mit UML, XML oder Java angefangen, wegen offensichtlichem technischem Unfug.

    Bin an allen Erfahrungsberichten bezüglich Microservices höchst interessiert.



  • @TyRoXx
    Dann kannst du genau so gut sagen dass jede Hochsprache, jedes Framework etc. der/die/das bestimmte Nachteile in Kauf nimmt (Overhead, Verzicht auf diverse Freiheiten, Starrheit, ...) um es schwerer für Programmier zu machen bestimmte Fehler zu machen (vor allem unabsichtlich), technisch gesehen totaler Unfug ist.
    Je nachdem wie man nun "technisch gesehen" versteht ist das natürlich richtig.
    Gleichzeitig richtig ist aber auch dass eine "technische" Betrachtung, bei der die obige Aussage richtig ist, realitätsfremd und unnütz ist. Weil jegliche Betrachtung einer Sache an der direkt Menschen arbeiten realitätsfremd und unnütz ist, wenn sie ignoriert wie Menschen eben sind.

    Gerade wenn du Dinge langfristig betrachten willst kannst du nicht einfach wegignorieren dass Leute grundsätzlich dazu tendieren den Weg des geringsten Widerstandes zu gehen. Wenn du Software haben willst deren schönes, wartbares, gekapseltes Design - so es überhaupt jemals existiert hat - nicht durch spätere Änderungen aufgeweicht oder ganz vernichtet wird, dann musst du einfach irgendwas tun. Hoffen dass alle Programmierer "brav" sein werden und das Design soweit verstehen dass eben das nicht passiert reicht einfach nicht.

    Und dann stellt sich die Frage: was tut man? Eine Möglichkeit ist Code-Reviews. Sollte man mMn. auf jeden Fall machen. Dummerweise funktioniert das auch nur so lange der Reviewer mehr vom grossen Ganzen versteht als der der den Code geschrieben hat. (Natürlich kann jeder Reviewer bestimmte Fehler finden, aber wo gegen das Design gearbeitet wird kann man schwer verstehen wenn man das Design nicht kennt/versteht.) Und natürlich gibt es beim Reviewer das selbe Problem wie bei dem Programmierer der den Code geschrieben/geändert hat: auch der durchschnittliche Reviewer geht den Weg des geringsten Widerstandes.
    Code-Reviews alleine sind also nicht genug.

    Und es gibt neben "Weg des geringsten Widerstandes" noch eine weitere Sache die stark dahin drückt dass Schnittstellen aufweichen: die wenigsten Programmierer schreiben gerne Code bei dem sie den Eindruck haben dass er unnötigen Overhead aufweist. Speziell wenn dieser Overhead sich nicht auf Laufzeitkosten beschränkt sondern auch dazu führt dass sie mehr tippen müssen. Was dann gerne dazu führt dass z.B. auf Kopien verzichtet wird und statt dessen Zeiger/Referenzen auf Daten rausgegeben werden die die eigene Komponente später nochmal modifizieren könnte, dass Dinge direkt aufgerufen werden statt über Events/Callbacks etc. Was im Endeffekt wieder gegen die Kapselung wirkt und hin in Richtung unwartbarer Wollknäul.

    Die Auftrennung in Services ermöglicht dir dagegen eine quasi-undurchdringliche Barriere einzuziehen.

    Natürlich ist das nicht gratis und natürlich hat es auch neben der geringeren Effizienz auch andere Nachteile. Ein mMn. grober Nachteil ist z.B. dass es Refactoring von Schnittstellen erschwert, bis zu dem Punkt wo es quasi unmöglich wird.

    Die Sache aber einfach als totalen Quatsch abzutun ist mMn. totaler Quatsch.

    ----

    Und wenn du andere Vorschläge hast wie man einen ähnlichen Effekt erreichen kann, dann immer her damit.



  • @TyRoXx
    Ein Teil der auch "technisch gesehen" überhaupt kein Unsinn ist, ist dass die Aufteilung in unterschiedliche Prozesse es ermöglicht dass alles bis auf das fehlerhafte Service weiterläuft wenn eines abschmiert.
    So lange man nicht auf die irre Idee kommt irgendwie fehlerfreie Software schreiben zu können, ist das alles andere als irrelevant.

    Speziell wenn man mit C++ arbeitet, wo fehlerhafter Code beliebige Daten im ganzen Programm ändern/vernichten kann, und zu allen denkbaren und undenkbaren Resultaten führen kann. Gerne auch "stille" Fehler.



  • @volkard: du hast nen Blog?

    MfG SideWinder



  • SideWinder schrieb:

    @volkard: du hast nen Blog?

    Nee.



  • Vielleicht hilft dir ein aktueller Artikel bei den Vor- und Nachteilen: http://www.heise.de/developer/artikel/Der-perfekte-Microservice-3091905.html



  • KPC schrieb:

    Vielleicht hilft dir ein aktueller Artikel bei den Vor- und Nachteilen: http://www.heise.de/developer/artikel/Der-perfekte-Microservice-3091905.html

    Ich bin vorher auch drüber gestolpert, habs mir aber nicht angesehen.

    "Weg vom starren, nicht wartbaren Monolithen, hin zu einer flexiblen, Microservice-basierten Architektur.". Ich mag solche pauschalen Aussagen nicht. Vielleicht könnte man stattdessen auch sagen "Weg vom unwartbaren, verteilten Chaos, hin zu einer sauberen, wartbaren, übersichtlichen, zentralen Architektur"?

    Ich bin jetzt selber nicht so von Micro Services überzeugt (arbeite aber auch nicht im Enterprise Bereich und wir haben auch nicht tausende Server rumstehen). Kann deren Daseinsberechtigung aber schon teilweise nachvollziehen. Deployment ist bei uns auch nicht immer einfach. Wir haben auch einiges an Software, die bei uns auf den Servern läuft. Ist aber kein Webzeugs, sondern unsere "normale" C++ Software, die als Backend läuft. Und die läuft sowieso auf dutzenden Servern, also könnte man theoretisch unterschiedliche Module verwenden. Ein Modul oder "Micro Service" kümmert sich um eine Sache, ein anderer um eine andere. Ist ja im Endeffekt sowieso so. Nur basiert das alles auf großen, zentralen Bibliotheken und wenn wir nicht auf alle Server eine einheitliche Version draufspielen, könnte sich das ganze auseinander entwickeln und dann hätten wir wieder Chaos. Im Moment schauts aber eher so aus, dass Modul A fertig ist und irgendwelche Kunden darauf warten, kann aber noch nicht Live gehen, weil Modul B noch im Alpha Stadium ist.


Anmelden zum Antworten