Agenda​
- DEMO: An Introduction to wRPC
- DISCUSSION: OTEL Metrics
- DISCUSSION: Roadmap Update
Meeting Notes​
Welcome to Ondřej Kupka joining us from Prague in the Czech Republic. He has been programming for 10 years professionally. He started with Go during his thesis and stayed with it ever since; a certified Gopher. Loves working in startups—data processing on Kafka, microservices with gRPC. After a break he is back and looking at what’s new and cool to help decide what’s next.
DEMO: An Introduction to wRPC
- This is one of the most ambitious projects planned for wasmCloud 1.0. We highly recommend reviewing the recording for the full details.
- wRPC will be the name of this protocol and is early stage in terms of wasmCloud implementation. RFC here. This is intended to be integrated with wasmCloud 1.0.
- As we push to 1.0 now is the time to be looking at the underlying protocols we need to maintain direct and stable component to component communication.
- wRPC is a new way to interact with components with complex data types—that capitalizes on the component model.
- Instead of wasifills, in wRPC we emphasise direct communication over imports and export handlers—composing components over a distributed network.
- Rather than linking exports and imports at compile time you can link them together dynamically, at runtime over a NATS lattice. This lets you run workloads on machines where a GPU is running: for lightweight implementation at the edge, for example.
- tl;dr this is a similar to the control interface RFC. Wasm components, actor modules and capability providers communicate over NATS via the RPC layer in wasmCloud.
- Traditionally, wasifills provided the translation between a wasmCloud contract and a wasi interface. this was how we would communicate with an actor with wasmbus. wRPC replaces this approach.
Q: Is there a future where we could have a wasmCloud-specific shim to make components more independent?
A: You don’t compile any of the wasmCloud elements into your component so there are no specific dependencies. The wasmCloud host looks at your imports and exports and communicates over import and export handlers. The connective tissue is facilitated by wasmCloud. No requirement to use RPC - you can bring whatever you already use.
DISCUSSION: OTEL Metrics
- We’ve made some good progress in this area and are at the point where we can share the intention.
- We support OTEL tracing today. You can provide an OTLP exporter URL and they will export no matter where you’re running.
- For 1.0 we’re focused on complete observability. If you have an OTLP collector for traces, logs, and metrics we will support that in wasmCloud 1.0.
- The hard part is done, implementing logic and traces are complete. We already use trace libraries for logging so logging is simpler to complete, just need to export them.
- OTEL metrics are what we would use if we use wasmCloud in a dev, QA and prod. We want to be able to asks questions of the workload. Do I need to scale my component? Which ones do I need to scale? Am I saturating resources on specific code etc.
- Specific features such as error rates and gauging actor concurrency. More to come.
DISCUSSION: Roadmap Update
- We have a number of completed tasks which is great to see.
- We have a couple of new issues that are ready for work and so we encourage everyone to take a look and get involved.
- Closed a couple more things:
- Lattice Prefix RFC clears up naming.
- Improving provider errors - separating from invocation errors.
- Check out the recording for the full details of what’s in the plan. There’s an interesting question from Vance on our confidence in delivering what is an ambitious roadmap for wasmCloud.