INSERVATE Consulting
MANAGEMENT IN DER
PUBLIC CLOUD – IST JETZT ALLES TOTAL ANDERS?
Vortrag ATUG 19.April 2018
AGENDA
§ Anwendungsarchitekturen – jetzt und morgen
§ Herausforderungen an Management in der Cloud
§ Software Development
§ IT Service Management
§ IT Systems Management
§ Beispiele für technische Umsetzung
§ Fazit und Empfehlungen
SOFTWARE-DEFINED INFRASTRUCTURE
§ Software Defined Infrastructure und Intransparenz der unteren Schichten (Managed Services)
§ Neue Architektur-Paradigmen und Plattformen (Microservices,
Container-Plattformen)
§ Dramatisch erhöhte Dynamik der Veränderungen in der Infrastruktur und veränderte Deployment-
Prozesse (Autoscaling, Failover, DevOps)
Was läuft in der Cloud?
TRADITIONELLE VS. MICROSERVICE-ARCHITEKTUR
§ Definition der Clusterkonfiguration ist Teil der Anwendung
§ Hohe Automation und Robustheit innerhalb des Clusters
§ Problemzone ist Performanz, nicht Ausfallswahrscheinlichkeit
§ Brauchen deshalb Einblick in den Zustand der Container und die Kommunikation zwischen den Komponenten insgesamt
Was läuft in der Cloud?
12 FACTOR APPS DEFINIEREN DIE RICHTUNG
1. Codebasis unter Versionskontrolle
2. Keine Abhängigkeiten im Code
3. Konfiguration extrahiert 4. Backing Services
austauschbar
5. Getrennte Stages
6. Zustandslose Prozesse
7. Erreichbarkeit über Port Bindings
8. Concurrency erlauben 9. Schnelle Verfügbarkeit 10. Development und
Produktion-Kompatibilität 11. Logs einbauen
12. Admin-Prozesse vorsehen
Was läuft in der Cloud?
KUBERNETES
§ Störungs-, Kapazitäts- und Continuity
Management sind praktisch Features der Cluster-Konfiguration und der instanziierten Anwendungsarchitektur in der Cloud
§ Logs sind eine wesentliche Informations- quelle über den Zustand eines Clusters und seiner gesamten Umgebung
§ Vorteile von Kubernetes Managed Services sind
§ Kein Betriebs- und Pflegeaufwand
§ Provider sichert Verfügbarkeit von zentralen Komponenten ab
§ Integration in administrative Funktionen vorhanden
Herausforderungen
CHANGE, RELEASE & DEPLOYMENT MANAGEMENT
§ Änderungen werden inkrementell im laufenden Betrieb eingebracht
(DevOps)
§ Releases sind häufige Sprints
§ Deployment geschieht quasi
automatisch auf „Knopfdruck“ aus der Build-Umgebung
§ Konfigurationsänderungen an der Infrastruktur sind ggfls. Teil des neuen Releases
§ Neue Interpretationsansätze für die ITSM-Prozesse notwendig!
Herausforderungen
CONFIGURATION MANAGEMENT
§ CMDB derzeit wichtig für Event Management und andere ITSM- Prozesse, auch Compliance
§ Fraglich, welche Cloud-CIs angesichts ihrer Flüchtigket
überhaupt noch in ITSM-Prozessen verwaltet werden (können)
§ Nur AWS hat einen Service der ein Configuration Mgmt. liefert
§ Klärung, was überhaupt in der
CMDB sichtbar sein soll -> Services!
Umsetzung
BEFÜLLUNG DER CMDB / RESOURCE NAMING
§ Ressourcennamen
§ Alarme von Ressourcen müssen mit CIs in der CMDB gematched werden
§ Namen sollen für den Operator eine Bedeutung haben
§ Korrelation CMDB/Cloud schwierig in dynamischen Umgebungen
§ Übernahme von Instanzlisten notwendig
§ Provider-eigenes Monitoring kennt die Namen
Umsetzung
SERVICE MAPS / KUBERNETES
Umsetzung
§ Definition von Service
§ Klassisch: eine Anwendung oder eine Leistung
§ Kubernetes: Zugang (IP, Port) zu einer Familie von Containern (Pods)
§ Kubernetes Services werden in der Cluster-Konfiguration
definiert
§ Haben Bezug zu Ressourcen
§ Liefern Bezeichner für
AWS CLOUDFORMATION (DESIGNER)
§ Clouds stellen Werkzeuge zur Definition von Muster-
konfigurationen zur Verfügung
§ Begriffe
§ Templates = VM-Muster
§ Schemas = App-Architekturen
§ Schemas könnten verwendet werden, um CMDB mit Basis- CIs zu versorgen
Umsetzung
MONITORING UND EVENT MANAGEMENT
§ Provider-eigenes Monitoring und Logging liefert Alarme zu
§ Zustandsänderungen
§ Konfigurationsänderungen
§ Ressourcenausfall
§ Überwachung ist auch im
dynamischen Umfeld gewährleistet
§ Überwachung von Metriken aus der
„cloud fabric“ möglich
§ Hohe Funktionalität und
Leistungsfähigkeit vorhanden
Umsetzung
INCIDENT & KNOWLEDGE MANAGEMENT
§ Mit der Cloud
§ HW-Infrastrukturen fallen weg
§ SLAs werden durch Cloud-Provider garantiert
§ Umgebungen skalieren automatisch und heilen sich selbst
§ Anwendungskonfigurationen werden von der Entwicklung verantwortet
§ Operating wird mit komplexeren
Szenarien konfrontiert sein als derzeit
§ Knowledge Management und Know-how-Aufbau elementar für zukünftiges 1st-Level Operating
Umsetzung
PROBLEM MANAGEMENT
§ Problem Management benötigt aktuelle und historische
Informationen für die Diagnose
§ Provider-eigene Logging-, Storage- und Analytics-Funktionen stellen dies bereit
§ Zusätzliche Tools können ergän-
zende Einsichten liefern (AI, curated expert)
§ Cloud-Archivierung, weil Transfer von Logging-Daten aus der Cloud nicht sinnvoll
Umsetzung
AVAILABILITY/CAPACITY,
SERVICE LEVEL & PROVIDER MANAGEMENT
§ Capacity Management ist in der Cloud kein Thema mehr
§ Anwendungen skalieren automatisch (sofern vorbereitet und richtig konfiguriert)
§ Clouds stellen praktisch unlimitierte Kapazitäten bereit
§ Availability Management ist ebenfalls keine Herausforderung
§ Kunde hat keinen Einfluss auf Verfügbarkeits- faktoren, außer über die Nutzung von
Diensten (Availability Zones)
§ Grundsätzliche Überwachung der SLA- Einhaltung ist ausreichend
§ Service Level & Provider Management
§ Kostenoptimierung und Sicherstellung der Lieferfähigkeit treten in den Vordergrund
• z.B. Verteilung der Workloads auf bestimmte Rechner- und Servicekategorien
§ Überwachung der Leistungsfähigkeit des Anbieters
• Verfügbarkeit insgesamt
• Angebotene Dienste und Weiterentwicklung
• Verrechnungsmodelle
§ Einsatz von Tools sinnvoll
§ Provider-eigene und Third-Party
Umsetzung
IT SERVICE CONTINUITY & SECURITY MANAGEMENT
§ Möglichkeiten zur Absicherung
gegen RZ-Ausfälle sind in der Cloud vielfältiger als on-premise
§ Infrastruktur- und Datenreplikation
§ Caching, DNS-Redirection u.v.a.
§ Provider-eigene Überwachung liefert die notwendigen Alarme
§ Durch das umfassende Logging aller Änderungen und Fehler-
zustände in der cloud fabric wird das Sicherheitsmanagement
unterstützt
Umsetzung
AWS MONITORING-FUNKTIONEN
§ AWS verfügt über einen
„Baukasten“ von Services mit denen sich Funktionen zur
§ Überwachung
§ Logging
§ Alerting
§ Analyse
§ Archivierung
§ Visualisierung
§ u.v.a.
zusammenstellen lassen
Umsetzung
AZURE MONITORING-FUNKTIONEN
Umsetzung
§ Azure bietet funktional ähnliche Services wie AWS an
§ In weniger modulare Services gebündelt, da auf Grundlage klassischer MS-Produkte
§ Stärken im Anwendungs-
management, da MS auch Entwicklungstools anbietet
§ Bemühungen von Microsoft
sichtbar, in diesem Bereich weiter
gegen AWS aufzuholen
SYSDIG
Tools
§ Ist fokussiert auf ITOM,
„non-intrusive“
§ Detailliertes Monitoring der Systeme, Topology Discovery
§ Liefert auch Informationen zu Anwendungszustand und
–performance
§ Verfügt über umfangreiche Alerting-Funktionen
§ Auch als Open Source verfügbar
INSTANA
Tools
§ Ist fokussiert auf APM,
„intrusive“
§ Detaillierte Traces von Calls durch Microservices
§ Überwacht auch Systemzustand und Performance
§ Integriert Cloud-Services
§ Topology Discovery
ARCHITEKTUR ON-PREMISE-INTEGRATION
Leitstand Webhook
Gateway
Azure Monitoring/
Alerts
AWS SNS CloudWatch
Instana
emise Tools
Cloud
sysdig Cloud
Trail
AnalyticsLog
GatewayCMDB
WIRTSCHAFTLICHKEIT NUTZUNG CLOUD-DIENSTE
§ Einzelne Beispiele für Gebühren
§ Überwachung EC2 Instanz:
$0,14/Monat
§ CloudWatch Alarm/Monat: $0,10
§ CloudWatch Logs: $0,63/GB,
$0,0324/GB Archiv
§ SNS: $0,60/1.000.000 HTTP-Messages
§ Einsatz der Dienste ist sehr günstig
§ Vergleich: Installation und Betreuung mit eigenen Tools und 1 FTE würde ca.
€ 10.000,-/Monat entsprechen
Fazit
EINFLUSS DER CLOUD AUF ITSM-PROZESSE
§ Klare Vorgaben für Prozesse und größtmögliche Transparenz zwischen Entwicklung und Betrieb schaffen, damit DevOps funktionieren kann
§ Hohe Dynamik erfordert Autodiscovery von Elementen in der Cloud, manuelle Pflege von vollständigen Konfigurationsdaten ist nicht mehr möglich
§ Konsequente Nutzung der cloud-eigenen Überwachungs- und Logging-Funktionen, da sie Teil der
„cloud fabric“ sind und dadurch optimale Instrumentierung und Funktionen liefern können, zudem sind die damit verbundenen Kosten niedrig
§ Einhaltung der Compliance beim Änderungsmanagement ist nur über Nutzung der cloud-eigenen Funktionen erreichbar
§ Vorkehrungen für die Auswertung und Archivierung von Logdaten sind zu treffen
§ Stärkung des betrieblichen Kubernetes- und Cloud-Knowhows durch Competence Center
Fazit
KERNAUSSAGEN
§ Die Nutzung der cloud-eigenen Services für Monitoring (hier und im Folgenden im
erweiterten Sinn mit allen Disziplinen) ist vorzusehen und die Integration mit dem eigenen Leitstand technisch zu lösen
§ Cloud bedeutet zukünftig in erster Linie Microservices und Kubernetes und nicht nur IaaS, dementsprechend sollte die Toolausstattung für das Monitoring angepasst sein
§ In einzelnen Bereichen ist es sinnvoll, die cloud-eigenen Services mit spezifischen Produkten zu ergänzen
§ Das Management von Unternehmensanwendungen in der Cloud bedeutet Änderungen am IT Service Management und anderen Prozessen im IT-Bereich, es bedarf des Aufbaus von spezifischem Cloud-Knowhow in IT Operations
§ Standardisierung, Musterarchitekturen und Richtlinien sind notwendig um die Komplexität der Cloud-IT beherrschbar zu machen
Fazit
LINKS
§ INSERVATE-Blog unter www.inservate.com/cloud-workspace
§ http://inservate.com/service-management/management-in-der-public- cloud-teil1/
§ http://inservate.com/service-management/management-in-der-public- cloud-teil-2/
§ Informationen zu sysdig unter www.sysdig.com
§ Architecture White Paper (https://goo.gl/s9MCoL)
§ Company Broschure (https://goo.gl/DXmPXp)
§ Informationen zu Instana unter www.instana.com
INSERVATE Consulting www.inservate.com info@inservate.com +49 89 8004 1535
