Multi Cloud Management – Big Bang Controller!

Lesezeit: 20 Minuten

alt text

CDT.HINTERGUND

Status Quo

alt text


Es gibt kaum noch Unternehmen, die nicht mindestens einen Clouddienst nutzen und in größeren Firmen ist es keine Seltenheit, wenn 100+ Clouddienste im Umlauf sind.

Viele habe diese nicht mal genau identifiziert, weil Sie als Software-as-a-Service (SaaS) kurzerhand aktiviert wurden, Bsp. Adobe Cloud, Entwicklerumgebungen oder Cloud-basierte Plugins für einschlägige Office365-Applikationen.

Gerade im “innovativen” Unternehmensumfeld kommt eine Vielzahl an SaaS-/PaaS-Lösungen zum Einsatz, egal ob für die agile, moderne Entwicklung oder um digitale Geschäftsideen kurzfristig zu testen und so nebenbei auch gleich produktiv zu nehmen.

Multi Cloud Management

Am Ende des Tages geht es nicht nur mehr um das Management einer Public Cloud, sondern einer Vielzahl von Software-as-a-Service, Platform-as-a-Service, Infrastructure-as-a-Service und Function-as-Service (SaaS/PaaS/IaaS/FaaS) Lösungen.

Diese in Einklang zu den bestehenden IT-Vorgaben zu bekommen, die über Jahrzehnte akribisch ausgearbeitet und implementiert wurden, ist für alle Unternehmen eine große Herausforderung geworden – insbesondere da die meisten Cloudprojekte außerhalb der zentralen IT passieren!

Des Weiteren sind Public Cloud-Dienste und Infrastrukturen per se standardisiert und folgen einer hoch-automatisierten Implementierungslogik. Also alles was über viele Jahre in der Unternehmens-IT weitgehend ausgeblendet wurde, um weiterhin den Fokus der individuellen Anpassungen zu folgen!

Immer unter dem Motto:

„Wir sind so speziell, dafür gibt es keine Lösung von der Stange!“

Aktuelle Lösungsansätze

Die Rettung naht! So auf jeden Fall wird es einem durch einschlägiges Buzzwording und unterschiedlichen Weboberflächen von kommerziellen Anbietern suggeriert. Gartner hat hierzu im Januar 2018 Jahren begonnen die Rahmenparameter festzulegen, siehe Gartner Blogeintrag und dabei folgende Mindestanforderungen an eine „Cloud Management Plattform“ definiert:


alt text Quelle:
Gartner MCMP Blog


Durch die ursprüngliche Idee des „Cloud-Brokerings“ und heute vielleicht auf Amazon AWS 50 EC2-Instanzen hochzufahren und am nächsten Tag, weil vielleicht günstiger oder schneller, diese kurz nach Microsoft Azure zu verschieben, entstanden natürlich auch sehr schnell viele Lösungsideen.

Wenn Sie heute in Google nach „Cloud Management“ oder „Cloud Brokering“ suchen, werden Sie eine hohe Anzahl an allen möglichen Tools bekommen. Angefangen von „Cloud Preisvergleichs-Portalen“, „Cloud Kosten- und Ressourcen-Optimierung“ oder vollumfängliche „Multi Cloud Orchestrator-Plattformen“, wie im nachfolgenden Gartner Quadrant abgebildet.

Der aktuelle Gartner Quadrant zu „Cloud Management Plattforms“ - Februar 2020.

alt text

Die Top-Player im Markt und die wir bei den ein oder anderen deutschen Kunden sehen:

  • Flexera (ehemals RightScale)
  • Morpheus Data
  • Scalr
  • CloudBolt

Diese Lösungen sind bei Weitem keine Click-and-run Installation und erfordern eine entsprechende Konzeptionierung und die Implementierungen sind komplex, wenn es mehr als eine Spielwiese bleiben soll!

CDT.BIG BANG CONTROLLER

Sinnhaftigkeit eines Cloud Orchestrator?

Der Autor kennt die genannten Lösungen und beschäftigt sich seit 2016 intensiv mit dem Thema wie Multi-Cloudumgebungen im heutigen IT-Zeitalter, sinnvoll gemanagt werden können.

Darüber hinaus haben wir die letzten 2 Jahre bei CLOUDETEER intensiv Lösungen und Frameworks evaluiert, auf Basis einer Vielzahl an unterschiedlichsten Cloudprojekten bei unseren Kunden.

Wie werden Public Cloud Infrastrukturen gemanagt?

Zu Beginn und leider häufiger permanent anzutreffen, mittels der einschlägigen Management Portalen, Beispiel: Azure Portal, AWS oder GCP Konsole.

Dies ist sicherlich sinnvoll, um zu Beginn sich mit den einzelnen Cloudlösungen vertraut zu machen. Jedoch spätestens, wenn größere Umgebungen, nach klaren Vorgaben “(Cloud Governance) bereitgestellt werden müssen, wird man sehr schnell an die Grenzen kommen!

Alle Hyperscaler-Architekturen sind von Haus aus nach der Software-Defined-anything (SDx) Logik aufgebaut und haben per se einen darunterliegenden Automatisierungs-Stack und nutzen entsprechende (REST) API’s. Diese sind fast gänzlich von extern, nach entsprechender Authentifizierung, erreichbar und werden auch kontinuierliche erweitert/abgekündigt.

Hier die Online-Verweise der API-Möglichkeiten bei

Zu den API’s selbst hat auch jeder Cloud-Provider seine Basisautomatisierungslogik für Infrastructure-as-Code (IaC) Implementierung.

  • Microsoft Azure – ARM und SDK’s für alle gängigen Programmiersprachen (Bsp. Azure SDK for Python)
  • Amazon AWS – CloudFormation und SDK’s für alle gängigen Programmiersprachen (Bsp. Boto3)
  • Google GCP – Cloud Deployment Manager (Python, Jinja2) und SDK’s für alle gängigen Programmiersprachen

Darüber hinaus entwickelt sich Hashicorp Terraform schnell weiter und ist de-facto der Infrastructure-as-Code (IaC) Standard geworden. Auch wenn jetzt hier die Ansible/Chef/Puppet-Fraktion wahrscheinlich einer anderen Meinung ist ;-)

Wie funktionieren die kommerziellen Lösungen?

Alle Lösungen müssen zwangsweise den davor beschriebenen Public Cloud Automatisierungs-Logiken folgen, ausnahmslos. Darüber hinaus obliegen den Zugriffen auf die Cloud-API’s, rigorose Vorgaben im Bereich Authentifizierung und wie auf die jeweiligen Bereiche zugegriffen werden kann und in welchem Umfang.

Alle Lösungen haben ihren Ursprung im Open Source Umfeld, sind immer Linux-basiert und bedienen sich bekannter Funktionen und Webservices-Frameworks. Egal ob es eigene „Python-Engines“, auf Basis bekannter Bibliotheken oder die altbekannten Ansible/Puppet/Chef Automatisierungs-Tools sind.

Viele laufen auch als Cloud-only Version und bieten anspruchsvolle Weboberflächen und meistens ist hier ein Großteil der „Software Logik“ verbaut oder nennen wir es der „echte Mehrwert“ ;-)

Somit stellen sich folgende Fragen:

  • Warum soll ich ein Tool als Abstraktionsschicht, von einer Abstraktionsschicht verwenden?
    Alle Tools müssen auf die nativen Hyperscaler-Funktionen zurückgreifen!

  • Wer migriert Cloudanwendungen wöchentlich, monatlich von einem Provider zum nächsten?
    Alleine die Komplexität einer IaaS/VM besteht aus: Netzwerk, Subnetz, NIC, Routing, Load Balancer, Security, Region, VM, Disk, Storage..und die Preisunterschiede untereinander unterscheiden sich nur noch geringfügig!

  • Netzwerk bleibt Netzwerk, auch im Cloudzeitalter!
    Anwendungen kann ich maximal abstrahieren (Serverless, Microservices). Aber der Großteil der Anwendung benötigt nach wie vor Multi-Tier Infrastrukturen (Bsp. Frontend, Backend, Middleware) und somit komplexe Netzwerkarchitekturen auf dem jeweiligen Hyperscaler – diese sind nicht ohne weiteres zu migrieren. Alleine am Beispiel Azure Hub & Spoke versus AWS Netzwerk wird man die Komplexität erkennen. Hier muss Hand angelegt und konzeptioniert werden, da hilft auch nicht das beste Tool und kein Infrastrucuture-as-Code Snippet!

  • Die IT muss sich so oder so mit Infrastructure-as-Code & Automatisierung zwingend auseinandersetzen – warum nicht gleich mit den anerkannten Standards arbeiten?
    CI/CD Pipelines mittels Azure DevOps, Jenkins oder Gitlab, oder Ansible und Terraform. Ein IT-Administrator muß sich intensiver mit Python, YAML, Docker und Kubernetes auseinandersetzen, um seine Cloudinfrastruktur bereitzustellen. Gestern vCenter-Vorlagen und heute Ansible, Terraform Skripte.

  • Warum eine proprietäre Template-Engine verwenden und erlernen, die im Hintergrund eine Konvertierung, im jeweiligen nativen Format vornimmt?
    Die Hyperscaler haben hier Ihre Standards wie Azure ARM, AWS Boto3, Terraform, Ansible oder offiziellen SDK’s.

  • Managed Kubernetes wird immer häufiger eingesetzt und hat seinen komplett eigenen Orchestrator, somit benötige ich ein zusätzliches Management Tool?
    Auch hier ist ein riesiger Markt entstanden und es gibt eine bessere Weboberfläche nach der anderen, als auch Abstraktionsschichten. Wir betreuen einige Managed Kubernetes-Umgebungen und unsere Erfahrung hat uns eines gelehrt: stay Native und Boardmittel sind perfekt! Monitoring ist die Herausforderung, nicht das Management!

  • Die Implementierung dieser Management Tools selbst ist komplex, erfordert fundiertes Linux, als auch Cloud Know-How!
    Kein Enterprise-Unternehmen nutzt eine Standard-VM aus dem Marketplace ohne weiteres und spezifische PaaS-Services müssen sowieso komplett „customized“ werden. Somit kommt zu der teuren Lizenzierung, auch einiges an externer Dienstleistungsunterstützung hinzu. Es ist auch keine Seltenheit, dass ein kompletter Managed Service dafür eingekauft wird. Hier sollte man den „Kosten / Nutzen“ für sich hinterfragen!

Zwischenfazit

Mit dieser Meinung bin ich nicht allein und hier finden Sie einen sehr amüsanten Artikel vom April 2020, über Multi Cloud Management und den „BIG BANG CONTROLLER“ 😉, siehe http://www.ifconfig.it/multiverse/.

Viele haben festgestellt, dass derlei Management Tools unnötig, kompliziert und überteuert sind. Darüber hinaus werden meist sehr einfache Workloads abgebildet, also IaaS/VM und einfache PaaS-Implementierungen. Am Ende des Tages muss man den jeweiligen Clouddienst und Abhängigkeiten verstehen und nicht nur bereitstellen. Ebenso darf das Cloudmonitoring nicht unterschätzt werden, das ein integraler Bestandteil sein sollte.

Im Jahre 2016/17 hat der Public-Cloudmarkt auch noch anders ausgesehen und viele dachten, wir integrieren einen Cloud-Service-Katalog/Cloud-Brokering. Zu dem Zeitpunkt war auch noch die einhellige Meinung, dass jedes Unternehmen seine eigene „Private Cloud“ (OpenStack, CloudFoundry) aufbaut. Wie die aktuellen Zahlen belegen, die wenigsten Private Cloud Projekte waren erfolgreich - klassisch VMware, zählt nicht als Private Cloud-Stack ;-)

Die Cloudtechnologien schreiten in einer Geschwindigkeit voran, wie nie zuvor in der IT und obliegen ständigen Veränderungen. Somit müssen alle Management Tools dazwischen ständig angepasst und aktualisiert werden!

Was nun?

  1. Gehen Sie hier mit Bedacht vor, auch hier gilt wieder – NICHT DAS TOOL IST ENTSCHEIDEND, sondern Public Cloud Services für sich sinnvoll eruieren, kennenlernen und vergleichen (Fokus auf PaaS/SaaS/FaaS).

  2. Machen Sie sich mit den nativen Mitteln vertraut, Bsp. Azure ARM und den Vielzahl an freien Github Quickstart-Vorlagen, oder AWS CloudFormation Vorlagen

  3. Public Cloud Provider forcieren Standardisierung, somit sollten Sie von Beginn an für alle Cloudprojekte entsprechende Vorgaben etablieren. Nur so kann später auch wirklich „echtes“ DevSecOps gewährleistet werden. Hier gibt es ausgezeichnete Cloud Adoption Frameworks, siehe auch CLOUDETEER CAF.

  4. Ziehen Sie gezielt externe Expertise hinzu. Hier sehen wir leider immer wieder, dass sich viele Unternehmen sehr schnell in den Bann von DevOps ziehen lassen und dabei noch nicht die ersten Schritte Ihrer Cloud-Transformation implementiert haben (Bsp. Hybride Netzwerkanbindung, Rechte- und Rollenkonzept, DevOps Basis-Toolset oder Cloud-Betriebsvorgaben).


Wir als CLOUDETEER haben dahingehend unseren Open Source OPS.STACK entwickelt und passen diesen kontinuierlich an. Am Beispiel von unserem Azure Marketplace oder auf unserer Webseite können Sie mehr darüber erfahren.

Unser Anspruch war von Beginn an:

  • Maximale Nutzung von nativen APIs (AWS, Azure, GCP, Oracle, SAP …)
  • Fokus auf eine flexible Continuous Integration & Continuous Deployment (CI/CD) Toolchain
  • Maximale Transparenz der aufgebauten Cloudarchitektur (automatisierte Inventur und somit agile Betriebsdokumentation, Nutzung von Kanban, alles ist Infrastructure-as-Code auf Basis Terraform oder wenn nicht anders möglich, die Hyperscaler-nativen Automatisierungstools)
  • Multi Cloud Operations (professionelle Überwachung, Alarmierung und ITSM-Integration, Responsive-Dashboards die in wenigen Stunden individuell angepasst werden können)
  • Es geht nicht nur um den Betrieb allein, es muss auch die Cloudarchitektur kontinuierlich optimiert werden. Public Cloud ist kein 5-Jahres One Time-Investment!


Ich freue mich auf Rückmeldungen und Ihre Meinung zu diesem Thema!

Gerald Fehringer
CISA, CISM, CISSP, OSCP, CE|H
E-Mail: gf |at] cloudeteer.de
Twitter: @zerohat