Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- nice project. can I use it like a microservice? in a small company, and installing Pollen in all computers. then, running a business logic in there? instead of 'centeral servers'? good to have WASM sandboxing everywhere.
"Use idle company machines as a decentralized, sandboxed microservice cluster"
by ivere27 - Hypothetically, yes! If your workloads are bounded and can compile to WASM, break them into logical units which would benefit from individual scalability, and `pln seed` them into the cluster. Ingress can be from any node. Any workload that doesn't suit the WASM seeds can be `pln serve`d on dedicated hosts.
You could also establish a dev cluster (/environment) where all devs run a local instance. You can iterate on services quickly, expose ngrok-like capabilities by exposing a local dev instance of a server with `pln serve 8080 test_server` for your colleagues to consume with `pln connect test_server`, etc, etc.
A more whacky idea I've not been able to get out of my head which might become possible as the access story solidifies: imagine a customer could access a controlled subset of your companies offering by having a delegated node, running in their own infrastructure, that ultimately you can delegate and revoke at any given time.
by sambigeara - Really neat project. The idea of a fully decentralized leaderless WASM runtime is bold. My main question is around failure modes -- how does it handle network segmentation or split-brain scenarios? Does the gossip protocol deal with this gracefully, or is there an eventual consistency aspect that workloads need to be aware of?by m_ramdhan
- So, the moment a partition occurs, nodes within their resultant partitions then view the remaining peers as the full view of the world. There is _no_ concept of a split brain scenario.
ANY decision around network topography or workload placement is a deterministic calculation run by all nodes individually. If all nodes see the same sub-set of peers representing their entire "cluster", they'll all naturally converge on the same view of what the cluster should look like. If the calculated output determines that Node A should claim Seed B, and it doesn't have it, it requests it from a peer who has it.
As soon as the partition recovers, nodes see the additional nodes re-enter the candidate set, which is then added in to future routing and placement decisions.
The main tradeoff to understand here is that you're at mercy of the random (best attempt redundant) placement of a seed. If the entire cluster has, say, 2 replicas stored on any given nodes, if a resultant partition doesn't happen to have either of those two nodes, then the seed will be unavailable until the partition recovers. You can work around this with "smart" initial placements (one near, one close, for example) but you're still at the mercy of random partition events. An additional factor is of course getting very unlucky with dropped gossip events, which would also impact the rate of convergence across the cluster.
by sambigeara - This looks fantastic, however it's not clear (to me), which WASM feature sets are supported? p1, p2, simd, garbage collection, tail calls, etc. Might be good to include in a table on the readme itself as different features will expose which compute loads can be used in this distributed runtime system.by drzaiusx11
- Thanks! It's just Wazero's default config[1] right now, so it implements (and is constrained to) those capabilities--WASI p1 is supported, WASI p2 isn't (Wazero yet to implement). Yes to SIMD, no to GC and tail calls (I think), etc. Full capabilities can be inferred from digging around in the code linked below.
Good suggestion on listing capabilities, will add a note.
[1]https://github.com/wazero/wazero/blob/2bbd517b7633bf6a126305...
by sambigeara - Wow, this is super cool. It almost feels like a DIY pocket-Cloudflare. I’m curious how a WASM binary gets mapped to HTTP endpoints that take JSON, how much of that is Pollen vs Extism? Are the routes encoded in the WASM binary somehow?by jitl
- Ha, thanks! The routing is all Pollen. You reach the workloads through the gRPC control API (exposed on a socket on the host) via a `pln call seed_name function_name payload` or with a more traditional gRPC client. But once they're in, it routes them to a keyed WASM instance of that given seed on whatever node happens to be hosting it at that moment.by sambigeara
- Did you have any applications in mind when you were designing this? Any weakness in precedents that you wanted to rectify? Are you familiar with Lunatic (https://lunatic.solutions/), and wasmCloud (https://wasmcloud.com/) ?by esafak
- Honestly, not really. It started as an experiment in local-first, convergent state (I have a historical fascination of this: https://news.ycombinator.com/item?id=27606604, https://news.ycombinator.com/item?id=42444856) and then continued to grow.
I do absolutely despise the complexity of administering modern distributed systems, hence my attempt to make Pollen as ergonomic and (as much as I hate to use this term) batteries-included as possible.
I've not come across either of those projects, oddly. I have a tendency to avoid looking for similar projects during the development of my own, lest I get despondent and run out of steam. Both sound cool, though. I'd say WASM was a natural workload "type" that fit nicely into what I was trying to achieve with Pollen, rather than a driving factor, if you know what I mean.
by sambigeara - I'm a little confused about a "zero-trust mesh" where I actually do need to trust the honesty of the nodes performing my computation. I'd suggest less buzzwords and more concrete examples.by yencabulator
- No idea why this post has picked up traction 2 days later, I’m out and about right now but will endeavour to respond thoughtfully when I’m back at my keyboard later on!by sambigeara
- A moderator added it to the second-chance pool: https://news.ycombinator.com/item?id=26998309by greyface-
- This is so nice. Encouraging to see such persistent serious efforts in the local-first, control-resistant tech space, even knowing it is a long uphill climb. Hope all the fragmented efforts help move toward something really formidable one day.by samantp
- Thank you. Me too!by sambigeara
- I know the individual words in the description but I'm a bit confused about what this is.
What would I use Pollen for?
I'm not sure I understand the "seed" metaphor.
by kaoD - Failed to mention in my other reply: a "seed" because I envisioned, perhaps too poetically, "seeding" some generic computational unit into the cluster only for it to organically spread to other nodes in the cluster... sort of like pollen? Maybe.by sambigeara
- Well, that’s a good question. I think the best answer for now is “we’ll see”?
I use it in place of Tailscale for some homelab applications. I’ve started to deploy other experiments on a “prod” cluster. The demo I showed shows how Pollen responds to a multi-step pipeline type application; two WASM seeds and a single egress communicating over the provided RPC mechanism (`pln://seed…` etc) whilst handling routing, back pressure and the like.
Right now, the workloads need to be stateless. I’m coming up with a story for state at the moment, which’ll likely start as some WAL-like convergent structure with thin (KV store etc) abstractions layered over it. Probably not dissimilar from the pattern underpinning the current CRDT gossip state.
by sambigeara - Hi everyone, I'm Sam. I started Pollen as an experiment last summer, got carried away, and have landed here.
It's a single Go binary. Install it on every machine you want in the cluster and they self-organise. Topology is derived deterministically from gossiped state, so workloads land where there's capacity, replicas migrate toward demand, and survivors rehost from failed nodes. The mesh is built on ed25519 identity with signed properties; any TCP or UDP service you pin gets mTLS. Connections punch direct between peers where possible, otherwise they relay through mutually accessible nodes.
I built it because I'm fascinated by local-first, convergent systems, and because I wanted to see if said systems could be applied to flip the traditional workload orchestration patterns on their head. I also _despise_ the operational complexity of modern systems and the thousands of bolted-on tools they demand. So I've attempted to make Pollen's ergonomics a primary concern (two-ish commands to a cluster, etc).
It serves busy, live, globally distributed clusters (per the demo), but it's very early days, so don't be surprised by any rough edges!
Very happy to answer anything in the thread!
Cheers.
Docs: https://docs.pln.sh
by sambigeara - This is very interesting! I agree about the operational complexity of many systems, cough Kubernetes.
For most systems, state storage is the toughest problem, have you considered adding some form of storage layer over the top or would you recommend another solution that allows all the workloads to share state?
by al_james - From someone who definitely doesn't fully understand what you made, this looks really cool!
I'm seeing some functionality that seems like it could replace some personal services I currently host via my tailscale network. Am I understanding this correctly? If so, do you have a feel for what the performance implications would be?
by digdugdirk - You have some workload demos which all definitely try out but could you paint us an example use-case of the technology?
What are the workloads in the runtime capable of?
by Levitating - Interesting project.
In a potential modern cloud, having a globally named primitives (computer, store, messaging) can unlock very wider applications. Have you come across any such?
by anilgulecha - Fascinating project – do you think there is a use case where a cluster could host web assets or a full static site? I wonder if it could act like a personal CDN in that way...by chris-corby
- This is incredible.
We’re building an AWS analogue catalogue of services (Databases, Compute, Auth, etc.) for distributed systems.
Want a job do Pollen-like dev full time?
william.blankenship@webai.com
Either way, would be great to compare notes!
by r3trohack3r - this is a great direction - self organizing service meshes that don't require a infinite tower of manually configured turtles to rest upon. state management is really going to be an intersting and I encourage you to post back here with your thoughts. strong consistency kind of gets you back to turtle-land pretty quickly, and free-for-all eventual turns out not be a good foundation. the sane middle ground seems to be monotonic eventual consistency, which I think is what CRDTs get you.
I wish more projects were conceived this way, instead of assuming that there is a kuberenetes cluster another database or two, and some message queues to lash it all together.
by convolvatron - This is neat, what does the actual throughput look like though?
Have been hacking on a wasm+webtransport stack for distributed simulation workers and found the ceiling on one connection/worker per machine pretty quick. Had to pin adapters/workers to cores to get the latency I was expecting, then needed to use dedicated tx/rx adapters to eliminate jitter. Some bullshit about interrupt scheduling
- It’s a really interesting question.
The real challenge is gating and reserving “slots” for downstream calls. If seed A on one node calls seed B on another, as it stands, Pollen holds that seed A instance up and waiting (with the memory overhead etc) until the response finds its way back across the cluster.
You can probably imagine how latencies then start impacting this (espesh when a node in USW is generating traffic that needs to ultimately land on my laptop in the UK), not to mention all of the contention from other nodes elsewhere generating load too.
In the demo, I see about 2500rps land on my laptop with 4k-5k generated across 4-5 nodes globally, but this is a multi hop scenario. If a call is only invoking a single, light WASM function, I see much higher throughout.
The project is in its infancy, no doubt I’ll have lots of fun figuring out how to optimise as it progresses!
In the first scenario above, memory seems to be the ceiling, in the latter, CPU.
(Edit: these numbers are really quite meaningless but I wanted to give something tangible)
by sambigeara - I suspect you have something cool, but I think if you told a clearer example story that solves a real-world problem on the homepage it might alleviate some questions I'm seeing (and also having) in the thread here!by dbalatero
- Yes, definitely.by sambigeara