001 - Cloud Landing Zones

Schon 2016 habe ich die ersten Public Cloud Landing Zones bewusst in Cloud-Projekten präsentiert und deren Wichtigkeit forciert. 8+ Jahre später muss ich immer noch feststellen wie schwer sich viele Unternehmen tun, das Thema effizient und professionell anzugehen. Hinzu kommen die fragwürdigen “Cloud Management-Plattformen”, bei denen ich mich jedes mal frage:

WIE kann eine zusätzliche Softwarelösung ein Problem lösen, wenn noch nicht mal die Grundlagen der nativen Design-Prinzipien angewandt wurden?

… sorry, dazu kommen wir später noch!

Hintergrund

Heute brauchen wir zum Glück niemanden mehr überzeugen, dass Public oder Private Cloud schlechter oder besser ist und in allen Unternehmen zum festen Bestandteil Ihrer modernen Enterprise Architektur gehören!

Es wundert auch niemanden mehr, warum der Großteil der Geschäftsanwendungen im Public Cloud Umfeld bereitgestellt wird, egal ob

• einfacher SaaS- (Software-as-a-Service) Lösungen und flexible Bereitstellung für spezifische Anwenderszenarien, losgelöst der geografischen Anbindung
• Ad-Hoc testen von komplexeren Anwendungen, ohne monatelanger Neubeschaffung, oder dass die IT verstanden hat, was das Business benötigt
• Softwareentwicklung in einer noch nie dagewesener Geschwindigkeit zu forcieren, da noch nie -fail fast, learn quick- realistischer war, als jetzt
• Architekturstandards zu forcieren, die man jahrzentelang ignoriert hat, egal ob Zero Trust-Prinzipien endlich zu etablieren oder einheitliche Hardware-/Software Standards zu gewährleisten
• oder einfach nur für die bessere CapEx- und OpEx- Planung, da nicht alle paar Jahre neue Hardware-/Software angeschafft werden muß

Leider mussten viele im Verlauf Ihrer Cloudprojekte feststellen: Cloudarchitekturen sind ebenfalls komplex und erfordern weiterhin gewisse Betriebs-Ressourcen!

Um diese Komplexität frühzeit zu adressieren, erfordert es die Enterprise-grade Landing Zone Design-Prinzipien einzuhalten!

Landing Zone

Wie bereits eingangs erwähnt, dieses ‘Landing Zone’ Prinzip wurde bereits vor Jahren von den einschlägigen Hyperscaler etabliert. Jedoch meist aus Mangel an Erfahrungen und fehlendem Wissen, wurden derlei Blaupausen meist unterschätzt und ignoriert.

Darüber hinaus gab (gibt) es X-verschiedene Meinungen und Interpretationen zu den einschlägigen Frameworks, wie (Auszug)

• AWS Well-Architecture Framework
• AZURE Well-Architecture Framework
• GCP Architecure Framework
• BSI C5 Katalog
• CNF Cloud Landscape

Was immer wieder unterschätzt wird, in welcher Vielzahl es hier Referenzarchitekturen gibt. Praxiserprobt, Einhaltung der relevanten Best-Practices und nicht zu vergessen, die problemlose Eingliederung in die bestehenden IT-Betriebsprozesse!

Vor einigen Jahren hat man Berge an Papier verfasst (leider auch heute noch anzutreffen), alleine schon um eine zwingend erforderliche Tagging- und Namens- Richtlinie zu konzeptionieren. Geschweige denn, ein halbwegs vernünftiges, hybrides Netzwerkkonzept aufzubauen!

All diese Dinge sind KEINE individuellen Herausforderungen mehr, sondern weit verbreitete Standards, die täglich Ihre Anwendung finden - lassen Sie sich hier nicht von Externen beirren!

Hinzu kommen auch heute im AI-Ops-Zeitalter (alle die bereits den nächsten DevSecOps-Reifegrad erreicht haben) - KEINE Cloud-Umgebung, kann autark und ohne Betriebskonzept, sicher und effizient (wirtschaftlich !!) betrieben werden. Gilt auch für SaaS-Applikationen, die extrem unterschätzt werden, was Ihre Sicherheit und Datenschutz betrifft!

Lösungsansatz

WIE & WO fange ich an?

• Niemand fängt auf grüner Wiese an. Daher ist es am einfachsten, einen kurzen “Landing Zone Check” von Experten durchführen zu lassen, die wissen was Sie tun!
  • Beachten Sie, derlei Checks benötigen nicht mehr als 2-4 Tage, wenn man weiss, welche Management-Portale wie genutzt werden können!
  • Der Dienstleister sollte fundierte Multi-Cloud Expertise haben und nicht einzelne Hyperscaler per se bevorzugen (Cloud-agnostisch)!
  • Ebenso die Bewertung im Kontext der vorgefundenen Dienste und nicht den Hersteller-White-Paper nachplappern!
• Danach Fokus auf die kritischen Findings und gezielte Architektur-Workshops mit den jeweiligen Verantwortlichen. Niemand wird über Nacht zum Cloud-Experten!

WAS sollte nun in einer aktuellen Multi-Cloud Landing Zone alles beachtet werden?

Hier die wichtigsten Schritte beim Konzeptionieren:

• Berücksichtigen Sie IMMER die bereitgestellten Referenzarchitekturen (Blaupausen), wie AZURE Architecture Center oder AWS Well-Architected Lenses - da für Grundszenarien (Tagging, Naming, Netzwerk, Security) umfassende Architekturvorgaben existieren!
• Die Grundlagen müssen sauber implementiert werden, wie einheitliches SSO (nur einen führenden IdP verwenden!), hybrides Netzwerk mit entsprechenden Security Zonen (nein, muss nicht immer gleich Cloud-Firewall per se bedeuten!), Standardeinstellungen zentral forcieren (Bsp. Azure Policies oder AWS Config/Security Hub), einheitliche Verwaltung von Cloud Accounts/Subscriptions mit selbigen Grundeinstellungen (Bsp. Netzwerk, Kosten-Alerts, erlaubte Dienste & Regionen)
• Nutzen Sie die hilfreichen AWS Workshops Portale oder AZURE Architecture Blog, um Architektur Deep-Dive Trainings durchzuführen
• Bleiben Sie aktuell mit Azure, mit den sehr hilfreichen YT-Videos von John Savills oder einschlägigen News Blogs von AWS oder Azure Weekly

Hier die wichtigsten Schritte beim Deployment/Betrieb:

• Nutzen Sie etablierte und aktuelle Infrastructure-as-Code (IaC) Vorlagen und entsprechende CI/CD-Pipelines
  • Auch hier nicht das Rad neu erfinden und von Scratch mit z.B. Terraform starten, Sie brauchen auch nicht eine darüberliegende Management-Plattform (unnötige Komplexität!)
  • Nutzen Sie Azure Sovereign Landing Zone für sichere Landing Zones & maximalen Datenschutz oder AWS Control Tower und AWS Security Reference Architecture
• Etablieren Sie eine einheitliche Überwachung: immer zuerst Cloud-native Mechanismen evaluieren und danach Bestandssysteme anpassen.
  • Mitlerweile haben viele Anbieter eine PaaS/SaaS-Integrationsmöglichkeit (Grafana, New Relic, Splunk, Elastic ..) und somit sparen Sie Datentransfer-Kosten (nicht zu unterschätzen!)
  • Integrieren Sie Service Management direkt über die einschlägigen REST-API’s, nur so kommt eine Kontinuität und Awareness im Alltags-Cloudbetrieb zum Tragen
• FINOPS (Cloud-Kostenkontrolle) muss ein etablierter Prozess werden - hier bieten ALLE Hyperscaler ein umfassendes Kostenmanagement an, muss nur initial sauber eingerichtet und als Prozess etabliert werden!

WIE gehe ich mit SaaS-Anwendungen um?

Wenn ein Unternehmen seriös Software-Inventur durchführt, dann ist es keine Seltenheit mehr, dass in mittelgroßen Firmen hunderte von SaaS-Applikationen/Plugins vorzufinden sind! Fast immer komplett ungemanaged, da hier meist durch den Fachbereich eine Funktion benötigt und kurzfristig lizenziert wurde. Somit fehlt es fast immer an:

• einheitlicher, sicherer Benutzerverwaltung (am Besten natürlich es ist in das unternehmensweite SSO integriert!)
• genereller SaaS-Inventur, was überhaupt aktiv genutzt wird (Kleinvieh in dem Bereich erzeugt hohe Kosten! Ebenso welche Daten abgelegt/ausgetauscht werden!)
  • Hier helfen Tools wie Microsoft Defender for Cloud Apps, oder am Perimeter die einschlägigen Firewall Analyse-Tools verwenden
• nutzen Sie einschlägige Leitlinien, wie den von der Cloud Security Alliance: SaaS Governance Best Practices for Cloud Customers, oder vom BSI: Sichere Nutzung von Cloud-Diensten

NOCH FRAGEN? SIE SUCHEN PRAXISERPROBTE KONZEPTE & IMPLEMENTIERUNGSUNTERSTÜTZUNG?

Kontaktieren Sie mich: gf @ ctopilot . de oder vereinbaren Sie einen Online-Termin!

Erfinde in der IT nicht immer das Rad neu. Lerne von den Besten und höre niemals auf zu lernen!

Gerald Fehringer