A wasi-cloud-core World proposal

[Mossaka]

This follows the footstep of #509 and a few discussions in WASI subgroup meetings, we want to create a World for all the wasi-cloud proposals and name it as wasi-cloud-core. This includes

• wasi-keyvalue
• wasi-messaging
• wasi-http
• wasi-runtime-config
• wasi-distributed-lock-service
• wasi-sql
• wasi-blob-store

Currently, progress on the above proposals varies in terms of completeness. The proposal specifications for wasi-keyvalue, wasi-messaging, wasi-http, wasi-sql, and wasi-blob-store are more fully formed. In these proposals, some of them are not updated with the WASI preview 2 syntax. By the end of Spring, we plan to add basic proposal specifications for the remaining wasi-cloud proposals and make sure all of the proposal specifications are aligned with the WASI preview 2 syntax. In addition, we want to validate all the WIT files using automated CIs and wasm-tools, and document any breaks and changes to the specifciation in a change log.

To elaborate on aligning the syntax of WIT with that of WASI preview 2, we want to use pseudo-stream/future/resource types, and to continue to align with future versions of WASI, as described in #515.

Each of these proposals have its own proposed WIT interfaces and worlds, but we raise this issue to propose a wasi-cloud-core World that has a similar structure to the following:

default world wasi-cloud-core {
  import wasi-keyvalue: wasi-keyvalue
  import wasi-blob-store: wasi-blob-store
  import wasi-sql: wasi-sql
  import wasi-messaging: wasi-messaging
  import wasi-runtime-config: wasi-runtime-config
  import wasi-distributed-locking: wasi-distributed-lock-service
  import default-upstream-HTTP: wasi-http.outgoing-handler
 
  export HTTP: wasi-http.incoming-handler
}

This is just a sketch of the proposed world, and much remains unknown to what it means to import a wasi-keyvalue world inside of another world, as imports and exports of a World only allow WIT interfaces. We will also explore the uses of WIT templates in each proposal to help us move runtime implementation to static time implementations.

A note on wasi-cloud-core overall scope

It is not meant to cover 100% of the features that distribtued application expecs, but it focuses on the 80% of the problem space with the assumption that most apps will fall into this scope. The API designs for these wasi-cloud proposals aggregate the common features across multiple providers. An example would be that wasi-keyvalue provides readwrite APIs which is the lowerest common dominator in all systems and is designed for rapid development expeirence.

[technosophos]

All of these make sense to me except for gRPC, which feels out of place and niche.

While gRPC gets used in the Kubernetes world, I can't think of many other contexts where it gets broad use. I can't think of any tier-1 cloud providers that require gRPC for communication (and even Kubernetes uses it only in very low level contexts that most developers never see) or which offer services that require gRPC to be able to use them. Additionally, there are many competing technologies that do what gRPC does, and there are good reasons for adopting those. Additionally, gRPC is particularly fragile and prone to breaking changes and incompatible implementations.

The rest of the proposed bindings refer to tremendously well-adopted "table stakes" features, and provide general purpose implementations.

Is there a powerful reason to include gRPC in what is otherwise a generic set of "table stakes" features? Otherwise, it feels like requiring it may prove to be a hinderance for adoption, especially in ecosystems that have no use for it or actively avoid it.

Otherwise, I'm pretty excited about this proposal.

[technosophos]

Also, I love the name.

[sbc100]

BTW, where does this name come from? Perhaps I am out of touch with the world of cloud and this is something most folks will immediately understand? (I tried googling "cloud" with "bursty" but it didn't seem helpful).

[technosophos]

My assumption was that it came from "bursty workloads" -- e.g. the kind of unit of work that handles computing in short-lived bursts rather than constantly. Examples: handling an HTTP request, responding on a message queue, listening for an event, and so on.

This would include patterns like:

• Edge functions (Fastly)
• Serverless functions
• ETL steps
• Cloud events

Opposed to bursty workloads would be anything that is expected to run continuously, or to handle very large operations that consume hours rather than seconds.

Again, though, this is my reading of a name that @Mossaka came up with. So he may drop in here and tell me I'm entirely wrong.

[squillace]

it could be bursty workload, too, easily

[Mossaka]

Is there a powerful reason to include gRPC in what is otherwise a generic set of "table stakes" features? Otherwise, it feels like requiring it may prove to be a hinderance for adoption, especially in ecosystems that have no use for it or actively avoid it.

Just to clarify, wasi-grpc is a proposal that hasn't been materialized yet, and this is the reason why I didn't put wasi-grpc in the bursty world proposal. AFAIK there are two primary modles for service to service/client communications: REST (HTTP) and RPC (source: Designing Data-Intensive Application chapter 4). Over the years, RPC has been evolved and among them, gRPC emerges as a RPC framework that uses Protocol Buffers encoding schemes. It could be argued that what we really want to abstract is the RPC model instead of gRPC. But what's fascinating about gRPC is that it supports streams communication.

Back to your question. Yes I agree that gRPC has compatibility, complexity, and performance issues. Some older system may not support the latest gRPC frameworks or some langauges are not supported by the gRPC codegen. But I still see values in wasi-gprc proposal itself, albeit it may have a hard time integrating itself into the bigger world unlike other wasi-cloud proposals. Does this sound reasonable to you?

[Mossaka]

Again, though, this is my reading of a name that @Mossaka came up with. So he may drop in here and tell me I'm entirely wrong.

The name is contributed by @squillace . It really is saying that this world is designed for serverless / edge function model.

[sbc100]

Again, though, this is my reading of a name that @Mossaka came up with. So he may drop in here and tell me I'm entirely wrong.

The name is contributed by @squillace . It really is saying that this world is designed for serverless / edge function model.

But is "bursty" a common word that used in the serverless / edge world (no pun indented)? I've never heard of it before, but maybe thats not surprising because its not an area I work in often.

If its not a common word, then would it make sense to use a word that is more commonly known? Why not just cloud?

[fibonacci1729]

Historically there have been conversations about supporting an include <world> WIT syntax to enable the union-ing of worlds supplemented by a with syntax to reconcile name conflicts. Sounds like this proposal is a good motivation to formalize some of those past ideas!

[squillace]

Again, though, this is my reading of a name that @Mossaka came up with. So he may drop in here and tell me I'm entirely wrong.

The name is contributed by @squillace . It really is saying that this world is designed for serverless / edge function model.

But is "bursty" a common word that used in the serverless / edge world (no pun indented)? I've never heard of it before, but maybe thats not surprising because its not an area I work in often.

If its not a common word, then would it make sense to use a word that is more commonly known? Why not just cloud?

no, @sbc100, bursty world is not a term of art, but rather a way to specify "fast-firing functions". The pattern would be "serverless" generally, but unlike that term it does not imply any process/module hangs around much at all. Hence, "bursty" rather than functions or serverless which don't really scope based on time of execution.

the cloud world is one I wanted to avoid, because the major cloud providers have 120+ services available, and that is definitely not "scope" :-)

That said, as naming is considered hard, just trying to drive in on a catchy but metaphorically appropriate name for the scope of work..... we could say "wasi-fast-functions" for example, but somehow it just isn't as suggestive.....

[sbc100]

I see, thanks for the explanation. I agree that "cloud" is not the right name for the thing your are describing.

It sounds like "bursty" might not the right name either though since (to me at least) its doesn't imply stateless-ness or throwaway-ness or lightwight-ness (which seem to be what you trying to get at?)

Can you explain more why you don't like "serverless"? To me it does imply those things, and I'm not sure what you mean by "does not imply any process/module hangs around much at all". I thought serverless kind of does imply that. Is the idea with this proposal that the process/module would, by definition, not stick around for more than one request?

Of course we don't need to all the bike-shedding here and now.. and as you say, naming is hard.

[lukewagner]

I like the terms "bursty" and "serverless" since they're both evocative of these ephemeral, quick-starting, auto-scaling-to-zero instances that I think a lot of us are imagining. That being said, there are a lot of different worlds that these qualities will apply to, including the existing wasi-http proposal. Moreover, with the wasi:http/proxy world (and I think the same logic applies here), there is no reason that a host must make instances short-lived or auto-scaled; the host can deliver as many or few events to a given instance as it wants and keep them alive/warm for as long as it wants (or likely make this configurable by per deployment). Thus, while I think "serverless" and "bursty" are qualities we want these worlds to have, I don't know if they are the defining properties of a single world.

In general, I'd suggest that we try to think of world names that describe the collection of functionality that is being exposed. That's tricky with the large set of functionality that Joe listed above. Just to throw in my 2c: one term that is admittedly amorphous, but maybe in the right way (given that we expect this set to grow over time), could be "service". If service feels overly general, an adjective that maybe makes sense is "persistent" (as in wasi-persistent-service), since a theme across messaging, kv, blob and sql is that these are all forms of persistent storage. ¯\(ツ)/¯

[squillace]

no problem bikeshedding on a friday. That's what friday's are for. the main conceptual boundary I'm trying to draw is between serverless generally, which can include very long running processes and thus remain alive for minutes or more, and fast firing functions, which almost certainly do not live much longer than a minute.

The former encompass "durable" functions that can be suspended and reanimated and the latter are essentially the generalized case of "CDN functions" that have if not milliseconds then only seconds to live, possibly to a minute. There are domain differences between the two approaches, though the design pattern seems the same. In bursty workloads, one of the main points is recycling the resources essentially or literally per request, which means resource efficiency does not require threading or connection management and so on.

serverless, however, might include precisely these things, depending on how they are being used. OR.... so I have been thinking. But as I said, bikeshedding naming on a friday is a good thing, so all thoughts here are flexible.

[squillace]

related to @lukewagner's comment that just sailed in, yes, I think persistence is a thing that might place some shapes in a different "domain" and hence world. OH! and to give even more context: with respecto bursty worlds, the list of capabilities here reflect what our customers are asking for in this precise world they describe. They say this is the 80% sweet spot -- more isn't needed.

This doesn't mean we cannot add or remove any, but just to give context for the source of the choices.....