Blueboat was originally named rusty-workers and used the Isolate model for workload isolation, similar to Cloudflare Workers. Later I changed to use process-based isolation because it seems that a shared-process multi-tenant system is overly complex for self-hosting users like myself to operate (automatically applying security patches within hours, sophisticated scheduling strategy to prevent ill-behaving applications from crashing the process, auditing each dependency for memory safety issues, etc.).
Blueboat is not yet optimized for global-scale operation but it is definitely the goal. Things not implemented include: custom TLS termination (which enables 0ms cold start), HTTP routing, and a single dashboard to operate the entire system.
Currently, the user needs to set up their own infrastructure for deploying Blueboat globally:
- Cross-region replicated S3-compatible storage for distributing code and config.
- Kafka instance at each region for log collection and task scheduling.
- A way to route traffic to a nearby location (usually DNS / Anycast).
First off, this is really cool. I have been hoping for something like this for a while.
Given that the Isolate model has already been developed, have you considered a hybrid isolate/process model, where workers created by a single user could be packed into a process via Isolates, but the process boundary protected different users from each other?
There are a metric tonne of use cases for enterprises to deploy their own serverless environments under their own control vs a cloud provider, for the very reason that only a fraction of compute is being processed at the edge vs VPC.
Doesn't this sort of... miss the entire point of serverless? It's an API framework, with syntax like serverless, but without the whole advantage of serverless: not having to manage individual servers, CDNs, networking, mirroring, etc.
So you end up with something like Flight PHP or Next.js's API routes, but still needs to be deployed and then manually managed and scaled.
Cloudflare Workers is innovative not because it's isolated or follows a particular syntax, but because they allow very fast and cheap functions to be run, globally, with zero maintenance on the customers' parts. Just write code and click save and it's available at data centers all around the world, instantly, for not even pennies.
Blueboat would be incredibly difficult to scale up and maintain across clusters. Correct me if I'm wrong, but there is no way to deploy this at a cost even remotely similar to what Cloudflare offers, since individual customers don't have their economies of scale (and peering agreements).
Not necessarily - I think the target audience is different.
If you are administering an internal datacenter in a company, then you can utilize this to offer a serverless env. to application developers in your company, and then those developers would benefits similar to that of AWS lambda/CF workers etc.
Someone will obviously have to manage servers, but in addition to it, it is also quite a bit of work to support orchestration of ephemeral functions, and a nice open source framework is definitely a huge help there.
That's a good point... you mean like enterprises with big IT teams who want to in-house Cloudflare Workers and run it on their own infrastructure?
That makes sense if they already have the network but not necessarily the easy to use APIs for serverless. Kinda a way to overlay new dev modalities onto old infrastructure, I suppose.
I thought the reason why Cloudflare Workers were great is that they utilize the many CDN points that Cloudflare owns. Or you can use Blueboat with say Fastly and achieve nearly the same thing?
Same, the cloudflare workers tagline is "Deploy serverless code instantly across the globe to give it exceptional performance, reliability, and scale." Maybe I missed something in the blueboat readme, but don't see how this deploys across the globe and scales automatically
How about 0ms cold starts?
Is this actually open source cloudflare workers or just open source serverless functions?
> Blueboat is not yet optimized for global-scale operation but it is definitely the goal. Things not implemented include: custom TLS termination (which enables 0ms cold start)
Cloudflare Workers have their own additional compelling value prop in operating on the edge. But I think something like this could offer a lot of value for a different use case:
In building complex SaaS apps, there's usually a constant flow of customer requests for custom features. Scripting, if managed very carefully [0], can provide an outlet for that and also allow people to glue together different features. AWS pushes people towards Lambda for customizing/gluing different AWS services.
A product could use AWS Lambda for its own scripting/glue, but that may end up being a little bit too free-form and depending on the use case Lambda cold start times may be unacceptable. So something like Blueboat could eventually be useful for running untrusted code to power customization of SaaS apps. This is especially the case if your service isn't marketed toward developers who can easily run their own Lambdas.
[0] Opening your app to scripting automatically exposes a huge API surface area which you'll likely have to support for a long time.
To be honest, how Cloudflare Workers work is a bit of a mystery to me as I've only done some very basic prototyping with the service (and not really focusing on the "edge" aspect of them), but it seems like the important "stuff" that makes them what they are is how they are deployed.
I am REALLY going to show my ignorance here, but is there some chance that the idea is these "workers" are intended to be deployed in the users browser for example, as actual service workers or something? i.e. is this more of a framework for creating service workers vs running in the "backend"?
Cloudflare workers != js workers. Kinda seems like that's what you are talking about at the end. In my understanding, Cloudflare workers, and "edge" stuff generally, are more like ephemeral server processes that can happen per request, which are backed by some kind of extensive infrastructure that cloudflare, aws, et al can provide.
Its not a server, but the promise a server will be there if someone hits that endpoint. Anything client side is not changed.
Serverless is compute execution, pure and OS-less.
The genius of Cloudflare Workers is that it couples the one place Cloudflare beats Amazon (their global ubiquity and edge deployment) into a product feature that a customer cares about.
The real genius of AWS at all wasn't "We can sell a thing people will buy" but rather "We can sell excess capacity on a thing we have to have, in order to offer {other, core product}."
And Cloudflare has to have network connectivity and minimal latency.
Cloudflare workers are executed on servers and quickly thrown away, they use APIs that make this clear as well, it has nothing to do with service workers. Could you expand a bit on you question?
I would be very interested if there was a decentralized version of Cloudflare Workers. Doing for compute what IPFS does for files with CF workers web like API (KV Store and Durable Objects).
As nikivi mentioned, the reason I use CF workers in my project is because of the global distribution of the workers. A user from Europe would have their worker request routed to the closest worker in CF network in Europe instead of a single standalone server on Blueboat which would be in Canada for example.
This renders Blueboat almost the same as having my own server at one location which sort of defeats the purpose imo.
I wonder if there's a use case for "distributed but not to the global internet as a whole"?
Maybe you could have a Blueboat Docker container running in each office for local office/intranet users? Or one in each of the datacenters your users VPN into? Some simple-ish dns based geographical or subnet routing for a handful of Blueboat instances in your various on-prem or local cloud zones should be manageable enough without need ing too much magic.
Not sure how to sensibly sync them all or centralise databases/storage for them though.
Blueboat was originally named rusty-workers and used the Isolate model for workload isolation, similar to Cloudflare Workers. Later I changed to use process-based isolation because it seems that a shared-process multi-tenant system is overly complex for self-hosting users like myself to operate (automatically applying security patches within hours, sophisticated scheduling strategy to prevent ill-behaving applications from crashing the process, auditing each dependency for memory safety issues, etc.).
Blueboat is not yet optimized for global-scale operation but it is definitely the goal. Things not implemented include: custom TLS termination (which enables 0ms cold start), HTTP routing, and a single dashboard to operate the entire system.
Currently, the user needs to set up their own infrastructure for deploying Blueboat globally:
- Cross-region replicated S3-compatible storage for distributing code and config.
- Kafka instance at each region for log collection and task scheduling.
- A way to route traffic to a nearby location (usually DNS / Anycast).
- Log aggregator (I use ClickHouse for this).