Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-Plattform finden
0 gefällt mir806 aufrufe
Das Dokument behandelt die Migration von IT-Services und Anwendungen auf cloudnative Plattformen, beleuchtet die Herausforderungen und Treiber für Unternehmen, die in die Cloud migrieren möchten. Es werden verschiedene Ansätze zur Migration sowie wichtige Überlegungen und Best Practices diskutiert, um die Vorteile cloudnativer Technologien zu nutzen, darunter Skalierbarkeit, Kosteneffizienz und Automatisierung. Zudem werden Fragen zur Zielarchitektur und zur Integration der Organisation in den Migrationsprozess aufgeworfen.
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-Plattform finden
- 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
- 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
- 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
- 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
- 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
- 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