5 ms·

Fastly focused exclusively on enterprise accounts and ceded the "entry level" developer market entirely to Cloudflare. Full on snobbishly. In the short run th

Fastly focused exclusively on enterprise accounts and ceded the "entry level" developer market entirely to Cloudflare. Full on snobbishly. In the short run that worked great as being best-in-class won big deals. In the long run that lost the mindshare fight and left 100M+/y in fat margin revenue off the table. And boy oh boy does it show in the market caps. As they bet the future on wasm-at-the-edge saving them from the crushing downward pressure of bandwidth pricing, having a compelling product for the "entry level"* developer market will be crucial to getting the mind and marketshare needed to hit revenue targets (eventually, not this year). Put simpler: fastly made itself overly exclusive and difficult to use, glitch is the polar opposite. Fastly's customer base is 45 year old vp's of infra/devops/sre, glitch's is 27 year old app/front-end dev/designers. There's more money in a deal with the former, there's more of the future in the latter. * I want to be clear, with ~20 years exp when I sit down to figure out a vue front end to my latest flask thingy I'm entry-level af in js/front-end land. Lowering barriers to entry, much like handicap accessibility, is usually a win for everyone.

stoicjumbotron 4y ago
But how would acquiring a developer focused platform give an edge to Fastly or improve their services?
- cagenut 4y ago
  The operating theory is that caching was only just the first/simplest/cheapest use of a globally distributed network of compute nodes (CDNs), but that as more and more transistors and clock cycles become available it incrementally makes sense to push more and more "workloads" out to the "edge" of the network, for latency benefits. Right now, the most immediate things that come after caching are stuff like input validation, auth validation, waf filtering, rate limiting, routing, decorating, error handling, load-balancing and traffic management type stuff. With WASM, and more specifically rust & javascript, IMHO the next step will be template rendering. After that maybe ML model inference? As long as transistors keep getting cheaper and the speed of light stays the same the opportunity space grows. Adopting and experimenting with all of that stuff will require developers fully embrace the CDN (oops, "edge") as part of their app architecture. A lot of places still treat the CDN as an ops/infra "config and forget" tool. More heroku for rust at the edge than varnish as a service.

stoicjumbotron 4y ago

But how would acquiring a developer focused platform give an edge to Fastly or improve their services?

cagenut 4y ago
The operating theory is that caching was only just the first/simplest/cheapest use of a globally distributed network of compute nodes (CDNs), but that as more and more transistors and clock cycles become available it incrementally makes sense to push more and more "workloads" out to the "edge" of the network, for latency benefits. Right now, the most immediate things that come after caching are stuff like input validation, auth validation, waf filtering, rate limiting, routing, decorating, error handling, load-balancing and traffic management type stuff. With WASM, and more specifically rust & javascript, IMHO the next step will be template rendering. After that maybe ML model inference? As long as transistors keep getting cheaper and the speed of light stays the same the opportunity space grows. Adopting and experimenting with all of that stuff will require developers fully embrace the CDN (oops, "edge") as part of their app architecture. A lot of places still treat the CDN as an ops/infra "config and forget" tool. More heroku for rust at the edge than varnish as a service.