Wie bringe ich meine bestehende Anwendung oder neue Idee in die Cloud? Was sind die Vorteile? Was die Nachteile? Diese Fragen beschäftigen sowohl etablierte Unternehmen als auch Jung-Unternehmer. In diesem Artikel beschreibe ich unsere Erfahrungen mit modernen SaaS-, Single-Mandanten- und Multi-Mandanten-Architekturen.
Mein Ziel ist hierbei, einen kurzen Überblick zu geben, welche Möglichkeiten es gibt, um ein bestehendes oder neues System in eine zeitgemäße IT-Architektur einzubetten.
Ich möchte diesen Artikel kurz und übersichtlich halten und dennoch einen Startpunkt für erste Überlegungen hin zu einer Cloud-Architektur-Strategie geben.
Da die Bedürfnisse für eine Cloud-Architektur sehr individuell sind, möchte ich bei Fragen gerne auf die Kommentarsektion verweisen.
Monolithische Architektur
Das fast schon “klassische” Cloud-Modell ist ein monolithischer Systemaufbau. Hierbei ist das System von außen betrachtet ein großes, in sich geschlossenes System, das bei einem Cloud-Anbieter, wie z. B. Amazon, Microsoft Azure oder in der Google Cloud betrieben wird.
Fast kein System ist allerdings vollständig monolithisch. Oft sind auch bei monolithischen Systemen zumindest Datenbank und Applikation Server voneinander getrennt.
Monolithische Systeme genießen, teilweise unberechtigter Weise, einen eher schlechten Ruf.
Ein Vorteil monolithischen System ist, dass Deployments, also das Ausrollen/Installieren von Updates, oftmals recht einfach vonstatten geht, da man es mit sehr wenigen Systemkomponenten zu tun hat und man nur ein System beachten muss.
Wenn das System bei einem Cloud-Anbieter gehostet wird, können auch bei monolithischen Systemen Vorteile gegenüber “klassischen” Hostern (z.B. Root Server, Colocation) entstehen. So lassen sich monolithische Systeme in der Cloud, durch Erhöhung der Leistung einer Maschine, dynamisch vertikal skalieren (scale up). Monolithische Systeme lassen sich unter bestimmten Umständen auch horizontal skalieren. Z.B. durch die Verwendung von Load-Balancern.
Dies kann vor allem bei Prototypen oder auch sog. Minimum Viable Products (MVP zu dt. „minimal überlebensfähiges Produkt“) in Frühphasen einen immensen Geschwindigkeitsvorteil bei der Weiterentwicklung bringen.
Wichtig ist hierbei aber, dass die Anwendung softwaretechnisch nicht eng gekoppelt sein sollte. Das heißt, dass softwaretechnische Prinzipien wie lose Kopplung, Inversion of Control, Clean Code, etc. Anwendung finden, um bei Bedarf das System auseinander ziehen zu können.
Gründe für das Auslagern von Systemkomponenten sind z. B. horizontale Skalierung oder Wartbarkeit. Dies bringt uns zum nächsten Architekturmodell.
Microservice Architektur
Wenn man mit einem monolithischen System, z. B. aus Gründen der Skalierung oder Wartbarkeit, an seine Grenzen stößt, macht es Sinn, das System auseinander zu ziehen. Ein Ansatz ist hierbei das System in sogenannte Microservices aufzuteilen. Der Begriff Microservices ist nicht klar definiert. Dies ist aus meiner Sicht auch nicht allzu wichtig. Wichtig für eine Anwendungsarchitektur ist, dass man sie nach den Kriterien aufteilt, die für den eigenen Anwendungsfall am meisten Sinn macht.
Ein Beispiel: Eine Anwendung ist monolithischer Natur und die Performance ist gut. Allerdings soll ein Single Sign-On (SSO zu dt.: Einmalanmeldung) und ein Office 365 Login eingebaut werden. An der Stelle macht es Sinn, das Identitätsmanagement (Autorisierung, Authentifizierung, Login, Registrierung, Passwort-Reset, usw.) zu extrahieren und in einen eigenen Dienst (Microservice) zu überführen.
Auf diese Art und Weise ließen sich auch weitere Komponenten des Systems extrahieren, wie z. B. Content-Delivery-Networks, Such-Services, Event-Queue-Services, etc.
Der Vorteil dieses Modells ist, dass man basierend auf dem eigenen Bedarf Dienste extrahieren oder zusammenziehen kann. Hier sollte immer das Spannungsfeld zwischen Wartbarkeit und Flexibilität betrachtet werden.
Microservice-Architekturen lass sich in der Regel etwas einfacher skalieren, als monolithische Systeme, da die einzelnen Services gezielt skaliert werden können. Systeme mit Microservices lassen sich je nach Aufbau sowohl vertikal als auch horizontal skalieren. Durch Erhöhung der Leistung eines Service oder durch die Parallelisierung von Services.
Im verlinkten Artikel beschreibe ich, wie wir eine bestehende monolithische Abwendung, die wir entwickelt haben, in eine modulare Architektur überführt haben (Hier auch noch einmal in englischer Sprache).
Multi-Mandant (SaaS) und Single-Mandant
Für viele Geschäftsmodelle stellt sich zusätzlich die Frage, ob es Sinn macht ein Multi-Mandant /Software as a Service (SaaS) Geschäftsmodell oder ein Single-Mandant-Modell zu verfolgen.
Multi-Mandant (SaaS)
Ein großer Vorteil einer Multi-Mandant-Architektur ist, dass sich mehrere Nutzer Infrastrukturressourcen sowie Softwareaktualisierungen teilen und Datensicherungen zentral vorgenommen werden können. So können Skaleneffekte bei Infrastrukturkosten und Wartung gehoben werden.
Die Sicherheit in Bezug auf Datentrennung unter den Mandanten wird bei dem Multi-Mandant-Model dadurch sichergestellt, dass bei jedem Nutzer-aufruf im Sicherheitskontext die Mandanten-Kennung validiert wird. Unser präferierter Weg diese Sicherheit zu gewährleisten, ist die Verwendung von modernen Identitätsmanagement-Mechanismen, wie OAuth2/OpenID-Connect.
Trotz der sehr guten Schutzmöglichkeiten hegen einige Kunden bei diesem Betriebsmodell Datenschutz- und Sicherheitsbedenken. Hier gilt es abzuwägen, was der genaue Bedarf der Kunden ist.
Single-Mandant
Grundsätzlich ist es möglich, eine voll cloud-basierte Microservice-Architektur auch für Einzel-Mandanten zu betreiben. Es ist als Softwareanbieter an dieser Stelle ebenfalls möglich zweigleisig zu fahren.
Konkret kann dies so aussehen, dass preissensitivere Kunden gemeinsam auf einem Multi-Mandaten-System agieren, während Kunden mit gesonderten Ansprüchen auf einem Einzelsystem (Single-Mandant) arbeiten.
Zusätzlich zu den hier gezeigten Beispielen gibt es auch Mischformen. So kann zum Beispiel eine “physische” Datentrennung hergestellt werden, indem jeder Mandant eine eigene Datenbank erhält, aber alle Mandanten die Application Server und Services teilen.
Fazit
Die Möglichkeiten zum sicheren und kosteneffizienten Betreiben von Anwendungen in der Cloud sind umfangreich und vielfältig.
Wichtig bei der Auswahl eines Modells für das eigene System ist eine Analyse des Bedarfs und gleichzeitig den MVP Gedanken im Hinterkopf zu behalten, um sich nicht zu lange mit einer Vorab-Planung zu beschäftigen, ohne wertvolles Kundenfeedback einzuholen.
Ein großer Vorteil der Cloud ist, dass mit relativ geringen Infrastrukturinvestitionen Erkenntnisse direkt von den zukünftigen Nutzern gesammelt werden können.
Bei weiterreichenden Fragen zu den vorgenannten Themen, können wir uns gerne in der Kommentarspalte unterhalten oder einen Termin vereinbaren unter https://www.brickmakers.de/kontakt
