Nokia, Ericsson and all the major telecoms providers have massive infrastructures and so it's been interesting to explain how WebAssembly allows the kind of scale telcos/ISPs are used to.
How do you build a large system like this? Once the team implemented everything in wasmCloud putting everything together becomes interesting.
The team implemented contracts in smithy + SDKs to create fresh interfaces which can replace the usual TMForum standard interfaces.
DEMO: Building NATS microservices in wasmCloud - Kevin
There hasn't been functionality for service discovery in NATS until now!
In the last week a few NATS clients have been rolling out new functionality that allows us to expose the code that is following the request response pattern. Essentially, you can now use NATS to discover or recover information — and it's rolling out as a free feature to clients.
Demo: using a local build called Bob; all services have unique IDs. You'll see it's possible to add arbitrary metadata to each service you run.
Each service has 1 or more end points.
This allows us to discover microservices and obtain a catalog on whats's running in the infrastructure, or in an account.
Does not sacrifice any of the good stuff we get from NATS — e.g. location agnostic goodness of NATS remains.
You can list all the all the services that are within communication within your NATS CLI.
Doesn't take much effort to expose wasmCloud actors as services.
Synadia plans to add an option to the NATS messaging provider (currently manual) — so it magically appears as a NATS service 🙂
If you're using any of the major languages you already have the ability to explicitly publish service information.
RFC: Separating out RPC events onto a diff topic rather than cloud events - refactor to the Rust host, we do not have the wasmbus RPC EVT events being published for every single event: https://github.com/wasmCloud/wasmCloud/issues/664
Now, you can see the status of all invocations.
Main point is to be able to create an aggregate metric — all invocations that failed and succeeded over time. We can start to see trends.
In particular, see whether you're succeeding over time — % of successful requests etc.
Similar to service mesh - delivered straight over NATS.
Implementing Prometheus metrics in wasmCloud:
Already have OTEL support for tracing - nice to get that data.
Some of the things missing; accuracy and historical comparison.
Rust Host lost some of that introspection.
Info on number of actors providers invocations that have a particular provider or actor.
Interesting summary stats around specific resource usage: so we can more accurately scale actors up and down.
Provider exposing metrics - counter for number of 500s/400s is pretty common. We want to be able to do the same thing in wasmCoud.
Some work to do to decide how, but this is where we're leaning.
Observability and metrics RFC - please get involved if you have expertise - we're excited to hear your opinions and experiences.