Was zur Hölle soll ein Microservice sein?



  • Es kursiert seit einiger Zeit ein neues Buzzword, das sogar schon in diesem Forum mindestens einmal erwähnt worden ist. Kann mir das mal jemand erklären, damit sogar ich es verstehe? Als Grundlage der konstruktiven Unterhaltung soll Wikipedia dienen, das das hier dazu schreibt (meine spontanen Kommentare dazwischen):

    Wikipedia schrieb:

    Der Gedanke hinter Microservices entspricht weitgehend dem der Unix-Philosophie („Do One Thing and Do It Well“). Die Dienste sollten üblicherweise die folgenden Eigenschaften haben:

    Oha, die fangen gleich mit dem Betriebssystem an, das tausend Sachen macht und nichts davon richtig.

    Wikipedia schrieb:

    Die Services können einfach ersetzt werden.

    Funktionen können auch einfach ersetzt werden.

    Wikipedia schrieb:

    Der Umfang eines Microsevices sollte für jedes Teammitglied überschaubar sein.

    Gilt auch für eine einzelne Funktion. Eigentlich gilt das für die ganze Anwendung, egal wie groß. Stichwort Abstraktion.

    Wikipedia schrieb:

    Ein Microservice sollte vom zuständigem Team (üblicherweise 5 bis 7 Entwickler) mit vertretbarem Zeitaufwand (z. B. innerhalb eines Monats) neu erstellt und ersetzt werden können.
    Die Dienste haben eine Geschäftsfunktion. Sie können beispielsweise einen Bestellvorgang, die Registrierung oder die Rechnungserstellung umfassen.

    Eine Funktion kann auch mit vertretbarem Zeitaufwand neu erstellt werden.

    Wikipedia schrieb:

    Jeder Service kann eine andere Programmiersprache, Datenbank oder einen ganz anderen Technologie-Stack nutzen.

    Eine Funktion kann auch in einer anderen Programmiersprache geschrieben sein. Eine Funktion kann eine beliebige Datenbank benutzen. Eine Funktion kann auch mit einem anderen Prozess kommunizieren, wenn nötig.

    Wikipedia schrieb:

    Jeder Microservice kann unabhängig von anderen Microservices in Produktion gebracht werden. Das erleichtert den Einstieg in Continuous Delivery.

    Eine Funktion kann auch unabhängig von anderen Funktionen "in Produktion gebracht" werden. Was auch immer das heißen soll. Ich sehe hier aber keinen Bezug zu Continuous Delivery.

    Wikipedia schrieb:

    Ein Microservice wird nur von einem Team entwickelt. So sorgt das Gesetz von Conway dafür, dass die Architektur auch durch organisatorische Maßnahmen abgesichert wird. Ebenso kann ein Team für mehrere fachlich zusammenhängende Microservices (Self-contained System )[3] verantwortlich sein.
    Ein Microservice sollte einen Bounded Context im Sinne von Domain-driven Design implementieren.

    Eine Funktion wird von demjenigen weiterentwickelt, der daran etwas ändern muss. Was hat denn bitte Conway's Law hier zu suchen? Geht es hier um Software oder um Unternehmensführung?

    Wikipedia schrieb:

    Die Größe eines Microservice nach unten wird hierbei dadurch begrenzt, da die Netzwerkkommunikation zwischen Microservices Resourcenintinsiv ausfallen kann und für jedes Microservice ein eigenes Deployment vorgesehen werden muss.

    Um eine Funktion aufzurufen brauche ich keine ressourcenintinsive Netzwerkkommunikation. Eine Funktion kann auch so klein sein wie nötig. Deployment ist für alle Funktionen in meinem Programm auf einmal erledigt.

    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.



  • Dann lies dir mal Microservices - a definition of this new architectural term von Martin Fowler durch (der Wiki-Artikel basiert wohl zu großen Teilen darauf).
    Es geht hierbei nicht um "single process applications", sondern um Applikationen auf Basis von Serviceorientierte Architektur.

    Auch der Heise-Artikel Microservices - Den Monolithen den Kampf ansagen erläutert das ganz gut.

    Es geht bei den Microservices also nicht um einzelne Funktionen, sondern um komplette Entwicklerpakete, welche einzeln getestet und "deployed" werden können.



  • 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