This is great news. I'm really rooting for a successful trend of Serverless runtimes, mainly as a weapon against rising cloud deployment costs.<p>While the general trend today is to back the serverless environment with Javascript runtimes (Cloudflare runs its edge on top of V8, Netlify uses deno, most other serverless runtimes use nodejs), I'm optimistic that WebAssembly will take over this space eventually, for a bunch of reasons like:<p>1. Running a WASM engine on the cloud means, running user code with all security
controls, but with a fraction of the overhead of a container or nodejs environment. Even the existing Javascript runtimes, comes with WebAssembly execution support out of the box! which means these companies can launch support for WASM with minimal infra changes.<p>2.It unlocks the possibility of running a wide range of languages. So there’s no lock-in with
the language that the Serverless provider mandates.<p>3.Web pages that are as ancient as the early 90s are perfectly
rendered even today in the most modern browsers because the group behind
the web standards strive for backward compatibility. WebAssembly’s specifications are
driven by those same folks - which means WASM is the ultimate format for any form of
code to exist. Basically, it means a WASM binary is future proof by default.<p>I've published my (ranty) notes on why Serverless will eventually replace Kubernetes as the dominant software deployment technique, here - <a href="https://writer.zohopublic.com/writer/published/nqy9o87cf7aa789ba49419eac167d0c34cfcb" rel="nofollow">https://writer.zohopublic.com/writer/published/nqy9o87cf7aa7...</a>
Netlify for me is a prime example of a great company gone wrong by raising too much VC money.
The basic product of Netlify is a great one: build and host static sites without the need to mess with any of the tech stack. For us developer folk, this should be easy: run the build command of any static site generator and stick the results into an S3 bucket. And yet, something as simple as this became so popular with even developer companies (see Hashicorp’s quotes on Netlify).<p>This could have been a great story but then tons and tons of VC money came in and now you’d have to think of ways to make the valuation worth it and make the product sticky: so now we have edge Deno powered functions, lambda-esq applications, form embedded HTML and so much other features that are used by the long tail of their customer base while they changed their price to charge by git committees and have daily short downtimes of 1 to 5 mins for the past month (monitored by external services, as they wouldn’t reflect that in their status page).<p>Soon, they’ll sell the company to some corp like Akamai or similar “enterprise” outfit leaving us high and dry.<p>There is a lot of money in building businesses that do boring stuff that just makes peoples lives easier. But when you take VC money, you’d need to build a moat to fend off cloud providers from the bottom, capture the value for the top from developers and everything in between.
Netlify pricing has always been confusing to me, but I'm not entirely sure why. I guess I'm more accustomed to pay-as-you-go in this space (CFW) than tiered plans (Netlify bundles their features into starter/pro/business).<p>It seems that the free plan is 3M invocations/mo, starter is 15M/mo, and business is 150M/mo, but there aren't any ways to increase those limits (business says to contact them for higher limits).<p>Personally I'd prefer true pay-as-you-go without hard limits, even if it's a bit more expensive. To me the point is to sign-up-and-forget-it without having to worry if I'm within those limitations.
I would love to jump over to something like Vercel or Netlify Edge, but maddeningly none of these platforms give you control over the cache key. I have pages that are server-side rendered with Cache-Control headers, but because our visitors come with unique tracking params on the end of their URL (e.g. from Mailchimp or Branch), we would essentially have no cache hits.<p>It seems the only way to have control over this is to write your own Cloudflare Workers. There must be a better way? I can't imagine this is an infrequent problem for people at scale.
We’ve been Netlify paying customers for 2 years now. While I appreciate the new features, the core platform has been becoming unreliable in the past 6 months. We’ve had a decent amount of downtime.<p>I do not recommend them anymore. We will move somewhere else.<p>Almost every few days we get a report that some customers can’t access our site from where they are. Our US east engineers can confirm that their POP is down.<p>Netlify’s status page says everything is working, but in reality it’s not.<p>Netlify as a CDN has failed for us on its core promise.
Does anyone know how those compare to regular Netlify Functions, other than running on the edge nodes? The main difference I’ve found is that they have much stricter CPU time budgets, but it seems to me that the use cases overlap quite a bit.
I don't want edge functions, I want edge appliances. An edge function means I still have to run my own janky devops for that specific appliance. Edge IPv6 Appliances or Bust.
How does this compare to cloudflare workers?<p>CF always seems so cheap compared to alternatives, if you ever expect to scale beyond the developer plans.