Der Weg in die Cloud ist für Unternehmen mit einer existierenden IT-Infrastruktur nach wie vor mit viel Skepsis verbunden. Neben Fragen zu Sicherheit und Datenschutz steht auch meist im Raum: Bringt die Nutzung der Cloud auch einen Mehrwert für das Unternehmen, für das Produkt und für diejenigen, welche an dessen Lebenszyklus (Design, Entwicklung, Betrieb etc.) beteiligt sind? Neben der Bereitstellung von Rechenkapazität bieten die “Big 3” (AWS, Google Cloud, Azure) Dienste und Produkte an, welche genau diesen Mehrwert schaffen können. Der nachfolgende Artikel soll dazu ermutigen, diese Dienste zu nutzen, um den meisten Profit aus der Cloud ziehen zu können.
Am Anfang steht die Anforderung, am Ende das Ziel
Bevor ein Umzug in die Cloud begonnen wird, sollten die Anforderungen klar sein. Das Ziel soll am Ende profitabel für alle Beteiligten sein. Kapitel fertig, oder? Nicht so schnell. Gerade bei einem so strategisch wichtigen Thema sollte nicht überstürzt vorgegangen werden. Mit der “profitablen” Cloud wird nur sehr vage das tatsächliche Ziel beschrieben. Wann ist es profitabel? Was muss alles erfüllt sein, damit es profitabel ist? Hier kommen die Anforderungen ins Spiel. Sie bestimmen den Weg, die Rahmenbedingungen und letzten Endes auch, ob das Ziel auch wirklich erreicht wurde oder überhaupt erreicht werden kann. Dass Anforderungen und Ziele im Gegensatz zueinander stehen, gibt es häufiger in der Softwareentwicklung. Größtenteils dann, wenn sie aus unterschiedlichen Kontexten heraus definiert werden und erst bei der Umsetzung aufeinandertreffen. Um dem entgegenzuwirken, sollte beides zusammen erarbeitet und anschließend bewertet und priorisiert werden. Im idealen Fall sollte pro Ziel auch mindestens eine Anforderung passend dazu vorhanden sein. Ziele ohne Anforderung oder umgekehrt haben in der Vergangenheit oft dazu geführt, dass spätestens zur Umsetzung Konflikte entstehen, da nicht das entsteht, was tatsächlich benötigt wird.
Tabelle 1 zeigt exemplarisch Ziele und deren Anforderungen für den Umzug in die Cloud.
Ziele | Anforderungen |
---|---|
Einsparung von Kosten |
|
Erhöhung der Verfügbarkeit |
|
Steigerung der Flexibilität |
|
Skalierung von onPremise in die Cloud bzw. Cloud-übergreifend (Hybrid-/Multi-Cloud) |
|
Da sich die Erde bekanntermaßen weiterdreht, sollten diese Anforderungen und Ziele als eine Art “Snapshot” der aktuellen eigenen Lage betrachtet werden, das heißt, wenn sich die eigene Lage ändert, muss noch einmal nachjustiert werden. Genau hier spielen die Cloudanbieter ihre Stärke aus: Da meist nur für die tatsächliche Nutzung bezahlt wird und kein Vorausinvestment nötig ist, kann jederzeit nachgebessert werden.
Vendor Lock-In: Ja oder Nein
Eines der am häufigsten diskutierten Argumente für oder gegen die Cloud ist das Thema Vendor Lock-In. Gerade hier ist es wichtig, sich den Anforderungen und Zielen bewusst zu sein. Muss der Vendor Lock-In wirklich vermieden werden? Oder überwiegt der Nutzen die Nachteile des Vendor Lock-In? Das Risiko, von einer Technologie bzw. dem Anbieter dieser Technologie abhängig zu sein, besteht immer, ganz unabhängig davon, ob es sich um einen Cloudanbieter, ein Open-Source-Projekt oder den Hersteller einer Datenbank handelt. Die Big 3 haben gemeinsam, dass je höherwertiger der Dienst ist, desto mehr kann vom Cloudanbieter langfristig profitiert werden. Jedoch wächst im gleichen Maß auch die Bindung an ihn oder seine Technologien. Abbildung 1 verdeutlicht den Zusammenhang von höherwertigen Diensten, Abhängigkeit zum Anbieter und dem Nutzen daraus.
Um von der Nutzung von höherwertigen Diensten profitieren zu können, hilft ein Blick in die “Pattern”-Kiste: Mittels des Patterns “Lose Kopplung” können Technologien (z.B. relationale Datenbanken) so integriert werden, dass diese mit überschaubarem Aufwand ausgetauscht werden können, ohne den fachlichen Code-Anteil im Wesentlichen zu verändern. In vielen gängigen Frameworks ist dies mittels “Dependency Injection” (z.B. Spring) oder Kapselung (z.B. slf4j) ein fester Bestandteil der Implementierung. So gesehen spielt der Vendor Lock-In aus Sicht der Anwendungsentwicklung keine wesentliche Rolle.
Höherwertige Dienste
Bei höherwertigen Diensten handelt es sich um sogenannte „Managed Services“. Bei diesen Diensten übernimmt der Cloudanbieter den wesentlichen Anteil vom Betrieb der Plattform (z.B. Bereitstellung einer relationalen Datenbank-Instanz) bis hin zur Bereitstellung einer kompletten Lösung für ein Themenfeld (z.B. Media-Streaming, Serverless).
Doch wie sieht es bei dem Thema “Vendor Lock-in” bezüglich Produktstrategie und Produktentwicklung aus? Gerade hier bieten die jeweiligen Cloudanbieter viele (z.T. fast) fertige Lösungen an, welche aus ihrem eigenem Tagesgeschäft entstanden sind. Gerade technisch komplexe Lösungen können so einfach eingekauft werden, ohne selbst Entwicklungsleistungen erbringen zu müssen und vor allem ohne sich langfristig durch teure Lizenzmodelle an diese zu binden. Neben Lösungen für komplexe Probleme, können auch viele einfache Dinge, wie das Hosten von Web-Inhalten, fast ohne Aufwand, einfach nur per “Klick”, erledigt werden. Da die Big 3 jeweils unterschiedliche Lösungen anbieten, lohnt es sich, vor Beginn der Entwicklung in deren Produkt- und Lösungsbaukasten nachzusehen, ob für das vorliegende Problem bereits eine fertige Lösung angeboten wird.
Ein Beispiel: Es soll ein neues digitales Produkt entwickelt werden, das mehreren Millionen Kunden weltweit auf unterschiedlichen Geräten Video-Content zur Verfügung stellen soll. In diesen wenigen Zeilen stecken viele technische Herausforderungen: Media Streaming, Media Transcoding, weltweites Content Delivery, Kundenmanagement usw. Natürlich können diese Dinge alle ohne die Unterstützung von höherwertigen Diensten umgesetzt werden, doch in welcher Zeit, mit welchem Aufwand und letzten Endes in welcher Qualität? Wäre es nicht zielführender, die entsprechenden Lösungen eines Cloudanbieters zu nutzen, um möglichst wenig Energie in die Entwicklung von bereits existenten Lösungen zu stecken? In diesem Fall bietet z.B. AWS für alle diese Punkte Lösungen an, die passend zum Business Case verbunden werden können (Abbildung 2).
Für weitere Ausführungen um das Thema “Vendor Lock-in” kann ich folgende Posts empfehlen:
- AWS: Blog Post von AWS, um ein paar Mythen aufzuklären
- INNOQ: Blog Post zum Thema Serverless und Vendor Lock-In
Mehrwert für die Digitale Nahrungskette
Die Zeiten, in denen analoge Sachverhalte digital transformiert wurden, sind langsam vorbei. Es gibt nur noch weniges, das transformiert werden muss. Doch was kommt jetzt? Die Startup-Szene macht es vor: Es wird immer wichtiger, einen Mehrwert mit digitalen Produkten zu schaffen, d.h. es muss dem Kunden das Leben leichter, effizienter und besser machen als vorher. Nicht nur Startups haben dies erkannt, sondern auch die Big 3 der Cloudanbieter. Jeder dieser Anbieter versucht auf unterschiedliche Weise, einen Mehrwert für die “Digitale Nahrungskette” ihrer Kunden zu liefern. Abbildung 3 zeigt eine exemplarische Digitale Nahrungskette. Diese kann unterschiedlich ausgeprägt sein, je nachdem wie detailreich diese definiert wird. Zur Vereinfachung habe ich sie auf 3 Phasen oder Kettenglieder reduziert.
Digitale Nahrungskette
Die „Digitale Nahrungskette“ ist der Entwicklungszyklus eines Digitalen Produktes, angefangen beim Produkt-Design, über die Produktrealisierung und zum Schluss der Launch des Produktes. Nach dem Launch fängt die Nahrungskette wieder von vorne an, da dieser neues „Futter“ (z.B. Feedback, Features, Fehler) für das Produkt-Design liefert.
Mehrwert für die Produkt-Realisierung und -Launch
Die beiden Phasen Produkt-Realisierung und -Launch profitieren gleichermaßen von der Nutzung von Cloudanbietern. Logischerweise entfallen die Beschaffung und das Managen von physischer Hardware und all dem, das dazu gehört. Jedoch ist der Mehrwert sehr gering, wenn nur die Hardware durch virtuelle Maschinen in der Cloud ersetzt wird (Datacenter in the Cloud), da nach wie vor viel operativer Aufwand (Installation, Konfiguration, Updates, Backups etc.) nötig ist. Einzig die Skalierung ist besser als zuvor. Ganz anders sieht es aus, wenn der operative Aufwand durch die Nutzung von höherwertigen Diensten immer mehr an den Cloudanbieter delegiert wird. Somit wird immer irrelevanter, “wie” etwas betrieben wird; es zählt nur noch, “was” betrieben werden soll. Das hört sich erst einmal unbedeutend an, ist aber langfristig äußerst wichtig. Das “Wie” wird nur noch ein Skript zum Bereitstellen der benötigten Dienste sein (Infrastructure as Code) und kein nennenswertes Problem darstellen. Das “Was” hingegen wird einzig und allein durch Anforderungen bestimmt und durch das eigene Budget limitiert. Das Investment, das bisher für den Betrieb von (meist wenigen) Produkten und Lösungen nötig war, kann nun für die Auswahl der strategisch besten Lösung verwendet werden. Passend dazu spielen die Big 3 der Cloudanbieter ihren besten Trumpf aus: Um die beste Lösung aus dem riesigen Produktportfolio finden zu können, müssen diese zwangsläufig getestet und evaluiert werden. Das ist kein Problem, da in wenigen “Klicks” angebotene Dienste bereitgestellt, getestet und wieder entfernt werden können; ohne Vertragsverhandlungen, Lizenzbindung oder Mindestlaufzeit.
Der größte Mehrwert für die Produkt-Realisierung liegt in der fast endlosen Vielfalt an existierenden Lösungen. Diese erfüllen von vornherein einige nicht funktionale Anforderungen, wie Verfügbarkeit oder Skalierbarkeit, zum Teil im hohen Maßen. Wenn dann auch noch der operative Aufwand für die Bereitstellung einer Anwendung, welcher mittlerweile fast komplett in die Anwendungsentwicklung gewandert ist, so weit wie möglich reduziert, bleibt viel Kapazität für die wichtigen Dinge – die Fachlichkeit – übrig. Das erhöht die Entwicklungsgeschwindigkeit von neuen Features und bringt den Beteiligten Freiraum, um ihr Wissen über neue Lösungen und Technologien auf dem aktuellen Stand zu halten. Somit wird auch das Produkt technisch permanent weiterentwickelt.
Mehrwert für das Produkt-Design
Für das Produkt-Design ist der Mehrwert nicht so offensichtlich, wie bei den anderen Phasen. Das Produkt-Design profitiert letzten Endes von dem Mehrwert der anderen Phasen. Durch deren höhere Entwicklungsgeschwindigkeit, nahezu unbegrenzt skalierbaren und verfügbaren Ressourcen, sowie fertigen Lösungen für unterschiedliche Themengebiete, kann das Produkt-Design sehr schnell an neue Begebenheiten und Anforderungen angepasst und erweitert werden. Ein weiterer Aspekt sind die Kosten. Werden für die Realisierung und den Launch ausschließlich höherwertige Dienste in Anspruch genommen, welche nur für die tatsächliche Nutzung (z.B. Serverless) Kosten verursachen, und das Produkt ist ein Flop, verursacht dieses nicht auch noch hohe Betriebskosten. Sollte das Produkt jedoch ein Erfolg werden, gibt es ebenfalls keinen Grund zur Sorge, da nur das zur Verfügung stehende Budget die Grenze zur Skalierung ist. Dieses Potential kann während des Produkt-Designs genutzt werden, um Prototypen (z.B. statische HTML-Dateien) für User-Acceptance-Tests einem großen Publikum zur Verfügung zu stellen (z.B. mithilfe von Storage-Services wie S3), ohne eine Betriebsumgebung zu benötigen.
Mehrwert für das Unternehmen
Nicht nur die Produktentwicklung profitiert von der Nutzung eines Cloudanbieters, sondern auch das Unternehmen selbst. Neben der Möglichkeit, interne Anwendungen in der Cloud betreiben zu können, bieten die Big 3 Lösungen an, welche die interne IT ergänzen können. Das fängt bei der Bereitstellung von Langzeitspeicher für Backups an und kann bei der Verwaltung von virtuellen Desktops enden. Analog zur Produktentwicklung wird auch hier nach und nach das “Was” zu betreiben ist wichtiger werden als das “Wie”.
An diesem Punkt kommt oft die Frage: Wie sieht es mit der Datensicherheit aus? Könnte nicht ein Administrator des Cloudanbieters Firmengeheimnisse oder Kundendaten ausspähen? Ja, er könnte es theoretisch. Doch das könnte jeder Administrator eines Rechenzentrums. Was hindert ihn also daran? Das sind Prozesse, Verträge, Zertifizierungen und nicht zuletzt das Vertrauen des Kunden, dass verantwortungsvoll mit den Daten umgegangen wird. Sollten bestimmte Informationen besonders schützenswert sein, bieten die Cloudanbieter selbst unterschiedliche Verfahren zur Verschlüsselung an. Alternativ können die Daten auch vor der Speicherung in der Cloud verschlüsselt werden. Dürfen Daten auf keinen Fall in der Cloud gespeichert werden, bieten die Big 3 Unterstützung für eine Hybrid-Cloud-Lösung an (sensible Daten und Systeme bleiben onPremise, weniger sensible Daten und Systeme können in die Cloud). Abgesehen von dem Vertrauen in den jeweiligen Cloudanbieter, bieten diese dem Kunden selbst die Möglichkeit seine eigenen Vorgaben und Verpflichtungen bezüglich der Datensicherheit einzuhalten, unter anderem durch ein fein granulares Berechtigungssystem oder ein Auditsystem, welches alle Zugriffe protokolliert. Stellen Sie sich hier am besten selbst die Frage: Würden Sie einem wenigen Köpfen großem Rechenzentrum mehr vertrauen, als einem milliardenschweren Unternehmen, das Unsummen in die eigene IT-Infrastruktur und dessen Sicherheit investiert, um sein eigenes Geschäftsmodell zu betreiben?