Here is a collection of my thoughts on two prominent Edge Computing companies, Fastly and Cloudflare.
TL:DWR (Too Long; Don’t Wanna Read):
• Serverless on the Edge is more limited than Central Computing Serverless, no matter which company is providing the service.
• Cloudflare has a language support advantage over Fastly since Fastly can’t support JavaScript.
• The more I look into it, the more convinced I am that Fastly’s startup time solution is superior to Cloudflare’s.
• There is a footrace between Cloudflare and Fastly for Edge Computing. Switching costs are high, so early wins are important. Cloudflare’s gains here with many new features being released while Fastly is still in Beta will be hard for Fastly to overcome.
• Fastly’s Signal Sciences acquisition plugs the hole in security that Fastly had, and with a top-notch solution for Edge Computing, and may have been the missing piece keeping Compute@Edge in Beta for so long.
• I believe that best of breed companies seek out other best of breed companies to partner with. Seeing that both Fastly and Signal Sciences have pushed DataDog integrations, including shared webinar sessions on YouTube. While Cloudflare and DataDog work together of course, they don’t seem to be at the same level.
• It’s too early for me to tell whether both Cloudflare and Fastly can win, or whether one will beat out the other. Right now I’d lean towards both doing well.
————
For those that want more details/background, read on at your own time-sink risk:
• Amazon actually has its own edge computing solution: Lambda@Edge. This is different than their standard (and industry first) serverless platform, Lambda. Amazon is one of those companies that appears to get into everything and then, depending on what sticks and what doesn’t, applies different levels of resources to further development. So, for instance, Lambda@Edge currently only supports two languages Node.js and Python (https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.htm… ) while the regular Lambda supports those plus JavaScript, Java, C#, Python, Go, Powershell, and Ruby. (https://dashbird.io/blog/most-effictient-lambda-language/ ).
The libraries and services available in each Amazon serverless solution are different, too, with Lambda@Edge having less. Reading the developer doc page for Lambda@Edge is also somewhat terrifying: https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope… It seems clear that Lambda@Edge is not a primetime AWS thing, at least just yet, unlike regular Lambda.
Language support is interesting. As these are platforms for developers, a major part of their success will depend on developers wanting to use them, and I believe that means supporting the languages developers already know. I think Cloudflare has a distinct advantage over Fastly by supporting JavaScript - every front-end web developer knows JavaScript, heck, for many developers it was the first language they learned. Fastly is working on supporting AssemblyScript, which is a “close relative” of TypeScript, which Microsoft developed to add static type definitions to JavaScript (https://www.fastly.com/blog/how-fastly-and-developer-communi… ). I haven’t used either of these JS-derived languages - it might be OK if Fastly can author a “AssemblyScript for JavaScript Developers” page that isn’t too long. I do think Fastly is constrained in being able to support full JavaScript by their Lucent-based solution, but that’s the price of really fast startup times. And, I personally dislike JS since there’s no compiler/lint checking, which means too emphasis on the test phase, which is a lousy way to develop, but obviously many developers disagree with me.
• We’ve had some discussion here on edge compute process startup time since both Fastly and Cloudflare are pushing that in their press releases. I honestly think Fastly has the better solution here, using Lucent instead of Chromium V-8. As an example, on 23June2020, a Cloudflare developer posted an issue with startup on CF’s community boards: https://community.cloudflare.com/t/fixed-cloudflare-workers-…
The fix eventually became using the new startup-in-the-background-during-SSL-handshaking feature Cloudflare has bragged about. If you have the time, read the whole thread I linked above. My take: Initial response from Cloudflare support was on 10July (Kenton Varda): “Unfortunately, using Wasm today – whether in Workers, or in the browser – generally requires putting some effort into dependency management to get code size down to a reasonable level…” and he further points out “The entire JavaScript standard library is built into V8 and therefore into the Workers Runtime” and then suggests using compile options to not include the standard libraries, but points out the difficulties that creates in actually using the damn thing. He then speculates about having separate modules calling each other or precompiling modules. Varda has a subsequent comment the next day that gets into more gory details. Nice to have the details, but the answer is not satisfying to the problem posted.
And then by 31July Varda finds a way to leverage the parallel startup thing CF had just announced. They get a 10x improvement! But, by 7Aug he writes: “I’m still not happy that large Wasm takes hundreds of milliseconds on first start. We should be able to get that down a lot further with code caching. Hoping to be able to work on that in the next few months.” Note that SSL handshaking is something like 50 ms, so the parallelization doesn’t reduce the effective startup time to zero. And it has other restrictions so it’s not universally applicable.
OK, that was a really deep technical dive, sorry. My point is that what Cloudflare is doing with respect to startup time is really just a bandaid. And to be fair, bandaids work for some things. But, right now I think that Fastly’s just plain old super-duper quick startup solution will work for more customers more easily.
• On Fastly and Signal Sciences, I regard the acquisition as Fastly filling the security hole in their solution. They got beat up on previous earnings calls about security. I even found this old Reddit post (https://www.reddit.com/r/devops/comments/e9cbms/any_opinions… ) that says: “Short answer is: Fastly if ALL you need is edge logic and caching because VCL is neat, but Cloudflare if you think you’ll need a WAF, SSO (cloudflare access), DNS, etc etc… Not that you can’t do it with Fastly but it’ll get expensive and complex real quick because you need to buy all those things from other vendors.”
The Reddit poster described themselves as “A Cloudflare turned Fastly customer because Cloudflare Workers wasn’t a thing and we needed to be able to run some routing and other things at the edge and VCL solved almost all of them. But we then wound up having to pay for other services and now with CF Workers I probably would’ve stayed with them.”
That was 8 months ago. My impression is that Fastly and Cloudflare are in a technology race against each other. In this situation, the poster initially went with Cloudflare, then switched to Fastly for the (about to be out-dated) VCL solution, then would rather have switched back to CloudFlare since Workers had what they needed, but now, maybe in the near future, might choose Fastly for Compute@Edge with Signal Sciences providing the WAF. But didn’t, due to switching costs.
I might further speculate that Fastly has been stuck in Beta with Compute@Edge precisely because its security offerings were not as robust as Cloudflare’s. In retrospect, it could be that Fastly was keeping it in Beta not because it wasn’t feature rich or not stable, but because the security needed to be production just wasn’t there (at least from Fastly, one could add security from another vendor on top, but that’s more complicated and maybe more expensive). So, now that Signal Sciences is getting acquired and then engineers can work together, perhaps they can now integrate the two solutions and then release.
• Cloudflare has a head start in edge computing with Workers already being out there. Fastly’s existing VCL support for limited Edge Computing can do some things (I assume the NY Times authentication is done with it), but their big splash is going to be when Compute@Edge gets out of Beta. They’re taking quite a while to get it out of Beta. I think that’s because the whole future of Fastly depends on it being a success. If Compute@Edge comes out and people say “Cloudflare is just as good and cheaper/easier,” then Fastly doesn’t grow like we need it to. So, in some ways, that Cloudflare just released a number of serverless edge computing features may be them trying to stay ahead of Fastly. The more customers Cloudflare snags today, the harder it will be for Fastly to steal them away even if their solution does turn out to be a bit better. So, perhaps one thing to watch is whether Fastly delays Compute@Edge or accelerates its release. Delays might mean they don’t think they’re enough better than Workers, acceleration could mean they’re ready or just that they can’t take risk losing the early sign-ups any longer.
Since a developer has to program to a specific Edge Computing platform and there are few standards, there is a natural resistance to switching between vendors even as new capabilities emerge in the other vendor. This tells me that this really is a footrace and the more sign-ups each company gets now the fewer, harder to get, customer conversions they’ll need to do later. This is different than switching between CDNs, which is pretty easy.
• Signal Sciences has a White Paper that you can download from their site (https://info.signalsciences.com/monolithic-to-modern-flexibl… ) that is interesting. The way WAFs (Web Application Firewalls) typically work is that you train them (“learning mode”) on your application to understand what your application does and doesn’t do. Signal Sciences claim this can take not just days, but weeks, and with Agile Development now finding its way to web applications, that’s unacceptable. What Signal Sciences did was to split the detection and decisioning phases apart from each other. Unfortunately, the paper doesn’t get into any of the details about how that works other than that the decisioning (pass or block) is made “holistically rather than as discrete events.” That sounds great, but it’s not informative to me at a technology level.
The other interesting part is when Signal Sciences gives percentages for their different deployment modes. They’re talking about how flexible their product is (WAF in the web server or WAF as a reverse-proxy or RASP [Runtime Application Self-Protection]), and then have a bar chart with percentages of use:
Nginx/Nginx++ (open source web server) is about 25%
Containers, Serverless is about 21%
Load Balancers is about 18%
Apache and RASPs are each about 12% (Apache is the original open source web server)
IIS is about 11% (Microsoft web server)
I suspect that Fastly is very/mostly interested in the Serverless deployment mode. Also interesting was that Signal Sciences customers were 71% on AWS. I don’t know who their competitors are, but I am curious why their customers use AWS more than the general population. Do they not work as well on Azure or GCP, are there other solutions for those platforms, or is there something about AWS customers in that they push the technology harder?
• Will there will be a single winner between Fastly and Cloudflare or can they both win? I don’t know. That they go after different size customers today maybe indicates that they both can win for their different markets, but you gotta believe that Cloudflare wants to snag some big fish and that Fastly wants to scale to many more customers. Fastly already has a self-service, no-salesperson model, so the only real snag there may be their low-end pricing (Cloudflare starts really cheap, as in free) and how good a developer you need to be to use Fastly. My concern here is that Fastly’s better tech may not be needed for many cases, and we all remember how a technically superior Beta did against a good enough VHS. At any rate, there doesn’t appear to be any reason why they both can’t do well with their different customer targets.