Cloud Native Applications Chance oder Risiko?

Größe: px

Ab Seite anzeigen:

Download "Cloud Native Applications Chance oder Risiko?"

Matilde Kranz
vor 7 Jahren
Abrufe

1 Cloud Native Applications Chance oder Risiko? Burkhard Noltensmeier Geschäftsführer, teuto.net Netzdienste GmbH 1 / 46

2 Agenda Wohin geht die Reise? Vision Buzzword Bingo Platform as a Service Fragen / Diskussion 2 / 46

3 Tipping Point! 3 / 46

4 The World s First Processor Chip Vorgestellt: 19 Juni 2016 einzeln programmierbar 0,7 Watt(!) 4 / 46

5 Wohin geht die Reise? Mehr Daten! Befeuert durch Megatrends: Internet of Things API Economy Deep Learning / Neuronale Netzwerke 5 / 46

6 Produkte aus der Cloud: SaaS End Customer Connected Car / Autonomous Driving Sprachinterface: Amazon Echo B2B Salesforce Google Docs 6 / 46

7 Openstack to Rescue? Hypecyle ist auf dem Höhepunkt Reality kicks in! Wo ist der Value? Keep it simple: Spezialisierung! Infrastructure as a Service Baremetal 7 / 46

8 Infrastructure Software is Dead Everybody s OpenStack software is equally bad. It s also as bad as all the other infrastructure software out there, you name it. Boris Renski, Mirantis 8 / 46

9 Developer brauchen Unterstützung Müssen komplexe vernetzte Anwendungen erstellen Automation Build, Test, Deploy von (Cloud Native) Anwendungen Skalierung und Ausfallsicherheit 9 / 46

10 Die aktuelle Situation Server/Virtuelle Maschine als kleinste Einheit traditionelle Anwendungen gehen von einer ständigen Verfügbarkeit der Server aus Server/VMs teilweise überlastet, teilweise nicht ausgelastet Schwierig zu automatisieren 10 / 46

11 Was ist die Vision? Software Entwicklung ohne Abhängigkeiten Schnelle Updatezyklen Anwendung skaliert von selbst Anwendung heilt sich selbst Hybrid Cloud Lastverschiebung 11 / 46

12 Buzzword Bingo Cloud Native Container Microservice PaaS (Platform as a Service) 12 / 46

13 Cloud Native 12 factor app Distributed Failure expected Autoscaling 13 / 46

14 Container Immutable Infrastructure Löst das Dependency Hell Problem Build Local, Deploy Global Open Container Initiative Alternative Implementierungen : Rocket rkt 14 / 46

15 Microservice Anwendung wird in kleine Teile geschnitten Rest API zur Kopplung der Services Reduzierung von Abhängigkeiten: Unabhängig zu deployen Unabhängig zu entwickeln 15 / 46

16 Herausforderungen durch Microservices Mitarbeiter mitnehmen Höhere Komplexität z.b. Abhängigkeiten in den Rest APIs Authentication / Authorization 16 / 46

17 Nutzen durch Microservices Schnelle Entwicklung durch parallele Teams Das beste Tool für das Problem 17 / 46

18 (Rest) API Dokumentation Open API Initiative aka Swagger Top Down: generate code from documentation Bottom Up: generate documentation from Code Language agnostic(!) Vorteil: Kunde kann die API anhand der Dokumentation verstehen und benutzen 18 / 46

19 19 / 46

20 Herausforderung: layered Microservices 20 / 46

21 Authentication SSO Auth2 / Open ID Connect OIDC (6) (4) (3) WebPortal (2) (5) REST Service (1) OpenID Connect / Oauth2 User / Browser 21 / 46

22 Erwartungen an eine PaaS Polyglott Vorgefertigte Services Building Blocks Sicherheit in der Plattform Scaling + Routing Monitoring 22 / 46

23 Differenzierungsmerkmale PaaS Entwicklungsgeschwindigkeit / ommunity Size Operational complexity Updatefähigkeit/Maintenance Service Building Blocks z.b. SQL, Hadoop, Cassanda On Premise / On Laptop 23 / 46

24 On Premise Paas Prä Docker Ära Cloud Foundry Apache Mesos Native Docker Kubernetes Docker Swarm 24 / 46

25 Cloud Foundry Entwickelt von Pivotal, 2012 EMC spin off Full lifecylcle Support Installierbare Services: SQL, MongoDB, Redis, Cassandra etc, Komplexes deployment / operating 25 / 46

26 Mesos Developed at University of California, Berkely 2009 efficient resource isolation and sharing across distributed applications, or frameworks Mesosphere entwickelt Data Center Operation System DCOS opensource 2016 Services für DCOS: Hadoop, Cassandra, Kubernetes 26 / 46

27 Mesos Pro: Effizientes Resource Management z.b. lokales Festplatten Management Contra: Complex Big Failure Domain 27 / 46

28 Docker Swarm Guter Entwickler Support (zu) Einfach zu nutzen Fehlende Features: Autoscaling Namespaces 28 / 46

29 Kubernetes Version 1.0 Juli 2015 von Google Cloud Native Computing Foundation (CNCF.io) einfach, jedoch nicht zu einfach 29 / 46

30 Kubernetes Strukturierung durch Pods, Labels, Services Operational Features Autscaling etc. Aktuell noch kein local Storage management 30 / 46

31 Docker Swam vs. Kubernetes 31 / 46

32 Google Trend 32 / 46

33 Stackoverflow 33 / 46

34 Github Activity 34 / 46

35 Kubernetes in Deutschland Fujitsu in München entwickelt Dashboard Soundcloud aus Berlin entwickelt Monitoring Prometheus.io Zalanondo entwickelt Postgresql Service patroni BMW entscheidet sich für Openshift/Kubernetes als Strategische Plattform 35 / 46

36 Kubernetes Vendor Support OpenShift 3 von Redhat Tektonic von Coreos 36 / 46

37 Vanilla Kubernetes Deloyment Ansible Flexibel AWS, Openstack, Baremetal 37 / 46

38 Ausblick: Kubernetes 1.3 PetSet für Stateful Application Ubernetes Federated Cluser Rkt Container OIDC 38 / 46

39 Hybrid Cloud: Ubernetes Ubernetes stellt eine Control Plane oberhalb eines einzelnen Kubernetes Clusters zur Verfügung. Gemeinsame Verwaltung von Kubernetes Clustern bei verschiedenen Cloud Providern bzw. Bare Metal In Zukunft dynamisches Scaling und Lastverschiebung möglich 39 / 46

40 Networking / Storage Networking mit Policy Enforcement Canal von tigera.io Romana.io Persistent Storage : CoreOS: Torus Big Data: pachyderm.io 40 / 46

41 Sicherheit Container auf Hypervisor z.b. rkt lkvm oder hypernetes Network Isolation auf Services-Ebene Intrusion Detection 41 / 46

42 Beispiel Saas: IoT teuto.net 42 / 46

43 Gitlab Integrierte Docker Registry Integriertes CI mit Kubernetes anbindung Flexible CI Pipeline 43 / 46

44 44 / 46

45 Cloud Native: Vom Metal zu Anwendung Ubuntu MaaS Ansible Orchestration Openstack IaaS Kubernetes PaaS Gitlab CI 45 / 46

46 46 / 46

Ähnliche Dokumente

Platform as a Service (PaaS) & Containerization

Platform as a Service (PaaS) & Containerization Open Source Roundtable Bundesverwaltung; Bern, 23. Juni 2016 André Kunz Chief Communications Officer Peter Mumenthaler Head of System Engineering 1. Puzzle