Where are all transactions gone?
Was in der Cloud alles verboten ist ...
Bildquelle: Andreas Hermsdorf / pixelio.de
OOP 20...
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
¤  Organ...
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
¤  Schicht...
Where are all transactions gone?
Messaging statt Transaktionen
¤  Inhouse-Systeme nutzen oft XA-Transaktionen
¤  Transak...
Where are all transactions gone?
Messaging statt Transaktionen
¤  Kommunikation zwischen Systemen über Message
Queues
¤ ...
In die Breite bauen.
Scale-out statt scale-up
¤  Inhouse-Ansatz – bessere, teure Hardware (scale-up) – für
die Cloud kein...
Vielfach hält besser.
Verfügbarkeit durch Redundanz
¤  In großen Systemen mit vielen Komponenten kann zu
jedem Zeitpunkt ...
Den Affen loslassen.
Fehlertoleranz und Ausfallsicherheit
¤  Klassische Welt: Never touch a
running system!
¤  Chaos Mon...
Weg mit dem Schichtsalat!
¤  Inhouse-Systeme: Drei bis 18 Application Layer
¤  (Un)Marshalling in jeder Schicht
¤  Kost...
Why buses don't fly in the cloud.
JSON statt XML, REST Api statt SOAP
¤  Kaum ein Cloud Service Anbieter setzt auf ESB
¤...
Why buses don't fly in the cloud.
JSON statt XML, REST Api statt SOAP
¤  JSON statt XML
¤  XML: Overhead durch Namespace...
Database as a Service
¤  Nicht mehr nur Auswahl zwischen zwei Anbietern
¤  NoSQL, (un)strukturierte Daten, hochparallele...
Database as a Service
Quelle: Kossmann D. et. al.: An Evaluation of Alternative Architectures for Transaction Processing i...
Filesystem? Welches Filesystem?
Cloud Storage ...
¤  Wohin schreiben Anwendungen in der Cloud?
¤  Alles läuft in VM. Was...
Lastverteilung oder Sticky Sessions?
¤  Caching verspricht bessere Antwortzeiten
¤  Lokale Caches (länderspezifisch) mac...
Cloud Design Patterns
¤  Rahmenbedingungen in der Cloud führen zu neuer
Generation von Design Patterns
¤  Cloud Design P...
Inhalt
¤  Ist IaaS von Inhouse so verschieden?
¤  Was in der Cloud alles verboten ist
¤  DevOps für die Cloud
¤  Organ...
DevOps für die Cloud, bitte!
¤  Staging Umgebungen haben in der Cloud dieselbe Konfiguration
wie in Produktion
¤  Virtua...
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...
Alles wird einfacher.
Ein bisschen ...
¤  Kosteneinsparung durch IaaS, PaaS und SaaS ist real
¤  Hohe Reife von Plattfor...
Vielen Dank.
¤  Bei Fragen bitte fragen.
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
Nächste SlideShare
Wird geladen in …5
×

Where are all transactions gone? Was in_der_cloud_alles_verboten_ist

412 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
412
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
8
Aktionen
Geteilt
0
Downloads
4
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Where are all transactions gone? Was in_der_cloud_alles_verboten_ist

  1. 1. Where are all transactions gone? Was in der Cloud alles verboten ist ... Bildquelle: Andreas Hermsdorf / pixelio.de OOP 2015 Ramon Anger Capgemini
  2. 2. Wer ist in der Cloud? Bildquelle: Tobias Sellmaier / pixelio.de
  3. 3. Migration in die Cloud ist scheinbar trivial.
  4. 4. Cloud Migration: Realität + Cloud Tools = Wunder
  5. 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. 6. Ist IaaS von Inhouse-Ansätzen verschieden? ¤  Webanwendung ¤  Batchanwendung ¤  Hochverfügbares System
  7. 7. Webanwendung mit AWS Quelle: http://aws.amazon.com/de/architecture/
  8. 8. Batchanwendung mit AWS Quelle: http://aws.amazon.com/de/architecture/
  9. 9. Hochverfügbares System mit AWS Quelle: http://aws.amazon.com/de/architecture/
  10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 26. DevOps für die Cloud, bitte! Toolsupport für CI & CD – auch für die Cloud – ist ausgereift
  27. 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. 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. 29. Vielen Dank. ¤  Bei Fragen bitte fragen.

×