Dema's Quartz đź”®

Radon ASPLOS

4 min read

Topics/Sections

Start High Level

Introduction

  • Motivation
  • Objective

Background

  • Technology
  • Programming models
  • Containers, Kubernetes: distributed application portability (lack constraints)
    • For this paper I’m inclined to argue that FaaS is a subset of this with different practice
  • ZeroMQ, …: messaging abstractions for DS (lack state, not really portable and modular, tool not solution)
  • Faasm, Sledge, Wasm runtimes: address performance of containers, same technological background, no significant contribution in programming model, too much freedom (sockets)
  • Akka, actor framework: yes programming model, but constrained by the framework implementation, no standard specification, no real reconfigurability

Vision

  • …

Two linked lines of work

Programming Model

  • Programming Abstractions and Abstraction levels
  • High level architecture
  • Scope of the programming model
    • Distributed systems implemented with low level primitives
    • Applications
  • Programming Model
  • Separation of Concerns
  • Two sets of interfaces
    • Application facing set of syscalls (part of the standard)
    • Component interface derived from the application one (egg or chicken first?) note: this is an implementation characteristic of the runtime
  • Developer roles
    • Application developers
    • Middleware developers
    • System developers
  • Interface as (evolving) standard
  • Execution model decoupling
    • Monolith
    • Distributed
    • *asS

Systems Aspects

  • Intermediate layer: WebAssembly
  • Compilation and execution model
  • Intrinsic performance characteristics induced by the model (rt efficient impl of critical parts)
  • Functional and non Functional requirements
  • Configurability of the systems
  • Differences in backing systems capabilities
  • Anti-vendor-lock-in
  • Transparent deployment modes
  • Cross-platform portability
  • Mobile code

Implementation + Interface

Maybe two sections

  • Concrete version of the two previous sections
  • The actual API
  • Programming atoms and characteristics of the interface
  • Radon runtime
  • Characteristics of execution flow within the runtime
  • Component interfaces
  • Dynamic vs. Static dispatch
  • State management for atoms
  • Inter-operation between the rust code and the wasm
  • …

Evaluation

  • Distributed first
    • Niente evaluation
  • Modularity
    • Layered
    • Comporre servizi componendo atoms
      • Dimostrato da KV-store / transactional KV-store
  • Flexibility
    • A livello di linguaggi
      • Non va nell’evaluation (low priority)
    • A livello di paradigmi di programmazione
      • Event-based → dataflow
      • Code mobility / client-server → serverless/distributed scheduler
        • Applicazione a microservizi deployata staticamente alla serverless (DeathStar?)
        • Stessa applicazione eseguita con un distributed scheduler per code mobility
        • Partiamo dalle nostre impl con numeri standalone, se abbiamo tempo confrontiamo con versione microservice uffciale
      • Request-response / P2P → KV-store (le shard sono di fatto peers)
  • Performance
    • Lightweight
      • Microbenchmark con costo chiamate di funzioni Radon
      • Confronto KV-store / Anna
      • Confronto Nexmark / Flink
  • Configurability
    • Puoi adattare runtime per incontrare i requirements
      • KV-store e/o Dataflow
  • Portability
    • Diverse piattaforme hardware
      • ARM / x86

Future

  • Extensibility for Accelerators
  • Static code analysis and Isolation using existing approach
  • Programming model with guarantees on top of the interface

Structure discussion

  • Inizio con introduction, background (e anche related work subito magari), poi la vision ad alto livello che setta lo scope e la struttura del lavoro
  • Poi dividere in due macro filoni la narrazione trattando da un lato la parte di programming model e dall’altro l’aspetto systems
    • L’idea sarebbe di presentare i due aspetti come quasi separati, ma facendo riferimento alle conseguenze che uno ha sull’altro
    • Queste due sezioni di fatto descrivono la contribution a livello teorico facendo riferimento solo tangenzialmente alla current implementation
  • A questo punto la sezione implementation ricongiunge il modello teorico e le caratteristiche systems che ne derivano a un sistema concreto che è l’implementazione attuale
    • Forse nella sezione programming model non farei nemmeno riferimento all’interfaccia specifica che abbiamo, ma ci rifletterei piĂą a livello generale (discorso distributed operating systems e caratteristiche del programming model as a whole) per poi presentare l’interfaccia che abbiamo scelto nella parte di implementation. Poi a sua volta questa sezione potrebbe essere divisa in due parti, una di API e una vera e propria di impl
  • Eval poi continua con quello che abbiamo giĂ  discusso sulla struttura
  • Chiusura forte poi sul future work presentando le possibilitĂ  che apre un modello e sistema di questo tipo (programing models costruiti sopra con guarantees, applicazione di tech wasm per rendere il tutto ancora piĂą interessante, come static analysis varie, isolation, aspetti di security etc, possibilitĂ  di aggiungere un’estensione all’interfaccia per supportare acceleratori hardware se disponibili per supportare AI e cagate varie, chi piĂą ne ha piĂą ne metta) che allo stesso tempo serve a rinforzare la motivation per il lavoro perchĂ© fa vedere quante applicazioni abilita

La divisione Programming Model vs. Systems sarebbe oltre per chiarezza che spero sia più semplice raccontare le cose sezionandole perpendicolarmente così e anche per fittare allo scope della venue con una divisione che rispetta i main topics di ASPLOS

Graph View