Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Stateful on Stateless - The Future of Applications in the Cloud

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 36 Anzeige

Stateful on Stateless - The Future of Applications in the Cloud

Herunterladen, um offline zu lesen

Most developers building applications on top of Kubernetes are still mainly relying on stateless protocols and design. The problem is that focusing exclusively on a stateless design ignores the hardest part in distributed systems: managing state—your data.
The challenge is not designing and implementing the services themselves, but managing the space in between the services: data consistency guarantees, reliable communication, data replication and failover, component failure detection and recovery, sharding, routing, consensus algorithms and so on.
Kubernetes and Akka work well together since each being responsible for a different layer and function in the application stack. Kubernetes allows for coarse-grained container-level management of resilience and scalability. Akka allows for fine-grained entity-level management of resilience and scalability. This talk demonstrates how the two play together to deliver the future of stateful applications in the cloud.

Most developers building applications on top of Kubernetes are still mainly relying on stateless protocols and design. The problem is that focusing exclusively on a stateless design ignores the hardest part in distributed systems: managing state—your data.
The challenge is not designing and implementing the services themselves, but managing the space in between the services: data consistency guarantees, reliable communication, data replication and failover, component failure detection and recovery, sharding, routing, consensus algorithms and so on.
Kubernetes and Akka work well together since each being responsible for a different layer and function in the application stack. Kubernetes allows for coarse-grained container-level management of resilience and scalability. Akka allows for fine-grained entity-level management of resilience and scalability. This talk demonstrates how the two play together to deliver the future of stateful applications in the cloud.

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (19)

Ähnlich wie Stateful on Stateless - The Future of Applications in the Cloud (20)

Anzeige

Weitere von Markus Eisele (20)

Aktuellste (20)

Anzeige

Stateful on Stateless - The Future of Applications in the Cloud

  1. 1. Stateful Serverless The Future of Applications in the Cloud Markus Eisele Director of Developer Advocacy, Lightbend JavaZone
  2. 2. @myfear 2
  3. 3. Industry Trends New World: Multicore, Cloud, Mobile, IoT, Big Data, AI 1 Towards Real-time Data-centric Streaming applications Towards a World with Automated Operations: Opsless 2 3
  4. 4. Reactive Systems The rules of the game have changed 4
  5. 5. Towards Fast Data Real-time, Data-centric, Event-driven 5 Reactive Microservices Big Data Fast Data Applications Increasing requirements for scalability & resilience Streaming data pipelines are being served by Microservices Increasing requirements for streaming vs. batch
  6. 6. 6 We predict that Serverless Computing will grow to dominate the future of Cloud Computing. - Berkeley CS Department “ Cloud computing simplified: a Berkeley view on serverless computing
  7. 7. 1. Cost and resource efficient—scale down to zero 2. Pay as you go—scale up on demand 3. Automation—of scale, failure handling, and recovery 4. Great developer experience—supporting full dev cycle 5. Reduced time, complexity, and risk—when moving to the Cloud 7 SERVERLESSPROVIDES A UNIFIED SOLUTION FOR CUTTING OPERATIONAL & DEVELOPMENT COSTS
  8. 8. SERVERLESS ≠FAAS 8FaaS = Function-as-a-Service
  9. 9. WHY SHOULD WE LET FAASHAVE ALL THE FUN? 9
  10. 10. 1. Paved the way for Serverless 2. Scaling on-demand from 0 to 10000s request, in a cost-efficient manner 3. Simplifies delivery of scalable and available applications 4. Encourages good distributed systems design (events-first, loose coupling, etc.) 5. Great as integration layer between various (ephemeral and durable) data sources 6. Great for stateless & processing-centric workloads 7. Great as data backbone moving data from A to B, transforming it along the way 10 WHAT’S GOOD WITH FAAS?
  11. 11. 11 USE CASES FOR FAAS Use-cases where throughput is key rather than low latency and requests can be completed in a short time window 1. Low traffic applications—enterprise IT services, and spiky workloads 2. Stateless web applications—serving static content form S3 (or similar) 3. Embarrassingly parallel processing tasks—invoked on demand & intermittently, examples include: resizing images, object recognition, log analysis 4. Orchestration functions—integration/coordination of calls to third-party services 5. Composing chains of functions—stateless workflow management, connected via data dependencies 6. Job scheduling—CRON jobs, triggers, etc.
  12. 12. 12 WHAT’S BAD WITH FAAS? Hard to build general-purpose applications 1. Retains the limitations of the 3-tier architecture 2. Functions are stateless, ephemeral, and short-lived 3. No direct addressability 4. No co-location of state and processing 5. Limited options for managing and coordinating distributed state 6. Limited options for modelling various consistency guarantees 7. Limited options for managing durable state, that is scalable and available
  13. 13. What We Want The Serverless Experience— but for general-purpose applications, including modern Fast Data and Reactive systems Stateful Functions— complementing stateless functions, expanding the toolbox and supported use-cases The cost efficiencies of FaaS— allowing the user to dial in trade-offs (related to cost, SLOs, use-cases) 13
  14. 14. Support For Use Cases Like Training and Serving of Machine Learning Models • Any dynamic in-memory model that needs to build up and served with low latency Real-time Distributed Stream Processing • E.g. Real-time Prediction/Recommendation Serving, Anomaly Detection User Sessions, Shopping Carts, Caching • Managing in-memory, yet durable, session state across individual requests Distributed Resilient Transactional Workflows • Saga Pattern, Workflow Orchestration, Rollback/Compensating Actions Shared Collaborative Workspaces • Collaborative Document Editing, Blackboards, Chat Rooms, etc. Leader Election • …and other standard distributed systems patterns/protocols for coordination 14
  15. 15. Technical Requirements • Stateful long-lived addressable virtual components—actors • Wide range of options for distributed coordination & communication patterns • Options for managing distributed state reliably at scale—ranging from strong to eventual consistency (durable/ephemeral) • Intelligent adaptive placement of stateful functions—physical co-location of state and processing, sharding, and sticky routing • Ways of managing end-to-end guarantees and correctness • Predictable performance, latency, and throughput—in startup time, communication/coordination, and storage of data 15
  16. 16. FaaS Abstracting Over Communication 16 Message In Deployment Message OutUser Function
  17. 17. FaaS With CRUD 17 Message In Deployment Message OutUser Function Database Not Serverless In An Ideal World
  18. 18. UNCONSTRAINED DATABASE ACCESS MAKES IT HARD TO AUTOMATE OPERATIONS 18
  19. 19. 19 Constraints liberate, liberties constrain. - Runar Bjarnason “ Cloud computing simplified: a Berkeley view on serverless computing
  20. 20. Stateful Serverless Abstracting Over State 20 Message In Deployment Message Out User Function Message In Message Out
  21. 21. We Need Better Models For Distributed State A couple of battle-tested, yet constrained, models are: 21 EVENT SOURCING & CRDTs
  22. 22. Event Sourced Functions 22 Event Log EventCommand Event Command HAPPY PATH
  23. 23. Event Sourced Functions 23 SAD PATH, RECOVER FROM FAILURE Event Log Replay Events
  24. 24. ACID 2.0 ASSOCIATIVE Batch-insensitive (grouping doesn't matter) a+(b+c)=(a+b)+c 24 COMMUTATIVE Order-insensitive (order doesn't matter) a+b=b+a IDEMPOTENT Retransmission-insensitive (duplication does not matter) a+a=a
  25. 25. Conflict-Free Replicated Data Types ACID 2.0 Strong Eventual Consistency Replicated & Decentralized Always Converge Correctly Monotonic Merge Function Highly Available & Scalable 25 Counters Registers Sets Maps Graphs (that all compose) CRDT DATA TYPES Convergent & Commutative Replicated Data Types - Shapiro et. al. 2011
  26. 26. Serverless CRDTs 26 Message In Deployment Message Out User Function States/Deltas In States/Deltas Out
  27. 27. 27 SO WHAT ARE WE DOING ABOUT IT?
  28. 28. What is Akka? Cloud Native, Reactive, Distributed Systems Runtime • Implementation of the Actor Model—Concurrency and Distribution • Decentralized, Self-Organizing, Peer-to-peer Service Mesh • Autonomous, Self-healing, Event-driven Services High Performance, High Throughput, and Low Latency • Communication: Point-to-Point, Pub-Sub, and Streaming • Protocols: HTTP, TCP, Aeron (UDP), Kafka, Reactive Streams, gRPC Distributed State Management • CRDTs, Event Sourcing, CQRS • Multi-Datacenter Clustering and Log Replication Find out more at: akka.io 28
  29. 29. Serving of Stateful Functions 29 Kubernetes Pod Knative Stateful Serving Knative Events Distributed Datastore (Cassandra, DynamoDB, Spanner,…) GRPC User Function (JavaScript, Go, Java…) Kubernetes PodUser Function (JavaScript, Go, Java…) Kubernetes PodUser Function (JavaScript, Go, Java…)
  30. 30. Kubernetes Pod Kubernetes Pod Kubernetes Pod Powered by Akka Cluster Sidecars 30 Kubernetes PodUser Function (JavaScript, Go, Java…) Kubernetes PodUser Function (JavaScript, Go, Java…) Kubernetes PodUser Function (JavaScript, Go, Java…) Knative Stateful Serving Akka Sidecar Akka Sidecar Akka Sidecar Distributed Datastore (Cassandra, DynamoDB, Spanner,…) Akka Cluster GRPC
  31. 31. In Summary 1. The promise of Serverless is revolutionary and could grow to dominate the future of Cloud Computing 2. FaaS is a good first step, but with limited addressable use-cases 3. Serverless 2.0 needs a runtime & programming model for general-purpose application development 4. We have started building it with Knative, Akka, and gRPC 5. We need your help 31
  32. 32. GET INVOLVED bit.ly/stateful-serverless-intro https://github.com/cloudstateio/cloudstate 32
  33. 33. Reactive Microservices Architecture Written for architects and developers that must quickly gain a fundamental understanding of microservice-based architectures, this free O’Reilly report explores the journey from SOA to microservices, discusses approaches to dismantling your monolith, and reviews the key tenets of a Reactive microservice: • Isolate all the Things • Act Autonomously • Do One Thing, and Do It Well • Own Your State, Exclusively • Embrace Asynchronous Message-Passing • Stay Mobile, but Addressable • Collaborate as Systems to Solve Problems http://bit.ly/ReactiveMicroservice 33
  34. 34. Developing Reactive Microservices The detailed example in this report is based on Lagom, a new framework that helps you follow the requirements for building distributed, reactive systems. • Get an overview of the Reactive Programming model and basic requirements for developing reactive microservices • Learn how to create base services, expose endpoints, and then connect them with a simple, web-based user interface • Understand how to deal with persistence, state, and clients • Use integration technologies to start a successful migration away from legacy systems http://bit.ly/DevelopReactiveMicroservice 34
  35. 35. Modern Java EE Design Patterns • Understand the challenges of starting a greenfield development vs tearing apart an existing brownfield application into services • Examine your business domain to see if microservices would be a good fit • Explore best practices for automation, high availability, data separation, and performance • Align your development teams around business capabilities and responsibilities • Inspect design patterns such as aggregator, proxy, pipeline, or shared resources to model service interactions http://bit.ly/SustainableEnterprise 35
  36. 36. Thank You Page Markus Eisele @myfear blog.eisele.net

×