Microservices, aber in gut?

Microservices, aber in gut?

Why it is smart to start investing in the stock market?

Lorem ipsum dolor sit amet, consectetur adipiscing elit lobortis arcu enim urna adipiscing praesent velit viverra sit semper lorem eu cursus vel hendrerit elementum morbi curabitur etiam nibh justo, lorem aliquet donec sed sit mi dignissim at ante massa mattis.

  1. Neque sodales ut etiam sit amet nisl purus non tellus orci ac auctor
  2. Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti
  3. Mauris commodo quis imperdiet massa tincidunt nunc pulvinar
  4. Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti

Should I be a trader to invest in the stock market?

Vitae congue eu consequat ac felis placerat vestibulum lectus mauris ultrices cursus sit amet dictum sit amet justo donec enim diam porttitor lacus luctus accumsan tortor posuere praesent tristique magna sit amet purus gravida quis blandit turpis.

Odio facilisis mauris sit amet massa vitae tortor.

What app should I use to invest in the stock market?

At risus viverra adipiscing at in tellus integer feugiat nisl pretium fusce id velit ut tortor sagittis orci a scelerisque purus semper eget at lectus urna duis convallis. porta nibh venenatis cras sed felis eget neque laoreet suspendisse interdum consectetur libero id faucibus nisl donec pretium vulputate sapien nec sagittis aliquam nunc lobortis mattis aliquam faucibus purus in.

  • Neque sodales ut etiam sit amet nisl purus non tellus orci ac auctor
  • Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti
  • Mauris commodo quis imperdiet massa tincidunt nunc pulvinar
  • Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti
Is it risky to invest in the stock market? If so, how much?

Nisi quis eleifend quam adipiscing vitae aliquet bibendum enim facilisis gravida neque. Velit euismod in pellentesque massa placerat volutpat lacus laoreet non curabitur gravida odio aenean sed adipiscing diam donec adipiscing tristique risus. amet est placerat in egestas erat imperdiet sed euismod nisi.

“Nisi quis eleifend quam adipiscing vitae aliquet bibendum enim facilisis gravida neque velit euismod in pellentesque massa placerat.”
Tell us if you are already investing in the stock market

Eget lorem dolor sed viverra ipsum nunc aliquet bibendum felis donec et odio pellentesque diam volutpat commodo sed egestas aliquam sem fringilla ut morbi tincidunt augue interdum velit euismod eu tincidunt tortor aliquam nulla facilisi aenean sed adipiscing diam donec adipiscing ut lectus arcu bibendum at varius vel pharetra nibh venenatis cras sed felis eget.

Die Softwarelandschaft ist übersäht von serviceorientierten Architekturen. Monolithen gelten als “nicht mehr State of the Art” – Heute “macht man halt Microservices”. Außer Acht gelassen wird jedoch der Aspekt, dass man es richtig machen muss, um tatsächlich einen Nutzen aus dieser Architektur zu ziehen. Folgender Artikel gibt einen Überblick über die Qualitätskriterien, die dazu erfüllt werden sollten.


WAS HAT DAS THEMA BEI UNS AUF DEN TISCH GEBRACHT?

Während der Zusammenarbeit mit einem Kunden entstand innerhalb des ersten Jahres eine monolithische Struktur. Gerade zu Beginn hatte die Entwicklung in dieser Form viele Vorteile: Nur ein Projekt muss erstellt und deploy- sowie lauffähig gemacht werden. Auch lokal lässt sich die Anwendung fix starten, weil nur einer statt zahlreicher Services involviert sind. Zudem nutzt das gesamte Entwicklerteam denselben Tech-Stack und die gesamte Domäne ist zugreifbar.

Klingt In der Theorie super, und auch wenn Monolithen in der Praxis nicht per se eine unsaubere Architektur bedeuten erinnert das Ergebnis in der Realität meist leider doch an Pasta statt sauber getrennten Bereichen. Zwar stellten wir über Codestyle-Regeln sicher, dass die beinhalteten Domänen voneinander getrennt blieben, für eine parallele Entwicklung mit zwei Entwicklerteams reichte das jedoch nicht mehr aus: Mittelgroße Refactorings des einen Teams blockierten das andere, Kommunikation wie auch Absprachen fraßen unsere Zeit und bei Deployments konnte man entspannt einmal um den Block spazieren.

Für eine strikte Trennung der Teams entschieden wir uns dazu, den Monolithen in mehrere Teile zu zerlegen. Im Zuge dessen beschäftigten wir uns mit der Frage, welche Kriterien Microservices erfüllen sollten, um einen positiven Beitrag zur Softwarequalität zu leisten. Denn bei unbedachtem Vorgehen wird aus einem “Ball of mud” leider eine Gruppe verteilter “balls of mud”:

WAS TUN, UM DAS ZU VERHINDERN?

Generell muss die Entscheidung für eine Software-Architektur immer im Kontext des Anwendungsfalls getroffen werden. Soll beispielsweise innerhalb einiger Wochen ein Prototyp auf die Beine gestellt werden, ist das Investment in Microservices nicht die beste Idee. Fällt die Wahl begründet auf Microservices, weil beispielsweise die unabhängige Skalierung einzelner Teile der Applikation von Bedeutung ist, sollten bestimmte Kriterien berücksichtigt werden. Andernfalls wird die Komplexität eines verteilten Systems eingekauft, ohne im Gegenzug daraus Profit zu schlagen.


AUSGEREIFTE INFRASTRUKTUR

Zunächst muss die Komplexität des verteilten Systems bewältigt werden. Um eine schnelle und effiziente Entwicklung sicherzustellen, ist eine ausgereifte Infrastruktur unabdinglich. Diese umfasst unter anderem die Automatisierung des Systems auf Ebenen wie Delivery und Deployment, Load Balancing mit Service Discovery sowie Monitoring.


PASSENDE ABGRENZUNG

Nicht nur das Was, sondern ebenso das Wie ist ausschlaggebend, um zwischen den Services eine passende Abgrenzung zu treffen getroffen. Ziel ist hier die lose Kopplung, um möglichst wenig Abhängigkeiten zwischen den Services zu erhalten. Jeder einzelne Service soll zudem über hohe Kohäsion verfügen und demnach Funktionalität in Gänze umsetzen. Zur Abgrenzung der Services stellt das DDD eine ganze Kiste an Werkzeugen bereit.


UNABHÄNGIGKEIT

Es genügt nicht nur, den Code in separate Repositories aufzuteilen. Ein System mit zehn getrennten Services kann noch immer einen Monolithen darstellen, wenn alles gemeinsam deployed werden muss. Anzustreben ist also nicht nur unabhängiger Code, sondern auch ein unabhängiges Deployment. Ebenso zu vermeiden sind Laufzeit-Monolithen. Passende Technologien Die getrennte Code-Basis und unabhängig lauffähige Applikationen machen es möglich, dem Verwendungszweck entsprechende Technologien zu nutzen. Diese sollte bedacht gewählt und die Gefahr des Technologiepluralismus gegengerechnet werden.


KOMMUNIKATION UND REAKTION

Je loser die Komponenten gekoppelt sind, desto weniger Kommunikation muss stattfinden. Komplett darauf verzichten lässt sich meist jedoch nicht. Dann gilt die “asynchron first”-Devise aus dem Reactive Manifesto, nach der Daten bevorzugt über Nachrichten ausgetauscht werden sollen. Das Manifest definiert zudem weitere Kriterien reaktiver Systeme: Antwortbereitschaft, Widerstandsfähigkeit, Elastizität (also die Anpassungsfähigkeit auf sich ändernde Lasten) sowie Wartbar- und Erweiterbarkeit. Im Grunde zahlen alle der Punkte auf die Reaktionsfähigkeit ein.


FEHLERTOLERANZ

Ein zusammengesetztes System bietet natürlich zahlreiche Punkte, an denen etwas kaputt gehen kann. Hier sollte ein Auge auf der Fehlertoleranz liegen: Ist ein Service langsam oder gar ausgefallen, sollte der Rest des Systems weiter funktionieren. Der Chaos Monkey von Netflix zielt genau hierauf ab und setzt einzelne Komponenten außer Gefecht, um sich ausbreitende Fehlerquellen zu identifizieren. Denkbar wäre der Einsatz von Caching, um als Fallback-Mechanismus auf zuvor abgefragte Daten zurückzugreifen, oder der Einsatz von Circuit Breakern, um dem Nutzer eine schnellere Antwort zu liefern und im Gegenzug Regenerationszeit einzukaufen.


ZUSTAND UND DATENHALTUNG

Ohne das Vorhandensein eines Zustands können ohne Probleme mehrere Instanzen eines Services gestartet werden. Zustandslosigkeit ist demnach ein anzustrebender Aspekt. Problematisch wird es jedoch, wenn mehrere Instanzen einen eigenen Zustand verwalten, der zudem synchronisiert werden muss.

ZUSAMMENFASSUNG

Die Qualitätskriterien in Kürze:

  • Eine ausgereifte Infrastruktur zur Bewältigung des verteilten Systems
  • Unabhängige Deploybarkeit der Komponenten
  • Passende Technologien mit Berücksichtigung des Technologiepluralismus
  • Änderbarkeit der Komponenten
  • Eine passende Abgrenzung, mit dem Ziel der losen Kopplung und einer hohen Kohäsion
  • Möglichst geringer Kommunikationsaufwand
  • Reaktionsfähigkeit und Fehlertoleranz des Systems
  • Zustandslosigkeit sowie eine verteilte Datenhaltung

Nicht alle der oben genannten Kriterien können zu jedem Zeitpunkt erfüllt werden, deren Berücksichtigung erhöht aber die Chance darauf, statt bei “distributed balls of mud” bei einer (mehr oder weniger) wohlgeformten Architektur zu landen:

Werden obige Punkte bei der Einleitung einer verteilten Architektur berücksichtigt, stehen die Chancen gut mit Microservices einen Zugewinn zu erlangen. Unser erster Schritt im anfangs erwähnten Projekt war das Heraustrennen eines ersten Microservices aus dem Monolithen. Dabei implementierten wir die Basis für eine serviceorientierte Architektur und stellten die Infrastruktur zur Kommunikation zwischen unabhängigen Komponenten bereit. Fortan wurden neue funktionale Bestandteile direkt als Microservices umgesetzt und Stück für Stück weitere Bereiche aus dem Monolithen herausgelöst.


LINKS

About the author
Subscribe To Our Newsletter - Bnkly X Webflow Template

Subscribe to our newsletter

Thanks for joining our newsletter
Oops! Something went wrong while submitting the form.