Kolumne: Stropek as a Service

Qual der Wahl in der Cloud – Im Dschungel der Cloud-Services gibt es keine simplen Antworten
Kommentare

Wer jetzt in die Cloud einsteigt, ist kein „Early Adopter“ mehr, sondern eher ein „Late Follower“. Man sollte meinen, dass der Einstieg ins Cloud-Computing deshalb leichter wäre: Die Cloud-Provider hatten jahrelang Zeit, an ihren Services zu feilen, die Dokumentation zu vervollständigen, Trainingsunterlagen zur Verfügung zu stellen etc. Kurz gesagt, die Kinderkrankheiten sollten überstanden sein.

Tatsächlich ist meine Erfahrung, dass der Schritt in die Cloud nicht leichter geworden ist; es haben sich nur die grundlegenden Fragestellungen geändert. In den frühen Jahren war es eine Herausforderung, überhaupt einen Cloud-Service für das jeweilige Problem zu finden. Wenn man einen aufgespürt hatte, waren die schlecht oder gar nicht dokumentierten technischen Details die nächste Hürde.

Heute sieht die Sache anders aus: Für jedes Problem, das nicht nur spezifisch für eine einzelne Organisation besteht, gibt es viele verschiedene Cloud-Dienste. Einen kompletten Marktüberblick zu erarbeiten, wird zur Sisyphosarbeit, wenn man nicht nur an der Oberfläche kratzen will. Selbst wenn man sich beim Design seiner SaaS-Lösung auf einen strategischen Partner wie Microsoft mit seiner Azure-Cloud konzentriert, wird man enttäuscht: Man kann auch hier auf eine technische Herausforderung keine einzelne Antwort erwarten. Es gibt immer eine Vielzahl an Möglichkeiten, die alle irgendwie sinnvoll sind. Wie soll man also entscheiden? Welche Kriterien gilt es zu beachten? Welche Fehler werden häufig gemacht?

Ein konkretes Beispiel

Lassen Sie mich ein konkretes Beispiel skizzieren, das die Herausforderung greifbarer macht. Es ist nicht aus der Luft gegriffen, sondern wurde mir in ähnlicher Form dutzende Male in SaaS-Architekturworkshops beschrieben. Unser fiktives Team möchte eine Multi-Tenant-SaaS-Lösung für eine bestimmte Branche entwickeln. Ganz dem Trend der Zeit folgend, soll sie im Backend aus einer Sammlung von RESTful-Microservices bestehen. Für die Daten wird eine Datenbank benötigt. Als Haupt-Frontend soll eine Web-App entwickelt werden. Für gewisse, spezialisierte Szenarien sind Apps für mobile Geräte vorgesehen. Als wichtigste nichtfunktionale Anforderungen werden gute Performance, Skalierbarkeit, Sicherheit, Verfügbarkeit und niedrige Betriebskosten genannt.

Jemand, der neu im Bereich Cloud-Computing ist, könnte meinen, dass es für ein so übliches Szenario von einem Anbieter wie Microsoft klare Empfehlungen gibt. Diese Hoffnung wird enttäuscht, und das aus gutem Grund:

  • Eine SaaS-Lösung für ein paar tausend Kunden sieht grundlegend anders aus als eine für Millionen Kunden.
  • Eine Architektur, die auf sehr viele, sporadisch arbeitende Benutzer optimiert ist, unterscheidet sich radikal von einer, die von wenigen, ständig aktiven Benutzern ausgeht.
  • Steht eine kürzestmögliche Time-to-Market im Vordergrund, muss anders ausgewählt werden als bei der Forderung nach hoher Unabhängigkeit von einem Cloud-Provider.
  • Jeder Cloud-Dienst bietet nicht nur spezifische Funktionen, sondern hat auch für ihn charakteristische Preismodelle. Man muss das Verhaltensmuster der Anwender antizipieren, um die späteren Cloud-Kosten abschätzen zu können.

Entscheidungen und Prioritäten

Bevor unser fiktives Team Cloud-Dienste auswählen kann, müssen strategische Entscheidungen getroffen und Prioritäten gesetzt werden. Das führt uns zu einem Kardinalfehler, der meiner Erfahrung nach aktuell von vielen Organisationen gemacht wird, die zurzeit in das Thema Cloud-Computing einsteigen: Die Entwicklung der Architektur von SaaS-Lösungen wird als rein technisches Problem angesehen. Entscheidungsträger delegieren die Aufgabe vollständig an technische Teams. Diese bewerten naturgemäß primär auf Basis technischer Kriterien. Mangels detaillierter Vorgaben entscheiden sie sich häufig für jene Cloud-Dienste als Basis ihrer SaaS-Lösung, die größtmögliche Flexibilität, Kontrolle und Skalierbarkeit versprechen. Niemandem wird während dieses Prozesses bewusst, dass höhere Kontrolle auch mehr Verantwortung bedeutet. Die Folge sind hohe Entwicklungs- und Betriebskosten. Systeme, die linear oder superlinear skalieren, sind in der Regel komplexer als limitierte Gegenstücke. Benötigt man die gebotene Skalierbarkeit nicht, verschwendet man wertvolle Zeit und Ressourcen.

Geschäftsstrategie und Technik abstimmen

Erfolgreich sind die Teams, denen es gelingt, in der Technik die Strategie abzubilden, die hinter der SaaS-Lösung steckt. Nicht das Maximum ist anzustreben, sondern das richtige Maß. Vielleicht muss da oder dort aus betriebswirtschaftlichen Gründen auf eine technisch attraktive Lösung verzichtet werden.

Um den richtigen Weg zu finden, ist eine enge Kooperation der Teams für geschäftliche und technische Planung notwendig. Das Technikteam muss die geschäftlichen Ziele kennen, und die für die strategische Planung zuständigen Personen müssen sich bis zu einem gewissen Grad Verständnis für die technischen Grundlagen aneignen.

Zurück zum Beispiel

Hier einige Beispiele, die zeigen, wie wichtig die Abstimmung von Geschäftsstrategie und Technik für unser oben erwähntes fiktives Team ist:

  • Rechnen wir mit Millionen an Benutzern, die noch dazu zu gewissen Stoßzeiten besonders aktiv sind, brauchen wir für die Authentifizierung ein hoch skalierbares System wie Microsoft Azure Active Directory B2C. Ist die Benutzerzahl aber gering und stehen die Funktionalität der APIs und die Kontrolle über Benutzer- und Passwortdaten (z. B. für einen späteren Wechsel des Cloud-Providers) im Vordergrund, würde ein eigener Identity Server oder ein Dienst wie Auth0 besser passen.
  • Um die Entwicklungskosten zu minimieren, sollte das Team auf funktional möglichst reichhaltige PaaS- und Serverless-Dienste zurückgreifen. Das bedeutet aber praktisch immer einen gewissen Lock-in-Effekt, der bei einem Verkauf des Unternehmens möglicherweise den Firmenwert schmälert. Eine Lösung auf Basis von Docker wäre flexibler, würde aber auch erheblich mehr Administrationsaufwand für den Betrieb der notwendigen Docker-Infrastruktur bedeuten.
  • In der Cloud hochverfügbare Datenbankserver zu betreiben, ist heutzutage ein Kinderspiel. Günstige, qualitativ hochwertige PaaS-Dienste gibt es für SQL und NoSQL. Will man aber eine Datenbanklösung, die vom Datenvolumen, von der Abfrageleistung und von ihrer regionalen Verteilbarkeit her nahezu unendlich skaliert, wird das Angebot recht übersichtlich und teuer. Überdimensionierung schlägt sich sehr negativ auf der Kostenseite nieder.
  • Üblicherweise werden Datenbank und Anwendungsserver getrennt. Dementsprechend gibt es dafür günstige, standardisierte Dienste in praktisch allen Clouds. Man bezahlt die Trennung aber durch erhöhte Latenz, die sich durch die Netzwerkverbindungen ergibt. Ein Dienst wie Azure App Fabric ermöglicht es, Daten und zugehörige Verarbeitung auf einzelnen Servern zusammenzuhalten (Co-Location), ohne Hochverfügbarkeit zu verlieren. Eine mächtige Architektur, die sich aber angesichts höherer Entwicklungskosten nur auszahlt, wenn die erreichbare Skalierbarkeit und Performance tatsächlich gefordert sind.
  • Geht das Geschäftsmodell von einer riesigen Anzahl an Tenants aus, die das SaaS-Angebot kostenlos nutzen, und einer kleinen Anzahl professioneller Tenants, deren Abonnements das Gratisangebot querfinanzieren, hat das Auswirkungen auf die Gestaltung der Multi-Tenancy-Funktionalität. Die Gratisabos müssen funktionell oder leistungsmäßig eingeschränkt werden. Ihre Betriebskosten sind auf ein Minimum zu reduzieren. Für die Bezahlabos muss die zugesicherte Performance garantiert werden. Das alles sind aufwendig zu entwickelnde oder teuer einzukaufende Funktionen, die für einen SaaS-Service unnötig sind, der nie über ein paar hundert größere B2B-Kunden hinauskommt.

Arbeiten mit Bildern

Oft stehe ich in der Praxis vor dem Problem, dass sich die Personen, die die geschäftliche Strategie entwickeln, nicht festlegen wollen. Dass mangelnde Festlegung auch eine Form der Entscheidung – nämlich für größtmögliche Flexibilität – ist, ist ihnen nicht bewusst. Ich arbeite gerne mit Bildern, um Problembewusstsein zu schaffen. Hier ein Beispiel: Wer ein Haus baut, muss sich gut überlegen, wo er es baut, da es später nicht mehr verschoben werden kann. Trifft man diese Entscheidung nicht, braucht es ein Haus auf Rädern, was wiederum eine Menge unerwünschter Konsequenzen hätte. Alle Wände aus Beton zu bauen gibt zwar Stabilität, ein nachträgliches Ändern wird aber schwierig. Eine Trockenbauwand gibt zwar Flexibilität, Küchenschränke würde ich aber nicht daran aufhängen. Die Technikteams müssen dem Businessteam klarmachen, welche Entscheidungen sorgfältig zu überlegende „Grundstücksentscheidungen“ sind und wo Detailplanung wegen einfacher Änderbarkeit verlorene Zeit wäre. Sie müssen durch solche Bilder auf konfliktäre Ziele aufmerksam machen und auf Priorisierung bestehen.

Mit kleinen Schritten zum Erfolg

Die Konsequenzen der Entscheidung für oder gegen gewisse Cloud-Services abzuschätzen, ist schwierig, wenn man gerade erst in die Thematik einsteigt. Meine Empfehlung ist eine Politik der kleinen Schritte. Realitätsnahe Machbarkeitsstudien und Prototypen helfen beim Gewinnen erster Erfahrungen. Ein Markteintritt in regional eingeschränkte Märkte oder eine Minimum-Viable-Product-Strategie hilft, die eigenen Annahmen zu verifizieren. Nach jedem kleinen Schritt sollte die Cloud-Architektur hinterfragt werden.

Perfektionismus von Anfang an ist der Feind. Man muss Dinge probieren und Erfahrungen sammeln können. Fehlentscheidungen sind nicht tragisch, wenn ihre Konsequenzen klein sind und ein Schritt zurück keine Tragödie darstellt. Wer meint, dass Cloud-basierte SaaS-Entwicklung wie Kochen nach Kochbuch ist, liegt falsch. Die Vielzahl an Möglichkeiten und das sich ständig verändernde Umfeld machen das Aufgabengebiet so herausfordernd, aber gleichzeitig auch so spannend.

Lesen Sie alle Ausgaben der Kolumne „Stropek as a Service„!
In der Kolumne greift Rainer Stropek spannende Aspekte wie die Finanzierung, den Customer Lifetime Value, aber auch wichtige Themen wie Billing, Kundenbindung durch Qualität oder APIs auf – alles aus der Sicht eines Unternehmers, der seit 20 Jahren in der IT-Branche tätig ist und seit fünf Jahren intensive Erfahrungen mit SaaS gesammelt hat.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -