Fastly had a dramatic quarter. After breaking $130 a share, in mid-October they pre-announced an expected miss for their Q3 revenue guidance, primarily attributable to revenue underperformance from their largest customer. This triggered a downward spiral for the stock to the $80’s prior to the actual earnings announcement on October 28th. The Q3 report largely met reduced expectations, but called into question the near term growth story as Q4 estimates appeared soft. The stock subsequently dropped into the $60 range, but has recovered since into the low $80’s as investors seem to maintain confidence in the long term story. Even with this volatility, the stock is up 286% in 2020.
Additionally, over the past several months, Fastly announced and completed the acquisition of Signal Sciences. Management highlighted the large opportunity for cross-sell to existing customers, adding rapid revenue growth and higher gross margin to the core business. They announced plans to combine product solutions for application and API security into a new offering called Secure@Edge. In mid-November, Fastly held their annual user conference, Altitude, which included a slew of product updates, customer talks and insights into next year’s roadmap.
In this blog post, I review the latest earnings report, the Signal Sciences acquisition and announcements from Altitude. I also revisit the competitive landscape and broader dynamics in the evolving edge compute, software-defined network and security markets. This information should help investors evaluate their own consideration for an investment in FSLY stock. At the end, I discuss application to my personal portfolio and investment plan going forward.
I have covered Fastly extensively in the past and will continue following the name. For new readers, you can review my prior posts, including the Signal Sciences acquisition, a primer on Fastly’s edge compute solution, past quarterly reviews and the original investment analysis. This also includes extensive coverage of Cloudflare (NET), which kicked off with my review of their Serverless Week back in July and initiation of a position.
Q3 Headline Financial Results
- Q3 Revenue of $70.6M, up 41.7% year/year. This compares to the consensus estimate of $71.3M, which would have represented growth of about 43.2%. However, this estimate is down from the company’s original Q3 revenue guidance for $73.5M to $75.5M, representing growth of 49.6% at the midpoint. As investors recall, Fastly pre-announced lower Q3 revenue guidance on Oct 14th, primarily due to usage drop-off from their largest customer. For comparison, Q2 Revenue growth was 62%. Revenue growth in Q3 2019 was 35%.
- Q3 Non-GAAP EPS was ($0.04) versus ($0.01) expected, representing a miss of $0.03. This compares to $0.02 in Q2 and ($0.09) in Q3 2019.
- Q3 Non-GAAP operating loss was ($4.2M), representing an operating margin of -5.9%. This compares to an operating loss of ($8.9M) in Q3 2019 for an operating margin of -17.9%. Q2 2020 operating margin was 2.4%. The change in operating margin in Q3 was due to revenue underperformance.
- Cash provided in operations was $27M in Q3 and capital expenditures were $14M, generating FCF of $13M in the quarter. This yields a FCF margin of 18%. In Q2, cash used in operations was $8.8M and capital expenditures were $3.1M, yielding a FCF margin of -16%. In Q3 2019, FCF was ($17.0M) for a FCF margin of -34.1%. Cash generated in operations was higher in Q3 due to a decrease in accounts receivable and timing of vendor payments.
- Q4 Revenue estimate of $80 – 84M, representing growth of 36 – 43% year/year. This compares to an adjusted analyst consensus of $82.3M, reflecting the impact of the pre-announced Q3 revenue estimate. This includes up to $8M of deferred revenue from Signal Sciences (adjusted for acquisition costs). If we back out the full $8M from the revenue estimate, this implies organic year/year growth of about 26%. However, it includes little revenue from their largest customer, which was presumably a component in the prior year quarter. For comparison, Q4 2019 revenue was $58.9M with growth of 44%. On the earnings call, leadership implied this estimate was conservative, given the uncertain environment and their challenges with the Q3 estimate.
- Q4 Non-GAAP EPS estimate of ($0.12) to ($0.08), as compared to ($0.02) expected. Q4 FY2019 EPS was ($0.10).
- Q4 estimated Non-GAAP operating loss of ($15.2M) to ($11.2M). In Q4 2019, Non-GAAP operating loss was ($9M).
- FY 2020 Revenue estimate of $288.2M – $292.2M, for growth of 44.7%. This is lowered from the prior estimate of $290-300M. This compares to the consensus revenue estimate of $291.3M for annualized growth of 45.3%. Revenue growth in 2019 was 38.7%.
- FY 2020 Non-GAAP EPS estimate of ($0.21) to ($0.17), versus analyst consensus estimate of ($0.06). The company had guided to ($0.06) to ($0.01) in Q2. FY 2019 Non-GAAP EPS was ($0.52).
- FY 2020 estimated Non-GAAP operating loss of ($23.1M) to ($19.1M). This is down from ($12M) to ($2M) set with the Q2 estimate. FY 2019 Non-GAAP operating loss was ($34M).
- Ended the quarter with cash, cash equivalents and marketable securities of $472M.
Other Performance Indicators
Adjusted EBITDA was $0.8M in Q3, up from ($5M) in Q2 2019. Adjusted EBITDA was $7M in Q2. This represented the second positive quarter for EBITDA and further underscores Fastly’s transition to profitability.
Non-GAAP gross margin was 59.8%, up 3.7% from 56.1% in Q3 2019. In Q2, gross margin was 61.7% and 57.6% in Q1. Fastly leadership attributes year/year improvements to efficiency in the operating model, as a consequence of their software-defined network and ability to leverage headcount through automation.
Continued improvement in operating expenses as a percentage of revenue by category, as compared to 2019. These numbers are Non-GAAP. GAAP measures exhibit a similar trend in terms of operational leverage improvement.
Expense Category | Q3 2020 | Q2 2020 | Q3 2019 |
R&D | 20% | 17% | 22% |
S&M | 27% | 24% | 33% |
G&A | 18% | 19% | 18% |
Dollar-Based Net Expansion Rate (DBNER) was 147% in Q3, which is up from 137% in Q2. Net Retention Rate (NRR) was 122% in Q3, down from 138% in Q2. DBNER does not include the impact of customer churn. NRR includes customer churn, but also includes the impact of billing overage. NRR, however, is based on revenue generated in the last month of the quarter, which in the case of Q3, experienced a significant drop from at least one large customer in September. To help smooth out this effect, Fastly published a new metric called Last Twelve Months NRR (LTM NRR). This was 141% in Q3, versus 136% in Q2. This reflects the change in spend over an entire 12 month period and includes the impact of churn.
Customer Activity
Fastly’s customer list represents the most progressive, innovative Internet businesses. These are generally large users of Fastly services, with a high average annual spend. These companies are often experiencing rapid growth themselves, which drives increases in spend year over year.
This expansion is evidenced by Fastly’s extremely high DBNER at 147%. This, of course, reflects customers that stay on the platform over the course of a year and excludes churn. DBNER provides what is probably the strongest indicator of the value of Fastly’s service to its customers. As Fastly extends its service offering deeper into customer infrastructure through edge compute and application security, this customer retention and expansion motion will continue.
In past investor presentations Fastly leadership has highlighted this expansion motion. At the KeyBanc analyst event in August, Fastly’s leadership described how most new customers start with a small usage allocation, as they validate performance and make operational adjustments. Then, from year 1 to 2, they typically scale up spend by 3x and increase by 40% year/year after that.
As part of the Q3 earnings report, we received updates on customer activity. Fastly ended Q3 with 2,047 total customers, adding 96 new ones over Q2. This represented sequential growth of 4.9% and annualized growth of 21.5%. Leadership highlighted the fact that this was the second highest absolute increase in customer count. This follows the 114 added in Q2 and 94 in Q1. Total customer adds are almost 2x the values each quarter in 2020, as compared to the prior year.
To get a sense for how this pace is progressing, we can look back 2 years. While sequential customer growth in Q3 stepped down from Q2, it is roughly inline with Q1. Additionally, comparing 2020 to 2019, we see a clear acceleration in quarterly customer adds. This level of total customer year/year growth falls in range, but on the lower side, as compared to some other software peers, like Twilio (at 21%), Datadog (at 38%), Elastic (at 37%) and competitor Cloudflare (at 25%).
Total Customer Counts
Q4 2018 = 1582
Q1 2019 = 1621 (+39) +2.4%
Q2 2019 = 1627 (+6) +0.3%
Q3 2019 = 1684 (+57) +3.4%
Q4 2019 = 1743 (+59) +3.4%
Q1 2020 = 1837 (+94) +5.1%
Q2 2020 = 1951 (+114) +5.8%
Q3 2020 = 2047 (+96) +4.9% (21.5% y/y)
Enterprise customer adds is exhibiting some stalling, which is worth trying to understand. As compared to 2019, we see almost the opposite effect so far in 2020 for enterprise customer adds relative to total customers. Fastly defines an enterprise customer as having spent over $100k in the past 12 months. In Q3, Fastly had a total of 313 enterprise customers, which was an increase of 9 over Q2 for growth of 3.0%. Q2 exhibited a similar trend, with only 7 additional enterprise customers over Q1 for sequential growth of 2.3%.
If we track this back to the beginning of 2019, we see that sequential growth was pretty good in 2019, and then dropped in 2020. There may be a few items that partially explain the slowdown. First, as noted above, the Fastly CEO pointed out that new customers generally expand their spend after 1-2 years of using the Fastly platform. Also, by definition, a new customer must be on the platform for 12 months before being considered for the enterprise customer label. Q2 2019 had the lowest number of new customer adds historically at just 6. It’s possible the general slowdown in customer adds in 2019 is impacting the rate of enterprise customer adds 12 months later in 2020.
Enterprise Custeomer Counts
Q1 2019 = 243 (+16) +6.6%
Q2 2019 = 262 (+19) +7.2%
Q3 2019 = 274 (+12) +4.4%
Q4 2019 = 288 (+14) +4.9%
Q1 2020 = 297 (+9) +3.0%
Q2 2020 = 304 (+7) +2.3%
Q3 2020 = 313 (+9) +3.0% (14.2% y/y)
The other partial explanation offered by the leadership in both Q2 and Q3 was the impact of COVID-19 on the usage spend by some customers in impacted verticals, like travel and hospitality. In these cases, the decrease in usage of their businesses in general may be causing some enterprise customers to drop below the $100k threshold, offsetting the growth of other customers past this spend level. As these industries recover, we may see a surge in enterprise customer counts in 2021.
Leadership didn’t provide detailed counts for customers moving up versus moving down. Fastly has many long-time customers in travel and hospitality, like Kayak, Airbnb, TripAdvisor, Ticketmaster and Hotel Tonight. These companies have reported significant reductions in usage year/year, over 80% in some cases.
Fastly clearly needs to ramp up customer acquisition and enterprise adds in particular. Arguably, Fastly’s sale motion is immature. They have talked in the past at analyst events about how little product marketing they did historically and that customers mostly came to them. In the Q3 shareholder letter, Fastly leadership highlighted the 29% increase in Sales and Marketing spend as being focused on driving future enterprise customer acquisition.
Sales and marketing expenses were $23 million in Q3 2020, representing 32% of revenue, up from $18 million, or 35% of revenue in Q3 2019. The increase was primarily driven by an increase in headcount and personnel-related costs to drive future enterprise customer acquisition growth, as well as to encourage further use of our platform by existing customers.
Fastly Q3 Shareholder Letter, October 2020
It’s also worth remembering that as part of the Q1 earnings report in May, Fastly announced the transition of its long-time EVP of Sales, Wolfgang Maasberg, out of the company. Wolfgang was to stay on through November. On that earnings call, Fastly’s CEO mentioned that he will be evaluating the executive leadership structure in this area going forward and will make appropriate strategic changes.
During the Needham Analyst Conference on November 17th, the Fastly CEO was asked for an update on this hire. His response indicated that the recruiting process is going well and should wrap up shortly. Having a new head of sales, presumably with enterprise experience, should help double-down on customer acquisition and upsell.
So we are at the – hopefully, the end of that process. We haven’t finalized yet, but we have some amazing candidates. I hope to have an announcement as soon as we have that done. But it’s been incredible the level of interest and excitement for the position.
Needham Virtual Conference, November 17, 2020
Enterprise customer growth rates for Fastly have lagged other software companies that report their counts with a similar threshold of $100k. Datadog grew enterprise customers by 52% year/year in Q3 and competitor Cloudflare grew their enterprise customer count by 63%. It is worth noting that these companies define enterprise customers differently. Cloudflare measures the customer’s spend for that quarter and multiplies by 4. Datadog takes the monthly recurring revenue for the last month of the quarter and multiplies by 12. These approaches allow the impact of new customer adds to manifest more quickly in enterprise customer counts. Regardless, Fastly’s enterprise customer growth has been slower comparatively in 2020 and needs to accelerate.
Fastly’s high DBNER also drove up average enterprise customer spend (measured over a trailing 12 month period). In Q3, this average spend increased to $753k, up from $716k in Q2 and $642k in Q1. In Q3 2019, this value was $575k, representing annualized growth of 31%. This further underscores the strong expansion motion for existing customers.
Enterprise customer spend made up 88% of total trailing 12 month revenue. This value stayed the same as in both Q2 and Q1. Fastly has issues with customer concentration, as evidenced by the impact of its largest customer (which we know is TikTok). This overall percentage of enterprise customer spend isn’t terribly out of line, as peer software company Datadog generates 75% of ARR from enterprise customers.
It is worth noting that Fastly services small and medium sized businesses through their partnerships with large web site aggregators, referred to as platform partners. These include Shopify, Wix and Adobe Magento for web sites and GitHub for developers. By referring smaller entities to these aggregators, Fastly is able to increase their business with these large partners (who also consume Fastly services) and obviate the need to maintain a sales/service function to support smaller customers.
This partially explains why Fastly’s overall customer count will not approach Cloudflare’s large total (cross 100k in Q3), as Fastly pushes small businesses towards these platform partners (or they land on Cloudflare). There are advantages and disadvantages to Fastly’s focus on larger companies. Advantages are efficiency in customer service and better platform utilization (cache hit rates) by serving fewer customers. Disadvantages are missing out on small players that eventually grow into big players. Also, a more diverse customer base reduces the volatility of customer concentration or enterprise specific spend reductions.
In Q3, Fastly landed new business across multiple verticals including e-commerce, media (live streaming and VOD), Fintech and Edtech. Some examples mentioned in the Shareholder Letter and earnings call were:
- One of the largest sportswear and footwear retailers in the U.S. migrated to Fastly during Q3. They are leveraging several services, including the security offerings to enhance application security for its customers, and Image Optimization to deliver the best image size for a user’s device. The customer is also building application logic to be applied at the edge, currently using VCL and presumably Compute@Edge in the future. They value the ability to deploy changes in real-time, without requiring support or partner services. Fastly didn’t disclose the name of this customer. Based on the attendee list at their Altitude user conference, it might be Under Armor or Footlocker.
- A large North American automotive parts retail chain is accelerating their digital transformation. They are adopting Fastly’s programmable application logic, adding Image Optimization and applying Web Application Firewall to their online experience at the edge of the network. Fastly is also helping with their cloud migration and applying more granular control over content delivery and security policies. Based on the attendee list at Altitude, this could be Discount Tire.
- Fastly continues to grow in the media and entertainment vertical, both domestically and internationally. They are winning meaningful commitments from large, U.S. and European media conglomerates. Their media delivery continues to differentiate by providing consistent performance at large scale.
- Momentum in the high-tech vertical continues, especially in FinTech and EdTech. Fastly’s edge-cloud platform demonstrates significant value to a wide array of customers, ranging from securing and accelerating the delivery of one of the world’s largest payment processors (likely Stripe or PayPal) to a multinational corporate learning platform.
- Heading into Q4, Fastly leadership highlighted several other significant customer wins, which are presumably on-boarding this quarter:
- A global leader in telecommunications, media and entertainment (possibly Warner Media)
- A leading EdTech software and solutions company widely used by higher education, K-12, business, and government clients around the world
- One of the largest American multinational retail companies (possibly Target, which had a number of attendees at Altitude)
- In Q3, Fastly leadership highlighted meaningful customer expansion from some of the best of the Web, including one of the largest U.S. general merchandise retailers, one of the largest American multinational consumer-to-consumer and business-to-consumer online marketplaces, and one of the most popular international ad-technology providers.
In September, Fastly announced a more formal partnership with the Google Cloud Platform (GCP). As part of it, Fastly will be available as a private listing on the Google Cloud Marketplace. This allows GCP customers to purchase Fastly services directly through the Marketplace using committed Google Cloud spend. Fastly is the first edge cloud content delivery solution to be offered on the Marketplace. This should result in easier on-boarding of new customers from the Google Cloud to Fastly, as the sign-up process is automated and billing is unified with the customer’s existing Google Cloud spend.
TikTok Exposure
During the Q2 earnings call on August 5th, Fastly management disclosed that their largest customer (TikTok) generated 12% of Fastly’s revenue for the first 6 months of the year. About half of this revenue is associated with usage in the U.S. Assuming a $300M revenue run rate for 2020, this would have represented about $36M in total annual revenue globally and was likely continuing to grow. At the time, the U.S. government was considering an outright ban of TikTok in the U.S. after September 15, so this revenue was highlighted as being at risk.
On October 14, Fastly pre-announced that Q3 revenue would be in the range of $70-71M, below their previous target for $73.5 – $75.5M. This was attributed to a significant revenue reduction for TikTok, due to the uncertain geopolitical environment. Subsequently, we learned that TikTok was concerned about a filing from the U.S. government that included a prohibition for any U.S. technology provider, including CDNs, to work with TikTok. It’s likely that TikTok dropped Fastly usage in late August or early September and dispersed CDN traffic amongst many providers in order to mitigate immediate risk to their operations.
For the low end of Q4 revenue guidance, Fastly leadership assumed that TikTok traffic remained at this reduced level only through October. Assuming TikTok generated reasonable revenue in Q4 2019, this would partially account for the lower organic growth projection in Q4 2020. Fastly is holding capacity open for TikTok to consume if they are able to ramp traffic back up. Given the possible changes in political priorities with an administration change, this action against TikTok may be postponed or dropped. It’s not clear at this point if TikTok will ramp traffic back up on Fastly, or pursue alternatives. However, it is worth noting that Fastly’s Q4 guidance did not include any TikTok contribution beyond early November. Given that there has been no ban on TikTok in the U.S. as of late November, any continued usage at the even the previous reduced levels would represent upside to Q4 guidance.
I won’t try to project the impact of TikTok or the potential path forward. I think the whole situation simply highlights Fastly’s high customer concentration at the enterprise level, which is something they need to work through. This is the same issue that Twilio faced following their IPO with Uber and now have reached the point where their Top 10 customers only contribute 14% of revenue. I would expect Fastly to achieve a similar distribution over time.
The main take-away for me regarding TikTok is an appreciation for the amount of traffic that they trusted on the Fastly network. If Fastly’s competitive position were brittle, TikTok wouldn’t have relied on them so heavily. This ramp up on Fastly happened while competitive offerings from incumbents like Akamai, Limelight and the cloud vendors were fully available at scale. Fastly would not be competing for this traffic based on price, so one can only conclude it was due to performance.
While TikTok was able to move off of Fastly’s services quickly, the impetus for doing so appears to have been an external cause, versus an issue with quality of service or pricing. Some investors have concluded this means Fastly’s content delivery services have no moat. I would argue that performance, as measured by cache hit rates, update times and programmability, is the moat. For a technology organization that biases towards optimizing the customer experience at all costs, these types of performance metrics matter. From personal experience, I can share that having to wait minutes for content or network routing changes to propagate globally is not acceptable if your company’s service is primarily delivered over the Internet. Some TikTok users have complained on Twitter that the service seems laggy, since reducing usage of Fastly. This is purely speculative and anecdotal, but seems to reinforce the point.
Regarding the ability for TikTok to execute the switch quickly, I assert that almost any technology service in a software stack could be changed out with enough pressure applied. Some investors seem to think that changing CDN providers is as easy as flipping a switch. For certain types of bulk delivery in which the content changes infrequently (like OTT video or game binaries), I agree that migrating to a new CDN is likely a configuration setting.
However, for a service in which the content is getting updated frequently (news sites, UGC video, social, e-commerce, etc.), the change of CDN would be more involved. This is because the engineering team would have to deal with cache invalidation. In the simplest case, imagine you are running a news site and an editor publishes an article. Your CMS would push the article/images to your origin storage and the web site would update to include links to the new content. The CDN provider would pick up the new content from origin and cache it for a fixed period of time defined by your TTL setting. But, what happens if the editor noticed a typo and needed to change out the article, or wanted to swap an image? In that case, the CMS would update the content at origin, but would also need to tell the CDN to invalidate its cached version of the content.
Handling cache invalidation requires coding to the CDN provider’s APIs, among other tasks. This involves some work and significant testing. Additional tasks associated with changing out a CDN would include updates to the CI/CD pipeline for code deployments and reconfiguring observability tools that monitor content delivery. Some customer demos from the Altitude conference, like Viacom CBS and USA Today, reflected even deeper levels of integration at the software infrastructure level. Additionally, as Fastly solutions move further down the software stack (like edge compute), switching costs will be even higher.
Analyst Reactions
Fastly received a number of downgrades and price target reductions over the course of October. These coincided with the pre-announcement of Q3 Earnings on October 14 and then the actual earnings report on October 28. In all cases, analysts lowered their price target for FSLY shares. Only two out of 8 analysts maintained a Buy rating equivalent.
The average price target for these updates is $78, representing a 14% increase from the closing price of $68.38 on October 29th and a 6% decrease from the current share price around $83.
Date | Analyst | Rating | Price Target |
10/29 | Craig Hallum | Hold | Lowered from $85 to $80 |
10/29 | Credit Suisse | Outperform | Lowered from $100 to $90 |
10/29 | B of A | Underperform | Lowered from $90 to $75 |
10/29 | Pritchard Cap | Sell | Lowered from $58 to $47 |
10/23 | Piper Sandler | Underweight | Lowered from $84 to $65 |
10/15 | DA Davidson | Buy | Lowered from $115 to $105 |
10/15 | Baird | Neutral | Lowered from $105 to $85 |
10/15 | Stifel | Hold | Lowered from $98 to $77 |
Following the Q3 earnings results, Credit Suisse maintained the highest price target with a Buy rating. Analyst Brad Zelnick provided the following commentary.
Credit Suisse analyst Brad Zelnick lowered the firm’s price target on Fastly to $90 from $100 given estimate revisions, which prudently exclude any future revenue from TikTok beyond Q4. The analyst notes that Fastly posted Q3 revenue results in line with its negative preannouncement and provided clarity on overhanging issues. Ultimately, Zelnick remains constructive on Fastly’s differentiation, and incrementally so in adding Signal Sciences to its platform. He keeps an Outperform rating on the shares.
Thefly.com, October 29, 2020
Product Development Activity
The majority of Fastly’s product development has been focused on their Compute@Edge product, which was in private beta with a set of existing customers for the majority of 2020. At the Altitude user conference, the leadership team revealed that 60 customers participated in the beta program and provided valuable feedback applied to real-world use cases.
With the Q3 earnings report, Fastly announced that their globally distributed, serverless compute environment Compute@Edge, has moved out of beta and into a limited availability status. This reflects the fact that a set of customers are now running production loads on the platform. As part of their press release and tidbits revealed during the user conference, Fastly referenced several of these customers, including Vox Media, Loveholidays, HashiCorp, MediaPro, Mux and Perimeter X. There may be other customers on Compute@Edge, who did not wish to be disclosed publicly for competitive reasons (this is common for large customers of software vendors).
Fastly leadership described a number of initial use cases for Compute@Edge. These include the following:
- Waiting Room Tokens. For high-demand events, the customer can create a waiting room and issue tokens to users for access. These control entry to the event. Sports video streamer MediaPro was referenced as using this capability.
- Authentication. For content or experiences that require user login, this authentication can be performed at the edge. Authentication has been a common use case for existing Fastly customers using VCL, like the New York Times.
- Dynamic Personalization. Once the app visitor has been authenticated, the site operator knows what content they can access and has a basic set of preferences available. Logic can be located at the edge to select from cached content (also at the edge) to compose a customized view for each user without requiring a full round trip back to origin. This would work well for content rich sites.
- Content Stitching. Similar to dynamic personalization, the template of a web page can be dynamically populated by making calls to cached content and third party services. A common use case is to stitch together personalized content with ad delivery. Vox Media discussed this use case in the Altitude conference.
- Full Microservices. This involves building an entire app experience or stand-alone service to run at the edge. One example is an A/B testing service. As new visitors come to a site, they can be randomly assigned to a user testing bucket and served the content appropriate to that multivariate test. U.K. travel service Loveholidays referenced building a full A/B testing service on Compute@Edge.
- Media Manipulation / Manifest File Update. For a new visitor to a content service, the provider can determine which type of media file to deliver based on the user’s device (desktop, phone, pad, etc.). This decision can be made at the edge, which eliminates a call back to origin and reduces the amount of content that needs to be cached in each PoP. Mux discussed this use case for Compute@Edge at the Altitude conference.
Interestingly, during the beta period for Compute@Edge, Fastly maintained a sign-up form on their site, which allowed potential customers to register interest in participating in the private beta. Once they switched to Limited Availability, this sign-up form was disabled with the message that “Due to overwhelming interest in Compute@Edge, our limited availability program is at maximum capacity.” This represents a positive signal for customer demand for the new offering.
In addition to moving Compute@Edge to Limited Availability, Fastly announced several enhancements to the platform to improve the developer experience in Q3.
- Terraform API Support: This allows developers to configure Fastly’s Compute@Edge platform through code, in the same way that they manage the rest of their infrastructure. Coding configuration allows the provisioning of resources, deployments and other changes to all be automated. Terraform is a popular solution for infrastructure management provided by HashiCorp. Further, this automates the CI/CD pipeline, so that application releases with code on Compute@Edge can be executed through automation.
- Command Line Interface (CLI): A new CLI (command line interface) for developers to use to program and deploy applications on the Compute@Edge platform. A CLI supplements the common UI driven Admin tooling, and is often the preferred way to manage infrastructure by most DevOps personnel.
- Expanded Language Support: Compute@Edge added support for AssemblyScript in beta. AssemblyScript is a sibling of JavaScript, stripped down for performance and security. For developers comfortable with JavaScript, AssemblyScript would be fairly straightforward to learn. JavaScript is the most popular language for developers, according to a recent StackOverflow survey.
- Observability Extension: Application stats and errors are now available to developers through both the user interface and programmatically via API. This allows developers to integrate observability of Compute@Edge into their other tooling for application monitoring.
Looking forward, one of the challenges for Compute@Edge will be to gain broad developer adoption. These types of usability feature enhancements will be important to ensure that developers don’t conclude that the performance advantages over competitive solutions aren’t overcome by the difficulty of using the platform. This encompasses tooling, CI/CD integration, observability and languages.
For languages in particular, because Fastly chose to build their own runtime in Lucet (versus leveraging the V8 engine, like all competitors), Compute@Edge will only run languages that can be compiled to produce a WebAssembly binary. This greatly reduces the language set available (at least currently), relative to the V8 engine. The V8 engine can also run JavaScript, which expands the set of candidate languages greatly, as many popular ones have an available compiler to JavaScript. Fastly’s Chief Product Architect explained this design choice for Compute@Edge in a past blog post.
In the Altitude user conference, Fastly’s CTO was optimistic that language support for WebAssembly will continue to expand in the future. In fact, when asked a question about the 5 year vision for Compute@Edge, he felt that all popular languages in the future will support WebAssembly as a deployment target. Having to make a distinction around supported languages for Compute@Edge will hopefully be a moot point in the future.
Network Expansion and PoP Design
In addition to launching Compute@Edge, Fastly delivered a few other infrastructure enhancements during the quarter. They expanded their global network capacity to 106TB. This is nearly double the capacity of 56TB from Q3 2019. While the incremental expansion from Q2 to Q3 was just 6TB, I think Fastly has more than enough capacity at this point. Due to travel restrictions, they focused on increasing the capacity of existing PoPs in Q3, versus launching new ones. This actually underscored Fastly’s continued focus on improving the performance of larger and more concentrated PoPs.
At the Altitude user conference, Fastly’s founder and Chief Architect (Artur Bergman) talked about this expansion of capacity at existing PoPs. As I have discussed previously, Fastly’s underlying architectural design focuses on maximizing the cache hit rate of its regional PoPs, versus launching more and more geographically granular PoPs. At Altitude, Artur introduced the concept of a Metro PoP, which adds more CPU and storage to existing PoPs in high density population areas.
In this case, Fastly is combining the power of two regional PoPs, one in Los Angeles and one in Orange County, CA, into a single “Metro PoP” that provides service to the greater Los Angeles area. The reason this is important is that it almost doubles the cache capacity and available bandwidth for content delivery, which will increase the cache hit rate even as Fastly grows. For servicing user requests from that metro area, a cache miss generates many times more latency than traveling 50 miles to service the request from a regional PoP. This is why Fastly’s focus on maximizing cache hit rates from fewer PoPs will deliver better performance than legacy providers that have deployed thousands of smaller PoPs.
Signal Sciences
In addition to highlighting Compute@Edge in the Q3 earnings report, Fastly leadership also provided an update on Secure@Edge. As investors will recall, Fastly announced their intent to acquire Signal Sciences on August 27 and closed the transaction on October 1. Signal Sciences provides a leading suite of products that focuses on web application and API security. The plan is to combine their capabilities with existing security solutions from Fastly into a consolidated application security solution called Secure@Edge. I covered the acquisition extensively in a prior post. I won’t rehash all the details of the acquisition here – interested readers can review that coverage.
The Fastly leadership team provided an update on the integration of the two company’s platforms. They also included a brief overview of the product roadmap for 2021 as part of the Altitude conference. What is exciting about the integration of the two product suites is the intent to build Secure@Edge capabilities on top of the Compute@Edge platform. This provides two benefits. First, it ensures that these security capabilities are ingrained into any applications built on Compute@Edge automatically. Second, it provides a “dog fooding” of Compute@Edge by Fastly’s engineering team.
We are well underway on integrating the application security capabilities from Signal Sciences into a unified new product offering called Secure@Edge. This will allow us to fulfill our mission of giving developers more power over the security of their applications and APIs, at the edge of the network. We are very optimistic about the immediate opportunities for cross-sell and upsell to both of our customer bases. There is great enthusiasm for the Signal Sciences solutions set from our customers, with an immediate interest in bot protection use cases. We are also seeing great interest from Signal Science customers to use the Fastly platform to ease and speed deployment of security solutions.
Fastly Q3 shareholder letter, October 2020
As mentioned, Fastly customers appear interested in getting access to the new security offering. During the Altitude user conference, Signal Sciences and Fastly leadership jointly held a fireside chat discussion on the topic “Why Fastly and Signal Sciences are building a unified security platform for secure DevOps.” In the session, the combined team discussed the Signal Sciences offering and the opportunities presented in combining with Fastly. The conference UI included a live chat stream, which allowed participants to actively post questions and comments. I recorded the following comments, reflecting interest by customers in getting access to the new security capabilities:
- Neiman Marcus: Interested in rate limiting and bot mitigation
- Filestack: Also looking forward to rate limiting feature
- ActBlue: Commented that rate limiting has already been useful (presumably an existing Signal Sciences customer).
- Other customers expressing interest in the new application and API security features: Meetup, USAA, 1800Flowers, Northfield IT.
These are just informal comments posted in the chat channel. There is likely more interest from other customers who didn’t bother posting. This initial interest is important as Fastly leadership justified the acquisition by anticipating that the cross-sell opportunity would be large. Primarily this applies to selling Secure@Edge to Fastly’s 2,000 customers. At time of acquisition, only about 18 of Fastly’s enterprise customers were shared with Signal Sciences. When the Signal Sciences CEO was describing how their WAF solution performs tuning of blocking logic automatically, the CTO of one of Fastly’s customers commented “Bless you for dealing with tuning.”
As another highlight of Signal Sciences’ capabilities, Gartner recognized Signal Sciences’ WAF solution as a Visionary their Magic Quadrant for Web Application Firewalls, published in October. This was the second year in a row that Signal Sciences received this recognition. Signal Sciences’ WAF protects more than 40,000 cloud-native, legacy, and serverless applications, processing over a trillion production requests per month.
Gartner rated Signal Sciences high on the product completeness axis and low on execution. Low execution is likely acknowledgement of their start-up status and small size, relative to competitive solutions offered by publicly traded companies. Gartner did comment that Signal Sciences is “gaining momentum”.
Strengths in Signal Sciences’ offering were ease of use, its extensive rules engine and flexible architecture. Gartner notes that Signal Sciences is often in the shortlist for WAF vendors with customers in North America, reflecting rapid penetration for such a young company. Signal Sciences customers provide extremely positive feedback and contrast the solution with prior experiences with the resource-demanding offerings of legacy competitors.
Gartner raised a number of cautions regarding the Signal Sciences offering as well. Highlights include challenges with automating agent updates, English language only customer support and documentation, lack of a physical device offering (important for hybrid deployments) and limited detection of advanced threats. These deficiencies will hopefully be addressed as part of a larger organization and as part of the integration with Fastly’s solutions.
Fastly competitor Akamai is placed in the Leaders quadrant, as a nod to the maturity and breadth of their offering. Gartner calls out Akamai’s broad coverage of attack type, including their recent move into the client-side with Page Integrity Manager. They also highlight Akamai’s depth in DDOS protection, spanning all network layers, which is arguably not a capability of Signal Sciences (but pairs nicely with Fastly’s DDOS solution). Akamai also has a global presence and a well-staffed Security Operations Center (SOC) available 24/7. Challenges for Akamai revolve around cost, programmatic access to WAF rules through an API and need for professional services for set up.
Cloudflare is in the Challengers quadrant. Gartner noted that they see Cloudflare in more enterprise deals as a considered vendor, but that they still wrestle with the perception of catering to SMB. Gartner recognized the breadth of Cloudflare’s offering both in physical presence internationally and their product coverage including CDN, enterprise access and serverless. They also noted the rapid product release pace, positive customer feedback and depth of WAF rule testing. Challenges included full API security, quality of enterprise support and lack of a few WAF features around account management, fraud detection and report automation.
While it is sometimes difficult to draw definitive conclusions about future success or an investment thesis from Gartner reports, they are helpful directionally. In this case, seeing Signal Sciences listed in the same report as several larger competitors is a positive sign.
Altitude User Conference
Fastly held their annual user conference, Altitude, on November 10 -12. The event was conducted virtually with about 5 hours of scheduled sessions. The agenda moved quickly, with no session lastly more than 20 minutes. It spanned product updates, strategic vision and customer demos. Fastly scheduled one event for EMEA on the 10th and one for North America on the 12th. Several sessions were repeated between the two events, but many of the customer demos varied based on whether the customer organization was based in the U.S. or Europe. I attended the North America event on the 12th.
Customer sessions across both events spanned different product categories, including content delivery, streaming and edge compute. One session provided early feedback from Compute@Edge beta customers Vox Media, Mux and Perimeter X. Customer demos in the North America event included presentations from Gannett (USA Today), PayPal, Yottaa, CBS, Chartbeat, TED, Ticketmaster, Financial Times, Adorama, Grubhub and MIT.
The North America event had over 850 registered attendees, mostly from customer organizations. Of these, I noted the following companies represented with at least one attendee, and in most cases several participants. I will paste the list below of brands I recognized. Of course, presence of a name here doesn’t imply they are a customer, nor does lack of a name imply a customer has churned.
CBS Red Ventures Cheddar
Pantheon Etsy Vroom
Affirm MLB Vimeo
Google Ask Media Under Armor
Taboola Amazon IGN
Adobe Gannett Brandfolder
Jetblue Bird Foursquare
Warner Media PayPal Giphy
Viacom Fox USAA
Discount Tire Business Insider CNN / Warner Media
Expedia Live Nation Grubhub
Build.com GoodRx WeWork
Disney Neiman Marcus Reddit
Target Twitch NBC Universal
New York Times Scribd Shopify
NFL Pinterest WWE
Harry's Casper Oracle (ISV Ecosystem)
Ticketmaster Salesforce Anaplan
1800flowers New Relic Policygenius
Slate Conde Naste TheRealreal
Bloomberg Bleacher Report CBS Sports
Fidelity Dish Network Footlocker
Hulu WW Rakuten
Carvana Kickstarter TED
Cisco Spotify NCR
Barstool Sports FuboTV ActBlue
Wikihow
Of the customer demos, here were a few highlights:
- PayPal. Presentation by the Team Lead for Edge Engineering. The title by itself was interesting to me, indicating that large Internet companies would dedicate a team to edge development. This reflects the important position edge infrastructure is assuming in an engineering organization. I haven’t seen this in the past. PayPal currently uses several products from Fastly including the origin service, shielding, content delivery and WAF. They like the programmability of the edge solution and real-time nature of updates. Going forward, they are looking forward to next-gen features from Fastly and the Image Optimizer service.
- USA Today. Ran their Election 2020 dashboards on Fastly. They built a sophisticated service that supports smart caching at a granular level. Every visual element of the national, state and local election summaries are cached, and can be programmatically updated on every new vote count update. They even put Fastly caching in front of a Google spreadsheet that allowed editors to enter commentary for each election result. Their cache hit ratio was over 90% throughout the election results period.
- Yottaa. Runs an e-commerce platform utilized by retailers like Ralph Lauren. Delivers 100M’s of pageviews a month through Fastly. By moving their content delivery to Fastly, experienced a 20-60% gain in performance and some retailers drove a 20% increase in business.
- Viacom CBS. Engineering team that provides the streaming platform for CBS Sports and other CBS brands. Built an internal system, Propeller, to determine which CDN provider for each customer on the fly. They use two other CDN’s, in addition to Fastly, but Fastly serves as the origin for the others and plays the pivotal role. This was the configuration used to stream the Superbowl.
- MIT. Uses Fastly to deliver their Open Courseware solution. This service consists of 2,400 courses and has 500k subscribers. They use Fastly’s Image Optimizer and Shielding feature. When they moved content delivery to Fastly, annual delivery costs reduced by 30%. This was because content was getting served from cache versus cost of delivery from origin (and was faster). Also, delivery from Fastly improved their data collection of user activity by geo location.
The other insightful session covered the product roadmap. This was led by Fastly’s heads of engineering and product. The session provided a brief overview of the planned product roadmap going into 2021. It started with Compute@Edge and Secure@Edge, which we would expect. However, they introduced two new product categories, called Perform@Edge and Observe@Edge.
I found this very interesting, as Fastly is already expanding the “@Edge” offering and applying the label to new categories. It isn’t clear at this point if the new products would generate additional revenue streams. Initially, it appears they could be utilized on a stand-alone basis, but also would have tie-ins with the other Edge products. Perform@Edge represents a formalization and doubling-down of content delivery and streaming, with new capabilities lined up for more robust video delivery support. Observe@Edge will build on top of Fastly’s existing logging and stats functionality to add deep observability, application tracing features, advanced analytics and alerting. The programmatic aspects of these offerings will be built on the Compute@Edge runtime.
Compute@Edge Roadmap
The first focus for Compute@Edge will be to continue hardening the platform and move into general availability for all customers. As part of this, the team will work with customers to support more complex applications, adding state with a distributed key/value store. As many customers are using Fastly for sophisticated content delivery use cases, like the example mentioned previously with USA Today, the team will extend cache control capabilities through their programmatic API.
A major driver of Compute@Edge adoption will be its usability for developers. The Fastly product development team is planning to support this by adding new languages and provisioning separate environments for developers to use for initial coding and testing. These would all be integrated into popular CI/CD pipelines and configuration management frameworks like Terraform for DevOps automation.
Secure@Edge Roadmap
For Secure@Edge, the plan is to finish the integration of Signal Sciences and Fastly’s platform into a single offering. This involves porting much of the technology to run on top of Compute@Edge. Immediate features, based on customer interest, are to offer rate limiting and bot mitigation. Additionally, they plan to create an authentication solution at the edge. I assume this could be used for both public and private applications. Finally, an aspect of the service that Fastly provides for its video streaming and CDN customers is to staff an operation center during large events to provide real-time support. Fastly intends to extend this live support for customers to application security monitoring.
Observe@Edge Roadmap
Observe@Edge would provide deep application and network observability from the vantage of the entry point at the edge. Many of Fastly’s customers already route incoming application and content delivery requests through Fastly’s network. Additionally, all of Fastly’s enterprise customers utilize at least one of their 25 logging endpoints. With their edge compute capability, Fastly could inspect this traffic at a more granular level and provide insights into application performance and network usage. They intend to build on top of their existing logging and stats functionality to add advanced analytics, tracing and alerting.
For customers that would host application infrastructure at origin, this observability could supplement that provided by server-based monitoring, like Datadog or Dynatrace. For the portion of the application run on a distributed serverless environment, like Compute@Edge, the Observe@Edge solution would provide more detailed monitoring of the activity within that portion of the application.
Observe@Edge would expose a programmable interface to allow customers to define their own custom metrics. This would be particularly relevant for data that goes outside of the realm of standard web application observability, like video delivery for an OTT provider or data streaming from a fleet of IoT devices. With these metrics, Observe@Edge would further provide customers the ability to trigger alerts on threshold ranges for certain metric values. For sensitive applications, Observe@Edge could ensure geographic locality of log data, versus the current architecture of most applications of sending all log data to a single geographic collection location.
While launching a monitoring/observability platform might seem like a new motion for Fastly, we should keep in mind that Signal Sciences brings sophisticated event data collection, processing and dashboarding capabilities as part of their solution. The dashboards published in the UI interface to the Signal Sciences product resemble the security monitoring or logging interface provided by other observability providers. Fastly even promotes job listings for these functions on its Careers page now, including a Senior Data Engineer – Elasticsearch, a Senior Software Engineer – React and a UX Engineer – React. As an aside, the Data Engineer job description reveals that Signal Sciences uses the ELK stack (ESTC) and MongoDB Atlas (MDB) for data storage.
Fastly recently published an interesting use case on their blog, in which Adobe is using Fastly’s edge network to collect all request/response calls for their serverless environment. These are captured by Fastly and shipped to a third party system, Epsagon, for graphing and user review. Because Adobe’s service relies on many other microservices and external APIs, a traditional agent-based hosted observability solution would be more challenging to build a full picture. By proxying all traffic requests through Fastly’s edge network, they are able to capture all these individual service calls and route them to the data collection and dashboarding system. This provides a glimpse into the potential need for the Observe@Edge solution.
Perform@Edge Roadmap
Because Fastly has a sizable content delivery and streaming business, they are planing to formalize this into the Perform@Edge offering. This will go far beyond the existing, simplified CDN use case to provide an intelligent network for programmable content delivery at the edge. This will leverage Compute@Edge to enhance video delivery, by adding dynamic ad insertion, manifest file manipulation, smart traffic routing and real-time optimization of content to fit the user’s device and preferences.
The Perform@Edge offering will also support and extend some existing Fastly content delivery features, like image optimization, media watermarking, origin shielding and varied formats. Customers will also get enhanced observability of their content delivery with custom metrics to reflect the performance of special streaming events. Finally, customers will have more granular control over content caching and refreshes.
Data@Edge
During the Compute@Edge talk at Altitude, the customer panel mentioned looking forward to a new offering, referred to as Data@Edge. While this hasn’t been formally announced by Fastly, we can assume it represents a new distributed data store for use by the serverless runtime. Fastly has a basic local cache available for the existing VCL environment called Edge Dictionaries. Data@Edge would presumably take this to the next level, providing an eventually consistent, distributed data store with a CRUD-like data interface for developers to use. This could be the key value store referenced in the Compute@Edge roadmap.
Fastly’s Principal Engineer, Peter Bourgon, discussed a data storage layer in the past. He weighed the challenges of building a distributed state management solution in a blog post from July 2020 and also in a tech talk at QCon London. The implied technical direction is to leverage CRDTs (conflict-free replicated data types), which have the benefit of guaranteed consistency, but more complexity in implementation.
In the blog post, he said that “Fastly is actively prototyping and deploying a CRDT-based edge state system.” Perhaps Data@Edge will represent the first incarnation of this to provide data storage for Compute@Edge. This job posting for a Software Engineer – Edge Data implies the same. The engineer will be responsible for building the infrastructure to enable state at the edge. The job description states this roles will be part of a team of engineers and that data storage will be leveraged to drive other product offerings in the future. “Collaborate with customer-facing teams to define and implement primitives that will power a huge number of future Fastly products”.
In addition to providing distributed data storage for use by Compute@Edge, Data@Edge might be offered as a stand-alone service. This would be similar to Fauna, which is a popular globally distributed, cloud-based data store. It is completely accessible through APIs and meant to be connected to directly by client applications (web or mobile). This future-facing approach to application development and infrastructure is dubbed the Client-serverless architecture and aligns well with Fastly’s capabilities.
Competitive Activity
During the Oppenheimer analyst call in August, Fastly’s CEO made an interesting comment. He said that he had a discussion recently with the CTO at a large customer. The CTO stated that for every $100 that he planned to spend on central cloud infrastructure, he would allocate $5-10 on application security and $5-10 to edge computing. This represents a strong statement about the future TAM for Fastly products. While the application security market is fairly well understood, investors are still struggling to size the market for edge compute. According to Gartner, the combination of spend for IaaS, PaaS and Cloud Management services is projected to exceed $170B by 2022. This implies the market just for edge computing could range from $8-17B, and represent a similar opportunity for application security.
In their investor presentation from August, Fastly leadership sized the addressable market at about $35B. In this case, they estimated an $18B market for edge computing and application security at the edge, and another $17.5B for the existing markets around content delivery and video streaming. We can assume that sales opportunities in edge application compute and security will be more greenfield, while content delivery would likely represent a mix of competitive displacement with some greenfield opportunities from new content distributors or expansions.
As investors consider the TAM, it is worth thinking about the paradigm that Fastly and other edge network providers are enabling. This is represented by the shift of delivery architecture from single deployments of server clusters to a mix of centralized and local application delivery points. This shift will encompass both compute and data storage.
This move from centralized application processing to distributed is the next logical step in the evolution of software architecture away from monolithic applications. Any popular web or mobile application is already powered by many services, distributed across the Internet. These could range from decomposed microservices provided by the application’s owner to third party services, like ad servers, video players, payments processors, etc. All of this content is then stitched together by the end user’s browser or mobile app. So, as it relates to the idea of breaking up a centralized application into a distributed network of contributing services, the genie is already out of the bottle.
If we then accept that a mobile app or web site running on each user’s device is stitching together logic and content from multiple services spread across the Internet, then it makes sense for the application owner see a benefit in locating some portion of application logic outside of the user’s device, but geographically local to the user, so as to not require a round-trip all the way to a centralized cluster of servers hosted in a single data center. At minimum, this local “edge logic” can perform some of this stitching functionality, particularly where it needs to be done in a secure environment (not on the user’s device).
This will have the immediate benefit of speed. By removing the round trip to a central server that then delegates some functionality to another service likely located in a different data center, the application will noticeably reduce latency. Content and data can be stored locally at the edge as well, which would further speed up application response times. If that user is located in a country with data transfer restrictions, the application owner can ensure that user’s data is kept within that country’s borders.
Finally, locating the entry point for an application at the edge has major security benefits. Requests for logic or content from third-party services that are restricted or sensitive can be proxied through the application facade at the edge entry point. The application is not dependent on the security of the user’s own device in order to ensure clean access to these services.
As enterprises complete the shift to the cost-saving measures provided
Fastly Q3 Shareholder LEtter, October 2020
by the central cloud, their next frontier is to move logic, compute power,
and security to the edge in order to more effectively meet their customers in the digital-first way that consumers have come to expect and rely on. We believe we are exceptionally well-positioned in the current enterprise technology environment, delivering multiple powerful solutions, tuned for the evolving DevOps workflow at the edge, opening up much broader enterprise customer opportunities
Given these advantages, this “edge compute” will improve the performance and security of a swath of future technologies. These will range from Internet application delivery, video capture/processing, data streaming, IoT, autonomous vehicles, manufacturing, transportation, etc. Many large technology providers will want to address aspects of this landscape, including the large cloud vendors (Amazon, MS, Google), component manufacturers, embedded systems providers, etc. This creates a broad playing field for technology providers.
Specific to Internet-based applications (where Fastly and Cloudflare focus), the application delivery architecture is evolving in several fundamental ways. These are architectural changes, primarily driven by developers and their increasing influence over infrastructure decisions. These are oriented towards removing overhead and increasing agility.
1. Towards serverless. Serverless environments eliminate the need for Development teams to worry about provisioning servers in order to run their applications. Developers upload code to a serverless environment and the hosting provider handles the rest. This is the next logical step in the progression from self-managed hosting (data centers) to cloud-managed hosting (AWS) to fully managed runtimes (serverless). The last big hurdle with serverless for synchronous web application delivery was the cold start time. Now that these times are fast enough to be imperceptible (under 1ms for Fastly and 3-5ms for Cloudflare), serverless can be used for synchronous workloads (when a human is waiting on the response) like a web or mobile app. This inflection in cold start times has now unlocked a whole new set of use cases for serverless application processing.
2. Microservices architecture. Modern software applications are being divided into distinct services, each with responsibility for a particular function. Examples of microservices for a typical consumer Internet web app might be authentication, product search, shopping cart, payments, user profile, etc. Outside of user features, other supporting software infrastructure can be delivered as a service. These services might provide A/B testing, user activity monitoring, content delivery and ad insertion. Breaking a single legacy application (often called a monolith) into separate services has several advantages for development teams. These include scalability, code separation, deployment pipelines and developer specialization.
3. Away from origin towards the edge of the network. As discussed above, processing code at the edge makes the application faster. It also helps address data sovereignty issues by keeping all data local to a country per PoP. With 5g, users will expect more responsive application performance and content delivery. With the move towards microservices, development teams can choose whether to locate each service at the origin or at the edge. Some application functions (packaged as services) would be good candidates for running at the edge. Examples are user authentication, content stitching, personalization, ad delivery, A/B testing and user behavior monitoring.
This is likely the main argument for the emergence of edge compute. Some investors have wondered whether there are sufficient use cases for edge compute or even why organizations would incur the overhead of pulling out slivers of functionality to run on an edge compute platform. However, the evolution of applications to a service-oriented architecture already provides the necessary momentum. Once a service is broken out, the choice to run it at origin or at edge follows.
4. Security. The migration of applications towards a distributed architecture consisting of microservices running in serverless environments will have significant implications for application security over time. In this architecture, monitoring and enforcing security at the network level and within the application runtime itself becomes more relevant. The notion of “endpoint” security becomes amorphous. In a serverless environment, where is the endpoint?
Security monitoring then logically moves to the network. If a provider can monitor all incoming network traffic for an application and apply sufficient intrusion detection logic (IDS), then they should reduce the need for an enterprise to maintain a fleet of monitoring agents on all the servers/containers running their application. This makes the positioning of Cloudflare One (with capabilities like Argo Tunnel and Magic Transit) coupled with new features like IDS and Magic Firewall very strategic. As the entry point for all web application traffic, Fastly is similarly well positioned with customers and can layer Secure@Edge over this.
Readers don’t need to take my word for some of these trends. On the recent Nvidia Q3 earnings call, CEO Jensen Huang riffed on this evolution in discussing future needs for their new Mellanox acquisition and high-speed networking.
But in the future, if you would like cloud computing to be the architecture for everything and every data center is multi-tenant, every data center is secure, then you’re going to have to secure every single node. And each one of those nodes are going to be a software-defined networking, software-defined storage, and it’s going to have per application security.
It’s safe to say that high-speed networking is going to be one of the most important things in cloud data centers as we go forward. And the vast majority of the world’s data center is still built for the traditional hyper-converged architecture, which is all moving over to microservices-based disaggregate –software-defined disaggregated architectures. And that journey is still in its early days.
Nivdia Q3 Earnings Call, November 2020
For the next generation of edge networks, like Fastly and Cloudflare, I view one size fits all services like CDN and DDOS mitigation as just the starting point. For Fastly, CDN is the low-hanging fruit for a software-defined network of global PoPs, and provided a suitable proof-of-concept. With Compute@Edge, Fastly will have a platform on which to build a whole slew of new products that are optimized to deliver distributed, serverless solutions from the edge for all kinds of use cases. This job description provides a teaser, and I agree that there are many next-gen services that could be built on top of a distributed edge compute platform. Cloudflare is taking a similar route with Workers and posits that all new products (like Cloudflare One) are built on top of Workers and their distributed network of PoPs.
How the cloud giants react to this will be interesting. I agree with other analysts that they won’t stand by and do nothing. But, I also think they have a lot invested in the status quo and technology evolution often sees the disrupter eventually getting disrupted.
As we highlighted last quarter, we remain extremely focused on innovation, system efficiency, and system design to further improve our network. We expect these improvements to reduce computing requirements for common workloads, increase overall POP capacity, and ultimately increase the amount of revenue per server.
fastly Q3 Shareholder Letter
In terms of the competitive landscape specifically for Fastly, I think it is worth checking in on the progress of the independent service providers and the cloud vendors since last quarter. Of the independents, Cloudflare (NET) and Akamai (AKAM) are most relevant. I acknowledge there are other independent providers (like Limelight), but I don’t think they are candidates to dominate the category going forward. Of these three, Akamai is the incumbent and Fastly and Cloudflare are disrupters. For more detail on the product offerings from Akamai and Cloudflare and updates in prior quarters, readers can refer to my original deep dive on Fastly and subsequent summaries of quarterly earnings, where these names were surfaced in the competitive sections.
Cloudflare
Cloudflare has emerged as a significant player across a number of technology fronts and likely represents Fastly’s most formidable competitor as a like-minded disruptor. Cloudflare became prominent in 2010-2015 for DDOS mitigation and other SMB web hosting services, like DNS, CDN and domain registration. While they still offer enhanced versions of these (and show an “Under Attack?” button at the top of their home page), they have broadened into a global cloud platform of network services for companies of all sizes, including a rapidly growing enterprise presence with 16% of the Fortunate 1000. Their high-level ambition is to “build a better Internet”. That vision can obviously cover a lot of ground.
A few items impress me about Cloudflare. First, their product development pace is torrid. Over the past several months, they have released significant additions to the product suite. These go beyond linear enhancements and represent full-featured, monetizeable product offerings. I will detail these below. Looking forward, they exhibit no intent of slowing down, continually teasing customers and investors with hints of future offerings.
The leadership team is highly engaged and customer-centric. Co-founder and CEO Matthew Prince maintains an active Twitter account and personally replies to product questions from engineers and customers. He even responds to production issues – talk about leading by example. The rest of the leadership team is engaged as well. In a similar vein, Cloudflare’s product marketing motion is strong. The Cloudflare Blog provides a rich source of product information with new updates almost daily. Product releases are often grouped into a digestible mini-series over the course of a week, supplemented by an MTV-era inspired video channel (I am aging myself) of engaging content available on Cloudflare TV.
Suffice it to say, I am bullish on Cloudflare’s opportunity going forward. As I will talk about at the end of this post, I have built a substantial position in NET in parallel to my allocation to FSLY. I think both names represent a prudent bet for investors on long term trends in software-defined networking, distributed serverless compute and security.
With that set-up, I will provide some updates on Cloudflare’s recent financial performance and product releases. I will also try to highlight differences in their product offering from Fastly’s, particularly around edge compute. These differences are technically nuanced and are shifting every quarter. While the two companies directly compete in several areas, I am comfortable betting on ownership in both. I may publish a stand-alone analysis on Cloudflare in the future. In the meantime, interested readers should check out coverage from hhhyper-smart peer analyst, Muji, over at the Hhhypergrowth blog.
In their Q3 earnings report on November 5th, Cloudflare (NET) delivered a strong acceleration in revenue. After consistently growing in the high 40% range for several quarters, they stepped over the 50% annualized revenue growth mark in Q3, just shy of a 55% increase. This represented a beat of about 15% over analyst expectations. Further, for Q4, they are projecting 41% growth. Given the Q3 outperformance, it’s likely they will keep growth above 50% next quarter as well.
With 100,000 paying customers, Cloudflare has traditionally focused on the SMB segment. However, they are continuing to move up-market, adding over 100 large customers (defined as spending $100k on an annualized basis) in the quarter for year/year growth of 64%. In fact, they achieved their first customer with over $10M ARR. Their DBNR was 116%. This is not as high as Fastly’s expansion metrics (even those accounting for churn), but is still strong and reflective of a broader customer base.
On the product development front, delivery over the past several months has been significant. Based on the cadence of product release announcements in 2020, Cloudflare appears to be out-maneuvering Fastly. They have brought more product to market so far this year, at least based on what we have seen publicly. While Fastly’s new development is still shrouded behind beta and LA programs for Compute@Edge, Cloudflare’s ede compute platform is fully released and open to all customers.
In past analyst calls, Fastly’s CEO has talked about how Fastly is very deliberate with their releases, ensuring that everything is in place before rolling out a new technology publicly. This is partially due to a desire to maintain stability for their customers, who are arguably running some of the largest sites on the Internet. I won’t debate the merits of this approach versus the agility of Cloudflare. It could also be a case of an iceberg analogy, where Compute@Edge and Secure@Edge will have many features bundled together under the surface of one single, large release. Historically, agile development has delivered more customer benefit than infrequent major releases, but there may be lots of activity happening behind the scenes of Fastly’s beta programs. We will see.
Here is a list of the major new product releases delivered by Cloudflare over the past several months:
Serverless Week
Serverless Week ran from July 27 – 31. For this event, I provided a full blog post detailing all the changes and comparing them to what we know about Fastly’s Compute@Edge platform. Cloudflare delivered a number of enhancements to their Workers product suite, including the following items:
- Reduced perceived cold start times by pre-warming isolates during the TLS negotiation. To be clear, they didn’t eliminate cold start times, but made them imperceptible in some cases through parallelization.
- Extended worker run times, eventually ramping up to 15 minutes. This will allow for more complex and heavier workloads to occur at the edge, accommodating functionality that is asynchronous (background jobs).
- Published lower costs for Worker activity, as compared to cloud vendors.
- Added support for 5 more development languages, including Python, Scala, Kotlin, Reason and Dart. This is in addition to the prior languages of JavaScript, C, C++, Rust and Go. Broad language support enables developer adoption.
- Rolled out a comprehensive security monitoring plan. While their Isolates runtime architecture represents a meaningful improvement over the legacy approach of keeping warmed threads in a container for subsequent requests, Cloudflare added additional monitoring to prevent side-channel attacks and other possible memory access exploits.
- Enhanced tooling, to help developers create their code, debug issues, rapidly distribute changes and manage capacity.
- Highlighted their favorable posture to address future data localization requirements. Cloudflare announced on July 15, that their network had expanded to 206 POPs covering over 100 countries. This helps customers achieve compliance with increasing requirements from countries worldwide for data sovereignty.
As I discussed in detail in a prior post on Compute@Edge, Fastly and Cloudflare took two different approaches with their serverless, edge compute solutions. Cloudflare chose to build their solution on the Chromium V8 Engine. This allowed them to leverage the work already done by the Google Chrome team and get a product to market quickly in 2018. This was a major improvement over the serverless solutions provided by the cloud vendors at the time, like Amazon Lambda. Cloudflare’s Workers reduced cold start times by 100x and used 10x less memory, allowing for more efficient utilization of hardware resources.
Rather than relying on existing technologies for serverless compute, like re-usable containers or the V8 Engine, Fastly decided to go all in on WebAssembly (Wasm), and built their own compiler and runtime, optimized for performance, security and compactness. The result was the Lucet compiler and runtime. Fastly has been working on this behind the scenes since 2017 and it provides the foundation for Compute@Edge, which is now running production code for several customers.
Lucet compiles WebAssembly into fast, efficient binaries for execution, that also enforce safety and security through very deliberate memory allocation and no residue from prior requests. Lucet supports WebAssembly and for this, Fastly even created its own compiler. Lucet also includes a heavily optimized, stripped-down runtime environment, on which the Fastly team spends the majority of their development cycles.
The result is better performance than the V8 Engine equivalent. Fastly has reported cold start times of 35 microseconds. This is at least 100 times faster than the V8 engine, which requires 3-5 milliseconds to start (3,000 to 5,000 microseconds). Similarly, because Lucet only includes code modules needed to run the compiled assembly code, it requires a very small memory footprint of a few kilobytes of memory. This is about 1000 times smaller than the 3MB used by the V8 Engine.
Both Fastly’s Lucet and Cloudflare’s Workers have significant performance advantages over legacy serverless solutions. This has allowed both to be used for synchronous workloads, where legacy serverless solutions were primarily relegated to offline, asynchronous jobs. This shift to synchronous requests dramatically expanded the use cases for serverless, to being suitable for real-time web and mobile applications.
Comparing Lucet to Workers, Lucet has a shorter cold start time. As mentioned above during Serverless Week, Cloudflare released an optimization that front-loads the cold start in some cases so that it runs in parallel to the initial TLS negotiation. Some will debate whether the difference in cold start times of <1ms versus 3-5ms really matters. A human waiting on the response would likely not notice.
However, PoP hardware utilization would become a significant factor. Lucet’s cold start requires 100x less CPU time to execute. More importantly, its memory footprint is 1,000x smaller. This implies that Fastly would be able to pack many more runtimes onto each PoP server. As demand for edge compute increases, Compute@Edge should scale more efficiently in Fastly’s PoPs than competitive offerings based on the V8 Engine. Fastly would be able to support more runtimes for the same hardware allocation.
However, like with many technology choices, there are trade-offs. For the enhanced performance of Lucet, it gives up language compatibility and doesn’t support JavaScript. While Fastly’s CTO speculated at Altitude that most modern programming languages would eventually compile to WebAssembly, this isn’t the case currently. To use Compute@Edge, a developer would need to write their code in Rust, C, C++, WebAssembly or AssemblyScript (a cousin of JavaScript that produces WebAssembly binaries and shares some syntax and semantics).
The V8 Engine, on the other hand, supports most popular languages. This is because the V8 Engine can execute JavaScript. Most languages have an open sourced compiler to JavaScript available. The list is pretty extensive, including most popular developer languages. Cloudflare has vetted many of these and incorporated them into its developer tooling for Workers. Of the 20 most popular languages as published by RedMonk, Cloudflare Workers currently supports 9 of them (highlighted in green).
These differences underscore what I think will be a divergence of workloads for Fastly’s and Cloudflare’s serverless offerings. In the near term, we could see Compute@Edge used by large Internet companies for whom performance is critical and their engineering organization has enough depth to allow for focus on a single language like Rust. PayPal represents a reasonable example customer, as evidenced by their presentation at Fastly’s Altitude conference and the existence of an “Edge Engineering” team.
Cloudflare Workers, on the other hand, would have broader appeal to more engineering organizations, due to language support and extended run time thresholds. In the Q3 earnings call, Cloudflare highlighted a number of customer use cases that are utilizing Workers, in addition to a staggering stat of 27,000 developers with individual deployments. Cloudflare’s focus on enabling data locality through granular data storage controls (see Durable Objects below) also provides an advantage for compliance. Cloudflare’s CEO published an insightful blog post to kick off Serverless Week that outlines his perspective on the product landscape and customer needs.
Given that edge compute use cases are still emerging and both serverless platforms are evolving, it is probably too early to try to size the relative opportunity for both. Suffice it to say, that Fastly and Cloudflare edge compute platforms have a head start over incumbent solutions and the opportunity for distributed serverless computing could be large enough to accommodate both offerings with plenty of growth.
Birthday Week
In recognition of their 10 year anniversary, Cloudflare (NET) hosted their Birthday Week from September 28 – Oct 2. This included a number of product announcements and a long list of speakers in interviews on Cloudflare TV. The speaker list was very impressive, including many CEO’s of leading Internet companies like Slack, Zoom, Upwork, Stripe, Rent the Runway, Box, DocuSign, OpenTable and PagerDuty.
The biggest take-aways for investors were associated with the product announcements. I liked the variety and depth across Cloudflare’s many product lines. Additionally, this further demonstrates Cloudflare’s rapid product development cycle, as these follow Serverless Week in late July, which also included a number of product releases. Here is a list of the major product announcements from Birthday Week, with links to posts on Cloudflare’s blog for more detail.
- Workers – Durable Objects. Durable objects provide persistent, consistent storage of data for Worker processes. Storing some sort of state between requests is foundational to most applications. The breadth of use cases where processing can be moved to the edge is expanded by having data storage available. Durable objects enables this, by allowing any set of data to be persisted with guaranteed consistency across requests. Objects can be shared between multiple application clients (users). This consistent and sharable data object storage enables many common use cases for multi-user Internet applications, like chat, collaboration, document sharing, gaming, social feeds, etc.
- Workers – Cron Triggers. Cron triggers allow worker processes to be kicked off based on a time schedule. This differs from the current method in which a user has to make a request in order to trigger a worker. This scheduling of tasks is common for many use cases, like downloading new data updates or sending out communications. With this capability, developers can set a worker to run on a time frequency, like every hour or daily.
- Privacy-first Analytics Service. Many free web site analytics packages are available on the Internet. Google Analytics is probably the most popular and familiar. However, most of these free services also track users across multiple sites and then combine that activity data to improve ad targeting. This raises privacy concerns. Cloudflare’s new Analytics Service provides the same level of free web site analytics, but without the inherent cost of giving up the privacy of that site’s users. This is a noble gesture by Cloudflare and will make their service slightly more sticky for small to medium sized web sites that are looking for an inexpensive tool to generate analytics.
- Cloudflare Radar. Given that Cloudflare processes a large portion of the traffic that traverses the Internet, they have insight into usage patterns globally. Radar provides a dashboard of Internet activity showing traffic flows, domain usage, DDOS attacks, protocols, browser usage, device preferences, etc. This can be sliced by country or even down to individual web site URLs. This service is free to the public. The benefit to Cloudflare would be increased visibility of their products.
- API Shield. API’s are code modules hosted on a server that provide access to application business logic and data for remote clients, like mobile devices. They deliver a standard interface to which client applications can connect. However, bad actors can also locate these API’s and try to manipulate them to extract data. Cloudflare’s API Shield product provides a way to protect API endpoints from exploit by requiring client certificates to authenticate and monitoring traffic for unauthorized behavior. This will provide another layer of protection for the WAF product line.
As an enhancement to the Workers product, Durable Objects represents a significant step forward. It also provides the primitive upon which more sophisticated data access and storage solutions could be built. The granular control over data location also bolsters the data sovereignty capability of Workers. This offering provides more flexibility and control than Fastly’s existing data storage solution, but we know Fastly is working on an enhanced edge data management solution as well.
Cron triggers provides another hint of target use cases for Workers. If a job is scheduled through cron, then it is asynchronous by definition. This, along with extended run times of up to 15 minutes, implies Workers is targeting offline workloads in addition to handling synchronous web requests.
While these new releases don’t represent stand-alone revenue streams at this point, they do provide meaningful incremental improvements to existing products and bring additional visibility to Cloudflare as a whole. I think these should lead to increased adoption over time and new customer adds. They also underscore Cloudflare’s rapid product development pipeline across a breadth of categories.
Zero Trust Week
On the heels of Birthday Week, Cloudflare held Zero Trust Week from October 12-16. I was floored by the rapid product execution demonstrated by Cloudflare in lining up so many more significant releases just after the prior two events. Through their blog and social media, Cloudflare generated a lot of buzz and momentum during this event. This certainly created the perception amongst the investor community that Cloudflare is on fire.
Zero Trust Week added another set of impressive enhancements. Here is a brief run-down of the major announcements. There were a number of other items, that I didn’t include for brevity:
- Cloudflare One. The week kicked off with the announcement of Cloudflare One, which provides a unified set of tools to enable a Zero Trust security posture for customers. It delivers a cloud-based, network-as-a-service to protect enterprise devices, data and employees. While this represented some packaging of existing products like Access, Gateway and Magic Transit, it also adds browser isolation, a next-gen firewall and intrusion detection. Cloudflare One is the umbrella product offering, with these other tools roll into it. The product release announcement included quotes from a number of customers, like JetBlue, OneTrust, Discord and INSEAD. These probably drove the market’s reaction, which resulted in NET closing the day up 23%.
- Partnerships. In order to round out the Zero Trust capabilities of the platform, Cloudflare announced partnerships with leading providers in identity management and endpoint protection. Cloudflare allows customers to preserve their existing identify management tools, with integrations between Cloudflare One and providers like Okta, Ping Identity, and OneLogin. Similarly, for device security (endpoint protection), Cloudflare is partnering with CrowdStrike, VMware Carbon Black, SentinelOne and Tanium. Cloudflare One also works across different identity providers, which provides an interesting capability that might enable future extensions.
- Magic Firewall. This provides a network-defined firewall for an enterprise to secure users, offices and data centers. Like a typical hardware firewall, users can specify allow/block rules based on IP, port, protocol, packet length, etc. This is integrated with Cloudflare One making these capabilities automatically available. The product has been launched as a limited beta for existing customers.
- Cloudflare Browser Isolation. This product addresses the risk that a script downloaded from an infected web site might introduce a vulnerability into a user’s device. To prevent this, Cloudflare actually runs a copy of the user’s browser in a sandboxed environment on one of Cloudflare’s distributed data centers. The results are then streamed to the user’s local browser instance as a set of draw commands to render the page. This prevents the user’s browser from actually running any code. If a vulnerability is encountered, it only installs on the sandboxed version of the browser, which is then destroyed in the cloud. This product is in beta now, and will be an offering within the Cloudflare One product.
- Intrusion Detection System (IDS). Cloudflare’s IDS product is a natural extension of the visibility enabled by Cloudflare One. Once a customer has connected their employees, devices and data centers to Cloudflare’s network, Cloudflare can actively inspect that traffic for threats. This takes the form of traffic shaping and traffic inspection. Shaping observes normal, expected behaviors and flags anything unusual, like a particular user accessing many resources in rapid sequence. Traffic inspection involves examining each user request for something malicious, revealing a targeted attack. For both types of detection, IDS can alert security personnel or take proactive action, like blocking a user’s source IP address.
These new capabilities with Cloudflare One are exciting, as they represent a big step forward in providing a network-first security solution for enterprises. Given that almost all security exploits start by traveling over the Internet, if Cloudflare can get customers to connect all their endpoints to the Cloudflare network, they are in a unique position to provide enhanced security services. This could even reduce the need for endpoint protection over time, as EPP agents look for malicious activity on a device before taking action. In the ideal case, that activity could be stopped at the network level first through IDS, before the exploit even starts.
Fastly uses a similar network-driven approach, but their current solutions focus primarily on application security and the developer organization. This is different from the buyer of enterprise security, which would fall under the CIO or CISO. So, in many respects, Cloudflare and Fastly are on divergent paths as it relates to their security roadmaps, but also overlap in areas of application security.
What is most interesting to consider about Cloudflare’s approach to network security is the potential for a winner-take-all outcome. Once Cloudflare convinces an enterprise to connect their offices, data centers, applications and employees to the Cloudflare network, it makes cross-sell of other services easier. It is a little bit of a Trojan horse in this regard. Granted, while the development organization in large digital native companies is autonomous and will choose the best infrastructure tooling based on their requirements, many mainstream enterprises might find it easier to just consume the full menu of Cloudflare offerings once they hitch their trailer to the Cloudflare network.
Akamai
Akamai has one of the oldest CDN offerings. They were born of the Internet, so to speak, incorporated in 1998, many years before there were cloud providers. Akamai supports all the standard CDN functions, including static content delivery, global load balancing and video streaming. A lot of their focus has shifted to security recently, providing Web Application Firewall (WAF), DDOS mitigation and bot protection. They even have a neat interactive graphic on their home page showing live attacks across the globe.
On the Oppenheimer analyst call in August, Fastly’s CEO discussed the competition for content delivery. He acknowledged that bulk video delivery has become commoditized, where Fastly sees competition from Limelight, Level3, Akamai and others. For every other content delivery use case, though, he said that Fastly generally competes with Akamai for enterprise business. From the CEO’s perspective, Fastly’s advantages over comparable Akamai solutions revolve around programmability, ease-of-use, developer tooling/controls and documentation. He also talked about how Fastly’s implementation for a new customer is usually very fast, requiring little outside help. This is opposed to Akamai, where the sales cycle is prolonged and involves engaging a professional services organization that is largely offshore. Based on my past experience using Akamai’s services, I can appreciate this perspective.
As it relates to edge computing, Akamai published a blog post in early August detailing their history of providing edge compute solutions. While they highlight a number of their product features that do indeed perform computations on the edge of their network (like DDOS or WAF), this isn’t edge computing in the context used by Cloudflare and Fastly. Compute@Edge and Cloudflare Workers provide a programmable serverless compute environment with complete developer tooling that can be synchronized across all POPs. For this, Akamai launched their EdgeWorkers product in October 2019. This solution is based on the V8 Engine and currently only supports JavaScript for development. The product is in private beta for existing customers, requiring a sign-up form and review to utilize. The state of this offering hasn’t changed since I visited it several months ago.
Akamai is almost 10 times larger than Fastly or Cloudflare. In Q3, they generated almost $800M in revenue. However, annualized growth has slowed to 12%. They have a deep and impressive customer list for the services they offer.
- 46 of the top 50 online retailers in the U.S. and Canada
- 7 of the top 10 European online retailers
- 47 of the top 50 television networks in the US
- 18 of the largest asset managers
- 7 of the top 10 world’s largest banks
- 7 of the top 10 world’s largest insurance carriers
- 7 of the top 10 world’s largest newspapers
While they are the largest provider, I think Akamai will begin losing market share to Fastly and Cloudflare and find it increasingly difficult to compete as service offerings and customer expectations for edge networking and compute continue to evolve.
Akamai’s incumbency and size create performance disadvantages. Akamai maintains a content distribution network spread across 4,000 locations. This has been built out over a long period and consists of several generations of network and server hardware. While having a large number of PoPs might seem like an advantage, it can actually be less performant due to low cache hit ratios for content delivery. Additionally, customer changes to content or network configuration take a long time to propagate across so many locations. Fastly maintains fewer, but more dense, POPs to maximize the cache hit ratios and make content update nearly real-time. The use case outlined by USA Today would not be as responsive on such a large network topology.
Similarly, Fastly (and Cloudflare) built their architectures around software-defined networking from the beginning. Rather than building their PoPs using the standard configuration of purchasing large, off the shelf routers, Fastly took a different approach with their network design. They moved all networking into code modules that run within the PoP servers themselves. This provides very granular control over traffic routing between PoPs and networks down to each individual request from a user. Fastly’s PoPs can calculate route selection for each type of content, use case and location, resulting in better content delivery performance than legacy solutions that generally apply a single routing rule at the border router for all cases.
Finally, Akamai’s pace of innovation and product delivery cadence has slowed. While enabling serverless edge compute is a capability that Akamai seems to consider important, the progress of their EdgeWorkers solution is not reflecting this. It appears to be in the same state now as announced a year ago and remains in private beta.
Cloud Vendors
It would be naive to discount the potential for competition from the cloud vendors (AWS, Azure and GCP). Obviously, this already exists for use cases around content delivery, video streaming and security, with no direct impact on Fastly’s business so far. Amazon’s Cloudfront CDN service has been live for 10 years, yet is not the primary choice for the large digital native web sites.
For serverless, AWS offers their Lambda@Edge product for edge computing. This is an extension of Amazon Cloudfront, which is their CDN service, and AWS Lambda, which provides Amazon’s serverless solution. In a similar approach to Amazon, Microsoft Azure offers edge computing (called Intelligent Edge) through the use of Azure Functions, which can be deployed on Azure, Azure Stack (a managed physical appliance) or Azure IoT Edge. Google supports serverless runtimes through their Cloud Functions. As mentioned previously, GCP has embraced Fastly through a strategic partnership as well.
I won’t go into detail covering each of these offerings. Primarily, that is because I haven’t seen meaningful change in the last couple of quarters. That’s not to say any one of them wouldn’t choose to double-down on edge compute in the future. AWS has their re:Invent conference in early December, which is when they often announce new product offerings. Also, the cloud vendors are pursuing other aspects of edge computing, like processing data from fleets of physical devices in manufacturing and transportation. Amazon’s Snow family of products represents an example of this.
However, my view of competition from the cloud vendors for Fastly or Cloudflare aligns with my generalized thesis that applies to any independent software company. I have written previously about how independent software providers compete favorably with look-alike offerings from the cloud vendors. I still maintain that in many software categories, independent providers build superior products and can maintain a lead over comparable offerings from the hyperscalers. This is a consequence of the independent’s ability to apply laser focus to customer needs, iterate quickly with frequent product releases and attract top talent to their technology category.
As it relates to Fastly and Cloudflare, I believe that CDN, distributed serverless compute and security are three areas where independents can effectively compete with the cloud vendors. The primary tailwind driving leverage for the independents is the multi-cloud trend. As enterprises evolve their cloud footprint, they are increasingly considering a multi-cloud strategy. This allows them to reduce lock-in, improve their negotiation posture and manage risk. Multi-cloud deployments bias towards neutral, independent software providers, as they provide a single API interface for service access and a network entry point for all microservices that could be hosted on separate clouds. I think these factors will favor leading independent providers like Fastly and Cloudflare.
A recent article on InfoQ covering Fastly’s enhancements to Compute@Edge provides additional perspective on Fastly’s offering and its relation to those of the large cloud providers.
Do-It-Yourself (DIY)
There has been some speculation by sell-side analysts that large content delivery providers (TikTok, Disney, etc.) may be considering building their own CDN’s to handle the delivery of their content. Their motivation is presumably to gain more control and lower costs.
At a fundamental level, this type of build/buy decision is common across many tech services, particularly once a company reaches a certain scale. As budget line items become very large for services such as cloud hosting, communications, monitoring, etc., there will naturally be consideration given to the feasibility of dedicating some engineers and hardware budget towards a DIY approach. In the past, we have seen Uber consider moving their customer communications off of Twilio. Large web properties (like Facebook) or SaaS companies (like DocuSign) will choose to run their own data centers. Some companies stand up their own observability solutions using open source packages.
As it relates to commodity CDN, a similar consideration could be raised by a large content distributor. This doesn’t represent an existential threat to Fastly or other CDN providers, in the same way that a large web property running their own data centers isn’t the end of AWS.
If fact, AWS provides a useful graphic to their AWS Cloud Practitioners to drive home the point. It identifies six advantages of using cloud computing versus running your own data centers. I would argue the same considerations apply to CDN.
Of course, Fastly offers more than basic CDN. Even a large company that dedicated resources to building out their own delivery network would quickly find themselves stymied by increasingly complex use cases. For video streaming, they would have to deal with surge protection, intelligent routing, changing formats by device, dynamic ad insertion, manifest manipulation, in addition to maintaining sufficient capacity for global distribution. Beyond the most basic use cases, the content distributor would be better served by outsourcing delivery.
Fastly Take-aways
Fastly has experienced a rough couple of months. I still see a long-term opportunity in owning the stock, but acknowledge the near term execution risk. While Q3 revenue growth of 42% stepped down significantly from Q2 levels, it is still higher than growth rates in the high 30% range from 2018-2019. The impact of TikTok was substantial and largely clouds financial results. The impetus for TikTok’s reduction was exogenous and not representative of competitive positioning or delivery quality. If anything, the heavy reliance of TikTok on Fastly’s network is a testament to Fastly’s ascendance as a viable competitor to Akamai and other legacy incumbents.
Looking forward to Q4, the overhang of TikTok carries forward. While the top-line revenue target of 36-43% appears favorable on the surface, it includes up to $8M of deferred revenue from Signal Sciences. This would imply just 26% organic growth, but could be higher as the actual amount of Signal Sciences revenue realized may be lower. Additionally, given their experience with Q3 estimates and the inherent variability of Fastly’s usage based model, it is likely these estimates are conservative.
Customer growth metrics have also been mixed. For customers already on the platform, the annualized increase in their spend is impressive, whether one includes the impact of churn (141% LTM NRR) or not (147% DBNER). These metrics imply that large customers have been increasing their spend by about 40% each year, which aligns with Fastly’s own commentary in analyst events. Given that 88% of revenue comes from enterprise customers, this spend expansion could drive high revenue growth by itself going forward.
However, the addition of new enterprise customers has slowed down in the past couple of quarters. While Fastly has added record numbers of new total customers in each quarter of 2020, fewer are crossing the $100k spend threshold for the trailing 12 month period than in prior years. Management attributes this to some customers in impacted verticals (hospitality, travel) dropping below $100k and asserts that the number of customers moving past the $100k threshold is still inline with prior trends. In theory, the enterprise customer count should re-accelerate as these verticals recover. Still, Cloudflare has grown large customers at a faster rate, so there may be something else happening here.
Fastly did close on the Signal Sciences acquisition on October 1st. That revenue will be included in the combined results going forward. The cross-sell opportunity was highlighted in the acquisition thesis, where services can be promoted both ways. At Fastly’s user conference, many existing Fastly customers expressed interest in rate limiting and bot mitigation. With Signal Sciences, Fastly is creating an additional product category, Secure@Edge, which will supplement their edge compute offering. In addition to revenue and product synergies, Signal Sciences brings higher margin products. At the Needham analyst event in November, the Fastly CEO estimated that gross margins could increase into the low 70% range, up from around 60% now.
The Altitude user conference in mid-November provided a view forward. First, presentations from existing customers reinforced the importance of Fastly’s offering to many major Internet properties and video streamers. Their level of infrastructure integration goes far beyond fungible CDN solutions in these cases, demonstrating that Fastly really can be sticky. Examples of companies that have embedded Fastly’s services deep into their infrastructure include Viacom CBS, Gannett/USA Today, PayPal, Vox Media, MIT, Grubhub and Ticketmaster. Additionally, a sampling of attendees to the North America event showed continued interest from many other large players and potentially some new customers.
The most significant take-away from Altitude was a glimpse into the product roadmap for 2021. Fastly subtlely revealed two new product directions, in addition to known edge offerings of Compute@Edge and Secure@Edge. These were a deep observability solution with Observe@Edge and enhancements to their existing video streaming and content delivery business in Perform@Edge. There was even reference to a new data management capability called Data@Edge. Each of these could generate stand-alone revenue streams in the future and represent facets of a full-featured @Edge platform. Job descriptions also imply there are many more product extensions planned, all powered by these edge capabilities.
And this brings us to the core of the Fastly investment thesis. To me, Fastly represents a bet on an innovative team that has applied hard core engineering to redefine each product category they enter. They first did this by disrupting the CDN market and rapidly grabbing share from the incumbent providers. Evidence of this lies in their marquee customer list, representing the most advanced and discerning Internet players. If Fastly didn’t build a better CDN, they wouldn’t have won this business from incumbents, who arguably already had the advantage of scale and pricing.
More recently, they have been applying the same deep engineering to edge compute, choosing to forgo the predictable path of leveraging existing solutions for isolated serverless environments to build their own highly optimized runtime in Lucet. They continue to question existing conventions and push boundaries in other areas, like using CRDT’s for a distributed data management layer. All of this is delivered from a software-defined network that allows every user request to be inspected, logged and routed dynamically. Implied new product offerings for Perform@Edge and Observe@Edge also make use of these capabilities.
Not to be overshadowed, Cloudflare has been been executing magnificently. Their product release cadence has been extreme, with each subsequent “release week” outdoing the last. The leadership team is very engaged with the community and casually drops hints of even more to come, with a casual air like what they just delivered was no big deal. Cloudflare’s vision that The Network is the Computer puts them on a timely trajectory to disrupt many technology sectors that gravitated towards delivering security, compute and storage from single points, whether encapsulated as endpoint protection or large origin data centers. As technology value chains swing back to leveraging the network, Cloudflare will be in the pole position.
So, what is an investor to do? For me, I would like to own both Fastly (FSLY) and Cloudflare (NET). Like watching two Grandmasters in the first moves of a chess game (yes, I just finished The Queen’s Gambit), I think it’s too early to call the outcome. I do think these two are far ahead of incumbent providers in delivering next generation distributed network, data, content and serverless solutions. The cloud hyperscalers will want a piece of the action as well, but their efforts will be diluted by their breadth, offering many large niches for these more nimble innovators.
Investment Plan
Given Cloudflare’s (NET) strong execution over the past several months, I had been accumulating shares into my largest position prior to their Q3 earnings report. Given their outperformance, NET now makes up 25% of my portfolio. For FSLY, I have landed at a 10% position after the drop in share price following the October peak and profit taking in recognition of their execution risk. I will likely ramp back up my FSLY allocation as new product offerings are released and show traction. Given the vision Fastly has laid out, there should still be plenty of upside.
I had established a 5 year price target for FSLY shares of $155, back in May when the stock was trading at $38.50. The shares are currently trading around $83. Even with the drop, that represents about 115% appreciation. I will keep the price target in place for now and will revisit it next year, once I have more visibility into the 2021 plan.
NOTE: This article does not represent investment advice and is solely the author’s opinion for managing his own investment portfolio. Readers are expected to perform their own due diligence before making investment decisions. Please see the Disclaimer for more detail.
Always amazed at the breadth of insight your provide. It’s a crime that I can access such posts for free. Thank you once again.
I have some concerns on Fastly’s competitive landscape against Cloudflare going into the future. Cloudflare had been a stronghold in the SMB sector, providing a huge breadth of performance & security services to SMBs frankly for free. Cloudflare’s entrachment in the SMB sector makes it hard for Fastly to penetrate, adding reasons for concern (or re-assurance for Cloudflare shareholders!). Cloudflare CEO Matthew Prince has touted multiple times in their 3Q 20 earnings call about how it has experienced accelerating enterprise customer growth, which has been Fastly’s stronghold. He even threw shade at Fastly, noting how “none of our customers account for more than 5% of revenue”.
While edge computing picks up steam, Prince has also emphasized the importance of data regulations, focusing on Durable Objects (though still innovating in the Workers front). As an example of a precautionary measure, it has partnered with a Chinese equivalent provider Yunjiasu (subsidiary of Baidu), in order to make sure its Chinese businesses are not affected and enterprises looking to enter the Chinese market can safely rely on Cloudflare over others. While Fastly is working on an enhanced data management solution, it seems that Cloudflare’s trojan horse of vertical integration may be the foundation for an abrupt takeover, as their breadth of service offerings could overwhelm any other competitors.
Lastly, one of Fastly’s advantage over Cloudflare is its streaming offering. This I believe is one of the reasons forcing enterprise customers to Fastly as their business models may depend on fast and reliable video delivery. While content delivery is getting increasingly commoditized, if Cloudflare jumps into the ship of streaming deliveries, I believe it can be another reason for customers to choose Cloudflare over Fastly.
Of course, these are preemptive concerns that require quantitative results to confirm. Still, I think Cloudflare leaderships’ insights and subsequent trojan-horse building for preemptive preparations may be quiet signals. Would love to read a standalone report on Cloudflare from you. Always appreciating your posts!
Really excellent overview as always. Just a quick one – I noticed that Unity have released a CDN offering. As one of the largest operators of gaming infrastructure, this is significant. Do you know if they will have created this themselves or piggy-backing off another provider? Also has implications for further feature releases on their end to optimise the network and delivery experience for their client’s games / virtual experiences.
Thanks – I looked into the Unity CDN service briefly. In the FAQ’s, they do imply they are leveraging another CDN provider “Cloud Content Delivery is built on the infrastructure of a leading CDN with rapid delivery nodes in countries around the world.” I am not sure which one they use, but know that Akamai and Limelight have traditionally focused on game delivery. This hasn’t been a market for Fastly in the past, as the large binary downloads don’t really benefit from the programmability of Fastly’s content delivery solution. That might change in the future, but I don’t think this represents any kind of concern.
Thank you for the great article. Could you please address one thing that wasn’t in your article? My understanding is that FSLY revenue model is one based on usage, meaning, the company earns revenue based on their customer’s usage during a particular time period. If a customer doesn’t use their services, FSLY earns no revenue. This is much different that most software firms who revenue is based on a recurring licensing model, in which they book a steady revenue stream per customer regardless of how much that customer uses their service during a given period. I believe Cloudflare is like this.
Until FSLY changes this revenue model, they will always be subject to the what happened to them in the Q3, where they had to pre-announce poor earnings and guidance not only because of TikTok, but because some of their larger customers didn’t use their service as much as they forecast.
To me, this makes FSLY subject to the whims of their customers, who can apparently switch to another CDN (like TikTok did) without much trouble at all. Is this usage-based revenue model a concern for you?
Hi there. You raise some good points here. First, Fastly’s usage-based revenue model does create volatility in revenue guidance and consistent delivery. As we saw over Q2 and Q3, for some quarters actuals can far exceed expectations and then others they can underperform. Fastly leadership (and investors) will need to learn how to manage for this. Other companies, most notably Twilio and the cloud vendors, have revenue models that are largely usage-based and have figured out how to smooth out the variability. Tactics like committing to a minimum usage level with tiered pricing have worked. Also, Fastly leadership has hinted that they are evaluating other revenue models, particularly given that Signal Sciences operates on a subscription basis (similar to Cloudflare).
I think Fastly will be able to figure out an approach that provides the right balance of predictability and flexibility. Keep in mind that some customers prefer a usage based model, if their business is seasonal. It prevents getting locked into a higher price to accommodate max usage. I have experienced this at a past company when negotiating with subscription based software vendors, where 80% of our business was generated in the summer. So, I had to figure out some mechanism to handle peak usage in the summer, but not overpay in the winter. Usage models cut both ways.
Regarding the ability for a customer to switch CDN providers easily, I don’t necessarily have a concern around this. It’s actually not that easy (non-tech folks seem to think you just flip a switch). It can certainly be done with sufficient internal political pressure. If I were told to switch CDN providers, my Eng team would still need to do the following: update content publishing workflows, code to a new CDN API (assuming the new provider has one), integrate with my team’s CI/CD pipeline for deployments, and test/test/test. Yes, it can be done more easily than switching out a database, but is at least as fungible as observability (DDOG, DT, etc.), endpoint protection (CRWD) or CPaaS (TWLO, BAND).
Also, as Fastly products work down the stack (compute, app security), switching costs will go up. Watching several of the customer presentations at Altitude, companies have embedded Fastly pretty deep into their content delivery infrastructure. Examples were Viacom CBS, USA Today and PayPal.
Fastly does need to diversify its large customer dependency. Twilio went through the same challenges early on (Uber) – and still are expected to report percent of revenue from Top 10 customers even now (which has been steady <15% for a while).
I really appreciate your detailed response. Thanks! Dave
Peter , do you find it credible that language support for WebAssembly will not be an issue for Fastly 5 years from now. Is the developer world moving towards websssembly as a common language? I’m not technically Davy enough to know ??
Lucet supports any language that can be compiled to a WebAssembly binary. That means more languages than just WebAssembly can be used for Lucet. Those languages just need to have a reliable, working compiler into a WebAssembly binary. Currently, that list includes Rust, C, C++ and of course, WebAssembly. Fastly just added support for AssemblyScript, which is a cousin of JavaScript. AssemblyScript has more rigorous type safety and a few other constraints, but would generally be familiar to JavaScript developers. Rust is also gaining in popularity for high performance server-side development.
To the Fastly CTO’s point, there likely will be more languages ported to support WebAssembly binaries in the future. It just requires the open source community to write the compiler for each. However, some popular languages, like JavaScript, will likely never be supported, as they are too flexible in some language conventions. In order to be highly performant, WebAssembly requires more rigor in certain semantics. That would ultimately underscore the trade-offs in runtimes over time. For large organizations, having a small engineering team that specializes in edge compute would make sense. In that case, they would be fine with using a specific language from the available choices. The challenge would be for smaller teams that have centralized on a single language, like JavaScript, for all development.
Simply awesome… hard to find better info for non tech investors than yours!
Good job!
Hi Peter, another great analysis! what do you think is the best GTM strategy for Fastly? Fastly reminds me of Slack in a weird way. Enterprise accounts for vast majority of their revenue but they both have hard time growing enterprise accounts. I do hope they announce their new head of sales soon. I think Joshua never really talked about sales initiative. and there’s definitely a high engineering to sales ratio at Fastly.
also why do you think they are limiting Compute@Edge at this point? as it’s mentioned in the Needham conference, it’s not a band-width heavy revenue driver.
I also think them reserving capacity for TikTok is somewhat unrealistic. I don’t think TikTok is ever going to give them as much traffic as they did before. Even if regulation risk went away, they know they need to rely on themselves ultimately in case someone else picks up on them again. They are definitely trying to internalize content delivery and willing to invest. Fastly needs to realize this and find their next TikTok-like customer. If you feel like you can always fall back on a customer, then you will never be motivated to find the next customer.
Another excellent commentary, Peter. Thank you. Lots to say in reply (especially as an investor) but will remark only with…
I chuckled (no, really I did!) when I read your comment “[Cloudflare’s vision that] The Network is the Computer…”
That statement was George Gilder’s near-mantra back 20 and 25 years ago, he said it so often; in fact, a few of us teased him about his repeated use of the phrase. In time, I learned the quip did not originate with GG but Eric Schmidt, as this 24 years old WIRED article (by George) reveals…
“BACK IN 1993, in a midnight email to me from his office at Sun Microsystems, CTO Eric Schmidt envisioned the future: ‘When the network becomes as fast as the processor, the computer hollows out and spreads across the network.’ His then-employer publicized this notion in a compact phrase: The network is the computer…”
The complete WIRED magazine article makes for fun reading in a time-capsule sort of way
https://www.wired.com/2006/10/cloudware/
Thanks again,
David
We’re drifting from the subject but I found that Cloudflare wrote about the history and meaning of the phrase in two blog posts:
The phrase was first coined in 1984 by John Gage, the 21st employee of Sun Microsystems, where he was credited with building Sun’s vision around “The Network is the Computer.”
https://blog.cloudflare.com/the-network-is-the-computer/
https://blog.cloudflare.com/john-gage/
Thank you for the correction and the two links!
Michelle Zatlyn, the CTO of Cloudflare was on the Investor´s Field Guide podcast recently and said Sun never trademarked the super tagline and so Cloudflare decided to get it trademarked.
https://investorfieldguide.com/michelle-zatlyn-protecting-the-internet-founders-field-guide-ep-11/
Thank you for another wonderful piece!
In their website, Fastly names airbnb as a customer. However, as of recently, when I use a basic CDN finder tool (such as the one at CDN Planet) I see only Akamai under airbnb.
Is there a way to check if this is indeed the case and if Fastly lost another high-profile customer? Are these tools accurate and reliable?
I would not rely on CDN finder tools to determine if a particular web site or service is a customer of Fastly’s. While these tools do sometimes show a correlation, there can be a high level of false negatives. Here are a few reasons:
– A Fastly customer can use a service other than CDN (WAF, DDOS, etc)
– Most web sites or services use different URLs/Hostnames for APIs, microservices, video delivery, etc. than the URL of the home page. If you simply type “xyz.com” into a CDN finder, you will see how traffic is served from their home page. But, the home page is often not where the bulk of traffic is delivered from once you download their mobile app, for example. Their API service powering the mobile app might be delivered from a different hostname, and that accounts for most of the service’s traffic. Oftentimes, the home page is just for initial sign-ups for marketing promotion.
– Use of CDN services can differ geographically, by time of day or other factors. So, you might be located in one part of world and see a different CDN from another user, or the CDN Finder tool might do the same. Alternately, use of CDN services might be shifted around by the customer to optimize costs by content type, time of day, etc.
– Video delivery is often performed at a different URL or even behind the scenes in ways that a CDN finder would not uncover.
Hope that helps.
I live in San Francisco. Enjoy the articles.
Do you plan to hold more Fastly or Cloudflare equity in the next five years?
Can you write an article on what potentially comes after serverless edge computing?
Hi – thanks for the feedback. I lived in San Francisco for most of my career. In terms of holding more FSLY or NET over the next 5 years, it’s hard to say. I currently have a ratio of about 2.5 times more NET than FSLY in my personal portfolio. However, as the story for Fastly materializes in 2021, I may bring them to closer parity. Cloudflare is executing better currently and has strong momentum, hence my bias towards that name at this point.
Regarding themes after serverless edge computing, I will definitely cover that. They are nascent at this point, so probably something for next year. Edge networks and computing still have a lot of runway for the near term.
Thanks Peter.
Abdiel Capital is mostly a tech-focused mid-cap growth hedge fund and their largest position as of 9/30/30 was Fastly. I have a good friend at Cloudflare on the sales side. I agree that there is room for both in the TAMs of CDN and serverless edge computing.
Difference in fortunes between elastic and splunk. it appears elastic might have reached the inflection you were looking for.
Yes – I am working on a recap of Elastic’s latest quarter now. Very pleased with the linearity of revenue growth for the last two quarters and marked improvement of profitability measures in parallel. Assuming growth stabilizes in the low 40% range, ESTC would be well positioned for 2021. As IT spending headwinds abate and impacted verticals recover, Elastic might even experience some acceleration in growth. I foresee a multiple expansion coming for ESTC that brings it more in line with software peers in the 40% revenue growth range. Their current P/S ratio in the low 20’s appears low compared to other names with similar revenue growth.
Im surprised it is cheap relative to the other software companies despite having an impressive slate of products. I agree at some point the stock price will increase in value to reach the sae valuation as the other companies. definitely a buy now.
Fantastic work overall Peter! I just started reading your blog today. This is a bit OT to this specific post on FSLY. I am wondering why you have are not interested in other Platform plays like ServiceNow (CRM) – they have enabled other companies like NCNO to build on top of them and release SAAS offerings. Second, also wondering why don’t you cover Platform plays like Facebook (FB) – across their FB, messenger, Instagram estate they provide tons of APIs and its a high growth company. Do you avoid Consumer space companies in general? Overall, fantastic work, learning a lot and thanks for keeping all of this in public domain and free!!!
Sorry I meant Salesforce (CRM) above and not ServiceNow. Apologies.
Thanks for the feedback. Fair question. I bias towards smaller companies (relatively) as I think they offer more upside. Price appreciation generally scales with revenue growth, assuming the company can maintain roughly the same rate of growth over a few quarters. High revenue growth is usually easier to maintain at lower absolute numbers. As the company gets larger, it is increasingly difficult to keep up the high growth. I like to see annual revenue growth above 30%. This is more common for software companies with annual sales below $1B (with a few exceptions) and market caps below $100B. Regarding FB, I do avoid consumer products companies, mostly because I can’t offer incrementally better insight to understand the company’s true value.