New directions in cloud programming

This paper appeared in CIDR'21. This paper is also on operationalizing CALM theorem, and is a good companion to the CALM-CRDT paper we covered yesterday.

The paper starts by pointing out the challenges of cloud programmability. It says that most developers find it hard to harness the enormous potential of the cloud, and that the cloud has yet to provide a programming environment that exposes the inherent power of the platform. The paper then lays out an agenda for providing a new generation of cloud programming environment to programmers in an evolutionary fashion.

I would like to start by challenging the claim that the cloud about not yet providing a noteworthy programming environment. I think there are many examples of successful cloud programming paradigms and frameworks that have emerged in the past decade, such as MapReduce, Resilient Distributed Datasets, Hadoop environment, Spark environment, real time data processing and streaming systems, distributed machine learning systems, scalable globe-spanning databases from NoSQL to NewSQL, RESTful architectures, FAAS, and Lambda and Kappa architectures. In addition to these, cloud computing also gave rise to supporting systems (VMs, containers), scheduling frameworks (Mesos, Kubernetes), SLAs, and observability, debugging, and devops tools. (My blog has summaries for most of the concepts listed above.)

Nevertheless, I agree with the paper that there is still room for improvement and innovation in cloud programming. The paper suggests that even "FaaS done right" is a low-level assembly language for the cloud, a simple infrastructure for launching sequential code without a programming model to host it. The paper advocates for the next generation of technology that should allow developers to address distributed concerns gradually, working with the assistance of new automation technologies.
 

PACT for cloud programming

The paper introduces PACT as a framework for decoupling cloud programming into separate concerns, each with an independent tool/language facet:

  • Program semantics involve lifting program specifications to a higher-level declarative intermediate representation, allowing developers to focus on application logic. This approach ensures a gradual transition toward addressing distributed concerns while still offering a familiar programming style.
  • Availability enables programmers to specify the desired availability independently of program semantics. A compiler stage then synthesizes code to provide the specified availability guarantee efficiently.
  • Consistency disentangles consistency invariants from code, making explicit the desired sequential semantics and the relaxations of those semantics tolerable in a distributed setting.
  • Targets for dynamic optimization enable programmers to specify multi-objective performance targets, considering factors such as billing costs, latency, and availability. The code should be able to dynamically redeploy and autoscale based on workload fluctuations.

The paper claims that PACT can enable developers to focus on application logic, and not worry about implementation aspects of consistency, durability, and availability. Developers can declare their consistency, availability, budgetary needs, and have the PACT's cloud runtime enforce such declarations.

This proposes an evolutionary approach where developers get initial success by writing simple familiar programs, and entrusting everything else to a compiler. The compiler will generate human-centric code in well-documented internal languages, suitable for eventual refinement by programmers. Programmers can then improve the generated programs incrementally by modifying the lower-level facets or "hinting" the compiler via constraints.


Hydro

To this end, the paper introduces Hydro, a programming language and runtime system that aligns with the proposed PACT approach. Hydro employs an event loop called HydroLogic, which computes results from program snapshots while ensuring fixpoint semantics. HydroLogic’s event loop considers the current snapshot of program state, which includes any new inbound messages to be handled. Each iteration (“tick”) of the loop uses the developer’s program specification to compute new results from the snapshot, and atomically updates state at the end of the tick. All computation within the tick is done to fixpoint. The snapshot and fixpoint semantics together ensure that the results of a tick are independent of the order in which statements appear in the program.

The language offers a rich data model and abstractions for persistent data structures and distributed data placement. The Hydroflow runtime is a strongly-typed single-node flow runtime implemented in Rust




Discussion

I think the PACT idea is feasible for a narrow domain and is very promising! But, when the domain is not narrow, this can be problematic. We can have domain-specific languages (DSLs) for narrow domains that can hide a lot of “mechanical” work from the programmers and delegate it to a runtime. SQL is a good example of this. SQL is declarative — programmers retrieve and update the data without worrying about how it is done under the hood. But SQL is also a powerful foot-gun because you lose predictability. This was the whole reason the NoSQL approach got started and prevalent. NoSQL breaks that separation of concerns abstraction, and that also causes a backlash. Systems design is all about tradeoffs, and is an act of balance. Without restraining the DSL, and narrowing the domain, it seems hard to operationalize PACT's clean abstractions in a scalable and practical manner.

Here is a presentation of the paper from Joe Hellerstein. It is a great pitch! This line was especially catchy: "in the future we will not overfit our programs". If the Hydro project and vision succeeds, we will write them in a declarative language, and will be able to tune the orthogonal facets of availability, consistency independently.


Comments

Popular posts from this blog

The end of a myth: Distributed transactions can scale

Foundational distributed systems papers

Hints for Distributed Systems Design

Learning about distributed systems: where to start?

Metastable failures in the wild

Scalable OLTP in the Cloud: What’s the BIG DEAL?

SIGMOD panel: Future of Database System Architectures

Amazon Aurora: Design Considerations + On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes

Dude, where's my Emacs?

There is plenty of room at the bottom