Public Cloud
Erfahrungsbericht
Szabolcs Szádeczky-Kardoss
BAT Nr. 39
23.03.2018
Was bewegt die SBB-IT?
SBB • IT • OM • 23.03.2018 2
 Agile Transformation
▪ DevOps
 Microservices und Containerisierung
▪ OpenShift Container Platform (siehe BAT Nr. 36)
 Weitere Cloud Services
▪ Public Cloud (AWS)
▪ Innovative Use Cases
 Machine Learning
 Analytics
 IoT
OpenShift Container Platform in Zahlen
SBB • IT • OM • 23.03.2018 3
Kennzahl März 2017 März 2018
OSE/OCP Version 3.2 3.5
Projekte (Namespaces) 400 950 (140)
Laufende Containers (Pods) 1400 3100 (700)
Services 1100 2600 (500)
Routen 900 2300 (500)
Deployments pro Tag 210 18000 (600)
User (Entwickler und AOM) 300 900
(In Klammern stehen die «produktiven» Zahlen.)
Containerisierung
SBB • IT • OM • 23.03.2018 4
 «Container und Containerorchestrierung ist die Zukunft»
▪ Besonders für interaktive, dynamische Anwendungen
 «Ein Prozess kann jederzeit terminiert werden. Die Anwendung
muss damit umgehen können.»
 In manchen Fällen gibt es aber «bessere» Lösungen:
▪ Datenbank (relational und nicht-relational)
▪ Messaging
▪ Analytics
▪ Machine Learning
▪ Serverless
Strategische Richtlinien für den Einsatz von
Cloud Services
SBB • IT • OM • 23.03.2018 5
 Bei allen MAKE-Anwendungen im Cloud-Umfeld streben wir
(Docker) Container als Deployment-Einheit an.
▪ Alle solche Anwendungen müssen generell die vom ESTA-Cloud
bereitgestellte Build/Deploy-Prozesse und OpenShift als
Laufzeitplattform verwenden.
 Unser längerfristiges Ziel ist es, die höherwertigen Amazon Services
bei den jeweiligen Stack* zu platzieren und etablieren.
▪ Mit unserer Unterstützung sollten die anderen Stacks in der Lage
sein solche Services für ihre Kunden/Projekte selber anbieten und
bereitstellen zu können.
*Stack = Kollektion von Technologie-Services inkl. dazu gehörende Tooling, Prozesse und Know-How
Die Wolke durchdringt alles?
SBB • IT • OM • 23.03.2018 6
MainframeStack
ClassicStack
CloudStack
MobileStack
IoTStack(NEU)
Workplace
SAP
Analytics
GIS
Logging, Monitoring
Common Services (Compute, Storage, …)
Network, Network-Security
IAM (Identity & Access Management)
Betriebsintegration
Technologiesteuerung
Alles
AWS AWS AWS AWS
Sematext
New Relic
AWS VPC
RH-SSO
IaaS
AWS
Herausforderungen
SBB • IT • OM • 23.03.2018 7
 Netzwerk
▪ Schnittstelle zwischen der alten (on-premise) und neuen Welt
 Durchlaufzeiten bei VPN, Firewall, DNS, Routing
▪ AWS: Minuten bis Stunden
▪ SBB: 2 bis 40 Arbeitstage
 Bandbreite
▪ Aktuelle Peaks bis zu ca. 1 Gbit/s
 Know-How
▪ Allgemein: AWS Certified Cloud Practitioner
▪ Netzwerk Architect / Engineer
Account Management
SBB • IT • OM • 23.03.2018 8
 AWS Accounts werden via AWS Organizations verwaltet
▪ Dedizierte bzw. shared Accounts mit Resource Tagging
▪ Feingranulare Rechteverteilung via IAM
Verwendung und Kosten
SBB • IT • OM • 23.03.2018 9
 Hauptgericht: EC2
 Beilage: RDS, CloudWatch, VPC, S3 und Support
▪ und natürlich IAM
 Dessert: Redshift, Kinesis, Device Farm
 Aktuell ca. 20-25 Accounts
▪ Werkzeugunterstützung (WZU)
▪ Cloud@SBB (OpenShift AWS)
▪ SBB-IT Non-Production
▪ und weitere (mit Kostenpunkt < $1000)
 Gesamtwachstum ca. 5% pro Monat
Erfahrungen mit AWS bei WZU
SBB • IT • OM • 23.03.2018 10
 Kosten
▪ «Mehr IT fürs Geld!» - vor allem Storage ist viel günstiger
▪ Automatisches Lifecycle und Preissenkungen ohne Verhandlung
 Funktionalität
▪ «Unfassbar grosser Katalog an Services, die ohne Bürokratie und
Investition bezogen werden können»
 Qualität
▪ Extrem hoch: 1 Ausfall einer VM in 2017, gelöst in Minuten
▪ «Schneller und technisch kompetenter Support ohne Ping-Pong»
 Skalierbarkeit
▪ «Auch grosse Kapazitätsänderungen werden unbürokratisch und
rasch freigegeben.»
Erfahrungen mit AWS bei WZU
SBB • IT • OM • 23.03.2018 11
 Effektivität / Effizienz
▪ Extrem hohe Autonomiegrad erreicht – bis auf DNS, VPN, Firewall
 «Grosse Veränderungen sind mit vergleichsweise kleinem
Aufwand durchführbar»
 Automatisierung
▪ «Auf AWS hat alles eine API und man kann alles damit machen»
 Nächtliche vollautomatisierte Backups und Restores mit
anschliessender Verifikation via Webtests
 Vollautomatisierte Überwachung sämtlicher VMs und DBs
 Community
▪ Grosse Masse an Kunden  aktive Communities
 gut wiederverwendbare Lösungen
Erfahrungen mit AWS bei WZU
SBB • IT • OM • 23.03.2018 12
 Dokumentation
▪ Öffentlich und ausgezeichnet
▪ Leider ist der Produkt/Service Roadmap geheim
 Sicherheit
▪ Höchste Sicherheitszertifizierungen
▪ Verschlüsselung auf Knopfdruck
▪ Anomalien-Erkennung (Intrusion Detection System)
 Transparenz
▪ Historische oder laufende Kosten einsehbar und analysierbar
▪ «Es gibt keine Überraschungen … später mit Nachverrechnungen
wegen <insert reason here>»
Ausblick
SBB • IT • OM • 23.03.2018 13
 Netzwerk und Anbindung
▪ Peering bzw. AWS Direct Connect
 Anschliessend: Anpassung Account Policy
 Containerisierung für Make-Anwendungen
▪ Bleibt weiterhin im Hauptfokus
 Verwendung von Public Cloud erweitern
▪ Neue Services «einführen», tiefere Integration wo sinnvoll
▪ Anzahl Provider erhöhen
 Know-How weiter aufbauen
▪ Zentrale Beratungsstelle
▪ Schulungen für alle ermöglichen und fördern

Public Cloud Erfahrungsbericht SBB

  • 1.
  • 2.
    Was bewegt dieSBB-IT? SBB • IT • OM • 23.03.2018 2  Agile Transformation ▪ DevOps  Microservices und Containerisierung ▪ OpenShift Container Platform (siehe BAT Nr. 36)  Weitere Cloud Services ▪ Public Cloud (AWS) ▪ Innovative Use Cases  Machine Learning  Analytics  IoT
  • 3.
    OpenShift Container Platformin Zahlen SBB • IT • OM • 23.03.2018 3 Kennzahl März 2017 März 2018 OSE/OCP Version 3.2 3.5 Projekte (Namespaces) 400 950 (140) Laufende Containers (Pods) 1400 3100 (700) Services 1100 2600 (500) Routen 900 2300 (500) Deployments pro Tag 210 18000 (600) User (Entwickler und AOM) 300 900 (In Klammern stehen die «produktiven» Zahlen.)
  • 4.
    Containerisierung SBB • IT• OM • 23.03.2018 4  «Container und Containerorchestrierung ist die Zukunft» ▪ Besonders für interaktive, dynamische Anwendungen  «Ein Prozess kann jederzeit terminiert werden. Die Anwendung muss damit umgehen können.»  In manchen Fällen gibt es aber «bessere» Lösungen: ▪ Datenbank (relational und nicht-relational) ▪ Messaging ▪ Analytics ▪ Machine Learning ▪ Serverless
  • 5.
    Strategische Richtlinien fürden Einsatz von Cloud Services SBB • IT • OM • 23.03.2018 5  Bei allen MAKE-Anwendungen im Cloud-Umfeld streben wir (Docker) Container als Deployment-Einheit an. ▪ Alle solche Anwendungen müssen generell die vom ESTA-Cloud bereitgestellte Build/Deploy-Prozesse und OpenShift als Laufzeitplattform verwenden.  Unser längerfristiges Ziel ist es, die höherwertigen Amazon Services bei den jeweiligen Stack* zu platzieren und etablieren. ▪ Mit unserer Unterstützung sollten die anderen Stacks in der Lage sein solche Services für ihre Kunden/Projekte selber anbieten und bereitstellen zu können. *Stack = Kollektion von Technologie-Services inkl. dazu gehörende Tooling, Prozesse und Know-How
  • 6.
    Die Wolke durchdringtalles? SBB • IT • OM • 23.03.2018 6 MainframeStack ClassicStack CloudStack MobileStack IoTStack(NEU) Workplace SAP Analytics GIS Logging, Monitoring Common Services (Compute, Storage, …) Network, Network-Security IAM (Identity & Access Management) Betriebsintegration Technologiesteuerung Alles AWS AWS AWS AWS Sematext New Relic AWS VPC RH-SSO IaaS AWS
  • 7.
    Herausforderungen SBB • IT• OM • 23.03.2018 7  Netzwerk ▪ Schnittstelle zwischen der alten (on-premise) und neuen Welt  Durchlaufzeiten bei VPN, Firewall, DNS, Routing ▪ AWS: Minuten bis Stunden ▪ SBB: 2 bis 40 Arbeitstage  Bandbreite ▪ Aktuelle Peaks bis zu ca. 1 Gbit/s  Know-How ▪ Allgemein: AWS Certified Cloud Practitioner ▪ Netzwerk Architect / Engineer
  • 8.
    Account Management SBB •IT • OM • 23.03.2018 8  AWS Accounts werden via AWS Organizations verwaltet ▪ Dedizierte bzw. shared Accounts mit Resource Tagging ▪ Feingranulare Rechteverteilung via IAM
  • 9.
    Verwendung und Kosten SBB• IT • OM • 23.03.2018 9  Hauptgericht: EC2  Beilage: RDS, CloudWatch, VPC, S3 und Support ▪ und natürlich IAM  Dessert: Redshift, Kinesis, Device Farm  Aktuell ca. 20-25 Accounts ▪ Werkzeugunterstützung (WZU) ▪ Cloud@SBB (OpenShift AWS) ▪ SBB-IT Non-Production ▪ und weitere (mit Kostenpunkt < $1000)  Gesamtwachstum ca. 5% pro Monat
  • 10.
    Erfahrungen mit AWSbei WZU SBB • IT • OM • 23.03.2018 10  Kosten ▪ «Mehr IT fürs Geld!» - vor allem Storage ist viel günstiger ▪ Automatisches Lifecycle und Preissenkungen ohne Verhandlung  Funktionalität ▪ «Unfassbar grosser Katalog an Services, die ohne Bürokratie und Investition bezogen werden können»  Qualität ▪ Extrem hoch: 1 Ausfall einer VM in 2017, gelöst in Minuten ▪ «Schneller und technisch kompetenter Support ohne Ping-Pong»  Skalierbarkeit ▪ «Auch grosse Kapazitätsänderungen werden unbürokratisch und rasch freigegeben.»
  • 11.
    Erfahrungen mit AWSbei WZU SBB • IT • OM • 23.03.2018 11  Effektivität / Effizienz ▪ Extrem hohe Autonomiegrad erreicht – bis auf DNS, VPN, Firewall  «Grosse Veränderungen sind mit vergleichsweise kleinem Aufwand durchführbar»  Automatisierung ▪ «Auf AWS hat alles eine API und man kann alles damit machen»  Nächtliche vollautomatisierte Backups und Restores mit anschliessender Verifikation via Webtests  Vollautomatisierte Überwachung sämtlicher VMs und DBs  Community ▪ Grosse Masse an Kunden  aktive Communities  gut wiederverwendbare Lösungen
  • 12.
    Erfahrungen mit AWSbei WZU SBB • IT • OM • 23.03.2018 12  Dokumentation ▪ Öffentlich und ausgezeichnet ▪ Leider ist der Produkt/Service Roadmap geheim  Sicherheit ▪ Höchste Sicherheitszertifizierungen ▪ Verschlüsselung auf Knopfdruck ▪ Anomalien-Erkennung (Intrusion Detection System)  Transparenz ▪ Historische oder laufende Kosten einsehbar und analysierbar ▪ «Es gibt keine Überraschungen … später mit Nachverrechnungen wegen <insert reason here>»
  • 13.
    Ausblick SBB • IT• OM • 23.03.2018 13  Netzwerk und Anbindung ▪ Peering bzw. AWS Direct Connect  Anschliessend: Anpassung Account Policy  Containerisierung für Make-Anwendungen ▪ Bleibt weiterhin im Hauptfokus  Verwendung von Public Cloud erweitern ▪ Neue Services «einführen», tiefere Integration wo sinnvoll ▪ Anzahl Provider erhöhen  Know-How weiter aufbauen ▪ Zentrale Beratungsstelle ▪ Schulungen für alle ermöglichen und fördern