Monolith vs Microservice Flashcards
Monolithen
Serverseitiges System basierend auf einer einzigen Anwendung
Ganzes in der Produktionsumgebung bereitgestellt
Muss als Ganzes durch alle Phasen des Continous Delivery Zyklus
Kann interner modular aufgebaut sein –> nur alle Module müssen gemeinsam in Produktion gebracht werden
Microservices
Jede Anwendungsfunktion stellt einen eigenen Dienst dar
Dieser läuft in einem Container
diese kommunizieren dann miteinander
Jedes „Microservice“ soll eine Aufgabe erledigen und das gut
Jeder Service kann unabhängig deployed werden
Eigene Daten pro Service (oder Datenschema)
Monolithen vs. Microservices
Grundsätze Architektur
Kommt auf das Unternehmen und den Anwendungsfall an
Muss das (Business-) Ziel erreichen Ziele klar definieren und priorisieren
Die Organisation & Kenntnisstand sollte betrachtet werden
Jede SWA bietet nur Framework „korrekte“ Umsetzung ist auch erfolgsentscheidend
Wann was? Microservices
Großes Entwickler Team
Erfahrener Software Entwickler
Hohe Komplexität der Software
Viele Nutzer
Skalierbarkeit der Applikation wichtig
Modularität/Erweiterbarkeit der Applikation wichtig
Ersetzung eines Legacy Software
Oftmals Änderung der Unternehmensstruktur
Wann was? Monolithen
Kleines Entwickler Team
Schnelles Deployment
Geringe Komplexität
Gartner Hype Cycle
Nachteile Micro Services
- Organisatorische Veränderungen innerhalb des Teams: Jedes Team muss den gesamten Lebenszyklus eines Microservices abdecken, um vollständig unabhängig zu sein.
- Evtl. Probleme zwischen den Teams, wenn ein Team auf Probleme stößt weil anderes Team etwas nicht implementiert hat
- Höhere Kosten. Microservices sind mit einer höheren Arbeitslast für Betrieb, Bereitstellung und Überwachung verbunden. Dies ist mit einem höheren Betriebsaufwand verbunden. Da Dienste miteinander kommunizieren, kann die daraus resultierende hohe Anzahl von Remoteaufrufen zu höheren Kosten im Zusammenhang mit Netzwerklatenz und -verarbeitung führen
- Die ständigen Änderungen, die an der Architektur erforderlich sind, erfordern viel Aufmerksamkeit und verursachen oft Probleme, insbesondere wenn die Architektur nicht dokumentiert ist
- Evtl. Höhere Komplexität bei Schnittstellenentwurf etc.
- Sicherheit evtl schwerer da Sicherheit für System als Ganzes und für jeden einzelnen Service
Nachteile Monolith
- Hohe Softwarekomplexität (unübersichtlich?)
- In einer zentralisierten Architektur sind die einzelnen Teile stark gekoppelt und voneinander abhängig. Dies führt zu einem einzelnen Fehlerpunkt, der das gesamte System zum Erliegen bringen kann.
- Technologie/Language abhängig
- Weniger einfach Skalierbarkeit und Erweiterbarkeit
Conway’s Law
Das Zusammenspiel der Schnittstellen eines Systems hängt notwendigerweise von der sozialen Struktur einer Organisation ab. Eine mangelnde zwischenmenschliche Kommunikation führt zu einer mangelhaften Lösung.
Der Entwurf von Systemen ist durch die Kommunikationsstrukturen der umsetzenden Organisationen vorbestimmt.
Das Gesetz von Conway basiert auf der Überlegung, dass für die Definition der Schnittstellen zwischen getrennten Softwaremodulen zwischenmenschliche Kommunikation notwendig ist. Daher haben die Kommunikationsstrukturen der Organisationen einen großen Einfluss auf die Strukturen dieser Schnittstellen.
Inverse Conway Maneuver
Dieser mutige Schritt besteht darin, das Conway-Gesetz zu nutzen, um indirekt unsere Endziele zu erreichen: Ihr Unternehmen zu geringeren Kosten zu transformieren, seine Kommunikationsstrukturen zu ändern, um die Entstehung optimaler architektonischer Entwürfe zu beeinflussen. Die wirklich zu stellende Frage ist dann: Was ist die richtige Organisation, um ein bestimmtes architektonisches Ziel zu erreichen?
Da die Organisationsstruktur die Architektur verändert, kann man die Organisationsstruktur an die Architektur anpassen
Wie kann man vorgehen, wenn man ein Altsystem in eine Microservice-Architektur überführen möchte? Welche Voraussetzungen müssen gelten?
https://www.anblicks.com/blog/eight-step-guide-to-migrate-monolithic-applications-into-microservices/
- logische Komponenten erkennen.
- Komponenten refactoren und umgestalten.
- Identifizieren Sie Komponentenabhängigkeiten.
- Komponentengruppen identifizieren.
- Erstellen Sie eine API für das Remote User Interface
- Migrieren Sie Komponentengruppen zu Micro Services (verschieben Sie Komponentengruppen in separate Projekte und führen Sie separate Bereitstellungen durch).
- Migrieren Sie Macroservice zu Microservices.
- Wiederholen Sie die Schritte 6-7, bis Sie fertig sind.
Wie gehe bei einem neuen Projekt vor? Sollte ich sofort mit Microservices starten?
Begründe deine Entscheidung
- Almost all the successful microservice stories have started with a monolith that got too big and was broken up
- Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
- he second issue with starting with microservices is that they only work well if you come up with good, stable boundaries between the services - which is essentially the task of drawing up the right set of BoundedContexts. Any refactoring of functionality between services is much harder than it is in a monolith. But even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning. By building a monolith first, you can figure out what the right boundaries are, before a microservices design brushes a layer of treacle over them. It also gives you time to develop the MicroservicePrerequisites you need for finer-grained services.
- I’ve heard different ways to execute a monolith-first strategy. The logical way is to design a monolith carefully, paying attention to modularity within the software, both at the API boundaries and how the data is stored. Do this well, and it’s a relatively simple matter to make the shift to microservices.
- A more common approach is to start with a monolith and gradually peel off microservices at the edges. Such an approach can leave a substantial monolith at the heart of the microservices architecture, but with most new development occurring in the microservices while the monolith is relatively quiescent.
- While the bulk of my contacts lean toward the monolith-first approach, it is by no means unanimous. The counter argument says that starting with microservices allows you to get used to the rhythm of developing in a microservice environment. It takes a lot, perhaps too much, discipline to build a monolith in a sufficiently modular way that it can be broken down into microservices easily. By starting with microservices you get everyone used to developing in separate small teams from the beginning, and having teams separated by service boundaries makes it much easier to scale up the development effort when you need to.
• To decide between the two, we should first nail down what exactly we mean by “monolith” and “microservice”.
• “System architectures lie on a spectrum.” Zachary Crockett, CTO of Particle told me during an interview.
• “When discussing microservices, people tend to focus on one end of that spectrum: many tiny applications passing too many messages to each other. At the other end of the spectrum you have a giant monolith doing too many things. For any real system, there are many possible service oriented architectures between those two extremes.” he explained.
When to potentially start with a MS directly
• In Familiar Territory
• Prepared and Experienced Team with MS
• Infrastructure is Cloud based
When not to do so
• Your Team Is At Founding Stage: Your team is small, between 2-5 members, and is thus unable to tackle a broader and high-overhead microservices architecture.
• You’re Building An Unproven Product or Proof of Concept
• You Have No Microservices Experience
https://buttercms.com/books/microservices-for-startups/should-you-always-start-with-a-monolith
