Blueboat, an open-source alternative to Cloudflare Workers | Hacker News Reader

Blueboat, an open-source alternative to Cloudflare Workers

github.com

226 pointsushakov24 comments

Hello HN! Author of Blueboat here.

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).

This this is awesome. Thank you for creating Blueboat.

Have you had any thoughts about how much rebuild it would take to support Deno javascript?

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.

Congrats on your milestone.

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?

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.

Not just old infrastructure, there are plenty of good reasons to run your own infrastructure beyond "that's what we've always done".

Edit: Good reasons not in the sense of "everyone should do it" but in the sense of "for some situations it's the right choice"

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?

https://workers.cloudflare.com/

See OP's top comment[0], specifically this part:

> 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)

[0]: https://news.ycombinator.com/item?id=29325570

Same (blue) boat here.

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 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 think cloudflare worker is basically like a browser tab

the only difference is that your browser is cloudflare and globally-distributed

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 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.

This is open source serverless functions that implement Web API functions.

Some distinctions:

1. Cloudflare Workers are Isolates, Blueboat are processes.

2. Cloudflare Workers are globally distributed and working in an anycast network, blueboat doesn't manage the network layer and are not distributed.

My recollection is that Cloudflare Workers uses Isolates, but also employs various process-based strategies. More detail here:

https://developers.cloudflare.com/workers/learning/security-...

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).

What would you say to be the main advantages over Deno Deploy[1] ?

[1] https://deno.com/deploy/docs

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.

Anyone else keep misreading the product name as "Bluebloat"?

Reply on news.ycombinator.com