Multi

Ein Fenster meines Hauses muss repariert werden. Ich weiß, dass ich es tun muss, aber am Ende ist es im Feld „Zu schwierig für den Moment“ gelandet, also beeile ich mich nicht, es zu klären. Der Luftzug ist in den neun Monaten des britischen Wetters, das als „grau und nass“ bekannt ist, wirklich ärgerlich.

Ich habe den Job jetzt schon seit zwei Jahren aufgeschoben – aber er kostet mich Geld. Viele der CIOs, die dies lesen, haben wahrscheinlich ihre eigenen Aufgaben im wirklichen Leben und ein viel größeres Problem in ihrem Arbeitsleben: das Problem der Bindung an die Cloud.

Was ist das, höre ich Sie fragen: Mit der Cloud stimmt etwas nicht? Nun, die britische Regulierungsbehörde für den Kommunikationssektor, Ofcom, glaubt, dass dies der Fall ist. Anfang des Jahres schockierte das Unternehmen den Markt mit der Ankündigung, dass es den britischen Cloud-Markt zur Untersuchung an die Wettbewerbs- und Marktaufsichtsbehörde verweisen werde.

Warum? Nun hat Ofcom Merkmale und Praktiken identifiziert, die es für Kunden schwieriger machen, zu wechseln und mehrere Cloud-Anbieter zu nutzen. Sie äußerten Bedenken hinsichtlich Hindernissen für die Interoperabilität, wie beispielsweise hohen Egress-Gebühren (die Gebühren, die Kunden zahlen, um ihre Daten aus einer Cloud zu übertragen). Die Regulierungsbehörde geht davon aus, dass Hyperscaler diese Gebühren deutlich höher ansetzen als andere Anbieter. Ofcom war auch besorgt über technische Einschränkungen der Interoperabilität sowie mögliche Probleme mit sogenannten Rabatten für zugesagte Ausgaben.

Ich werde mich nicht auf eine lange Debatte darüber einlassen, aber ich bin ein leidenschaftlicher Verfechter der Nutzung aller Vorteile der Cloud. Der Erhalt dieser Vorteile sollte nicht bedeuten, dass Sie Ihren bestehenden Vertrag auflösen und neu beginnen müssen, selbst wenn das möglich wäre.

Es kann durchaus sein, dass Cloud-Vertragsangelegenheiten nicht in Ihrer Hand liegen und auf einer höheren Ebene im Unternehmen oder direkt vom CFO behandelt werden. Daher ist es unwahrscheinlich, dass Sie einfach von einem Hyperscaler zum anderen wechseln können. Ein Teil von Ihnen stimmt der kritischen Einschätzung von Ofcom vielleicht reumütig zu, aber gibt es etwas, was Sie dagegen wirklich tun können?

Ich schlage vor, dass es so ist. Vielen Entwicklern und IT-Architekten liegt das wirklich am Herzen, und obwohl der große Vertrag möglicherweise auf einer höheren Ebene unterzeichnet wird, sind es Menschen wie wir vor Ort, die dafür verantwortlich sind, dass er funktioniert. Außerdem wird Ihr Budget auf den Prüfstand gestellt, wenn Sie am Ende die vereinbarten Ausgaben überschreiten.

Ich sehe zwei Möglichkeiten, wie CIOs die Art und Weise, wie die Cloud in ihren Unternehmen verwaltet wird, ändern können. Die erste besteht darin, Ihren Fall einfach mit Ihrem Account Manager zu besprechen.

Es gibt aber auch eine zweite technische Option, die Ihnen möglicherweise mehr Vorteile bringen könnte, bis möglicherweise neue, von den Regulierungsbehörden gesteuerte Cloud-Freiheiten entstehen. Dabei geht es darum, bewusst mit Software und Plattformen zu arbeiten, die Sie nicht vollständig und teuer auf den Technologie-Stack eines einzigen Anbieters verlassen.

Das gilt für viele Anwendungsbereiche, aber der Bereich, den ich am besten kenne, sind Datenbanken, deshalb werde ich mich darauf konzentrieren. Jeder Hyperscaler verfügt über eine verwirrende Vielfalt an SQL-, NoSQL-, Graph- und What-have-you-Optionen. Diese sind ebenfalls abgestuft, sodass Sie eine Datenbank für kleine, mittlere und unternehmensweite/große Probleme auswählen können.

Aber Sie wollen sich nicht auf eine einzige Ebene eines Cloud-Stacks festlegen, sondern sich selbst Optionen geben. Die gute Nachricht ist, dass Sie „Vanilla Postgres“ wählen können – die grundlegende Open-Source-Version der Postgres-SQL-Sprache von jedem der Cloud-Anbieter, die Sie auf postgres.org erhalten können.

Allerdings besteht bei diesem Ansatz des „kleinsten gemeinsamen Nenners“ die Gefahr, dass Sie möglicherweise auf Probleme stoßen, wenn Ihre App wächst und Sie Funktionen auf Unternehmensebene hinzufügen müssen. An dieser Stelle könnte es nützlich sein, sich daran zu erinnern, warum Sie überhaupt mit Cloud-Datenbanken arbeiten wollten (und, was noch wichtiger ist, ob Ofcom und Gartner Recht haben und Multi-Cloud das ist, was wir alle anstreben sollten). Sie modernisieren Ihre Datenschicht, um alle erstaunlichen Cloud-nativen Funktionen zu nutzen, die Ihnen gefehlt haben, einschließlich der einfachen Skalierbarkeit und Ausfallsicherheit vor Ort. Wenn Sie diese nicht wirklich nutzen, dann vollziehen Sie nur eine Umstellung und erleben daher in realer finanzieller (aber auch technischer) Hinsicht nicht die wirklichen Vorteile der Cloud.

Ein großer Teil der Verlagerung Ihrer Anwendungen in die Cloud muss also die Datenbankmodernisierung sein, aber es ist nicht offensichtlich, wie Sie dorthin gelangen, ohne ein maßgeschneidertes Angebot von einem der großen Cloud-Anbieter zu übernehmen. Besser wäre es, Datenbanken zu wählen, die über verschiedene öffentliche Clouds laufen und über gemeinsame APIs verfügen. Das Sahnehäubchen wäre hier die Arbeit mit „Born-in-the-Cloud“-Technologien, denn bei näherer Betrachtung handelt es sich bei vielen Produkten einfach nur um traditionelle Technologien, die in der Cloud neu implementiert werden.

Es ist völlig natürlich, zu prüfen, was Ihr Anbieter zu bieten hat. Sie befinden sich sowieso in ihrer Cloud, und es ist sicherlich von Vorteil, die breite Palette an Diensten und Funktionen zu berücksichtigen, die a) in Ihrer Umgebung funktionieren und b) in der Cloud entstanden sind.

Sie müssen auch verstehen, dass diese Dienste und Funktionen immer in irgendeiner Weise an die jeweilige Cloud-Umgebung angepasst werden. Die vollständig verwaltete relationale Datenbank-Engine von AWS, Aurora, ist mit MySQL und PostgreSQL kompatibel, wurde jedoch speziell für die Ausführung auf Amazon entwickelt. Das bedeutet, dass es nicht lokal ausgeführt werden kann und schon gar nicht in der GCP (Googles Cloud) funktioniert.

Das Ergebnis ist, dass Sie bald Änderungen an Ihrer Anwendung vornehmen müssen, um sie an eine maßgeschneiderte Version von Postgres anzupassen, die in der Cloud-Umgebung Ihres Hyperscaler-Partners sehr effizient läuft, aber Ihre allgemeine Flexibilität einschränkt. Bis zu einem gewissen Grad werden Sie an diese Version der Anwendung gebunden sein, weil sie nirgendwo anders wirklich funktionieren kann. Gleiches gilt für das Google-Äquivalent von Vanilla Postgres (CloudSQL for Postgres) oder die Microsoft-Version (Azure PostgreSQL).

Es überrascht nicht, dass jeder Hyperscaler Ihnen gerne einen Vorgeschmack auf „Postgres“ bietet, unabhängig davon, ob Sie am unteren, mittleren oder oberen Ende beginnen möchten. Stellen Sie sich das als eine Drei-mal-Drei-Matrix vor, in der es für jede der wichtigsten Cloud-Plattformen Amazon AWS, Google Cloud Platform und Microsoft Azure drei SQL-Cloud-Datenbanken mit niedrigem bis hohem SQL-Wert gibt. Das untere Ende jedes Stapels kommt ziemlich nah an Vanilla Postgres heran, aber sobald man skaliert, entfernt man sich immer weiter von diesem Standard.

Jeder Anbieter, der drei vertikale Angebote anbietet, ist großartig (wenn Sie mit ihnen vertikal aufsteigen möchten). Aber was passiert, wenn Sie im Rahmen einer neuen, von Ofcom inspirierten (oder sogar vorgeschriebenen) Multi-Cloud-Strategie die Cloud wechseln oder eine weitere Cloud hinzufügen möchten?

Wie kommt man beispielsweise vom Mittelklasse-Google zum Low-End-Amazon? Wir reden viel über Skalierung, aber sicherlich ist eines der Hauptverkaufsargumente der Cloud, dass man genauso leicht nach unten gehen kann wie nach oben? In Wirklichkeit ist es nahezu unmöglich, sich in dieser Matrix zu bewegen, da es keine konsistente API gibt, die für alle diese Produkte funktioniert.

Ich werde dies anhand eines praktischen Beispiels zeigen. Nehmen wir an, Sie entwickeln auf der RDS-Ebene auf Amazon und entscheiden sich für die nächste Iteration, dass Sie in der Mitte zu Google AlloyDB wechseln. Sie werden durch die Bindung auf RDS-Ebene behindert und müssen außerdem über Clouds hinweg migrieren, sodass Sie am Ende viel umschreiben und die Komplexität verwalten müssen. Bei jeder Migration entstehen zeitliche und finanzielle Nachteile.

Aus diesem Grund können wir unter den derzeitigen Regelungen des Cloud-Marktes keine schönen Dinge wie Multi-Cloud haben. Eine Kombination aus Aurora vor Ort und in der Cloud ist nicht möglich. Mit RDS ist keine Multi-Cloud möglich; Dies ist nur in der Cloud-Umgebung des Anbieters möglich. Und wenn Sie es vergrößern oder verkleinern möchten, müssen Sie einen Prozess durchlaufen, um es zu ändern.

Rechnet man die Preisnachlässe hinzu, ist es einfacher, für praktisch alles beim gleichen Cloud-Anbieter zu bleiben … und bevor man sich versieht, sitzt man für immer fest. Und das kaputte Fenster wird nie repariert.

Die gute Nachricht ist, dass es mehrere Open-Source-Datenbanken auf Postgres-Basis gibt, die gemeinsame APIs verwenden und Ihnen so Portabilität und Zugriff auf die großartigen Cloud-Funktionen bieten, die Sie nutzen möchten.

Wenn Sie diesen Weg einschlagen, können Sie sich, anstatt zu versuchen, durch das komplexe Labyrinth der Hyperscaler-Datenbanken zu navigieren, Ihre Optionen in Bezug auf Cloud-Datenbanken offen halten und einige der Cloud-Hotfallen vermeiden, die die Anbieter vor uns baumeln lassen!

Fazit: Es wird mindestens 18 Monate dauern (wenn überhaupt), bis die CMA in den britischen Cloud-Markt eingreifen und darauf drängen kann, Multi-Cloud zur Norm zu machen. Aufgrund der Art und Weise, wie der Cloud-Markt derzeit organisiert ist, müssen Sie also etwas unternehmen Datenbankoptionen, die Ihnen in Zukunft Ärger und Geld ersparen. Wenn Sie Open-Source-Postgres-Optionen in Betracht ziehen, profitieren Sie von vielen Vorteilen der Multi-Cloud.

Noch besser: Wenn Sie jetzt darüber nachdenken, können Sie Panikattacken aufgrund einer möglichen künftigen Multi-Cloud-Regulierung durch Ofcom vermeiden.

Weißt du was? Ich fühle mich so inspiriert, dass heute endlich das Fenster repariert wird.