Beste Architektur für MVP: Monolith, SOA, Microservices oder Serverless? Teil 2

Im November startet OTUS ein neues Bildungsprogramm, "Software Architect". In diesem Zusammenhang setzen wir eine Reihe von Veröffentlichungen für zukünftige Kursteilnehmer und Leser unseres Blogs fort.

Lesen Sie den ersten Teil


Microservice-Architektur


Microservices sind eine Art serviceorientierter Software-Architektur, die sich darauf konzentriert, eine Reihe von eigenständigen Komponenten zu erstellen, aus denen die Anwendung besteht. Im Gegensatz zu monolithischen Anwendungen, die als Ganzes erstellt wurden, bestehen Microservice-Anwendungen aus mehreren unabhängigen Komponenten, die über die API miteinander verbunden sind.


Die Struktur von Mikrodiensten und die monolithische Architektur im Vergleich

Der Microservice-Ansatz konzentriert sich in erster Linie auf Geschäftsprioritäten und -chancen, während der monolithische Ansatz nach Technologieebenen, Benutzeroberflächen und Datenbanken organisiert ist. Der Microservice-Ansatz hat sich in den letzten Jahren zu einem Trend entwickelt, da immer mehr Unternehmen flexibler werden und zu DevOps wechseln.

Microservices sind einfach deshalb wichtig, weil sie durch die Vereinfachung von Systemen einen einzigartigen Kundennutzen schaffen. Indem Sie Ihr System oder Ihre Anwendung in viele kleinere Teile aufteilen, können Sie die Duplizierung reduzieren, die Konsistenz erhöhen und die Kommunikation zwischen Teilen verringern, wodurch Ihre gemeinsamen Teile des Systems verständlicher, skalierbarer und einfacher zu ändern sind.
Lucas Kraus, Autor von Microservices


Es gibt viele Beispiele für Unternehmen, die sich von einem monolithischen Ansatz zu Mikrodienstleistungen entwickelt haben. Zu den bekanntesten zählen Netflix, Amazon, Twitter, eBay und PayPal. Um festzustellen, ob Microservices für Ihr Projekt geeignet sind, identifizieren wir die Vor- und Nachteile dieses Ansatzes.

Vorteile von Microservices


Einfach zu entwickeln, zu testen und bereitzustellen


Der größte Vorteil von Microservices gegenüber anderen Architekturen besteht darin, dass kleine Einzeldienste unabhängig voneinander erstellt, getestet und bereitgestellt werden können. Da die Bereitstellungseinheit klein ist, wird die Entwicklung und Veröffentlichung einfacher und schneller. Darüber hinaus ist die Freigabe einer Einheit nicht auf die Freigabe einer anderen Einheit beschränkt, die noch nicht abgeschlossen ist. Das letzte Plus ist, dass das Bereitstellungsrisiko verringert wird, wenn Entwickler Teile der Software freigeben, nicht die gesamte Anwendung.

Erhöhte Flexibilität


Mithilfe von Microservices können mehrere Teams unabhängig und schnell an ihren Diensten arbeiten. Jeder einzelne Teil der Anwendung kann aufgrund der Isolierung von Mikrodienstkomponenten unabhängig erstellt werden. Sie haben beispielsweise ein Team von 100 Mitarbeitern, die an der gesamten Anwendung arbeiten (wie bei einem monolithischen Ansatz), oder Sie haben 10 Teams von 10 Mitarbeitern, die verschiedene Dienste entwickeln.
Stellen wir es uns visuell vor.



Dank der erhöhten Flexibilität können Entwickler Systemkomponenten aktualisieren, ohne die Anwendung herunterfahren zu müssen. Darüber hinaus bietet Flexibilität einen sichereren Bereitstellungsprozess und eine längere Betriebszeit. Neue Funktionen können nach Bedarf hinzugefügt werden, ohne auf den Start der gesamten Anwendung zu warten.

Die Fähigkeit, horizontal zu skalieren


Die vertikale Skalierung (mit derselben Software, aber auf leistungsstärkeren Computern) kann durch die Bandbreite der einzelnen Dienste begrenzt sein. Die horizontale Skalierung (Erstellen von mehr Diensten in einem Pool) ist jedoch nicht beschränkt und kann dynamisch mit Mikrodiensten arbeiten. Darüber hinaus kann die horizontale Skalierung vollständig automatisiert werden.

Nachteile von Microservices


Schwierigkeit


Der größte Nachteil von Microservices ist ihre Komplexität. Die Aufteilung der Anwendung in unabhängige Mikrodienste bringt mehr Kontrollartefakte mit sich. Diese Art von Architektur erfordert sorgfältige Planung, enormen Aufwand, Teamressourcen und Fähigkeiten. Die Gründe für die hohe Komplexität sind folgende:

  • Erhöhter Automatisierungsbedarf, da jeder Service überprüft und gesteuert werden muss
  • Verfügbare Tools funktionieren nicht mit Dienstabhängigkeiten
  • Die Datenkonsistenz und das Transaktionsmanagement werden schwieriger, da jeder Dienst über eine Datenbank verfügt

Sicherheitsbedenken


In einer Microservice-Anwendung erhöht jede Funktionalität, die von außen über die API interagiert, die Wahrscheinlichkeit von Angriffen. Diese Angriffe können nur auftreten, wenn beim Erstellen der Anwendung nicht die richtigen Sicherheitsmaßnahmen ergriffen werden.

Verschiedene Programmiersprachen


Die Möglichkeit, verschiedene Programmiersprachen zu wählen, ist ein zweischneidiges Schwert. Die Verwendung verschiedener Sprachen erschwert die Bereitstellung. Außerdem ist es schwieriger, Programmierer zwischen Entwicklungsstadien zu wechseln, wenn jeder Dienst in einer anderen Sprache geschrieben ist.

Zusammenfassend


Microservices sind gut, aber nicht für alle Arten von Anwendungen. Diese Vorlage eignet sich hervorragend für die Entwicklung von Anwendungen und komplexen Systemen. Sie können sich überlegen, eine Microservice-Architektur auszuwählen, wenn Sie über mehrere erfahrene Teams verfügen und die Anwendung komplex genug ist, um sie in Services aufzuteilen. Wenn eine Anwendung groß ist und flexibel und skalierbar sein muss, ist eine Microservice-Architektur von Vorteil.

Jetzt können wir diese drei Softwarearchitekturen vergleichen, um die Unterschiede zwischen ihnen visuell zu identifizieren.



Monolithische Anwendungen bestehen aus voneinander abhängigen, unteilbaren Blöcken und weisen eine sehr niedrige Entwicklungsgeschwindigkeit auf. SOA gliedert sich in kleinere, mäßig verwandte Dienste und entwickelt sich nur langsam. Microservices sind sehr kleine, lose gekoppelte unabhängige Dienste, die sich durch schnelle Entwicklung und kontinuierliche Integration auszeichnen.

Serverlose Architektur


Die serverlose Architektur ist ein Cloud-Computing-Ansatz zum Erstellen und Ausführen von Anwendungen und Diensten, ohne dass eine Infrastrukturverwaltung erforderlich ist. In serverlosen Anwendungen erfolgt die Codeausführung plattformgesteuert, sodass Entwickler Code bereitstellen können, ohne sich um Serverwartung und -wartung kümmern zu müssen. In der Tat bedeutet Serverlosigkeit nicht "kein Server". Die Anwendung wird weiterhin auf den Servern ausgeführt, aber ein Cloud-Dienst eines Drittanbieters wie AWS ist für diese Server voll verantwortlich. Serverlose Architektur macht zusätzliche Ressourcen, Anwendungsskalierung, Serverwartung sowie Speicher- und Datenbanksysteme überflüssig.

Die serverlose Architektur umfasst zwei Konzepte:

  • FaaS (Function as a Service) ist ein Cloud-Computing-Modell, mit dem Entwickler Teile der Funktionalität in die Cloud hochladen und diese Teile unabhängig voneinander ausführen können
  • BaaS (Backend as a Service) ist ein Cloud-Computing-Modell, mit dem Entwickler Backend-Aspekte (Datenbankverwaltung, Cloud-Speicher, Hosting, Benutzerauthentifizierung usw.) auslagern sowie nur Teile schreiben und unterstützen können externe Schnittstelle.


So sieht eine serverlose Struktur aus

Mithilfe einer serverlosen Architektur können sich Entwickler auf das Produkt selbst konzentrieren, ohne sich um die Serververwaltung oder die Laufzeiten kümmern zu müssen. Dies ermöglicht Entwicklern, sich auf die Entwicklung von Produkten mit hoher Zuverlässigkeit und Skalierbarkeit zu konzentrieren.

Es gibt viele Cloud-Lösungsanbieter auf dem Markt. Hier sind einige der führenden Serverless-Computing-Anbieter:


Führende Serverless-Computing-Anbieter

Um herauszufinden, ob diese Art von Architektur für Ihr Projekt erforderlich ist, ermitteln wir die Vor- und Nachteile der Implementierung eines Modells ohne Server.

Vorteile der serverlosen Architektur


Einfach bereitzustellen


In serverlosen Anwendungen müssen sich Entwickler keine Gedanken über die Infrastruktur machen. Dadurch können sie sich auf den Code selbst konzentrieren. Dank der serverlosen Architektur können Sie eine Anwendung schnell bereitstellen, da die Bereitstellung nur wenige Stunden oder Tage dauert (im Vergleich zu Tagen oder Wochen mit dem herkömmlichen Ansatz).

Kostensenkung


Der Umstieg auf eine serverlose Architektur senkt die Kosten. Da Sie keine Datenbanken, keine Logik und keine Server verarbeiten müssen, können Sie nicht nur besseren Code erstellen, sondern auch die Kosten senken. Wenn Sie ein Modell ohne Server verwenden, zahlen Sie nur für die tatsächlich verwendeten CPU-Zyklen und den tatsächlich verwendeten Arbeitsspeicher.

Verbesserte Skalierbarkeit


Viele Geschäftsinhaber möchten, dass ihre Apps leistungsstark und skalierbar sind, z. B. Google oder Facebook. Serverloses Computing macht die Skalierung automatisch und reibungslos. Ihre Anwendung wird automatisch skaliert, wenn sich die Last oder die Benutzerbasis erhöht, ohne die Leistung zu beeinträchtigen. Serverlose Anwendungen können eine große Anzahl von Anforderungen verarbeiten, während herkömmliche Anwendungen mit ihrem plötzlichen Anstieg überlastet werden.

Nachteile der serverlosen Architektur


Lieferantenbindung


Die Lieferantenbindung beschreibt eine Situation, in der Sie dem Lieferanten die vollständige Kontrolle über Ihre Abläufe geben. Infolgedessen sind Änderungen in der Geschäftslogik begrenzt, und die Migration von einem Anbieter zu einem anderen kann schwierig sein.

Nicht für langfristige Aufgaben.


Das serverlose Modell ist nicht für lange Vorgänge geeignet. Serverlose Anwendungen eignen sich für kurze Prozesse in Echtzeit. Dauert die Aufgabe jedoch länger als fünf Minuten, sind für die serverlose Anwendung zusätzliche FaaS-Funktionen erforderlich.

Zusammenfassend


Die serverlose Softwarearchitektur ist nützlich, um einmalige Aufgaben zu lösen und Prozesse zu unterstützen. Es eignet sich hervorragend für kundenintensive Anwendungen und Anwendungen, die schnell wachsen und unbegrenzte Skalierbarkeit benötigen.

Schauen wir uns zum Schluss das folgende Bild an, um herauszufinden, wann diese vier Architekturtypen ausgewählt werden sollen:



Die Auswahl der richtigen Architektur für Ihr MVP ist eine Herausforderung. RubyGarage verfügt jedoch über langjährige Erfahrung, um Ihnen bei der Auswahl zu helfen. Der Autor des Artikels beantwortet gerne alle Ihre Fragen zu diesem Thema.

Source: https://habr.com/ru/post/de477930/


All Articles