Microservices

• Bei Microservices teilt man Software in verschieden Dienste auf. Warum macht man das und was sind die Vorteile?
  • Man erstellt eine Dienst pro Business Entity oder pro ein Teil von Funkionalitaet (fuer ein Geschaeftfeld)
  • Diese Dienste haben eine einfache Struktur, im Vergleich zu Monoliten. Die Komplexitaet steckt nicht mehr in Code, sondern in Kommunikation zwischen Microservices.
  • Diese Kommunikation ist normalerweise ueber REST (heute auch ueber GraphQL) gestaltet und ist leichtgewichtig.
  • Man ist frei in Technologieauswahl fuer jedes Microservice, was aber auch eigene Nachteile hat. Man kann passende Datenbanktechnologien und Frameworks aufwaehlen.
  • Man kann sehr leicht neue Funktionalieat hinzufuegen
  • Wiederverwendung bei Microservices ist ein riesen Vorteil. Die sind klein und kapseln ein Stueck von Business Logik, die kann fuer viele Projekte parallel benutzt werden.
• Welche Eigenschaften haben Microservices?
  • Unabhaengige Entwicklung, ein Team kuemmert sich um eigenes Microservice
  • CI/CD und unabhaengiges Deployment
  • Man kann verschiedene Sprachen verwenden
  • Eigene Datenbanken - Decentralized Data Management
  • Elastizitaet - System kann sich automatisch an Load skalieren, meist horizontal
• What is Design for Failure?
  • System ist mit der Annahme gebaut, dasss die einzigen Komponenten ausfallen koenten.
  • Solche Ausfaelle sollen schnell automatisch erkannt und repariert werden.
  • Verschiedene Metriken werden kontinuerlich von allen Microservices gesammelt, Is Alive, Ressorcen, Last
• Ein Beispiel geben, wo Microservices gut sind
  • In allen Bereichen, wo die Funktionalietaet sich rapid Aendern kann. Bei Produkten, die kurze Productuion Cycles haben.
• Ein Beispiel geben, wo Microservice ungeeignet sind
  • Microservices sind dann schlecht, wenn die Funktionalietat sich selten aendert, und mann will auch moeglicht wenig verschieden Sprachen und Technologien haben. Zum beispiel in Embedded Software.
• Was sind die Nachteile von unterschiedlichen Sprachen in Microservices?
  • Kommunikationsprobleme zwischen Teams, schwierigere Knowledge Sharing, Personalprobleme. Wird man in Web das Frontend in HTML, CSS, JS mit Framework Vue schreiben und Backend mit Python entwickeln mit einem Framework und ORM, und als Datenbank immer PostgreSQL nehmen, waere es viel leichter die Entwicklern zwischen Teams zu schieben, und neue Entwicklern zu hiren.
  • Wird es entschieden, dass man ein Microservice in Lisp implementiert, und Zweite mit Haskell, und Dritte mit C++, und dann noch 5 Sprachen, und 3 Web Frameworks, dann wird die Situation sehr gefaehrlich fuer Management.
• Was unterscheidet Microservices von anderen servicebasierten Architekturen?
  • Bei Microservices wird normalerweise die Kommunikation ueber HTTP verwendet.
  • Bei SOA wird die Kommunikation oft ueber eigenen XML-basierten Protocoll gestaltet.
  • Die Microservices sind feingranularer und kleiner, SOA Services sind relativ gross und komplex
  • In SOA wird man normalerweise alle services auf einem Server deployen, Microservices laufen normalerweise in eigenen Containers. Microservices sind also sehr stark von Deployment-Infrastruktur abstrahiert.
• Wo hat man hauefiger verschiedene Sprachen, bei Microservices oder bei Schicten?
  • Bei Schichten hat man immer verschiedene Stacks pro Schicht. Bei Microservices wird es normalerweise weniger Sprachen geben, aber kann auch mehrere sein.
• Wieso werden Microservices heute so hauefig verwendet?
  • Man kann leicht die neue Funktionalitaet hinzufuegen, Integration und QA Aufwand ist auch niedriger
  • Eignet sich sehr gut fuer dynamische Projekte
• Wie is das, wenn Sie bei Microservices neue Funktionalitaet hinzufuegen wollen?
  • Es wird entweder das neue Microservice erstellt, oder schon ein vorhandenes Microservice wird modifizert (und eventuell neue API-Version erstellt).
• Angenommen, wir haben einige Microservices die voreinanger abhaengen, wo kann es zu Probleme fuehren?
  • Es wird oft passieren, dann ein Microservice auf Datenbanken von anderen Microservices zugreifen muss.
  • Dann hat man zwei Moeglichkeiten:
    • Datenbank in jedem Microservice zu replizieren, dann kommt aber Syncronisationsoverhead und andere Datenkonsistenz-Aufgaben.
    • Ein Microservice mit diesem Datenbank erstellten und lassen anderen Microservices dieses Datenbank-Microservice benutzen, was kann potenziell ein Bottleneck und Single Point of Failure erstellen
• Was waere wenn man in einem Microservice basierten Projekt eine Technologie aendern muesste?
  • Dann muss man viele Microservices anpassen, und diese Anpassungen werden separat in verschiedenen Teams passieren.
  • Mit Schichtenarchitektur waere es einfacher.
• Wenn Sie Microservices machen wollen und jemand in Team ist voll gut mit Clean Architecture und will das verwenden, was machen Sie dann?
  • Man kann in jedem Microservice Clean Architecture bauen

Schictenarchitektur

• Fat Client vs Thin Client
  • Fat Client: Daten sind auf Client-Side bearbeitet (zB Datenverarbeitung auf dem Client)
  • Thin Client: Funktionalitaet von Client ist nur IO (zB nur REST calls to BFF)
• Ist die 3 Schichten Architektur immer in verschieden Sprachen implementiert?
  • Normalerweise gibt es bei 3 Schichten Architektur immer die Trennung zwischen UI, Business Logik und Datenbank, daraus ergeben sich klassisch Sprachgebiete.
• Wann bieter es sich an, eine Schitenarchitektur zu nehmen?
  • Wenn die Funktionalietaet sich nicht oft wechselt, die Technologie aber schon.
• Wenn Sie jetzt mal eine 3-Schichten Architektur betrachten, wo wird die Dependency Rule verletzt?
  • Businesslogik ist oft direkt von Datenbanktechnologie abhaengig. Um es zu reparieren, muss man ein Interface fuer Datenbank erstellen (zB ein ORM nehmen) und dann in Business Logik nur mit Business Entities arbeiten (und keine SQL Abfragen mehr in code Schreiben).
• Wie is das, wenn Sie bei Schictenarchitektur neue Funktionalitaet hinzufuegen wollen?
  • Dann wird man alle Schichten anpassen muessen.
  • Mit Microservices waere es einfacher.