Stateful on Stateless - The Future of Applications in the Cloud
3 likes481 views
The document discusses stateful serverless computing and its advantages over stateless serverless functions (FaaS). It argues that stateful serverless is needed to support more complex, general-purpose applications involving distributed state. It proposes serving stateful functions using Knative and Akka Cluster to provide a unified programming model and runtime for serverless applications with both stateless and stateful capabilities. This would allow building applications involving real-time stream processing, machine learning models, user sessions, workflows and more using a serverless paradigm.
Ad
More Related Content
What's hot (19)
Similar to Stateful on Stateless - The Future of Applications in the Cloud (20)
Ad
More from Markus Eisele (20)
Ad
Recently uploaded (20)
Stateful on Stateless - The Future of Applications in the Cloud
- 1. Stateful Serverless The Future of Applications in the Cloud Markus Eisele Director of Developer Advocacy, Lightbend JavaZone
- 2. @myfear 2
- 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. Reactive Systems The rules of the game have changed 4
- 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 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. 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. SERVERLESS ≠FAAS 8FaaS = Function-as-a-Service
- 9. WHY SHOULD WE LET FAASHAVE ALL THE FUN? 9
- 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 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 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. 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. 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. 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. FaaS Abstracting Over Communication 16 Message In Deployment Message OutUser Function
- 17. FaaS With CRUD 17 Message In Deployment Message OutUser Function Database Not Serverless In An Ideal World
- 18. UNCONSTRAINED DATABASE ACCESS MAKES IT HARD TO AUTOMATE OPERATIONS 18
- 19. 19 Constraints liberate, liberties constrain. - Runar Bjarnason “ Cloud computing simplified: a Berkeley view on serverless computing
- 20. Stateful Serverless Abstracting Over State 20 Message In Deployment Message Out User Function Message In Message Out
- 21. We Need Better Models For Distributed State A couple of battle-tested, yet constrained, models are: 21 EVENT SOURCING & CRDTs
- 23. Event Sourced Functions 23 SAD PATH, RECOVER FROM FAILURE Event Log Replay Events
- 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. 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. Serverless CRDTs 26 Message In Deployment Message Out User Function States/Deltas In States/Deltas Out
- 27. 27 SO WHAT ARE WE DOING ABOUT IT?
- 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. 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. 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. 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
- 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. 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. 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. Thank You Page Markus Eisele @myfear blog.eisele.net