Mein Vortrag auf der OOP 2015 Where all the transactions gone? Was in der Cloud alles verboten ist. Gegenstand des Vortrags sind neun Dinge, die in der Cloud im Gegensatz zu inhouse-Anwendungen grundlegend anders sind. Darüber hinaus geht der Vortrag kurz auf DevOps für die Cloud und Organisation für die Cloud ein. Ursprünglich hat mein Kollege Marc Bauer den Vorschlag eingereicht, hatte dann aber leider keine Möglichkeit, den Vortrag selbst zu halten.

1. Where are all transactions gone?
Was in der Cloud alles verboten ist ...
Bildquelle: Andreas Hermsdorf / pixelio.de
OOP 2015
Ramon Anger
Capgemini

2. Wer ist in der Cloud?
Bildquelle: Tobias Sellmaier / pixelio.de

3. Migration in die Cloud ist scheinbar trivial.

4. Cloud Migration:
Realität + Cloud Tools = Wunder

5. Inhalt
¤ Ist IaaS von Inhouse so verschieden?
¤ Was in der Cloud alles verboten ist
¤ DevOps für die Cloud
¤ Organisation für die Cloud
¤ Ausblick: Alles wird einfacher. Ein bisschen

6. Ist IaaS von Inhouse-Ansätzen
verschieden?
¤ Webanwendung
¤ Batchanwendung
¤ Hochverfügbares System

7. Webanwendung mit AWS
Quelle: http://aws.amazon.com/de/architecture/

8. Batchanwendung mit AWS
Quelle: http://aws.amazon.com/de/architecture/

9. Hochverfügbares System mit AWS
Quelle: http://aws.amazon.com/de/architecture/

10. Was in der Cloud alles verboten ist ...
¤ Transaktionen
¤ Scale-up
¤ Bottlenecks
¤ Angst vor Ausfällen
¤ Schichtsalat
¤ Enterprise Service Bus
¤ „Klassische“ Datenbanken
¤ Lokales Filesystem
¤ Sticky Sessions
¤ Verboten heißt nicht: Geht nicht!

11. Where are all transactions gone?
Messaging statt Transaktionen
¤ Inhouse-Systeme nutzen oft XA-Transaktionen
¤ Transaktion abgeschlossen, wenn alle Teiltransaktionen
abgeschlossen (2-Phase-Commit)
¤ Beteiligte Ressourcen blockieren
¤ XA-Transaktionen über das Web nicht sinnvoll (Latenz)
¤ Verfügbarkeit der beteiligten Systeme problematisch,
Kompensationen erforderlich
¤ Entkopplung von Transaktionen notwendig – zeitlich/logisch

12. Where are all transactions gone?
Messaging statt Transaktionen
¤ Kommunikation zwischen Systemen über Message
Queues
¤ Loose Kopplung zwischen Systemen
¤ Vermeidet wortreiche Kommunikation (keine Rückantwort,
Fire & Forget)
¤ Daten gemeinsam übertragen à Roundtrips vermeiden

13. In die Breite bauen.
Scale-out statt scale-up
¤ Inhouse-Ansatz – bessere, teure Hardware (scale-up) – für
die Cloud keine realistische Option
¤ Cloud-Ansatz: Scale-out – Stateless Application und
Webserver
¤ State muss sein? à in Client verlagern
¤ Komponenten müssen Scale-out unterstützen à DB
Server, SAN, Netzwerk, Stromversorgung
¤ Jede Cloud-Komponente hat natürliche Limits
¤ Beispiel: Azure Storage maximal 100 TB

14. Vielfach hält besser.
Verfügbarkeit durch Redundanz
¤ In großen Systemen mit vielen Komponenten kann zu
jedem Zeitpunkt eine Komponente ausfallen
¤ Application oder Webserver à kein Problem
¤ DB, SAN à kritisch
¤ Anwendungen in der Cloud zerfallen in redundante
Komponenten
¤ Datenbanken, Cloud Storage in mehreren Instanzen mit
automatischer Synchronisation
¤ Fehlerbeseitigung/Neustart der Komponenten
vollautomatisiert, idealerweise ohne Downtime
¤ Fokus auf Verfügbarkeit geschäftskritischer Komponenten

15. Den Affen loslassen.
Fehlertoleranz und Ausfallsicherheit
¤ Klassische Welt: Never touch a
running system!
¤ Chaos Monkey: ... randomly
disables production instances to
make sure it can survive common
types of failure without any
customer impact ...
¤ http://techblog.netflix.com/2011/07/
netflix-simian-army.html
¤ http://techblog.netflix.com/2012/07/
chaos-monkey-released-into-
wild.html

16. Weg mit dem Schichtsalat!
¤ Inhouse-Systeme: Drei bis 18 Application Layer
¤ (Un)Marshalling in jeder Schicht
¤ Kostet Ressourcen und Zeit
¤ Aufteilung in kleine, funktionale Komponenten sinnvoll à
Microservices
¤ Weniger Layer ... hoffentlich

17. Why buses don't fly in the cloud.
JSON statt XML, REST Api statt SOAP
¤ Kaum ein Cloud Service Anbieter setzt auf ESB
¤ ESB: Grund für SOA -> DOA (dead on arrival)
¤ SOAP und XML nicht flexibel genug
¤ Smart endpoints and dumb pipes (Martin Fowler à
Microservices)
¤ Reduktion auf Message routing, iPaaS
¤ Logik liegt in den Komponenten

18. Why buses don't fly in the cloud.
JSON statt XML, REST Api statt SOAP
¤ JSON statt XML
¤ XML: Overhead durch Namespaces und Encoding, eher für
strukturierte Daten
¤ JSON: leichtgewichtig, für (un-)strukturierte Daten
¤ REST statt SOAP
¤ Zugriff auf Ressource statt Service-Operation
¤ Services basieren aktuell eher auf REST statt auf SOAP

19. Database as a Service
¤ Nicht mehr nur Auswahl zwischen zwei Anbietern
¤ NoSQL, (un)strukturierte Daten, hochparalleler Zugriff
¤ Sowohl PaaS als auch IaaS möglich
¤ Datenbankentwurf in der Cloud
1. Logisches und physisches Datenmodell entwerfen
¤ Klassisches Vorgehen
2. Datenbankservice auswählen
¤ Wie soll auf Daten zugegriffen werden?
¤ Welche Sicherheitsaspekte bestehen?
¤ Wie soll Governance berücksichtigt werden?
3. Proof of Concept durchführen

20. Database as a Service
Quelle: Kossmann D. et. al.: An Evaluation of Alternative Architectures for Transaction Processing in the Cloud, http://
cs.brown.edu/~kraskat/pub/sigmod10-cloudbench.pdf

21. Filesystem? Welches Filesystem?
Cloud Storage ...
¤ Wohin schreiben Anwendungen in der Cloud?
¤ Alles läuft in VM. Was passiert bei Neustart?
¤ Cloud Storage: (unstrukturiertes) Datenobjekt zusammen
mit Metadaten und global eindeutiger ID speichern
¤ RESTful Service: Objekt über eindeutige ID zugreifen
¤ Cloud Storage / Blob Store sind nicht gut für Daten geeignet,
die sich häufig verändern, sind aber stark parallel nutzbar
¤ Veränderliche Daten über Message Queues,
Datenbanken verarbeiten

22. Lastverteilung oder Sticky Sessions?
¤ Caching verspricht bessere Antwortzeiten
¤ Lokale Caches (länderspezifisch) machen Konzentration
relevanter Sessions auf bestimmte Maschinen sinnvoll
¤ Sticky Sessions beschränken Skalierbarkeit von
Anwendungen
¤ LoadBalancer kann Last nicht wirklich verteilen
¤ AWS und Azure bieten Sticky Sessions Feature an
¤ Sticky Session können unter GCP z.B. mit kubernetes
genutzt werden

23. Cloud Design Patterns
¤ Rahmenbedingungen in der Cloud führen zu neuer
Generation von Design Patterns
¤ Cloud Design Patterns: Prescriptive Architecture
Guidance for Cloud Applications, Alex Homer et. al.,
https://msdn.microsoft.com/en-us/library/
dn568099.aspx
¤ Cloud Architecture Patterns, Bill Wilder,
http://it-ebooks.info/book/947/

24. Inhalt
¤ Ist IaaS von Inhouse so verschieden?
¤ Was in der Cloud alles verboten ist
¤ DevOps für die Cloud
¤ Organisation für die Cloud
¤ Ausblick: Alles wird einfacher. Ein bisschen

25. DevOps für die Cloud, bitte!
¤ Staging Umgebungen haben in der Cloud dieselbe Konfiguration
wie in Produktion
¤ Virtualisiert, etwas weniger „Breite“
¤ Durch Pay-per-Use erschwinglich
¤ In Entwicklung dieselben Tools wie Produktion nutzen
¤ Für Entwicklung Produktion klonen
¤ Durch Pay-per-Use erschwinglich
¤ Automatisiere alles!
¤ z.B. automatisches Penetration Testing mit gauntlt
¤ Deploy/Upgrade ohne Downtime
¤ (Wieder)aufsetzen von Instanzen
¤ Scriptable Infrastructure, Auto-scaling, Proactive Scaling

26. DevOps für die Cloud, bitte!
Toolsupport für CI & CD – auch für die Cloud – ist ausgereift

27. Cross-funktional.
Organisation für die Cloud
¤ Organisation von Komponenten um kleine, cross-
funktionale Teams ... oder umgekehrt
¤ Services so (klein) schneiden, dass ein Service von einem
Team betreut werden kann
¤ Komponente zu komplex à schneiden oder vereinfachen
¤ Governance wird durch Unabhängigkeit leichter
¤ Skalierung mit vielen, parallel arbeitende Teams realistisch
¤ à Microservices (Martin Fowler)

28. Alles wird einfacher.
Ein bisschen ...
¤ Kosteneinsparung durch IaaS, PaaS und SaaS ist real
¤ Hohe Reife von Plattformen, Services und Tools unterstützt
Übergang in die Cloud
¤ Hohe Anforderungen der Service-Anbieter führen zu
flexibleren, widerstandsfähigeren Systemen
¤ Entkopplung von Systemen führt zu besserem Design
¤ Nächster Schritt
¤ Standardisierung auf Ebene von Protokollen, APIs

29. Vielen Dank.
¤ Bei Fragen bitte fragen.