ECN Summit 2019, München: Workshop von Josef Adersberger (@adersberger, CTO QAware), Helmut Weiss (Beck et al.) und Mario Lohner (Syncier Cloud) Abstract: Um eine Anwendungslandschaft in die Zukunft zu führen wird immer deutlicher, dass kein Weg mehr an Cloud Native Plattformen wie Kubernetes vorbei führt. Eine flexiblere Entwicklung, hochfrequente Releases sowie geringere Betriebskosten und eine bessere Skalierbarkeit zählen mit zu den Hauptvorteilen dieser Technologie. Dies erreicht man jedoch nicht durch eine simple Migration der bestehenden Anwendungen in einen Container und einem Betrieb auf Kubernetes. Im Workshop gliedert sich dabei in drei Teile: - Migration von IT-Services in die Cloud - Migration von Anwendungen in die Cloud - Aufbau einer Kubernetes-Plattform mit Blick auf Day 2

1. Cloud Native Migration: Wie IT-Landschaften ihren Weg
auf eine Cloud Native Plattform finden
Josef Adersberger (QAware & Syncier), Helmut Weiss (Beck et al.), Mario Lohner (Syncier)
Mindmap-Protokoll: https://mm.tt/1338769919?t=9wTITREGrC

2. Eine kurze Vorstellungsrunde
2
Mein Name ist ...
Ich arbeite bei … und meine Funktion dort ist ….
Der Status unserer Cloud -Journey ist ...
Meine Erwartungen an diesen Workshop sind ….

3. Migration von IT-Services in die Cloud
Migration von Anwendungen in die Cloud
Aufbau einer Kubernetes-Plattform mit Blick auf Day 2

4. Migration von IT-Services in die Cloud
Migration von Anwendungen in die Cloud
Aufbau einer Kubernetes-Plattform mit Blick auf Day 2

5. Wozu migriert man IT Services in die Cloud?
5
Als eine Antwort auf heutige Herausforderungen.
McKinsey:
“90% aller CEOs gehen davon aus, dass die Digitalisierung ihr heutiges Geschäftsmodell bedroht.”
“15% sehen ihre IT darauf gut vorbereitet.”
→ 85% sind darauf heute noch nicht gut vorbereitet!
Gartner:
“67% der Business Leader gehen davon aus, dass sie zu einem Modell mit kürzeren Release Zyklen
gelangen müssen, um konkurrenzfähig zu bleiben.”

6. Thesen:
“Heute geht es nicht mehr darum schnellere Software zu entwickeln, sondern
schneller Software zu entwickeln.”
“⅓ der Cloud Migrationen scheitern und ein weiteres Drittel erreichen
gesteckte Ziele nicht.”
“Eine moderne Applikation ist keine statische Anwendung, sondern per
Definition ein sich ständig verändernder Service.”
“Das Rückgrat aller Unternehmen wird zukünftig digital sein.”
“Disrupt or be disrupted.”
6

7. Treiber hinter einer Cloud Journey
Quelle: Microsoft Cloud Adoption Framework
7

8. Die Cloud Journey
Quelle: AWS
8

9. Rehosting / Lift & Shift / Forklifting
9
Quelle; AWS

10. Rehosting / Lift & Shift / Forklifting
10

11. Rehosting / Lift & Shift / Forklifting
11
● Hybride Services
● Zeit als Treiber (Time to Market...)
● Capex → Opex
● End-of-Life Szenarien (RZ Rückbau…)
● Compliance, Security
● Geografische Verteilung
● Cloud-first Strategie
● Skalierung
● Disaster Recovery (RTO / RPO)

12. Die Cloud Journey: Ende-zu-Ende Betrachtung
12

13. Wo klemmt es? Biz- Devs - Ops
Walls of confusion
13
● Agile
● kurze Releasezyklen
● Kundenkontakt
● Dynamisch
● Business-getrieben
● Compliant
● ITSM / ITIL
● Stabilität, SLAs
● Langzeitplanung
● IT-getrieben
● kein Kundenkontakt
● Agile
● Design Thinking
● MVP
Business Process
Idee ka-ching!
Development
liefert Wert durch
schnelle
Umsetzung neuer
Features
Operations
liefert Wert durch
Stabilität und
Prozess-
Compliance
Konflikt
Business
fordert die
Umsetzung neuer
Ideen
Agile Development DevOps

14. Ungleiche Prioritäten bei den “4 Cs”
14
Den “4 Cs” (Cloud - Cluster - Container - Code) wird ungleiche Priorität zugeteilt.
Schwerpunkt liegt oft beim Code und der erhöhten Flexibilität in der Entwicklung.
Dadurch gehen oft erfolgskritische Vorteile von Cloud Technologien verloren, die
maßgeblich außerhalb des Codes adressiert werden, wie die Skalierbarkeit,
Kostenoptimierung und Automatisierung

15. Migration von IT-Services in die Cloud
Migration von Anwendungen in die Cloud
Aufbau einer Kubernetes-Plattform mit Blick auf Day 2

16. Warum?
16
ELASTICITY PRODUCTIVITY
EFFICIENCY ATTRACTIVENESS
Cloud Native Enterprises Cloud-native als Wegbereiter für autonome Systeme und Produktorientierung:
https://www.qaware.de/fileadmin/user_upload/OS-Sonderdruck_5-2019_QAware-Digital.pdf
❏ Data
❏ Load
❏ Developer: Lead
time to features
❏ Operations: SOP
automation ratio
❏ Talent
❏ Customers
❏ On demand resource
consumption
❏ Less toil
AVAILABILITY
❏ Lower MTTR
❏ Higher resiliency
CLOUD NATIVE
PROPHEZEIUNG

17. CIOLet’s bring
all our web applications
onto a cloud
native platform.

18. 18
❏ All 152 legacy applications
migrated and in production
within 17 months
❏ All security -hardened and
modernized to containerized 12-
factor -apps

19. Insurance as a Service. ©Syncier
The
Architect’s
Point of View

20. 20
Visibility

21. Cloudalyzer: A single source of truth for migration -related software
landscape information
Insurance as a Service. ©Syncier 21
Tableau analysisMIGRATION
DATABASEQAVALIDATOR
SONARQUBE
EAM TOOL
QUESTIONNAIRES
JIRA
XLS
STATIC ANALYSIS
IBM MIGRATION TOOL
…
MIGRATION TASKS
BASIC
TOUR-DE-MIGRATION
SYSTEM PROPERTIES
OW ASP Scanner
jQAssistant

22. 22
How to make applications more
cloud native?

23. Veränderung der Bebauung
Veränderung einer Anwendung

24. Dominant application properties for migration decisions
24

25. 25
CLOUD ALIEN APPLICATION
CLOUD FRIENDLY APPLICATION
CLOUD NATIVE
APPLICATION
● leverage the benefits of
cloud native technology:
elasticity, efficiency,
productivity
● are secure & compliant
● can be operated on a
standard operations
procedure level by SRE
team
● can easily be integrated by
third parties

26. Cloud friendly applications: A sweet spot for legacy apps
26
Cloud Friendly Apps
… and enhance each
application according the 12
factors
Put the monolith into a
container

27. ENTERPRISE
APP
ENTERPRISE
APP
ENTERPRISE
APP'
ENTERPRISE
APP'

28. https://speakerdeck.com/adersberger/cloud-native-and-javaee-freund-oder-feind

29. Der Weg in die Cloud sollte auf Sicht gefahren werden
29
CI/CD The service can be deployed with CI/CD with a lead time for change < 5min and automated post-deployment checks
Source repo The source and infrastructure code of the application is available on pre-defined github repositories within the
organization
Config externalized All configuration items including public keys & public certificates are externalized in ConfigMaps
Secrets externalized All secrets (passwords and private certificates) are externalized in Secrets
Probes available Liveness and readiness probes are available for each container according the naming and port standard
Prometheus monitoring endpoints are available with at least OS and server level metrics
Logs Logs are written to SOUT
Container interface A container interface is defined according: https://www.javaland.eu/formes/pubfiles/9953332/2018-nn-
josef_adersberger-kubernetes-_und_docker-patterns_und_-antipatterns-praesentation.pdf
Runbook A runbook is available
API documentation An API documentation according OpenAPI 3.0 is defined and accessible under a standard endpoint at the service
API design The API is designed according a given set of best practices like GraphQL and the Open Microservice Guide
(https://microservice.guide)
API security ● All public endpoints are only accessible with a mTLS 1.2 connection
● Every request holds a user and service identity based on OIDC/JWT
Resilience All outbound synchronous requests must be wrapped with a circuit breaker

30. Insurance as a Service. ©Syncier
The
Project Manager’s
Point of View

32. An emergent design approach for large -scale application migration to
a cloud plattform
Insurance as a Service. ©Syncier 32
APPLICATION BLUEPRINT
MIGRATION COOKBOOK
TOUR-DE-MIGRATION
GOLIVE READINESS CHECKLIST
Q1/17 Q2/17 Q3/17 Q4/17 Q1/18 Q2/18
APPLICATION MIGRATION
CLOUD PLATFORM SETUP
PRE-STUDY

33. Management support
❏ Strong management
support
❏ Clear scope &priorities
❏ Courage to drive the
change to cloud native
development

34. Project marketing

35. Industrialization

36. ARCHITECTURE TEAM
DOZENS OF MIGRATION PROJECTS RUNNING IN PARALLEL
(organized in release trains)
‣ Training sessions
‣ Support sessions
‣ Co-Location &remote
‣ Guidance / best practice sharing (cookbook,
sample application)
‣ Unified development environment (via
GitHub)
‣ Standard base images
‣ Pre-migrated frameworks
‣ Solutions: Security service, ambassadors
INDUSTRIALIZATION TEAM
‣ Application blueprint
‣ Migration database
SUPPORT TEAM
‣ Feedback

37. Co-location
One co-location space for
❏ support- &
❏ industrialization team
Visiting migration team members
(could book support slots)

38. Transparency
Launch Status
Activities &Milestones
Quality
GoLive Planning
Operational

39. Insurance as a Service. ©Syncier
The
Developer’s
Point of View

40. https://youtu.be/yB6Zl8nqqqE
https://speakerdeck.com/adersberger/patterns-and-pains-of-
migrating-legacy-applications-to-kubernetes
https://speakerdeck.com/adersberger/the-good-the-bad-and-the-ugly-
of-migrating-hundreds-of-legacy-applications-to-kubernetes

41. 41
Fragen
1. Was sind die zentralen Fragen der Anwendungsmigration in die Cloud?
2. Welche Anwendungen sollten sinnvollerweise in die Cloud migriert werden?
1. Wie sieht eine sinnvolle Zielarchitektur für bestehende Anwendungen auf einer Cloud
Native Plattform aus, um möglichst viele Vorteile der neuen Technology zu realisieren?
1. Wie muss die eigene Organisation - allen voran die Entwickler - hierfür eingebunden
werden?

42. Migration von IT-Services in die Cloud
Migration von Anwendungen in die Cloud
Aufbau einer Kubernetes-Plattform mit Blick auf Day 2

43. Technology Perspective

44. 44
Cloud Native
Landscape
January 2017

45. 45
Cloud Native
Landscape
May 2018

46. 46
Cloud Native
Landscape
Today
Challenge:
pick the right tools
integrate them well
keep them up2date
replace them again

47. 1st wave 2nd wave 3rd wave 4th wave
First
pioneers
The rise of
fundamental
technologies
Ecosystem
explosion
Internet
Ecosystem
maturity, consolidation,
integration
PaaS
IaaS
CaaS
PaaS

48. Challenge #1: High efforts to get productive and stay state of the art
48
enterprise
readinessproduction-ready
scalable platform
first cluster
up and running
effort
“stuck in PoC”
High
technical
inflation

49. Challenge #2: How to stay unaffected in times of cloud & container wars?
49
Pivotal -> IPO-> VMware
Amazon vs. Microsoft vs. Google vs. Alibaba
CoreOS-> RedHat -> IBM

50. Container-as-a-Service (CaaS)
Platform-as-a-Service (PaaS)
CloudiFire Technology Blueprint: Building blocks
Developer
Collaboration
Continuous
Integration
Developer Chat
Continuous
Quality
Developer
Self Service
Service
Provisioning
Package
Management
Platform
Provisioning
Infrastructure
Provisioning
Secret & Cert
Management
Continuous
Compliance
Secure Software
Supply Chain
Backup &
Recovery
SIEM |
Audit Log
Incident
Response
Orchestration
SOP Automation
Alerting Metrics
Traces
Logs
APM
Billing, Accounting & Reporting
Continuous
Delivery
Provisioning
Continuous
Security
SRE Toolchain
Diagnosability
(Cluster & Apps)
Infrastructure-as-a-Service (IaaS) Hardware Virtualization Bare Metal
API Management
Microservice Platform
Customer IAM
Service Mesh | Egress | DC-Connect
Nanoservice Platform Dataservice Platform Legacy Platform
Microservice Chassis Nanoservice Chassis Dataservice Chassis Legacy Chassis
Kubernetes-as-a-Service
Cluster Virtualization
Secure Container Runtime Secure Native Storage Secure Cloud Native Network
Infrastructure
Image Registry
Ingress | Web Layer
Continuous
Delivery

51. Container-as-a-Service (CaaS)
Platform-as-a-Service (PaaS)
The PaaS is assembled of a sane default choice of open source components
github, gitlab,
Bitbucket
Open Service
Broker&
kube-apps
HELM
KaaS-specific
tooling
Terraform, Ansible
Vault, cert-
manager, SPIFFE
Phylake
(CFi project),OPA
PagerDuty,
OpsGenie
k8s CRDs
Grafana,
Prometheus,
Elastalert
Prometheus+
Grafana
Jaeger
EFK
Instana,
Dynatrace, Kiali
WunderBAR (CFi project)
Continuous
Delivery
Provisioning
Continuous
Security
SRE Toolchain
Diagnosability
(Cluster & Apps)
AWS, Azure, Google Cloud
OpenStack
vmWare Bare Metal
Kong, tyk
Microservice Platform
Keycloak
Istio, Linkerd, Consul Connect
Nanoservice Platform Dataservice Platform Legacy Platform
Spring Boot, Microprofile Knative, Kubeless, …
Kafka, Postgres, Redis,
Spark, Presto, kubeflow, …
LEAP (CFi project)
Rancher, Kubermatic,Gardener
AKS, EKS, GKE
Cluster Virtualization
Docker, CRI-O
infrastructure-native, Portworx,
Quobyte, Rook
infrastructure-native,
Cilium, Calico, weave
Infrastructure
nginx, traefik, gloo,metallb, Istio/Envoy
Jenkins/JX,gitlab,
Concourse, Knative
Slack, Mattermost
SonarQube,
jQAssistant
CLI, ChatBot,
YAML
Artifactory, Nexus,
Harbor
ArgoCD, JX, gitlab,
Spinnaker,
Concourse
Clair, copper.sh,
Grafeas, Anchore
Velero,
infrastructure-
native
EFK, SIEMonster,
Metron, OSSIM

52. Operations Perspective

53. 53
Topics to be addressed starting from day 2
Billing & Accounting Messaging ITSM Prozesse
Cost Optimization Alerting IT Service Catalog
Data Services SIEM (KPI-) Monitoring
Observability Data Center Connectivity SLA
Backup & Restore / DR Audit Log

54. Fragen
1. Wie muss die Kubernetes Infrastruktur aufgebaut sein, dass sie auch
auf den Day 2 Betrieb ausgelegt ist?
2. Was muss die Plattform neben Kubernetes als Container Manager
noch bieten, damit die Anwendungen den vollen Vorteil der Cloud
Native Technologie heben können?
54