Cloudflare (NET) recently announced “Workers Unbound,” a private Beta that adds to their existing Edge Computing offerings. The press release (https://blog.cloudflare.com/introducing-workers-unbound/ ) talks about extending CPU limits so more complicated tasks can be run at the edge, and lowering costs compared to the big cloud players. But, in other blog posts/articles, two other things got more of my attention:
-
A claimed “0 nanosecond cold startup time”
-
CEO Matthew Prince claiming: “The fact that we’ve been able to roll out a whole Zscaler competitor in almost no time is because of the fact that we had this platform and we could build on it ourselves.” (https://techcrunch.com/2020/07/27/cloudflare-launches-worker… )
1: Here’s the blog post on the startup time: https://blog.cloudflare.com/eliminating-cold-starts-with-clo… The startup time is actually 5ms, but if the request is over HTTPS (secure) AND the code to run is tied to the root URL, then Cloudflare cleverly starts up the process during the secure handshaking so by the time the code is ready to run (about 5 ms later) the process is ready. My problem with this, however, is that most real sites don’t run code at their root URLs. This would only work, for instance, at www.shopify.com and not at www.shopify.com/free-trial or any other child URL. Seems very limited.
Cloudflare is well aware of this limitation and says: “We plan to introduce more optimizations in the future that can preload specific paths.” It’ll be interesting to see what can be done, but remember that once the secure handshaking is done for the first page, it’s retained for all subsequent pages, so this startup time hiding can only be done for the first page. Any subsequent page that calls an API will have to wait the full startup time no matter what.
In comparison to Fastly, without such anticipatory tricks their startup time is 35 milli-seconds (compared with Cloudflare’s 5000 milli-seconds for non-root processes) and Fastly’s memory overhead is measured in kilo-bytes instead of Cloudflares mega-bytes. This came from Fastly developing its own runtime, whereas Cloudflare simply adopted Google’s V8 Engine that it developed for its Chrome browser. Less memory usage not only helps customers, btw, it helps Fastly as it means they don’t need as much hardware to service customers.
2: The creating “a whole ZScaler competitor in almost no time” is intriguing if true. This fits in with Cloudflare’s security focus. The product is called “Cloudflare for Teams,” and consists of Cloudflare Access and Cloudflare Gateway. I’m a bit confused as to the recent claim, however, because Access was first announced in 2018 and Gateway came from their acquisition of S2 Systems (https://www.darkreading.com/cloud/cloudflare-adds-new-endpoi… ).
Even taking Prince’s development claims with a grain of salt, it does appear that ZScaler’s moat may be filling in quickly. BTW, it’s ironic to talk about a ZScaler moat, since the whole “zero-trust” approach is to get rid of walls and moats and VPNs.