Vielen Dank für diesen Realitätscheck! Es ist wie es immer ist, für jede Situation muss abgewogen werden, welcher Weg der Bessere ist und Wege können sich natürlich auch mit der Zeit wieder verändern. Wichtig ist, dass niemand der Illusion verfällt, das Microservices in der Entwicklung oder dem Betrieb wenig bis garnix kosten. Ich find es super, dass auch auf diesen Aspekt so anschaulich eingegangen wurde. Mich hat das Video in meiner Wahrnehmung und meinem Bauchgefühl im aktuellen Projekt bestätigt. Danke dafür und macht weiter so.
Also ich bin selber auf Microservices umgestiegen um deren Vorteile zu nutzen. Nur um erstmal das ganze gut Nutzen zu können habe ich mir eine Zwischeninstanz gebastelt die überprüft ob die ganzen Events erfolgreich durchgingen und einen Rollback veranlassen damit man die Konsistenz der Daten behält. Es ist einfacherer und schneller einen Monolithen zu basteln. Es ist auch empfehlenswert wenn man diese ganzen Vorteile von Microservices nicht nutzen will, wie du im Video schon gesagt hattest. Ich bemerke selber einen Trend der zeigt dass alle darauf wechseln wollen weil Netflix und co. auf das ganze setzen und man das nicht verpassen möchte
Ich muss sagen das bei uns unsere Haupt Software ist ein Monolith aber schon sehr sauber organisiert von anfang an macht spaß damit zu arbeiten und unsere "cloud" Funktionen sind alle sehr spezifisch unterteilt teilweise monolithen teilweise "Micro Services" je nachdem was man wie zählt also wir haben um bei spiel eine API die auf eine rout sehr sehr viele Anfragen kriegt und unabhängig vom rest der API agieren kann die ist einzeln implementiert der rest der API ist ein Monolith da wir das ganze nicht so stark scallieren müssen. Ich denke das ein Mix aus beiden sachen der beste Weg ist so ist man an keine Architektur gebunden und kann die Vorteile von beiden Seite mit nehmen es muss aber auch zum Anwendungs Fall passen.
Plugins vereinigt die Vorteile beider Welten. Zur Laufzeit ist es ein Monolith. Aber in der Entwicklung kannst die Plugins in einzelnen Teams entwickeln. Du kannst ein einzelnes Plugin austauschen wie einen Microservice. Bei verschiedenen Kunden kannst du unterschiedliche Plugins installieren/lizensieren.
So schade das OSGI quasi gestorben ist. Wir haben unser letztes Projekt mit Apache Karaf begonnen ... war super vielversprechend ...aber nun sind wir sehr glücklich, dass wir davon weg sind: die Idee ist super, aber wenn wichtige Bibliotheken wie Apache Camel nicht mehr OSGI unterstützen, dann kann die Idee und der OSGI Server noch so gut sein.... Jetzt läuft alles in einem super aufgeräumten Monolithen, die CI/CD Pipeline läuft fast von selbst und wir sind glücklich 😅
Entschuldigung für Englisch schreiben, aber mein technische Deutsch ist nicht so gut. Your honesty, objectivity and candor is so refreshing. Microservices was the latest buzzword, just like XML was years ago, when there was a specific need for nothing but a communication standard between applications, yet next thing you know every goddamned thing was xml (I've even seen java code in xml....what the hell?!) So now here we are, recognizing the need for having smaller, more "neural" programs which can be written so they can easily be swapped out, rewritten in more appropriate languages, used by multiple applications maybe, or scaled separately from other parts of the system. Fine, so why have I seen a microservice whose sole purpose was to interface with a database that only one other application needed? Wahnsinn! Why have people just split their monoliths into microservices with absolutely no questions asked about the design benefits? How will you track down a bug? How are you going to trace a problem from 5 different logs on 5 different machines, which you used to easily do with a Ruby script on the monolith's single log file? "Splunk!" they say. Yeah, right. Splunk (another craze by the way) won't do that. Splunk will NEVER do that. And why? Because it does not speak the language of the code, so to speak; it speaks Splunk, which is a generic, glorified grep language. And it's not running on the box, either, so it's way too slow. But let me give another example, something I also saw first-hand that was very serious. There was an upgrade to a microservice that used a database. It passed unit tests, system tests, manual testing. So it went to prod, but it broke, and no one knew could tell why. This was a big deal. So what happened? Well, because the database schema in prod didn't match. Gee, that's crazy. Why was that? Well, because the schema update was officially part of a different microservice which was going out on a different schedule. The two microservices were tracked as separate products, yet shared the same database, so they literally FORGOT to test both of them when one was upgraded. I must say this was shocking, because this would have NEVER happened in the IT world before microservices. If two products used the same db then everyone was well aware that they had to be tested together. The reality is that we have swapped out monoliths, which are like a single individuals that function in a normal, sane manner, have flaws, but can also fix those flaws and improve themselves -- we've swapped these out with multiple individuals, who inherently could care less about one another, are self-centered (by design!), and have poorer communication! So I completely agree; in most cases monoliths are far better. Of course no one will listen, just like they won't listen to any down sides of going to the cloud. IT has gotten worse -- not better -- since the heydays of CMMi.
Ich kann aus Erfahrung sagen, dass man den Mehraufwand durch Monitoring/Logging/Traceing/Orchestration/... nicht unterschätzen sollte bei Microservices. Das ganze braucht dann noch Service Discovery. Gott bewahre jemand würde eine Container IP in Prometheus hardcoden. Und neben den Resourcen eines Microservices hat man auch "nicht Business Code". Also den DB Zugriff, die API, Metriken,... und das in jedem Service immer wieder. Dann kommen noch solche Fragen wie TLS, Authentication und Circuit Breaking auf. Ich glaube viel der Wahrnehmung von Microservices gegenüber Monolithen beruht darauf, dass man davon ausgeht, dass die Entwicklung und der Betrieb von Microservicen optimal verläuft. Meiner Beobachtung nach stammen viele Vorteile aus der Umsetzung der Software und nicht der Architektur oder ihrer Tools. Redundanz/Skalierbarkeit beispielsweise, muss in der Software berücksichtigt werden, ob Monolith oder Microservice.
Ich betreibe mit einem Freund einen Monolithen und bib generell froh, dass ich mir keine Microservices angetan habe. Ich hab dabei Tests, Spring und OOP machen vieles einfacher, eine CI/CD pipeline, es läuft mit K8s (wofür ich auch gute Gründe habe, u.a. mit mehreren Instanzen des Monoliths) und es funktioniert gut.
6:00 also Microservice Teams müssen auch manchmal miteinander Kommunizieren. Denn manchmal benötigen diese eventuell eine Information mehr von einem anderen Microservice. Bspw. ein Produkt hat einen Preis und bei einem Microservice soll jetzt dieser Preis angezeigt werden also muss man sich doch die Information von denen holen um damit zu arbeiten oder habe ich evt. bei den Microservice Thema was missverstanden
Hi Juus, man versucht die Services möglichst gut zu isolieren und wenige oder keine Abhängigkeiten zu anderen Services zu haben. Mit einem gemeinsamen Event Bus geht das etwas besser, bei gemeinsen Services müssen wie du es beschrieben hast, auch andere Services aufgerufen werden. Dann versucht man durch eine Beschreibung der Schnittstelle die Services zu entkoppeln, so dass die Services zu einem gewissen Grad isoliert weiterentwickelt werden können. Manchmal ist es gut zu kommunizieren, so wie du es beschreibst. Wesentlich ist, dass der Abstimmungsaufwand reduziert wird und nicht die Auslieferung neuer Releases bremst.
Ein anderer Aspekt: Anwender von Software mögen es oft garnicht, wenn sich Funktionalitäten und Oberflächen bewährter Software laufend ändern. Kann man daraus schließen, dass sich Microservices nicht für jede Software, oder nicht für alle Lifecycle-Phasen eignen ? Könnte es aus Effizienzgründen sogar ratsam sein, eine Microservice-Architektur wieder in größere Blöcke zu konsolidieren, sobald sich an Funktionalität und Skalierung nicht mehr viel ändert ?
Hallo Paul, ja aus Gründen der Effizienz oder der Wartbarkeit, kann es sinnvoll sein, zu kleine Microservices in größeren Einheiten zusammenzufassen. Für den Anwender ist es meist nicht direkt ersichtlich, ob er mit einem Monolith oder mit mehreren Microservices arbeitet. Es gibt Techniken und Frameworks, bei denen du eine einheitliche Oberfläche bewahren kannst, obwohl Teile der Oberfläche von verschiedenen Services stammen.
Wieso spricht mir dieser Beitrag so aus der Seele? Klasse?
Ich liebe es das Ihr das visuell mit diesen Kisten erklärt.
Sehr deutlich erklärt, sowas habe ich gesucht 🙂
Danke für das Feedback. Freut mich, dass die Kisten gut ankommen.
Vielen Dank für diesen Realitätscheck! Es ist wie es immer ist, für jede Situation muss abgewogen werden, welcher Weg der Bessere ist und Wege können sich natürlich auch mit der Zeit wieder verändern. Wichtig ist, dass niemand der Illusion verfällt, das Microservices in der Entwicklung oder dem Betrieb wenig bis garnix kosten. Ich find es super, dass auch auf diesen Aspekt so anschaulich eingegangen wurde. Mich hat das Video in meiner Wahrnehmung und meinem Bauchgefühl im aktuellen Projekt bestätigt. Danke dafür und macht weiter so.
Hallo Stefan, danke für deine Einschätzung und das Feedback.
sehr gut. ich habe gerade für einen Sales Kollegen eine einfache Erklärung gesucht. Tolles Kistenmodell. Danke. Goldwert
sehr anschaulich 😆 👍
Also ich bin selber auf Microservices umgestiegen um deren Vorteile zu nutzen. Nur um erstmal das ganze gut Nutzen zu können habe ich mir eine Zwischeninstanz gebastelt die überprüft ob die ganzen Events erfolgreich durchgingen und einen Rollback veranlassen damit man die Konsistenz der Daten behält. Es ist einfacherer und schneller einen Monolithen zu basteln. Es ist auch empfehlenswert wenn man diese ganzen Vorteile von Microservices nicht nutzen will, wie du im Video schon gesagt hattest. Ich bemerke selber einen Trend der zeigt dass alle darauf wechseln wollen weil Netflix und co. auf das ganze setzen und man das nicht verpassen möchte
Ich muss sagen das bei uns unsere Haupt Software ist ein Monolith aber schon sehr sauber organisiert von anfang an macht spaß damit zu arbeiten und unsere "cloud" Funktionen sind alle sehr spezifisch unterteilt teilweise monolithen teilweise "Micro Services" je nachdem was man wie zählt also wir haben um bei spiel eine API die auf eine rout sehr sehr viele Anfragen kriegt und unabhängig vom rest der API agieren kann die ist einzeln implementiert der rest der API ist ein Monolith da wir das ganze nicht so stark scallieren müssen. Ich denke das ein Mix aus beiden sachen der beste Weg ist so ist man an keine Architektur gebunden und kann die Vorteile von beiden Seite mit nehmen es muss aber auch zum Anwendungs Fall passen.
@dustsucker4704 danke für dein Kommentar mit eueren Erfahrungen
Plugins vereinigt die Vorteile beider Welten. Zur Laufzeit ist es ein Monolith. Aber in der Entwicklung kannst die Plugins in einzelnen Teams entwickeln. Du kannst ein einzelnes Plugin austauschen wie einen Microservice. Bei verschiedenen Kunden kannst du unterschiedliche Plugins installieren/lizensieren.
So schade das OSGI quasi gestorben ist. Wir haben unser letztes Projekt mit Apache Karaf begonnen ... war super vielversprechend ...aber nun sind wir sehr glücklich, dass wir davon weg sind: die Idee ist super, aber wenn wichtige Bibliotheken wie Apache Camel nicht mehr OSGI unterstützen, dann kann die Idee und der OSGI Server noch so gut sein.... Jetzt läuft alles in einem super aufgeräumten Monolithen, die CI/CD Pipeline läuft fast von selbst und wir sind glücklich 😅
@@skrrytchWenn man nur eine Installation hat oder alle Installation genau gleich sind, mag das funktionieren.
Entschuldigung für Englisch schreiben, aber mein technische Deutsch ist nicht so gut. Your honesty, objectivity and candor is so refreshing. Microservices was the latest buzzword, just like XML was years ago, when there was a specific need for nothing but a communication standard between applications, yet next thing you know every goddamned thing was xml (I've even seen java code in xml....what the hell?!) So now here we are, recognizing the need for having smaller, more "neural" programs which can be written so they can easily be swapped out, rewritten in more appropriate languages, used by multiple applications maybe, or scaled separately from other parts of the system. Fine, so why have I seen a microservice whose sole purpose was to interface with a database that only one other application needed? Wahnsinn! Why have people just split their monoliths into microservices with absolutely no questions asked about the design benefits? How will you track down a bug? How are you going to trace a problem from 5 different logs on 5 different machines, which you used to easily do with a Ruby script on the monolith's single log file? "Splunk!" they say. Yeah, right. Splunk (another craze by the way) won't do that. Splunk will NEVER do that. And why? Because it does not speak the language of the code, so to speak; it speaks Splunk, which is a generic, glorified grep language. And it's not running on the box, either, so it's way too slow. But let me give another example, something I also saw first-hand that was very serious. There was an upgrade to a microservice that used a database. It passed unit tests, system tests, manual testing. So it went to prod, but it broke, and no one knew could tell why. This was a big deal. So what happened? Well, because the database schema in prod didn't match. Gee, that's crazy. Why was that? Well, because the schema update was officially part of a different microservice which was going out on a different schedule. The two microservices were tracked as separate products, yet shared the same database, so they literally FORGOT to test both of them when one was upgraded. I must say this was shocking, because this would have NEVER happened in the IT world before microservices. If two products used the same db then everyone was well aware that they had to be tested together. The reality is that we have swapped out monoliths, which are like a single individuals that function in a normal, sane manner, have flaws, but can also fix those flaws and improve themselves -- we've swapped these out with multiple individuals, who inherently could care less about one another, are self-centered (by design!), and have poorer communication! So I completely agree; in most cases monoliths are far better. Of course no one will listen, just like they won't listen to any down sides of going to the cloud. IT has gotten worse -- not better -- since the heydays of CMMi.
Hi Bill, thanks for sharing your insights.
Ich kann aus Erfahrung sagen, dass man den Mehraufwand durch Monitoring/Logging/Traceing/Orchestration/... nicht unterschätzen sollte bei Microservices. Das ganze braucht dann noch Service Discovery. Gott bewahre jemand würde eine Container IP in Prometheus hardcoden.
Und neben den Resourcen eines Microservices hat man auch "nicht Business Code". Also den DB Zugriff, die API, Metriken,... und das in jedem Service immer wieder. Dann kommen noch solche Fragen wie TLS, Authentication und Circuit Breaking auf.
Ich glaube viel der Wahrnehmung von Microservices gegenüber Monolithen beruht darauf, dass man davon ausgeht, dass die Entwicklung und der Betrieb von Microservicen optimal verläuft. Meiner Beobachtung nach stammen viele Vorteile aus der Umsetzung der Software und nicht der Architektur oder ihrer Tools. Redundanz/Skalierbarkeit beispielsweise, muss in der Software berücksichtigt werden, ob Monolith oder Microservice.
Danke für deine Erfahrungen und die Beispiele.
Ich betreibe mit einem Freund einen Monolithen und bib generell froh, dass ich mir keine Microservices angetan habe.
Ich hab dabei Tests, Spring und OOP machen vieles einfacher, eine CI/CD pipeline, es läuft mit K8s (wofür ich auch gute Gründe habe, u.a. mit mehreren Instanzen des Monoliths) und es funktioniert gut.
Echt gutes Video!
Noch bevor ich das video angeguckt habe musste ich sofort an stackoverflow denken, deren service läuft auch über ein monolith
6:00 also Microservice Teams müssen auch manchmal miteinander Kommunizieren. Denn manchmal benötigen diese eventuell eine Information mehr von einem anderen Microservice. Bspw. ein Produkt hat einen Preis und bei einem Microservice soll jetzt dieser Preis angezeigt werden also muss man sich doch die Information von denen holen um damit zu arbeiten oder habe ich evt. bei den Microservice Thema was missverstanden
Hi Juus, man versucht die Services möglichst gut zu isolieren und wenige oder keine Abhängigkeiten zu anderen Services zu haben. Mit einem gemeinsamen Event Bus geht das etwas besser, bei gemeinsen Services müssen wie du es beschrieben hast, auch andere Services aufgerufen werden. Dann versucht man durch eine Beschreibung der Schnittstelle die Services zu entkoppeln, so dass die Services zu einem gewissen Grad isoliert weiterentwickelt werden können. Manchmal ist es gut zu kommunizieren, so wie du es beschreibst. Wesentlich ist, dass der Abstimmungsaufwand reduziert wird und nicht die Auslieferung neuer Releases bremst.
Ein anderer Aspekt: Anwender von Software mögen es oft garnicht, wenn sich Funktionalitäten und Oberflächen bewährter Software laufend ändern. Kann man daraus schließen, dass sich Microservices nicht für jede Software, oder nicht für alle Lifecycle-Phasen eignen ? Könnte es aus Effizienzgründen sogar ratsam sein, eine Microservice-Architektur wieder in größere Blöcke zu konsolidieren, sobald sich an Funktionalität und Skalierung nicht mehr viel ändert ?
Hallo Paul, ja aus Gründen der Effizienz oder der Wartbarkeit, kann es sinnvoll sein, zu kleine Microservices in größeren Einheiten zusammenzufassen. Für den Anwender ist es meist nicht direkt ersichtlich, ob er mit einem Monolith oder mit mehreren Microservices arbeitet. Es gibt Techniken und Frameworks, bei denen du eine einheitliche Oberfläche bewahren kannst, obwohl Teile der Oberfläche von verschiedenen Services stammen.
Lol, Golang ist genau für MS gemacht.