Where are all transactions gone?

Was in der Cloud alles verboten ist ...

Bildquelle: Andreas Hermsdorf / pixelio.de

OOP 2015 Ramon Anger

Capgemini

Wer ist in der Cloud?

Bildquelle: Tobias Sellmaier / pixelio.de

Migration in die Cloud ist scheinbar trivial.

Cloud Migration:

Realität + Cloud Tools = Wunder

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

Ist IaaS von Inhouse-Ansätzen verschieden?

¤  Webanwendung

¤  Batchanwendung

¤  Hochverfügbares System

Webanwendung mit AWS

Quelle: http://aws.amazon.com/de/architecture/

Batchanwendung mit AWS

Quelle: http://aws.amazon.com/de/architecture/

Hochverfügbares System mit AWS

Quelle: http://aws.amazon.com/de/architecture/

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!

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

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

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

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

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

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

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

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

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

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

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

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

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/

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

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

DevOps für die Cloud, bitte!

Toolsupport für CI & CD – auch für die Cloud – ist ausgereift

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)

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

Vielen Dank.

¤  Bei Fragen bitte fragen.