Viele Wege führen nach Rom…
In den letzten Monaten habe ich immer wieder mit Kunden diskutiert, was es bedeutet, unabhängig zu jeglicher Cloud zu sein. Welche Anforderungen muss ich erfüllen, damit ich nicht in die Lage komme, dass ich nur mit großer Mühe eine Cloud wieder verlassen kann? Warum will ich überhaupt cloud-neutral sein? Welche Nachteile hat es, wenn ich cloud-neutral bin?
Der Stein des Anstoßes ist meistens ein ähnlicher Gedanke.
- “Unsere Entwickler nutzen Public Clouds.”
- “Wir wollen die Hoheit über unsere Infrastruktur behalten und gleichzeitig agiler werden.”
- “Der Wildwuchs in meinem Rechenzentrum hindert mich daran aktiv neue Projekte anzugehen, weil mir die Zeit fehlt und ich meine Zeit mit Patching und Fehlersuche verbringe.”
Das ist lediglich ein kleiner Auszug aus den Gedanken. Am Ende führt es immer wieder in eine Richtung:“Wir müssen Cloud machen!”
An sich ist der Gedanke super. Unter Cloud verstehen zehn Leute allerdings elf verschiedene Dinge und nur weil ich Cloud mache, mache ich auch nicht gleich Cloud. Wie auch immer…
Wenn ich unabhängig von jeglichen Clouds sein möchte, brauche ich eine Standardisierung, die sich in jeder gewählten Cloud umsetzen lässt. Das bedeutet, dass ich mich auf Dienste beschränke, die überall verfügbar sind.
Ein Beispiel: Ich möchte eine simple 3-Tier Applikation betreiben und habe heute Amazon Web Services (AWS) als meinen bevorzugten Cloud Provider gewählt. Da meine Entwickler keine Ahnung von Infrastruktur haben, wurden bei AWS als Loadbalancer der Elastic Load Balancer, mehrere Apache Webserver und als Datenbank das Relational Database Service (RDS) von AWS betrieben. Das ist grundsätzlich ein guter Gedanke, um Applikationen schnell auf den Markt bringen zu können.
Spannend wird es, sobald ich feststelle, dass die Applikation beim permanenten Betrieb und in erheblicher Skalierung zu teuer wird oder mein Unternehmen strategisch entscheidet in Zukunft nur noch mit Microsoft Azure zu arbeiten. Ab dem Moment muss ich mir überlegen, wie ich diese Applikationen umschreiben kann, sodass sie auch in anderen Umgebungen lauffähig werden. Zusätzlich zu den Diensten kommen die Anforderungen des Netzes an die Applikationen.
Applikationen, die allein auf Layer 3 Ebene arbeiten, lassen sich über geschicktes Load Balancing sicherlich migrieren. Sobald allerdings Abhängigkeiten auf Layer 2 Ebene entstehen, wird es früher oder später komplex.
Wie migriere ich Applikationen ?
Wenn Applikationen heute oder in naher Zukunft migriert werden sollen und/oder die Möglichkeit bestehen soll eine Applikation zu einem späteren Zeitpunkt in irgendeiner anderen Cloud (Public oder Private) auszurollen, dann sollte ein Tool die Kontrolle haben die Installationsroutinen ausführen zu können.
Cisco CloudCenter bietet hierbei die Möglichkeit genau eine solche cloud-neutrale Umgebung aufzubauen. Ohne weiter auf das Produkt als ein solches einzugehen, ist es unbedingt notwendig die Rahmenparameter abzustecken.
Ich kann eine Applikationen nur dann migrieren, wenn Netzwerkregeln und Tunneltechnologien so definiert sind, dass Applikationen unabhängig von der Umgebung funktionieren können.
In den meisten Fällen, wenn klassische Applikationen (wie beispielsweise die erwähnte 3-Tier Applikation) migriert werden sollen, kommen wir zu folgendem Szenario:
- Eine 3-Tier Applikation in der Private Cloud soll in eine Public Cloud umziehen
- Die Applikation wird als neue Hülle in der Public Cloud aufgebaut
- Kommunikationsbeziehungen müssen an die Regelwerke angepasst werden
- Daten werden migriert
- Die “alte” Applikation wird abgeschaltet
Das ist nur ein Beispiel, denn es gibt hier keine Allzwecklösung. Wenn ich beispielsweise ein Distributed Database verwende, kann ein solcher Prozess auch mehr oder weniger “live” passieren. Wenn eine Applikation bereits auf Kubernetes läuft, könnte theoretisch ein Cluster eingebaut werden, der die Grenzen zwischen Public und Private Cloud auflöst.
Warum theoretisch? Die Frage ist: Will ich das wirklich? Sind die Security Mechanismen in der Tat komplett gleich, sodass ich weiterhin die Compliance einhalte?
Es sind also nicht immer technische Probleme die auftreten, sondern häufigiger Sicherheit und Compliance, die eine reibungslose Cloudneutralität erschweren.
Authors
