CIO Guide zu Cloud Betriebsmodellen

Lesezeit: 20 Minuten

alt text

INTRO

☁ Moderner MULTI-CLOUD Betrieb - das unterschätzte Thema! ☁

Die Organisation von IT Betriebsteams ist eine komplexe Angelegenheit geworden. Durch den Einsatz einer Vielzahl von Hardware- und Softwarelösungen haben sich vielfältige Silos gebildet. Speicher-, Netzwerk-, Firewall-, Server-, Virtualisierungs- und Betriebssystemteams sind durch das Service Management Teams nur schwerfällig zur Zusammenarbeit zu bewegen.

Auch wenn das System gut aufeinander abgestimmt ist, produzieren vielfach anfallende, einfache Changes einen unglaublichen Koordinations- und Verwaltungsaufwand, der in keinem Verhältnis mehr zu der eigentlich durchzuführenden Arbeit steht.

Diese langjährig eingespielten Prozesse und strikte Trennung der IT Betriebsteams sowie starre, mit hohem manuellen Aufwand verbundene Releaseprozesse, lassen jedoch jeden Versuch in der Cloud Innovation und Agilität zu entfalten im Keim ersticken. Und das muss nicht so sein!

AKTUELLE SITUATION

Fail fast / learn fast, DevOps, cross-funktionale Teams, Site Reliability Engineering - große, erfolgreiche Technologieunternehmen sind auch insbesondere deswegen so erfolgreich, weil sie neben dem gezielten Einsatz von neuen Technologien auch den Betrieb grundlegend anders organisiert haben. Nicht umsonst hat z.B. Site Reliability Engineering seinen Ursprung bei Google. Wie kann die eigene Organisation hiervon profitieren?

Mythos

Die Einstellung, dass man im Cloud-Zeitalter das bisherige On-Premise Betriebsmodell 1:1 weiterführen kann, ist leider weit verbreitet. Darüber hinaus wird der Gedanke an das zukünftige Betriebsmodell von Cloud Umgebungen in der Projektphase häufig stiefmütterlich behandelt und man merkt erst nach der Inbetriebnahme, was alles für einen reibungslosen Betrieb noch fehlt.

Es beginnt bei banal einfachen Dingen, wie:

  • Wer ist eigentlich für den Cloud-Plattformbetrieb zuständig - Sysadmin, Netzwerker, Security, Cloud Competence Center?
  • Welche Events & Metriken muss ich überhaupt aktivieren?
  • Werden die Cloud-Ressourcen in unserer zentralen CMDB inventarisiert?
  • Wie gehen wir mit Cloud Service Management Anfragen um, wo landen Tickets und wer bearbeitet diese?
  • Welche Cloud Service Management Prozesse sind tatsächlich notwendig und was kann von Teams eigenverantwortlich bearbeitet werden?
  • Wie können manuelle Prozesse durch robuste, reproduzierbare und schnellere Automatisierung abgelöst werden?
  • Wie kann eine positive, konstruktive Fehlerkultur etabliert werden?


Die Fragen die sich jedes Cloud-Betriebsteam daher, zeitnah stellen muss:

-Wer übernimmt die Verantwortung für den Cloud-Plattform Betrieb (bestehendes/neues Team)?
-Sind wir fachlich aufgestellt, um adäquaten Cloud-Basis Support überhaupt zu leisten?
-Sollen individuelle Cloud-Applikationen durch die Entwickler selbst überwacht werden?
-Existieren schon *SRE-/*DevOps- Prinzipien in unserer Organisation?
-Ist unsere bestehende Überwachungsinfrastruktur (Tooling) Cloud-ready?
-Was für zusätzliche Kosten muss ich für Cloud-native Überwachung einkalkulieren?
- Sind Voraussetzungen für FinOps in der Organisation gegeben um den Wechsel von CapEx hin zu OpEx begleiten?

*DevOps: SAFe - The DevOps Handbook
*SRE: IBM - Implement Site Reliability Engineering

WAS hat sich geändert?

Nicht nur das Thema Infrastructure-as-Code, automatisierte Cloud-Bereitstellung, sondern auch das Thema Logging und Überwachung hat sich in den letzten Jahren deutlich verändert und sich stark auf die Gestaltung der Cloud Betriebsteams ausgewirkt.

Auf der einen Seite haben wir die Hyperscaler (Cloud-Provider wie AWS, AZURE oder GCP), die Ihre Software-Defined-Anything Architektur auf massive Skalierung von millionen von Kunden ausgerichtet haben und auf der anderen Seite, das neue Zeitalter von modernen Softwarearchitekturen, wie Containerisierung, Microservices oder Serverless.

All diese verschiedenen Dimensionen (Schichten) müssen adäquat protokolliert, als auch überwacht werden. Hier passiert sehr häufig der Fehler, sich zu sehr auf Security zu fokussieren, anstatt den kompletten Stack darunter gleich mit zu betrachten!

Hier ein Beispiel, welche Multi-Cloud Ebenen heute überwacht werden müssen und wie sich dahingehend auch das “Tooling” anpassen muss:

CDT Multi CLoud Monitoring Landscape Anklicken zum Vergrößern

Die Abbildung zeigt schematisch wie wir unsere Cloudüberwachung bei Kunden vornehmen und in unseren CLOUDETEER OPS.STACK integriert haben.

Auch hier dominieren einschlägige Open-Source Lösungen und sind in der *CNCF-Community etablierte Referenzarchitekturen!

*CNCF: Cloud Native Computing Foundation - Observability Tools

Durch das Thema Containerisierung, Microservices und Orchestrierungs-Plattformen wie Kubernetes, kommen zusätzliche Technologien und Komplexitäten hinzu, wo es bislang im klassischen IT-Betriebsumfeld wenig Berührungen gab.

In diesem Umfeld spricht man auch von “Distributed Tracing", da hier eine hohe Dichte an Applikationen und darunterliegende Infrastruktur überwacht werden muss. Auch hier ist eine professionelle Monitoring-Integration zwingend erforderlich und in eine standardisierte Architektur zu überführen.


WO und WIE fange ich an?

Wie so häufig im Betriebsumfeld, gilt es hier einen pragmatischen und nicht ein “Tool-fits-all” Ansatz zu wählen. Zuerst die wichtigsten, organisatorischen Voraussetzungen und danach die technischen Lösungen klären!

Wir haben in den letzten 5+ Jahren eine Vielzahl an Cloudprojekten begleitet, als auch bestehende Betriebsmannschaften in die Lage versetzt, ein passendens Cloud-Betriebsmodell zu etablieren.

Unsere Erfahrung hat gezeigt, das die nachfolgenden Themenblöcke in jedem Cloud-Projekt, egal wie klein oder groß, rechtzeitig berücksichtigt werden sollten:

1. Klärung zur Aufstellung des Cloud-Plattform Betriebs - eigenes versus bestehendes Team? Die Verantwortlichen müssen sich über ein passendes Cloud-Betriebsmodell einig werden. Hier geht es nicht sofort vollumfänglich DevOps-Prinzipien, oder die perfekte Cloud-Automatisierung zu etablieren. Beginnen Sie über das Cloud Competence Center entsprechende Schlüsselressourcen zu begeistern und hier in kleinen Schritten loszulegen.

2. Klärung ob Cloud-Anwendungsbetrieb durch Entwickler durchgeführt wird - hier bedarf es sich mit den SRE-, DevOps- und ITILv4- Prinzipien auseinander zu setzen. Die Komplexität der Cloud-basierten Anwendungen sollte nicht unterschätzt werden und bedarf fast immer einer sehr engen Abstimmung und Zusammenarbeit mit den Softwareentwicklern. Nur dadurch wird später ein reibungsloser Cloud-Betrieb gewährleistet, ohne zeitintensiver Nachforschung (Root-Cause-Analyse) bei Problemen.

3. In-house Cloud-Expertise evaluieren (Culture-Change durch Externes Know-How) - Cloud-Expertise wird nicht über Nacht aufgebaut und schon gar nicht, wenn nebenbei Linienaktivitäten weiterhin wahrgenommen werden müssen. Es bedarf dedizierter Ressourcen für das Thema Cloud und auch hier mit fokussierter Ausrichtung der Fachlichkeit (Bsp. Azure, AWS, Kubernetes oder M365). Hier zeigt sich, wenn gezielt externe Experten hinzugezogen werden, kann hier die eigene Mannschaft deutlich schneller “Up-to-Speed” gebracht werden. Aber natürlich muß den Mitarbeitern ein Weg aufgezeigt werden, damit Sie nicht abgehängt werden (Lernpfade, Zertifizierungen, Freiräume für Schulungen und Hands-On Trainings).

4. Anpassungen des Toolings für Monitoring & Alarmierung - vertrauen Sie nicht allein auf Forrester- oder Gartner-Quadrant’s. Hier gilt es nicht, das Beste kommerzielle/Open-Source basierte Tool zu finden, sondern was zuerst Ihr Anspruch in dem Bereich ist. Hier muss man sich den Fragen stellen:
Wie weit möchte ich mit meiner automatisierten Cloud-Bereitstelllung gehen? Starte ich sofort mit Continuous Deployment-Pipelines? Benutzen wir proprietären Infrastructure-as-Code pro Cloud, oder offenen Standard? Welche Events und Metriken muss ich überhaupt überwachen? Welche Cloud-nativen Tools sollten wir sinnvollerweise verwenden?
Überlegen Sie sehr genau, ob Sie sich eine “Cloud Management Plattform Lösung”, wie Morpheus Data oder Flexera ins Haus holen. Da hier eine Abstraktionsschicht vor einem Public Cloud Provider und der suggerierte Cloud-Service-Katalog wenig sinnvoll ist. Darüber hinaus holen Sie sich eine zusätzliche Komplexität, der weder wirtschaftlich, noch hilfreich im täglichen IT-Betrieb ist.

5. Service Desk Integration in einen modernen Cloud-Betrieb - die Vielfalt und somit hohe Komplexität von Cloud-Diensten, erfordert auch im Service Desk neue Ansätze. Es bedarf einer smarten Cloud-CMDB (automatisiertes Inventory), damit hier eine zentrale Sicht, als auch Kostenmonitoring ermöglicht wird. Darüber hinaus auch agile Betriebshandbücher auf Basis von Markdown-Syntax und durch die häufigen Änderungen muß das Thema GitOps mitberücksichtigt werden. Nutzung von zentralen Cloud-Dashboards (übergreifende Visualisierung der wichtigsten Komponenten) auf Basis, z.Bsp. Grafana oder Kibana, für übergreifende Sichten auf Multi-Cloud Umgebungen.

6. Realistische Einschätzung und eventuell Übergangs-Cloudbetrieb durch Externe - wenn produktive Cloud-Workloads Live gehen sollen und Sie unsicher sind, ob Sie diese in Eigenregie verwalten können, holen Sie sich lieber einen flexiblen Cloud Service Provider. Hier sollte nicht gleich ein 5-Jahres Servicevertrag unterzeichnet und auch gezielt auf einen Provider zugegangen werden, der praktische Erfahrung und auf Augenhöhe den Betrieb übernehmen kann.

FAZIT

Um ein erfolgreiches und langfristiges Cloud-Betriebsmodell zu etablieren, erfordert es eine Neuausrichtung der bestehende IT-Silos. Hinzu kommt eine enge Verzahnung mit den Applikationsentwicklern, denn nur dadurch kann der erforderliche Automatisierungs-grad erreicht werden.

Nutzen Sie die Chance, um ihre bestehende IT-Organisation der neuen IT-Ära anzupassen und mit Cloud Technologien Ihre Systemlandschaft zu modernisieren - *SaaS/DaaS before PaaS/CaaS before FaaS before IaaS!

*SaaS: Software-as-a-Service (Bsp. Salesforce)
*DaaS: Desktop-as-a-Service (Bsp. Microsoft AVD/Managed Desktop)
*PaaS: Platform-as-a-Service (Bsp. Managed SQL)
*CaaS: Container-as-a-Service (Bsp. Azure AKS, AWS EKS, Google GKE)
*FaaS: Function-as-a-Service (Bsp. Azure Logic Apps, AWS Lambda, Google Cloud Functions)
*IaaS: Infrastructure-as-a-Service (Bsp. VM's, EC2)




Wir als CLOUDETEER haben vielfältige Projekterfahrung für sichere Implementierung von Public Cloud-Diensten und als Cloud Managed Service Provider, erleben wir die täglichen Betriebs-Herausforderungen hautnah.

Darüber hinaus unterstützen wir auch Entwickler auf Ihrer Cloud-Reise, um IaaS/PaaS/SaaS optimal und sicher einzusetzen, als auch bei der Einführung von DevSecOps-Prinzipien im täglichen Software-Development-Lifecycle!

Wir LEBEN Cloud-Plattformen in allen Facetten und Kubernetes, Microservices oder Cloud-Security sind bei uns keine Add-Ons, sondern werden immer mitberücksichtigt!

Kommen Sie gerne auf uns zu. Wir erstellen Ihnen professionelle Konzepte, implementieren diese mit Ihnen gemeinsam und helfen Ihnen beim Multi-Cloud Basisbetrieb!


Wie immer freue ich mich auf Rückmeldungen und Ihre Meinung zu diesem Thema!

Fragen, Kritik, Hinweise?

Gerald Fehringer
CTO, Co-Founder
CISSP, CISA, CISM, CCSP, Cloud Nerd-by-nature
E-Mail: gf @ cloudeteer.de
Twitter: @zerohat

CLOUDETEER
Twitter: @cloudeteer
GitHub: @cloudeteer
Meetup: @CloudNatics