Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Stateful Functions as a Service: programming th...

Stateful Functions as a Service: programming the cloud

Introductory talk during the online meetup organized by Big Data Republic in Aug. 2020.

Asterios Katsifodimos

August 27, 2020
Tweet

Other Decks in Programming

Transcript

  1. Bringing the State back to Cloud Functions Asterios Katsifodimos, Asst.

    Professor 1 Stateful Functions as a Service Online Meetup 27/08/2020, organized by Big Data Republic
  2. 2 Canonical (micro)services architecture in 2020 Database (state)layer Data base

    Order service Payment service Stock service Data base Data base To checkout: stock & update stock -> verify payment -> checkout the cart.
  3. Perform an order iff there is stock available and the

    payment is cleared. Services are stateless Database does the heavy- lifting High latency, costly state access 3 Microservices Architecture (1): Easiest Implem. Order Business Logic Stock Business Logic Payment Business Logic DB RPC C all RPC Response RPC C all RPC Response RPC Call RPC Response REST Call REST Call DB DB
  4. Make state of each service local to the business logic.

    Services now are stateful Low-latency access to local state Service calls still expensive Not obvious how to scale this out (e.g., shard the state in some way) Fault tolerance is hard 4 Microservices Architecture (2): Embedded State/DB Order DB Business Logic Stock DB Business Logic Payment DB Business Logic REST Call REST Call
  5. Each message exchange/change to the state goes through an event-log.

    Services are asynchronous/reactive. If we lose state, we replay the log and rebuild it. Time-travel debugging, audits, etc. are trivial. 5 Microservices Architecture (3): Event Sourcing Order DB Business Logic Stock DB Business Logic Payment DB Business Logic REST Call REST Call event-log event-log
  6. 6 Microservices Architecture (4): Scalable Deployment RPC Calls Subscribe for

    Responses event-log event-log Order 1 Business Logic Order 2 Business Logic Order 3 Business Logic Stock 1 Business Logic Stock 2 Business Logic Payment 1 Business Logic event-log DB DB DB DB DB DB
  7. Machines in company premises 7 A tale of the cloud:

    first was the VMs Before the cloud In the cloud: VMs available to rent
  8. Function-as-a-Service (FaaS) for achieving serverless 9 AWS claimed to have

    some good news VM Fn Fn Fn VM Fn Fn Fn VM Fn Fn Fn Cloud database Managed Infrastructure (autoscaling!) Function-based programming model Stateless functions No State Fn-to-fn calls Transactions & orchestration among function calls
  9. Assignment: implement Stock, Order, Payment microservices with one tool from

    of each layer: Goal: maximum consistent order.checkout() throughput in the Cloud Quiz question: out of 40, 5-person teams, how many managed to sustain a deployment of 10K order chekcouts per second, and keep the data consistent? 10 Meanwhile at the TU Delft campus… Service Layer: Flask/Spring, AWS Lambdas, Azure Functions. Akka Persistence Layer: Postgres, CockroachDB, Mongo, Cassandra, Redis Infra Layer: Docker+Kubernetes on Amazon or Google Cloud
  10. 11 Ongoing research in Distributed Systems and Databases for decades.

    How to make stateful computations fault tolerant? How do we (or should we) guarantee message delivery? How do we consistently query the global state of a full system? What abstractions should people use? None! State Management is hard! And the current technology is primitive! (or the students have learned nothing)
  11. We live in the stone ages. Building Cloud applications is

    like programming assembly before compilers were around. “Two-pizza” dev team in the year 2020.
  12. A Call to Arms: novel SFaaS abstractions & systems Global

    Application State Querying and Consolidation Versioned Deployments/State/Schema Transactions & Service Orchestration Functions & communication compiled to efficient implementations Time-Travel Debugging Capabilities Holistic Optimization of Service Compositions
  13. 15 My Research: stateful functions as DAGs of operators Marios

    Fragkoulis Adil Akhter (ING Bank) Pedro Silvestre [1] Operational Stream Processing: Towards Scalable and Consistent Event-Driven Applications Asterios Katsifodimos, Marios Fragkoulis. In EDBT 2019. [2] Stateful Functions as a Service in Action Adil Akhter, Marios Fragkoulis, Asterios Katsifodimos. In VLDB 2019. Together with:
  14. 16 A programming model*for authoring cloud applications Function definition Transaction

    orchestration Function call Transaction failure handling Function arguments Function state Function state update *currently compiles to cyclic Flink+Kafka dataflows.
  15. 17 Business Logic Managed State Logical Message Inboxes Outgoing Message

    Router SVC1 SVC5 SVC2 SVC4 Input Message Queues SVC3 Control Event (commit, prepare, snapshot marker, etc.) Message Managed Operator State Output Message Queue Time-travel debugging using checkpoints and message broker Guaranteed message delivery and exactly-once processing Each operator executes a (group of) microservices or functions that share the same state Operator-local state partitioned on key input for scalability and fault-tolerance
  16. 18 Building Cloud applications is like programming assembly before compilers

    were around. We need to fix this. How? • Talk to your Cloud provider • Support intitiatives like Cloudstate.io, Flink’s Stateful Functions, MS Orleans, CloudBurst, etc. • Talk to me if you want to know more about our plans!