Cloud-native Apps 2.0
2 gefällt mir710 aufrufe
Der Dokument beschreibt die Entwicklung und Prinzipien von cloud-nativen Anwendungen (CNA), die aus lose gekoppelten, elastischen Mikroservices bestehen und auf automatisierten Plattformen betrieben werden. Diese Systeme skalieren automatisch abhängig von der Last und verfolgen das Prinzip der Kostenassoziativität im Cloud Computing. Der Text untersucht auch verschiedene Frameworks, Dienste und Architekturansätze, die zur Erstellung und Verwaltung von CNA verwendet werden.
Cloud-native Apps 2.0
- 1. Stateless Services + Service Orchestration + Data (Stateful Services) Cloud-native Apps 2.0 Inhaltliche Entwicklung: Prof. Dr. Nane Kratzke, Technische Hochschule Lübeck, Mönkhofer Weg 239, 23562 Lübeck unter Mitwirkung von: Dr. Adersberger, QAware Managed Services CNCF Projects Microservice Serverless Container Isolated State Commercial: Quobyte I Portworx Open Source: Ceph I FS I IPFS I HDFS I Objective FS I XtreemFS I Rook I ... AWS {S3, EBS, Glacier, ... } Azure {Files, BLOBS, Data Lake, ... } Google { Filestore, Datastore, ... } Beispiel für Kostenassoziativität: Der Betrieb einer virtuellen Maschine für 100 Std. oder 100 virtueller Maschi- nen für 1 Std. kostet (fast) dasselbe. Weiterführende Links: www.qaware.de/news/cloud-ready www.sigs-datacom.de/wissen „Eine Cloud-native Applikation ist ein verteiltes, elastisches und horizontal skalierbares Softwaresystem, welches aus Service- orientierten Komponenten (Diensten) besteht, die Zustände in ei- nem Minimum an zustandsbehafteten Komponenten isolieren. Die Applikation und ihre Komponenten werden gemäß Cloud-spezifi- scher Entwurfsmuster entworfen und auf einer elastischen Platt- form betrieben.“ Definition Definitionund Erläuterungen CNA unterscheiden sich damit von „klassischen“ Multi-Tier Applikationen vor allem hin- sichtlich des Grades ihrer Verteilung und ihrer Elastizität. CNA sind elastisch, d.h. sie können ihren Ressourcenbedarf dem zu verarbeitenden Workload (idealerweise vollautomatisch) anpassen, um so das Pay-as-you-go Prinzip und die Kostenassoziativität des Cloud Computing als Kostenvorteil zu nutzen. CNA sind insbesondere für Anwendungen interessant, deren Workload schwer prog nostizierbar ist, deren Nutzung Peak-Loads unterliegt oder für die exponentielles Wachstum angestrebt wird. Prinzipien von CNA: L I D E A Isolated State Um horizontale Skalierbarkeit zu optimieren, versucht man zu- standsbehaftete Komponenten und deren Skalierungskomplexi- tät zu isolieren. Distributed CNA sind verteilte Systeme (web- scale), die aus unabhängig von- einander austauschbaren Diens- ten komponiert werden. Elastic CNAsindelastisch,d.h.siefordern Ressourcen (Compute, Storage, Network) abhängig von einer Last an (wenig Last → wenig Ressour- cen, hohe Last → mehr Ressour- cen). Die Skalierung erfolgt dabei meist horizontal (mehr Ressour- cen) und nicht vertikal (stärkere Ressourcen). Automated CNA sollten meist auf automa- tisierten Plattformen betrieben werden die wenig bis keinen Operatoreingriff erfordern. Loosely coupled Die Dienste rufen sich unterein- ander idealerweise nicht direkt auf, sondern interagieren indi- rekt über entkoppelnde Messa- ging-Lösungen. In Anlehnung an: Fehling, C., Leymann, F., Retter, R., Schupeck, W., Arbitter, P., „Cloud Computing Patterns - Fundamentals to Design, Build, and Manage Cloud Applications“, Springer, 2014 Design for Failure („Everything fails all the time“): Mittels Resilienz schützen sich Cloud- native Applikationen z.B. per Circuit Breaker vor einer fehlerhaften und langsamen Umgebung. Einzelne Ser- viceausfälle sollten nie die gesamte Cloud-native Applikation beeinträch- tigen. Center of Excellence CNA werden häufig auf elastischen Self-Service-Plattformen betrieben und basieren auf Software-Defined-Infrastruktur Prinzipien. Architekturen von CNA sind meist Service-orientiert und folgen zunehmend der pragmatischen Microservice-Interpretation dieses Ansatzes. CNA Entwicklungsmethodiken beruhen oft auf Cloud-spezifischen Software- entwicklungsmustern und DevOps Ansätzen. (N. Kratzke, P.-C. Quint, Understanding Cloud-native Applications after 10 Years of Cloud Computing, Journal of Software and Systems, 2017) Cloud-native Applikationen (CNA): Softwaresysteme, die explizit für die Cloud entwickelt werden Spring (Boot) Akka Ballerina Lagom Node.js Jolie (research) MicroProfile Dropwizard … Microservice Frameworks Clustered Storage Solutions Drone.io Spinnaker JenkinsX GO-CD Concourse Knative Continuous Delivery In Anlehnung an: OPEN DATA CENTER ALLIANCE Best Practi- ces: Architecting Cloud-Aware Applications (Rev. 1.0) und Mario-Leander Reimer (QAWare) Cloud Application Maturity Level Level Maturity 3 | Adaptive Cloud Native Applikation skaliert elastisch (lastab- hängig) Migration auf andere Infrastrukturen ohne Service Downtime 2 | Abstracted Cloud Resilient Dienste sind stateless Applikation ist designed for failure Applikation ist Infra- struktur agnostisch (runs anywhere) 1 | Loosely Coupled Cloud Friendly Applikation ist aus lose gekoppelten Diensten komponiert Dienste sind per Namen adressierbar Applikation berück- sichtigt 12-Factor App Prinzipien Applikation trennt Compute und Storage Dienste Applikation basiert auf Compute-, Storage- und Netzwerkdiensten 0 | Virtualized Cloud Ready Applikation läuft auf virtualisierter Infra- struktur Applikation kann auto- matisiert ausgeprägt werden Applikationen werden aus Services komponiert. Frameworks Zur Serviceentwicklung existieren Frameworks für Microservices, für Nanoservices (FaaS) und für die Datenana- lyse mittels Machine Learning oder BigData- Frameworks. Service Operation Services sind lose gekoppelt und unab- hängig voneinander auf CaaS Plattformen de- ploybar. Die Kopplung erfolgt entweder Event- basiert (Messaging) oder mittels Stateful Services (NoSQL DB) CaaS Elastische Container Plattformen integrieren IaaS Ressourcen zu einer verteilten Cloud Runtime Environment für Services. Infrastructure IaaS Provider stellen Computing, Networking und Storage Ressourcen bereit. Circle CI, Codeship I Travis CI, AWS Code Pipeline I Azure Continuous Delivery I Google Cloud Continuous Delivery Serverless I Squeezer ... Kubeless I Knative I OpenFaaS I OpenWhisk I nuclio I Fn project I Fission I Spring Functions ... AWS Lambda Azure Functions Google Functions ... Nanoservice Frameworks (FaaS) AWS ECS I EKS Azure Kubernetes Service Google Container Engine Kubernetes Cloud Foundry Docker Swarm OpenShift DC/OS (Mesos) Nomad Container Platforms (Ausführung standardisierter Deployment Units, Container as a Service) MySQL I Maria DB I Postgres I Cockroach DB I Vitess I CitusDB I Mongo DB I Couch DB I Cassandra I Neo4j I ... AWS {RDS I DynamoDB I SimpleDB I ... } Azure {SQL I DocumentDB I ... } Google {SQL I BigTable I Spanner I Memory Store I ... } … Database Solutions and Services Istio Consul Connect Linkerd ... Service Meshs Envoy ... Prana Service Proxies Fault Tolerant Communication Finagle Proxygen ... Hystrix Resilience4j Metrics: Prometheus I Sensu I ... Logs: ELF/EFK I Stack I fluentd I ... Traces: Jaeger I OpenTracing I ZipKin I ... Loggly, Datadog, ... AWS { ES, CloudWatch } Azure Log Analytics Google Stackdriver Logging MonitoringService Discovery CoreDNS Eureka Consul ... AWS SQS Azure Event Grid Google Task Queue ... Active MQ Artemis NATS Kafka ... Messaging/Streaming Spark I Flink I Storm I Caffe I CNTK I Torch I Keras I ... AWS {Glue I Athena I EMR, Transcribe I Translate I Compre- hend I Lex I Deep Learning I ...} Azure {Databricks I Machine Lear- ning I Stream Analytics I Data Lake Analytics I ...} Google {Dataflow I Dataproc I Vision I Speech I Translation I ...} (Big) Data + Machine Learning SaaSPaaSIaaS IT-Probleme lösen. Digitale Zukunft gestalten.