Das Thema Datenschutz und der Vendor Lock-in geben sich beim Thema Cloud Computing die Klinke in die Hand. Im Interview für die Computerwoche machte Eucalyptus CEO Marten Mickos mir gegenüber eine interessante Aussage: “Die Leute erinnern sich daran, was Microsoft und Oracle in der Vergangenheit getan haben. Nun vermuten sie, das VMware dasselbe vorhat.” Der Wink mit dem Zaunpfahl ist hier nicht zu übersehen. Aber, Marten hat recht!

Tradition in der Moderne: Psychologen an die Front

Der Lock-in selbst ist an sich nicht das Problem. Wie viele Windows (Workstation/ Server) Installationen gibt es bspw. weltweit? Und wie viele Leute ärgern sich täglich über Windows und schimpfen auf das System, nutzen es aber dennoch weil es nicht anders geht? Und warum ist das so? Ganz einfach, selbst in der “alten Welt” haben wir uns regelmäßig in die Abgründe eines Anbieters begeben und uns bewusst auf einen Vendor Lock-in eingelassen. Es wurde nur in dieser Form, wie wir es heute tun, niemals darüber gesprochen. Denn, bleiben wir beim Beispiel Windows, hat man ein System (Windows Server) aus dem Hause Microsoft, dann hat man sich in 90% aller Fälle beim Mailserver auch für ein Microsoft System (Exchange) entschieden. Passt ja alles so gut zusammen, Schnittstellen und so weiter.

Es geht beim Cloud Vendor Lock-in nicht direkt um den Anbieter oder die Systeme selbst, nein es ist ein psychologisches Problem. Denn wo die DATEN und PROZESSE in der “alten Welt” noch auf den eigenen Servern ihr Unwesen trieben, befinden sich diese nun beim Anbieter, also nicht mehr im eigenen Einflussbereich.

Macht ALLE eure Hausaufgaben!

Es ist falsch mit dem Finger auf die Cloud Anbieter zu zeigen. Es wäre von den Anbietern aber ebenso falsch, nach Außen nicht offen zu sein.

APIs, APIs, APIs

Neben Ausnahmen stellen allerdings alle großen Player am Markt eine dokumentierte API nach Außen bereit. Wodurch sich die Daten, Systeme usw. wieder aus der Cloud herausholen lassen. Natürlich gibt es Services, die mit Vorsicht zu genießen sind. Zwei davon sind die Amazon DynamoDB und der Amazon Simple Workflow. Bei beiden handelt es sich um proprietäre Systeme, für die man explizit entwickeln muss und es bisher keine on-Premise Lösungen gibt. Aber machen wir uns nichts vor, auch ein Windows Azure, Rackspace, OpenStack, Eucalyptus, Google, T-Systems und wie sie alle heißen haben irgendwo einen Lock-in. Denn dabei handelt es sich nun einmal um proprietäre Systeme. Die Einzige Forderungen die man an die Anbietern stellen kann ist, zu allen Services die sie im Portfolio haben, auch eine umfangreiche API bereitzustellen, was sie zum größten Teil auch machen.

Evaluieren, Evaluieren, Evaluieren

Als Nutzer sollte man sich nicht auf einen Anbieter verlassen und vor allem generalistisch entwickeln. Die Web-TV Agentur “schnee von morgen” nutzt bspw. primär zwar die Amazon Cloud, hat aber ein equivalentes Code-Modell für die Google App Engine entwickelt. Es bringt nichts mit dem Finger auf einen Anbieter zu zeigen. Wenn er die Anforderungen nicht erfüllt, dann wird er halt nicht genommen, Punkt. Er wird schon sehen, was er davon hat. Um sich bestmöglich vor einem Lock-in zu schützen, muss ein Cloud Nutzer die Anbieter seiner Wahl daher penibelst unter die Lupe nehmen bzw. nehmen lassen und dann den Anbieter für einen Bereich auswählen, bei dem ein Lock-in nicht zutrifft. Es wird in Zukunft zudem vermehrt dazu kommen, dass man nicht alle Services von einem Anbieter bezieht, sondern auf Cloud Broker zurückgreift, die für die Zuteilung der Services zuständig sind.

Bildquelle: http://delimiter.com.au