6376 5011

www.menti.com

Mentimeter

Wenn du ”Cloud Native” hörst, woran denkst du dann zuerst?

Mentimeter

Seid ihr bereits auf einer der bekannten großen Cloud Plattformen wie AWS, Google oder Azure unterwegs?

Was ist Cloud Native Computing?

68% der Unternehmen haben damit begonnen, eine Cloud Native Infrastruktur aufzubauen.

– O'Reilly 2019

Faktor 10
schnellere Entwicklung

Faktor 100

geringere Infrastruktur-Kosten

Programmiersprachen

• jeder Service kann in der Sprache implementiert werden, welche am besten zum Problem passt
  • Golang für schnelle, hoch skalierbare Services
  • Python für Data Services und Machine Learning
  • PHP oder TypeScript für CMS
  • Ruby on Rails für REST-APIs
• Stichwort: "Polyglotte Micro Services"
• kleine Services als Lambda Funktionen

"Marketing hat ein Ticket eingestellt, nächste Woche kommt die Fernsehwerbung. Wir brauchen 20 neue Server."
 

"Ich habe sie gerade bei Dell bestellt, in
 zwei Monaten sind sie da."

Elastizität

• Lastspitzen werden automatisch durch zusätzliche Ressourcen abgefangen
• Workload verteilt sich auf mehrere Service-Instanzen
• Load Balancing auf System Level und Auto-Scaler für Hosts und Services
• Down Time minimieren
• Kostenfaktor: es nur läuft soviel, wie tatsächlich gebraucht wird #scale2zero

Re-Platforming

• Cloud Native Applications fügen sich in ihre Umgebung ein
  • Netzwerke werden dynamisch provisioniert
  • Storage wird skalierbar und passt sich an
  • Datenbanken werden austauschbar, skalierbar, bieten Betriebssicherheit

Continuous Delivery I 

• kontinuierliche Updates mit neuen Features und Services ausliefern
• Software Updates mit Zero Downtime einspielen
• Rollback einzelner Services im Falle eines fehlerhaften Deploys
• Canary Releases : neue Versionen zunächst partiell an User Segmente ausliefern
• Blue/Green Releases: Traffic erst schrittweise auf neue Version leiten

Continuous Delivery II

• starkes Decoupling von Services
• jeder kann jederzeit deployen
• "you build it – you run it"
• Support für Scripting & GitOps
• Stichwort: ”CI/CD Pipelines”
• Qualität & Funktion ist zu jedem Zeitpunkt automatisch geprüft

Modulares Design

• einzelne Services die zusammen ein System bilden
  • Microservices
  • Miniservices
  • Macroservices
• kleinere Einheiten sind leichter im Deployment zu managen als ein grosser Monolith

Infrastruktur Services

• fertige Lösungen für Szenarien, die in den meisten Software Systemen enthalten sind
  • Authentifizierung
  • Role Model / Permissions
  • Encryption as a Service
  • Datenbanken / Storage
  • Message & Event Bus
  • Service Mesh & Discovery
  • Ingress / Egress

Architektur Patterns

• durchdachte Lösungen für Use Cases, die man in den meisten Software-Systemen antrifft
  • Health Probe / Managed Lifecycle
  • Batch Processing
  • Reactive Processing
  • System Warm-Up
  • Sidecar / Ambassador / Proxy
  • Configuration
  • Circuit Breaker

Circuit Breaker I

• Problem: ein Service fällt aus und es gibt massiv Stau im Gesamtsystem
• Lösung/Ziel: das System muss sich erholen und zurück in den "Green State" kommen
• Hindernis: durch vermehrte und ständige Reloads steht das System noch mehr unter Last

Circuit Breaker II

Automatisierung

• On-premise Applications häufig manuell gewartet und langsam
• Cloud Native
  • Application Management per Scripting und Infrastruktur automatisiert
  • schnelleres Deployment
  • höhere Zuverlässigkeit
  • klare Abläufe und Prozesse

Stateless

• Cloud Native Applications sind nicht fix an eine Infrastruktur gebunden
• State wird in Datenbanken, Storage oder Message Bus (Event Sourcing) gehalten
• unterstützt Skalierung, Verfügbarkeit und Resilienz

Summary

Nachlese auf Medium.com – What Is Cloud Native Computing?

Mentimeter

Schon Lust bekommen auf Cloud Technologien?

Mentimeter

Wie oft wird in deinen Softwareprojekten ein Update oder ein neues Release auf Produktion deployed?

Mentimeter

Wie lange dauert es für gewöhnlich, bis ein Change Request in deinem Softwareprojekt umgesetzt und live gestellt wird?

Nachlese – State of DevOps Report 2021 (presented by puppet)

Container Orchestrierung

Kubernetes Cluster

• Laufzeitumgebung für Software Komponenten, deployed in Docker Containern:
  • Application
  • Cloud Native Services
  • Infrastruktur

Kubernetes Cluster

• Programmierung von Hardware Ressourcen, Infrastructure as Code:
  • AWS CloudFormation
  • Hashicorp Terraform
  • RedHat Ansible

Kubernetes Cluster

• Umfangreiche API
• Standard Tooling
• Sehr hohe Flexibilität
• Support für Scripting und Automatisierung
• Skalierung und Resilienz
• Rate Limits
• Backups / Rollbacks
• Cloud: AWS, GKE, AKS
• On Premise: Bare Metal, VMware vSphere, Rancher

Lösung für Vendor Lock-in

• Data Lock-in
  "Die Daten und Datenstrukturen bekomme ich nicht herausgelöst."

• Application Lock-in
  "Ich kann meinen Code nicht umziehen."

• Structural Lock-in
  "Ich kann die Integration, Kommunikation und interaktion von Komponenten nicht umziehen."

Polygot Software Developers

Polyglotte Services

• Jede Programmiersprache hat ihre Vor- und Nachteile
• Performance: Interpreter, Transpiler, Compiler
• Konzepte: prozedural, funktional, objektorientiert
• Ökosysteme der Sprachen
• Framework-Auswahl kann entscheidend sein für Fortschritt im Projekt

Reaktive Software Architekturen

Trustworthy Cloud

• Best Practice Strategien
  • Zero Trust Infrastructure
  • Assume Breach
  • BeyondCorp
  • Data Tagging
  • Crypto Shredding

CI/CD Pipelines

Continuous Integration

Continuous Delivery

Migrationspfad

Migration Patterns

• geeignete Subsysteme identifizieren und als neuen Service herauslösen
• Bestandsdaten in neues Softwaresystem replizieren
• Daten-Updates per Message Bus asynchron an neue Services verteilen
• Proxy Komponenten anlegen
• Facades aufbauen
• inkrementelle Migration vs. Big Bang ”Strategie”

Cloud Native Landscape

Mentimeter

Mit welchen Begriffen würdest du nun selbst ”Cloud Native” am ehesten assozieren?

Mentimeter

Mit welchen Begriffen würdest du nun selbst ”Cloud Native” am ehesten assozieren?

Mentimeter

Bist du bereit für Cloud Native?

Cloud Native vs Organisation

Monolithic
Teams

Im Monolithen

Monolithic Delivery

• CoreDB und Ops als Monolith
• DBA & Ops als Engpass
• DBA & Ops als Diktator
• Alles ist abzustimmen
• Alles dauert lange

• CoreDB und Ops als Monolith
• DBA & Ops als Engpass
• DBA & Ops als Diktator
• Alles ist abzustimmen
• Alles dauert lange

• Besser wäre eine Architektur ohne Abhängigkeiten...
   
• ... MicroServices! 

• Besser wäre eine Architektur ohne Abhängigkeiten...
   
• ... MicroServices! 

Build-run-Teams

• Sowohl Feature als auch Component-Teams
• Volle Verantwortung für alle Features von einer Komponente
• Nur auf Basis von Micro/Mini-Service-Architekturen machbar
• Kann weitgehend autark agieren - von GUI zu Deploy
• Mit den anderen Komponenten
  wird über APIs geredet.

Platform Team

• Eigenständiges Team, das sich um Auswahl, Aufbau und Konfiguration des Basissets von Werkzeugen und Praktiken, die von allen Teams genutzt werden, kümmert.
• Selbst ein Built-Run-Team für die Platform.
• Fokus ist sowohl Stabilität der Platform als auch Performance und Arbeitserleichterung für die anderen Teams

Service Delivery

Technical Consulting /
ENABLING Teams

• Cross-Cutting zu stream aligned teams
• bandwidth to research
• develop tools, methodologies etc

Enabling Teams

• sind in kontinuierlichem, regelmäßigem Kontakt zu Teams
• bei Bedarf auch Teil der Teams
• sorgen dafür, dass zukünftige Probleme rechtzeitig mit Tooling, Methoden und Ansätzen gelöst werden können 
• stützen den Technology Lifecycle im Teams
• erlaubt es, neue und komplexe Technologien zu verstehen und einzusetzen
  • Training, Workshops, HandsOn-Kooperation

COMPLICATED SUBSYSTEMS

COMPLICATED SUBSYSTEMS

• Legacy-Systeme sind komplexe Subsysteme!
   
• Verteilen über mehrere Teams?
• Als Teilaufgabe in einem Team?
• Als Feature-Thema in einem Feature-Team?

Gesamtbild

Das Modernisierungs-
Dilemma

• Die Plattform existiert noch nicht
  • es fehlt die neue Infrastruktur
  • es fehlen Services und Beispiele, die sie nutzen
• Die alte Plattform muss auch weiterbetrieben werden
• Die Kollegen kennen die neuen Technologien noch nicht

Core Team

• Das erste Team für die neue Platform
• Drei Deliveries: 
  • die neue Platform
  • Architektur und Beispiele 
  • Bootcamp, Onboarding & Schulung
• HandsOn-Aufbau der neuen Plattform
• Geht später in Platform-Team und BR-Teams auf.

Platform- und Built-Run-Team integriert.

MVP Platform

• Wird vom Core Team gebaut
• Sobald es von anderen nutzbar ist können auch andere Teams darauf aufsetzen
• nach ca 2 Monaten vorhanden
• 20%-40% der finalen Plattformfeatures
• Experimente und PoC gehören dazu.

Start

Legacy Software

Core-Team

Monolith

Platform-
MVP

Erster Service

Ramp-Up

Core-Team

Platform Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Platform-
MVP

Erster
Service

Zweiter
Service

Platform Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Platform-
MVP

Erster
Service

Zweiter
Service

Platform Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Platform-
MVP

Erster
Service

Zweiter
Service

Legacy Software

Monolith

Praxis-Beispiel

https://www.cnpatterns.org/

https://teamtopologies.com/