Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Migrating from Netlify to Cloudflare Workers Sites for 2x Performance (2020) (brianli.com)
101 points by indigodaddy on Feb 11, 2022 | hide | past | favorite | 65 comments


> Long story short, it turns out that Workers KV also works for storing static sites generated by Hugo, Gatsby, and other SSGs. This makes complete sense if you think about it. When you access a static site, you point your browser to a unique URL, and the server returns a pre-generated static HTML file. In this model, the URL is the “key” and the contents of the HTML file is the “value”. Thus, a static site can be stored in a key-value data store like Workers KV.

Why not just use Cloudflare's standard CDN? It makes no sense. By this logic, a file system is a perfect key value store, because ya know, the key is the full path and the file is the value.


> By this logic, a file system is a perfect key value store, because ya know, the key is the full path and the file is the value.

They're not wrong.

I'm still waiting for people to rediscover (fast)cgi as the "worker" interface.


cloudflare and others workers are almost literally fastcgi for javascript.

The problem is that node is not a good cgi engine.


They also have native Rust libraries - I just made a worker that's an SMS gateway for Canadian tide data, it was a really fun project.


On cloudflare I am almost sure that Rust is supported with compilation to WebAssembly.


Ah yes, thanks for pointing out that it's compiled to WASM... I meant in comparison to other languages like Python were it's compiled (transpiled?) to Javascript: https://developers.cloudflare.com/workers/platform/languages...

Using Python for Workers was weird, and it felt like you needed to be both a Python and JS expert to make it work.


It is indeed - but why is that relevant, or somehow undesirable?


It is not undesirable in the least, it was a response to "native" which for rust usually means "compiled to x86/arm/risc-v/etc


Rust and WASM with some combination of Container Orchestration through block-chained nodes which only come online when you are not using your phone and willing to power the transactions.

Cloudflare Workers and KV @ the Edge can do a lot to manage the control plane.


cloudflare workers run in an environment more like Chrome than node.


Cloudflare doesn't use Node for Workers.


exactly, I think that no "workers" platform uses node as it is not feasible to use node for fastcgi, so javascript fastcgi need to use alternative runtimes.

Since node is so dominant for serverside js, fastcgi with javascript is very uncommon.

PS: I do not know whether deno is better for fastcgi, but it is unlikely that it would be good enough.


What about Node makes it unsuitable for FastCGI? I always found it curious that Cloudflare Workers does not use Node, makes sense that there could be an underlying reason.


Node is not designed to be multi-tenant. That is, it is expected that a single Node.js process runs a single Node application. Additionally, Node does not attempt to provide any isolation of that application -- it is assumed that the application code is fully trusted.

So, in order to host Node apps on behalf of multiple customers, you must run multiple copies of Node.js as separate processes, and you must use some sort of secure containerization or VMs to isolate them from each other and from the system.

That in turn means there's a lot of overhead involved in running each application instance. To amortize that overhead, it's necessary for each instance to handle a large number of events, so that the per-event overhead is reasonable. So, you need to concentrate your traffic stream onto a small number of instances.

Workers, however, had the design goal that every application would run at every one of Cloudflare's hundreds of locations, in order to run as close to the end user as possible. That implies that there may be hundreds of instances of an app around the world, while each instance only handles traffic from a particular locality, which may be small. This means the setup overhead per instance had to be much less, and it had to be possible to run tens of thousands of live instances per machine, with the ability to quickly load from a library of millions on disk on-demand.

That's just not possible with containers, or even processes. But it is possible if you run lightweight V8 JavaScript instances -- called "isolates" -- all inside a single process.

This talk of mine goes into a lot more detail: https://www.infoq.com/presentations/cloudflare-v8/

(I'm the lead engineer for Workers.)


I believe I made a mistake, my previous comments are about CGI not FastCGI.

Also I am not an expert so I will not be able to prove anything, but I can try my best to express my opinions.

I do not think that node has any problems with FastCGI

So basically Node's start latency are too slow for CGI and FastCGI is bad for a worker platforms (or for any multitenant offering).

The reason is that cloudflare doesn't want to keep track which workers are for which customers and want to offer a clean slate environment for each request.

This either means spinning up new processes or using some other in-process isolation techniques. All javascript workers platforms I know use V8 isolates, which (I believe) node does not offer.

PS: I made also another mistake, it looks like deno offers a worker platform on V8 isolates. https://deno.com/deploy


This blogpost is from 2020. It seems that the author has since migrated the site to Vercel. It would be interesting to know why he has now chosen Vercel.

  $ dig +short brianli.com
  76.76.21.21
  
  $ whois 76.76.21.21 | grep OrgName  
  OrgName:        Vercel, Inc



TLDR; He dual hosted on CloudFlare & Vercel for redundancy, then CloudFlare had an outage. Doesn't say if he dropped CF altogether after that or what.


lol


Why use Cloudflare Workers for a Hugo site when they have Pages[1] that is specifically designed for static site build tools like Hugo, Jekyll, etc?

[1] https://developers.cloudflare.com/pages/framework-guides/dep...


This post was written in 2020 before Cloudflare Pages was launched.

Presumably Pages was created because they saw a lot of people using Workers and KV for this use case.


Exactly: if the author had waited another four months, they would have been able to save themselves a lot of trouble.


Seems CloudFlare is really becoming a jack of all trades, which is cool because they are more and more a [developer friendly] replacement for those big cloud providers.


> more and more a [developer friendly] replacement for those big cloud providers.

They ARE a big cloud provider.


Yeah they certainly are. But their services catalog only recently started to approach the: "hell, I can pull an entire commercial app just out of Cloudflare infra". There are still a few missing spots, but seems they'll close the gaps pretty soon. Excited to see.


Pages doesn't allow for direct deployments. Has to go via git repo + webhooks. We make static sites with our CMS and don't really want to integrate another thing into our workflow. Lots of CF and git API calls to automate the whole thing reliably. Thus, we're sticking with workers sites for now. Pages is an attractive offering, however.


Yeah, the totally managed deployment for Pages is great to get started, but not being able to run through our regular CI tool is a major bummer and has us also sticking with Worker sites.


It is possible to use the CI to build the website. My static site generator is written in haskell, so for me CI was the only option. Here's how (GHA is my CI):

* build the website and produce a GHA artifact packaged as a zip or somesuch;

* invoke Pages deploy hook API endpoint;

* within cloudflare pages run a (e.g. python) script to download the artifact, decompress it and place the resulting files in the correct output directory.

Ideally these kinds of gymnastics wouldn't be necessary and it would be possible to just run something like `cfpages deploy .` but it is not absolutely impossible to get something working, either.


Cloudflare Pages is hardcoded to GitHub (rather than just Git).


Does CF Pages support atomic deployments yet?


I don't know how much other FaaS have changed over the years but I really like CF Workers because it provides a local test server with live reload from my command line by simply running "wrangler dev" instead of pushing my code to a git repo or pasting changes into a web GUI.


The tradition of yearly blog host migration.

The blog is on Vercel now.

$ dig brianli.com @dns.google +short

76.76.21.21

(76.76.21.21 is Vercel's vanity IPv4 address)



> When you deploy a site using Cloudflare Workers Sites, the entire Cloudflare network, with over 150 data centers around the world, effectively becomes your origin server. In comparison, Netlify’s global CDN only conists of 6 locations for free users and 12 locations for enterprise plans.

I don't understand the value (or hype) of Netlify if Cloudflare has many PoP (Points of Presences) and is effectively way faster.

Netlify looking similarly like an expensive Heroku (more PoP only on enterprise plans) which doesn't seem like a global network to me.

Curious to know is anyone on Netlify considering moving or staying?


I've done some migrations and there's no perfect solution. Currently I'm split between netlify and vercel. The downsides I know for each:

- Netlify doesn't support Range headers which means you can't host clickonce installers for windows apps there

- Vercel doesn't support IPv6 which really is table stakes these days

- S3 + CloudFront are very low-level and the bandwidth is expensive

- CloudFlare supports targeted harassment so dropped for moral reasons


Can you please explicate your last point?

I don't know about first two but S3 or CloudFront is from Amazon which certainly have too many blemishes. Also, AFAIK Cloudflare is an infrastructure provider so, I wonder why would ethics come here.

Are we going to blame Google for making a browser that is used for hundreds of immoral things?

The only reason I think one will disdain over Cloudflare is due to monopoly. And, many argue they do some DDOS attack, but I have never seen any modicum of evidence.


They will go to the court to prevent revealing the identity and suing people who run websites organising persistent harassment, then keep hosting the website with that knowledge, like here: https://twitter.com/stealthygeek/status/1485731083534667779 (CW and all that)

Google browser is not in the same situation because the abusers are not direct, paying customers of Google and Google is not fighting to both keep them and hide their identity.

I understand why CF would want to keep their privacy position. But once they know about the abuse and don't drop those customers - they support the abuse.


What are the practical implications of not supporting IPv6? Does it make for longer loading times on devices that only natively have IPv6 which I believe includes most cellular devices?


Honestly not that many practical ones. It does improve the behaviour on ipv6 devices, but not significantly. I admit that for me it's more of a "we know it's happening, so I'd like to support companies not dragging their feet" position. It will hopefully come at some point: https://github.com/vercel/community/discussions/47


CloudFront is only more expensive for the first 400GB. Netlify's bandwidth is $0.20/GB after the 400GB mark compared to CloudFront's $0.085/GB.


Hey do you have any more information on cloudflare supporting targeted harassment? I had t heard of it.



can anyone explain "CloudFlare supports targeted harassment"?



Netlify is the best for static site hosting you can buy, cloudlflare page have unlimited data and free analytics but for in general, netlify have you cover whit more complete and mature implementations like cms


Netlify has way more deployment knobs and integrations, but Cloudflare Pages (and not Workers Sites) is quickly catching up in that regard.


Using Github Actions, Worker Sites and the CF worker, I think the level of customization is quite high without too much work.

For example, our hobby React SPA deploys on merge using Actions. It also has dynamic opengraph tags for pretty Discord embeds using CF worker.


One of the few grips I have with the more recent Cloudflare Pages is that the build times sometimes are 10x slower than Netlify.

If you need to perform a fast update or rollback, it does take its time.


The Pages team said on Twitter yesterday they're working on supporting pre built deploy. Not sure if it will be via drag and drop or CLI though.

Edit:

See this thread where I lamented on being forced to deploy from Github:

https://twitter.com/PierB/status/1491812373233119244


Especially, getting their support service is quite expensive. For a side-project or personal blog we can get away without support, but a commercial application wouldn't be advisable.


Purely anecdotical, but moving to almost anywhere from Netlify (free tier) results in a major performance boost. A simple static site of mine went from 300ms to 80ms when I eventually transferred it to a cheap ssd webhost. Sure, free service, but know the strings attached.


Also anecdotal but I've also had the unpleasant experience of them suspending an account on the free tier through some automated system (still not 100% why, they didn't respond to our email). Account suspension results in all your sites getting immediately taken down without warning, if you host DNS there that also gets taken down. I wasn't hosting anything critical there so not a huge deal for me but I will never recommend them for anything serious.


I host bunch static sites and have done benchmarks around TFTB and general network performance. Netlify is fast and most people won't notice much difference since the web page will be cached after the first visit.

Cloudflare is faster, you also get http3 over http2. Also Cloudflare has much better peering around the globe. When I do traceroute it's fewer hops compared to Netlify. I have tried vercel but haven't tested it extensively they use AWS and Cloudfront. If you use Github pages or Firebase hosting they both use Fastly. Fastly is also really good, in certain regions Fastly has better peering with ISP over Cloudflare. At Least where I am located Fastly is faster, but both Github pages and Firebase hosting doesn't have support for http3. On a fast network between h2 and h3 you won't find much difference. On a unstable or slow network h3 makes a big difference.


Anecdotal, but I'm looking into migrating one of my projects websites to Vercel from Netlify (which it seems like the author ultimately did).

Vercel deployed in 3 minutes and is 2-4x as fast to load for me: https://thelounge-github-io-jwd9o31su-mleiter.vercel.app/

versus 7 minutes building/deploying on netlify: https://deploy-preview-259--thelounge.netlify.app/


Nice - I'd be interested to hear about cases where sites that are not just static have been migrated over. Those really are the big use cases.

For example can you move a Next.js site that leverages Incremental Static Generation to Cloudflare. I wonder if ISR is even possible out of the box without you having to setup complicated caching logic anywhere besides Netlify and Vercel.


Where are the images stored in a setup like this?


You could use Cloudflare R2 if you already are on Cloudflare.


R2 doesn't exist yet: https://www.cloudflare.com/en-gb/r2-storage/ (And, more importantly, it's not very clear when it will exist.)


From the earnings call yesterday: "We're on track for R2 to progress to open beta in Q2 and then be generally available in the second half of 2022."


Oh, nice! Thanks for that tidbit, appreciate it :)

Edit: I'm an idiot, you work for Cloudflare, lol - I thought you were just particularly sharp-eyed


You can use Backblaze B2 with Cloudflare in front in the mean time.


R2 is something I look forward to.

I'm just imagining what would happen when would also provide managed Postgres in the same easy to handle and affordable manner as their other services.


For sure: Cloudflare is increasingly feeling like a better alternative to the 'bare cloud' providers, for most of my projects and I suspect also for the 99% of companies who are just building generic CRUD web/mobile app backends.

Customisability is AWS/GCP's strong suit, but as a corollary they don't make it nearly as easy to 'paint within the lines' - which is an odd UX stance to take when, by definition, 99% of your customers fall within the 99%. Personally I would have designed it to be 'simple by default, configurable if you need it', but far be it from me to say what's best.


Great post and tutorial. I wonder how performance would compare with an AWS S3 + CloudFront deployment.


Getting a 403 for some of the assets on that site




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: