Fastly: One-on-One With the Chief Product Architect – CML

Fastly (FSLY) is our number two Spotlight Top Pick and we have just completed our first one-on-one conversation with the Chief Product Architect and former SVP, Product and Chief Security Officer, Sean Leach.

(Not to be confused with Artur Bergman, the Executive Chairperson and Chief Architect.)

Update: 5-24-2021
I had one outstanding question that the company answered through email. We have included that question and response as the final portion of the Q&A.
End Update

As an aside…
When it comes to discussing Fastly, its technology, the technology of the Internet, and how it competes with Cloudflare, this is the best I can do. For better or worse.

Support has no more answers — no clarifying statements, this is it…

I hope you enjoy the journey, friends.

Fastly does expose some research institutions to Sean according to his LinkedIn Profile, but IR made it a rule that we could not proceed in the normal transcription process we do with CEOs, but rather we are permitted to summarize our findings in our own words.

So, the transcription portion will in fact read as a transcription of my questions and then a ‘what we learned’ paraphrase.

Since that’s the design, it does allow us to combine the transcription portion with the analysis portion, so this might actually read a little cleaner than a CEO interview.

This was a product and technology driven conversation, rather deep in some areas and had virtually nothing to do with revenue or other financial metrics.

This was a conversation about product and we are privileged to share it with you.

There is a good piece called What are Edge Networks? written by Muji (Matthew Eash), which might be a required place to start before reading the dossier below.

With a strong understanding of the technologies involved, the conversation we had may be far (far) more valuable and thought provoking.

Two images we will borrow from Mr. Eash are helpful.

The first is a diagram of how legacy CDNs (content delivery networks) work.

Source: hhhypergrowth blog

Those little circles are devices (a prior version dossier named them as servers) connecting to servers inside points of presence (PoPs) (geographic locations) and you can think of the servers as a collection of very small (dumb) hardware designed to deliver static web content that help make the Internet faster by taking the load off of a single network (the central cloud) and distributing it.

We choose the term ‘collection’ rather than network, because the legacy CDN infrastructure did not have an all encompassing smart network that connected them all into a larger brain, roughly speaking.

But, then we got the evolution of the CDN network into an edge network, where first, the little servers were reconstructed with more ram, more storage, and more computing power (more CPU cores), and second, were connected by a software defined network.

Source: hhhypergrowth blog

Here we see a new architecture by connecting the PoPs with a programmable network (a software defined network) — it’s denoted as the orange box that connects the PoPs.

When technologists refer to edge networks, they are referring to the network formed over both the programmable network (the big orange box) and the edge servers (the little orange blocks).

I’ll just repeat it — the upgrade of the little orange boxes and then the big orange box has changed and will change the Internet forever.The orange box itself, its existence, separates Fastly, Zscaler (security), and Cloudflare from legacy CDNs (no matter what the CDNs call their network).

The architecture of the orange box is what separates Fastly from everyone else, in our opinion, and we will discuss that at length.

The machines in the PoPs are larger and smarter, and they are connected by network which allows for real time flexibility, logic injection, automation control over the entire global network at once and customization.

Basically, jargon to explain that the dumb / small computers with limited operability that could only function to distribute load off of a central cloud, can now (are now) turned into an actual network — its own private cloud away from the central cloud and with that built in programmable network, the universe of operations and functions have exploded.

This is the edge cloud and we believe it will change the way we use the Internet, what we can do with the Internet, and then feather out into security.

The old way is archaic and limiting, whether that is just functioning on a central cloud which is slow and expensive, like Amazon/Microsoft/Google or legacy CDN networks, like Akamai.

Then we wrap this up in the thematic, edge computing, as we see a tiny market growing 20-fold in six-years:

A change has come — let’s call it an evolution.

We just covered about 1% of the edge cloud as a refresher, please do go back and read our most recent dossiers on Fastly for a deeper dive.

And, as you have read and will read, we believe that one edge cloud is “better” than another based on speed, scalability, and security. That means an investment in Fastly is an investment in founder Artur Bergman.

In general, in this dossier, we discuss, clearly:

* The differences between Fastly and Cloudflare

* Why we feel Fastly, in the long-term, has the brightest future

* The risk of what having ‘the best technology’ and not very good selling means

* Fastly’s security offerings

* Compute@edge, its progress, present, and future

We note that there are several perspectives to look at objective fact.

Fastly delivered about $300 million in revenue last year (2020). This is a fact.

And now the perspectives:

* Oh my God! Fastly’s technology is so good that it did $300 million in revenue by, essentially, word of mouth and no formal chief revenue officer structure.

(This is how the CEO described it to us a few months ago, and he did not do so for a pat on the back — he was critical of it.)

* Oh my God! Fastly has focused so long and so hard on technology that they have ignored the selling portion of the enterprise and are now behind — at a point of standstill, having to generate inertia to move forward again.

Our perspective goes back to the objective fact which yields truth in several perspectives. It’s many things which can be true at the same time.

Yes, Fastly’s tech is so strong it did $300 million in revenue by word of mouth and, yes, Fastly has woefully under served the sales portion of the business.

Last quarter the company announced the hiring of its first Chief Revenue Officer and in the last quarter the company saw the largest single gain in new accounts ever.

Whether that was due to the new CRO, or a new trend, or no trend at all, we’ll just have to wait and see.

But another perspective is that a quarter means very little and in the case of Fastly, as you will read, a year might not matter yet either.

As the company works out its sales team and execution, we don’t simply give it a free pass. We expect to see 30% revenue growth compounded over the foreseeable future even as the sales process stumbles along.

If (when) the sales process does turn into as efficacious a machine as the technology, then we expect in excess of 30% CAGR for several years — as in more than five years.

When addressing the announcement that Fastly would be going in another direction from its CFO of five-years, CEO Joshua Bixby pointed out to us that this is a repeating pattern that Fastly is engaging in, to scale the business with executives that have worked with multi-billion-dollar sales.

The company recently hired the former chief people person of PayPal, an executive from VMware as chief revenue officer, and a CTO with scale experience.

He is looking to do the same with the CFO position — “you can rest assured that one of the characteristics that we are looking for .. is having seen around the corner.”

We note that once that CFO has been named, it does leave pressure on the CEO, then with a stacked team, to perform. There is risk there for the CEO, and therefore there is risk there for shareholders.

Our view is that it is reasonable to be bullish, even very bullish, on the company that creates the best technology in a thematic that in and of itself is growing so fast that tailwinds alone will thrust most companies forward.

We know that the best technology doesn’t always win — in fact, you could make an argument that when the best technology competes against a peer with the best marketing, it’s the latter that wins the spoils (and the stock price gains).

The space Fastly (and competitors) live in is, however, defined by the largest enterprises with a hyper focus on customer engagement and ROI from technology — that should lead to a desire for the best technology and we do see that with Fastly and its roster of enterprises.

But the future may well lie in the hands of the best marketers that have ‘very good’ technology, and that would be Cloudflare. We have detailed discussions about this below.

Ultimately, Fastly is a company that has always built for the future, not the present, and by the time the present catches up to the future, we do see a history of industry changing successes.

While Fastly is the ‘little guy,’ its impact on the technology of the industry is far outsized.

What seemed dumb and overkill before now seems obvious — we’ll discuss that below.

What was once a tiresome exercise with no real value add is now defacto for the industry, with legacy left behind.

We believe we will continue to see that pattern emerge with Fastly, but now with much larger bets on technology — moves that cannot be replicated easily, if at all.

In total, we have had a standing belief that Fastly’s technology, based on architectural decisions, is the best in the world in the space of global programmable networks and edge compute (I feel the same way about CDN, but that’s a different subject).

We believe that architecture makes it the only truly scalable programmable network and we think that the largest enterprises in the world are starting to catch on (and thus Fastly is so dominated with enterprise business).

I spoke with the Chief Product Architect just to educate myself and our wonderful community, which is to say it’s all out there, but I’m not good enough to grasp it all without help.

That conversation, the one we share below, has reiterated our view, but more importantly it has allowed us to describe the technology and its differences between any other company clearly, which is to say, the statement ‘Fastly’s technology is the best,’ is kind of meaningless without some explanation.

I can now at least communicate the differences I see with detail, and clarity.

We also want to express how highly we think of Cloudflare (NET) in this arena, and how much of an impact these two companies will have on a better version of the Internet, because as of now, as a CEO running an enterprise, the current infrastructure sucks… it just does.

Technology needs have grown far faster than the tech from the cloud titans has grown and these two companies are enabling it and it’s fabulous.

But, yes, we believe that Fastly’s technology, really from an architectural level, is the best and clearly so.

Now, stock prices could be a different thing altogether – the best tech does not always win (whatever win means).

For us, if it’s in the realm of infrastructure, we just have to invest in the best tech, and if that decision means not the best returns in the future, then yeah, it’s an opportunity lost.

We don’t have the future, so our investment goes with the technology with the idea that probabilities are in favor of the best tech winning, but not guaranteed, and there will be new entrants, current players adapting, and many winners.

But, please allow for the perspective that we are wrong. Sometimes the companies with the most focused sales teams win — and they win a lot — leaving the tech guys down and out.

Now, please enjoy our dossier.

One-on-One with Fastly’s Chief Product Architect

Ophir Gottlieb:
Okay. I’m going to start with a bit of a soliloquy, because if that’s correct, then I can actually have the possibility to ask you questions.

This is how I see it. Fastly built its edge networks from a software-defined networking architecture, which allows its flexibility, its logic injection, automation control over the entire global network at once, customization, more than we would loosely call the legacy CDN.

In a sense, legacy CDNs actually have, back then, intentionally placed architectural designs from the past that make it difficult for them to really move into this programmable network.

(This is in direct reference to those images we shared at the top of this dossier; the dumb connections versus the programmable network (the orange box).)

It’s their own architecture, their legacy is holding them back. And, while Fastly CDN products have their own advantages, like straight down the middle CDN, I want to talk about the programmable network and the security part.

I just want you to know I’m not selling Fastly CDN short, I just want to talk about the other stuff.

Fastly’s programmable network is in fact its own private network away from the central cloud.

The power lies in this network that connects all the edges at the points of presence (PoPs).

I have many questions, but first after that long soliloquy, did everything I just say roughly true, because my questions are kind of based on that.

We Learned:
That conceptual understanding of Fastly is correct.

When Fastly was founded about 10-years ago, the Internet was a far different place than when the legacy CDNs, like Akamai, started their businesses in the 1990s.

There was no need for several thousand points of presence the Internet and routing had converged.

The Internet, and therefore Fastly, needed far fewer PoPs because the focus was not just around delivering static content.

The world had changed to delivering a programmable network that enterprises could then customize with their own programming.

Fastly has built much larger vertical PoPs which relative to the legacy systems have a lot of CPU cores, a lot of RAM, a lot of storage, and that has resulted in a much better CDN experience.

Having said that, this early decision also gave Fastly the ability to expose the compute layer of the network to its enterprise customers, which ultimately led to the compute@edge product line.

I want to start backwards and go into some particular use cases.

One great example of the control of the programmable network itself is Fastly’s origin shield, where it essentially promotes an edge in a certain location to sort of act as a master edge, communicating with origin.

And because of that, the origin shield acts as security for what I guess we could call the first mile.

Can you talk to me just about the origin shield product, and sort of raise my IQ on just that, what I’m roughly calling the first mile?

We Learned:
As background, Origin Connect is a direct private network connection between an organization’s origin server and a Fastly Shield point of presence (POP).

Fastly has noted before that ‘Using Origin Connect is akin to plugging directly into an outlet instead of connecting to an extension cord first.’

Now, onto Sean’s insights.

Fastly’s origin shield provides two distinct functions, one surrounds security and the other surrounds content delivery.

The media shield product is focused on content delivery.

The technology it uses is called ‘request collapsing.’ When a piece of content or something from the central cloud or data center that receives heavy traffic (like a live sporting event)
and it is Fastly’s job to shield the origin (the central cloud) from all of the traffic.

In this case, the CDN prevents millions of clients from all acquiring that single piece of content from the central cloud.

Fastly has the clients at the edge servers, then those edge servers hit the shield.

Consider end users in three regions (in the images above): Lyon (France), Washington DC (United States), and Tokyo (Japan). Each of these regions has a local Fastly POP available to them that caches information by default.

If the user in Lyon requests a resource that is not cached on the Fastly Paris POP, however, that POP will make a request to the origin server, cache the resources in the response, and return the cached resource to the user.

With shielding enabled, however, the POP you designate collects all requests to your origin server instead. For example, the Fastly Virginia POP was designated as the shield for a server located in the AWS us-east-1 region (as shown in the illustration below).

So, there’s one request to the backend for the snippet of content, encoder, application, and, then that services all of those clients.

This greatly decreases your need for the central cloud infrastructure.

This would be the CDN portion.

But there is also a security benefit, which is what I was asking about.

The security product (benefit) is having a private interconnect between Fastly and the origin which does not expose the central cloud IPs to the rest of the Internet. This means they cannot be attacked.

The only route to the origin is through Fastly’s edge — that’s the security service.

All of this is clever, but none of it is really novel at this point when compared to Cloudflare.

This was an introductory question to open up a larger security discussion.

Okay. Now, let’s talk about security.

I’m going to call that the first mile, which might be a dumb name. But does Fastly then have an end-to-end solution that secures a funnel from the origin to an edge cloud, and maybe that’s a master edge, maybe not.

Then second moves from that edge and secures the funnel to the programmable network, and then third secures the programmable network itself, and, finally fourth goes from the programmable network and secures the funnel to the end device?

Truly end to end security. Does Fastly have that?

We Learned:
Fastly does offer security all the way from the origin to the last edge cloud point, but does not provide security on the actual device.

Here is our third image from the hhhypergrowth blog:

Source: hhhypergrowth blog

(Fastly provides security across this entire domain, into the origin server, but not onto the end user device.)

If we look at security as a combination of confidentiality and vulnerability protection, Fastly provides encryption from the device all the way to the origin and back.

Fastly focuses on the security protection within its programmable network and any traffic destined to the customer’s applications.

Device security is where Zscaler and Palo Alto Networks come in.

(I believe that Cloudflare for Teams does secure devices, possibly through partnerships, but I’m not an expert on Cloudflare.)

So, when the traffic ingresses and egresses in Fastly’s network, the company provides all of the security from that point to the application and back.

But once it egresses Fastly, traffic it goes to the device or the local land or local network security and Fastly does not secure the devices themselves.

All right. Is there a name for this holistic security? Is this secure at edge or is this several products for each funnel? This would be essentially clarity for product names and the ability for enterprise. Can enterprises pick pieces of this or this is called secured edge?

We Learned:
This is where the progression from and the integration of Signal Sciences (SigSci) comes in.

Fastly had the programmable network and the scale but needed the precision and the easy-to-use security of Signal Sciences.

SigSci has technology that can do detection and mitigation of security threats that can run in an enterprises central cloud environment or even a private data center environment.

The integration gets that SigSci technology to run on the Fastly edge as well.

That’s what is referred to as the secure@edge product and allows enterprises choose where they want the security.

So, enterprises may have application in AWS (or any central cloud) or any private cloud (an enterprise cloud). They have microservices that are running in these clouds that communicate with each other.

Enterprises choose where they want the security. Fastly can run the detection mitigation only within the data center, which would be security for internal traffic.

But the enterprise can also run security out on the edge to take advantage of the scale and the global distribution that Fastly provides.

That’s what the secure@edge and Signal Science acquisition allows; customers are able to choose where they want to run the detection and enforcement protection.

(Cloudflare does this too with a combination of different products.)

Previous to Signal Sciences, all of Fastly’s security logic ran in its edge network, not in the data center or central cloud.

Back then, Fastly could still protect those applications, but all that traffic had to flow through Fastly.

With Signal Sciences, Fastly can now offer security that runs only in the data center or only in the central cloud.

This is useful for enterprises that desire the security protection of Signal Sciences, but may not desire to change their edge provider.

So, in total, the SigSci acquisition allows enterprises to run security where it makes sense to them.

Sean did note that he felt this was a ‘big differentiator’ against some of Fastly’s competition — that is to run security in different locations.

I don’t think he was referring to Cloudflare in this case.

As for an objective measure of Fastly (SigSci) versus competitors, we can turn tothe Magic Quadrant of web application firewall (WAF) in 2020 From Gartner.

We see that SigSci ranks higher on ‘completeness of vision’ and lower on ‘ability to execute’ relative to Cloudflare.

This phenomenon is essentially the Fastly story, as we will discuss in greater detail below.

The top two WAFs according to Gartner peer Insights are SigSci and Cloudflare, with the edge (no pun intended) going to SigSci.

We see SigSci with the higher rating (and in fact the highest rating in the entire peer group) and a higher ‘Willingness to recommend.’

Of the entire cohort per Gartner peer Insights, SigSci has the highest ‘Overall Peer Rating’ and the highest ‘Willingness to recommend’ for companies with more than 80 reviews (SigSci has 210)

The cohort consists of:

AWS (Amazon)
Azure (Microsoft)

… and many others.

At this point, I was wholly satisfied with understanding the security offering, and wanted to dive into compute@edge and the fundamental and objective differences between Fastly and Cloudflare.

I want to go to the compute layer now, the programmable network. Cloudflare built its network on basically the Chrome V8 engine. Let’s call it a JavaScript engine.

And, I believe that Fastly actually built its network on a lower level, a systems level. This should offer significant performance benefits in time. It removes the browser level and goes one layer down. Before I ask a question about, is that fundamentally true at that moment?

We Learned:
Sean agreed with that premise and reiterated that is how Fastly sees the world.

He noted that much of his early time at Fastly focused on this rather large undertaking and the team saw that Chrome V8 was designed in the browser environment and Fastly needed to move to a server environment.

For the record, Chrome V8 is Google’s open-source high-performance JavaScript and WebAssembly engine, written in C++.

Fastly went ahead and built, ground up, a native WebAssembly compiler and runtime.

Lucet is designed to take WebAssembly beyond the browser, and build a platform for faster, safer execution on Fastly’s edge cloud.

For the technically oriented, this is from a substack entitled Fastly Edge Compute Explained (our emphasis is added):

Using WebAssembly, the runtime has been stripped down to a tiny footprint. The Fastly team deliberately left out any capability that wasn’t needed.In this state, the runtime resembles an operating system kernel and is packaged as a compiled code module. That is then swapped onto the processor stack in one operation.

This minimizes start up time and allows thousands of runtimes to spin up in parallel on a single server.

The Lucet runtime occupies into a few kilobytes of memory, versus at least 3MB for the V8 Engine.

Source: POFFRINGA substack

In 2019, Fastly noted that ‘Lucet is the engine behind Terrarium, our experimental platform for edge computation using WebAssembly. Soon, we will make it available on Fastly’s edge cloud as well.’

It’s now available as Fastly wrote in March 2020, How Lucet and Wasmtime make a stronger compiler, together.

Here’s more:

We believe WebAssembly will help define high-performing, secure edge compute. And when we open-sourced Lucet — the first WebAssembly runtime designed for edge computing — we knew it would be useful beyond the edge.This is one reason we formed the Bytecode Alliance, an open-source community focused on improving WebAssembly-based compilers, alongside Mozilla, Intel, and Red Hat.

You may recall that we spoke with Fastly’s CEO (Joshua Bixby) just a few weeks ago and specifically asked about the Bytecode Alliance, which Microsoft had just joined.

We encourage a read that line of questioning in the prior dossier Fastly CEO: One-on-One.

The short version is this:

We then discussed Microsoft’s recent joining to the Bytecode Alliance and the impact on the industry he noted:

…[W]hen Microsoft joined and you see Google and you see Intel; it really starts to signal that WebAssembly is the defacto standard.This is the VHS of the VHS versus beta story.

I then asked if Fastly was engaged with Microsoft on this topic to which answered “we are absolutely in talks.”

Now back to this dossier…

Sean noted the decision to create Lucet — to build it themselves.

He then brought it back to Fastly’s history of doing the difficult things first — the projects that may not be obviously ROI positive to short-term thinkers, but in the long-term may be the only real sustainable version of edge computing at scale.

We note the similarity to the earlier decision Fastly made to build its own routing and load balancing layer on top of Arista switches well before a programmable network was even a thought.

Sean said that was the best decision Fastly ever made technically with respect to the flexibility gained and therefore the ability to deploy PoPs quickly, the ability to control the network and program the network.

He believes that the decision Fastly made to build its own compiler runtime environment on top of the WebAssembly ecosystem will give Fastly far better long-term performance and stability and security benefits.

The team did look at V8, and decided it didn’t have the security and sand boxing requirements that Fastly needed.

Sandboxing is a software management strategy that isolates applications from critical system resources and other programs. It provides an extra layer of security that prevents malware or harmful applications from negatively affecting your system.

So, as you will read shortly, Fastly did this with an eye toward the future, years even, with a belief that without this systems level architecture, the future needs of the Internet (and enterprises) will be unservable using the Chrome V8 architecture.

As for evidence that this architectural move has some value, Fastly shared this snippet about compute@edge on its website:

At 35.4 microseconds, Compute@edge provides a 100x faster code execution startup time than other serverless solutions.”

Cold start times have been reported of 35 microseconds. This is at least 100 times faster than other approaches, like the V8 engine, which requires 3-5 milliseconds to start (3,000 to 5,000 microseconds).

Get ready now — this is where we will be discussing exactly the differences between Cloudflare and Fastly.

I’m going to go now a step further. Since WebAssembly (WASM) modules can run in any WebAssembly system interface (WASI), they’re compliant, this feels like the decision to go to the system level for Fastly is an architectural choice that roughly dominates an architecture built on V8.

So, if systems level can do everything that V8 architecture can do and then more, that would be a dominating strategy. I’m not using the word dominate colloquially, but rather in game theory.

So, a dominant strategy refers to the optimal option for a player among all the competitive strategy set, no matter how that player’s opponents may play, and the opposite strategy is called inferior strategy.

So, in this case, if an enterprise only requires compute and delivery that V8 could provide, Fastly and Cloudflare both suffice, but if an enterprise needs the scalability of a systems level compute layer, then only Fastly will suffice. This would be a roughly dominant design.

First, is that true, roughly speaking? And second, can you explain what that difference actually is, so the benefits of going systems level?

We Learned:
Sean felt it was true and the noted that Fastly has been spending a few years getting this compute layer out and stress tested.

He did note that there was ‘real significant’ production traffic (read: revenue generating traffic) already on compute@edge.

I bring this up because I have read countless posts on Twitter claiming this not to be true.

He noted that Fastly designed the system to be able to handle, what he referred to as, ‘the load of Fastly.’

He pressed to say that the goal was not to build an architecture that could handle ‘just some of the requests’, which, without specifics, he claimed others have done.

Rather the architecture was built to handle all of the traffic through Fastly.

He noted that if the decision to build the Lucet (WebAssembly compiler) was notdone on the systems level, he did believe that Fastly would not have been able to route all of the traffic through its network and still maintain the performance expectations that the firm holds itself to.

He then said that just as important as the performance, was the safety and the sand boxing between the requests.

From all of Fastly’s research, the company would not have been able to accomplish these goals with V8.

This is a stark and objective difference between Fastly and Cloudflare.

While it was a massive amount of work, and certainly slow, he noted that this architecture gives Fastly more confidence that enterprises would be able to build much higher traffic services on top of its edge, not just now, but in the next five to ten years.

I note this five-to-ten-year remark but it gets at the thesis behind Fastly.

The company has a vision of its products, its network, that must satisfy not just today, but several years in the future.

Sean’s focused on what Fastly expects the future to look like, and what Fastly expects of itself in that future.

He noted that he believed that the engineering that Fastly has done is a competitive advantage to any competitor naming scale and safety.

This is the ethos of Fastly, for better or worse.

The company named ‘Fastly’ doesn’t move that… fastly, but rather purposefully endures the effort to build its technology in a way that addresses the most difficult problems early, rather than build ‘easier’ today, and deal with ‘harder’ later.

Artur Bergman is just not the ‘do the easy stuff’ first guy.

We’ve had the pleasure of speaking with him twice (both shared with CML Pro) and even in those conversations his version of the world is rather clear.

Imagine if we had a chore list, personally, for the weekend. I’m talking about a list of ten things like emptying the dishwasher (easy and fast), doing the laundry (easy and not very fast), to refinishing the entire surface of the backyard deck, then re-shellacking it (hard and not fast).

This is the guy who would do the deck before even looking at the dishwasher or laundry.

So, an observer might see someone else ticking items off of a checklist and seemingly moving faster, but in the long-run, if bad weather hit earlier than expected, Artur’s deck would be done, and he could clean up the dishes while it’s raining outside.

The person that seemed to be moving quickly would have a ruined deck — but yeah, the dishes would be done.

Fastly has assumed its founder’s ethos.

In the realm of technology this is the best way, in our opinion, but in the realm of finance — of stock prices — of revenue — of customer acquisition, we could make a strong argument that this is not the best way.

So, there is a risk to Fastly as stock price — the best technology does not always win, and we can see the reasoning.

When we first introduced Fastly back in 2019 we noted that the best technology does not always win and if it does win it does not necessarily produce the best stock returns.

We went into and remain bullish on this company because we believe that in the realm of Internet infrastructure, the best technology has a better chance of winning than not.

This is an industry which actually does have measures — objective ones — and the largest companies in the world will see a difference that to many may be less obvious.

We also wrote:

Fastly has, perhaps incidentally, developed a personality and that …… [i]t’s not going to be a flashy marketing campaign or a loud CEO, this company is placing its bets on simply being the best technology in the world.

Artur Bergman, who was CEO at the time said to us:

We’re by far the best suited solution for that and in many ways the only one that really unlocks the power of the edge and really allows you to build globally reliable, secure applications.

Everything about this company is a focus on technology.

Shareholders like the best technology if it means the best stock return.

These two things do not necessarily equate.

Now, let’s continue with our conversation.

My impression is that this is very much sort of an ethos of Fastly.

In the beginning days, Fastly, I guess Artur back then was making decisions that were very forward-looking. Now some of the decisions like, “Obviously.” It wasn’t obvious back then.

And, so this one feels to me that… It’s another one where it’s not so apparent today the difference between going systems level versus V8.

It feels it’s going to take time to when it will be quite apparent.

And, this architectural change is actually not as easy to replicate as some of the other decisions having larger PoPs or SSDs.

This is actually straight down the middle architecturally. You can’t just change from being based on V8 to going systems level.

We Learned:
Sean reiterated that it was ‘a lot of work’ and they have spent years on it.

In fact, his exact words to that question were, ‘You nailed it.’

Back in the old days, Artur said you can’t build a good CDN without SSDs (Solid State Drives) and Akamai and the rest laughed.

And today, well, everybody agrees that SSDs are the only way to build a good CDN.

In the old days the criticisms of Fastly (and Artur) were that network provers needed to buy routers and load balancers. This was the way — this was the law of the land. You can’t program a switch.

And today, here we are, everybody is programming the switch.

Sean feels that the decision to go systems level is very similar and that in the future the realization will be as obvious.

However, this move is not easy to replicate.

This, as Sean said, was years.

Yeah. Okay. That’s my version of the world too. My next question is about compute. This is going to sound dumb, but I’m just going to ask it, and I’m going to let myself be embarrassed.

Is compute@edge essentially the programmable network built on a systems level architecture? Is that product that we’re calling compute@edge the same as what we just talked about, what I just described?

We Learned:
Yes, I have it right.

Fastly built compute@edge to have the ability to expose the interface, even more, to its customers.

So, rather than ask for Fastly to make configuration changes, now the enterprises have the power and flexibility.

Previously, Fastly could program the network, and did, but now with compute@edge, the company has exposed that functionality to customers as well.

He also did note that the company is just getting started on this in terms of the flexibility and the power that they are exposing through this interface.

Fastly’s goal is to make the network fully programmable using the compute@edge infrastructure and APIs.

He did say that Fastly had some short-term goals which he referred to as ‘really cool’ with respect to the use cases, like dynamic content manipulation.

There are also some ‘really cool’ routing use cases that Fastly is seeing some customers use, but really it’s about the potential of the fully programmable network.

We repeat this to repeat the mantra that an investment in Fastly is an investment in patience — patience that the best technology in the world will be the winner.

Okay. I talked to Joshua [Bixby, CEO] about this.

Where is compute@edge in terms of product? Is it in production? Is it available to anyone who wants it?

I know at one point it was a limited beta, but that was I think a few quarters ago.

Where is compute@edge now and where will compute that edge be, I don’t know, in a few years, in a year or whatever it is?

We Learned:
The product is in limited availability right now and the difference between that and beta is that Fastly can put production traffic on it.

He noted that Fastly has ‘quite a few customers’ putting significant production traffic on it. This enables the customers and Fastly to learn what the platform can do, and where it can go.

Sean called it the Fastly way — that in the very early days they didn’t know what it had built — or perhaps better said, the company thought it had built a powerful CDN, but what Fastly really saw were their customers use the power of the first version of the first generation of the platform to build use on top of it that Fastly maybe had not conceived of.

With compute@edge, Fastly has given enterprises even more power and finally, some of them are in production. Again, Fastly is starting to see new use cases, use cases Fastly hadn’t thought of before.

To put a finer point on it, he said that that’s where Fastly is right now — production traffic that is showing new use cases.

I have a particular view of the world, which is it goes too fast for some people. This is going to sound so silly.

I just feel the Internet is fundamentally changing, parts of the infrastructure of the Internet in particular in this area. It seems so obvious to me that in a few years… We don’t have to talk about Fastly.

I’m talking about certain applications, running this where you have this virtual end to end security. We have origin shielding, where things are faster and safer and more programmable.

There will be no version of the world where someone at scale isn’t doing that.

It seems so obvious to me, but I don’t know. I just look at what’s happening in infrastructure.

I just look at my company. This is what we have to do. The old way is bad. It’s insufficient even for us.

We Learned:
Sean agreed, said they were seeing the same thing and then noted that it was happening even with partnerships and integrations.

Here he brought up Okta and the partnership announced a few months ago — the true path of zero trust and zero trust protection.

From Fastly’s blog post, which Sean actually authored:

Our new partnership with Okta will integrate our web application and API protection platform with their identity and access management platform.By feeding intelligence to Okta, we can help them spot potential bad actors to make better authentication decisions.

COVID made this a requirement, because people were no longer in corporate headquarters but were rather distributed. So, apps were distributed and then people were distributed.

It was simply true that enterprises couldn’t trust the network anymore.

That meant there had to be a way to combine application security with identity, which Okta, of course, is the leader in.

What Fastly built with Okta helps identify a different layer of risk — namely if an enterprise is using Okta to authenticate users, and then a user starts to display activity that might look nefarious — the network needed a way to signal to that identity provider that something wasn’t quite right — a signal that a more intrusive identity checking of this end-user is required.

(This, again, is where the idea of a programmable network as opposed to simply connections between ‘dumb’ PoPs has created a new Internet. The ‘orange’ box is the compute edge.)

Source: hhhypergrowth blog

That might mean forcing an additional two-factor and it might mean simply killing connection completely.

What Fastly built in conjunction with Okta was the ability to take the security signals that Fastly has as it can see the traffic going through its network and adding a protective layer over the applications and then signaling to Okta that there may be a compromise.

This is an example of a new use case — the new world of a programmable network, in real time now.

Previously enterprises might have to wait an hour to authenticate again, to invalidate that client in which time great damage could have been done.

Now it’s real time across the edge network (Fastly) working with the identity manager (Okta).

Is that partnership with Okta in this one realm, is that something that gets initiated on the Okta side, or is that something gets initiated on the Fastly side or just both? I’m saying a customer.

We Learned:
It’s a joint customer solution.

Now, I’m going to ask you, if I can just a couple of questions about competitors. And, if you can’t say, it’s fine.

Does Fastly have, or is it developing or has it been announced a sort of B2B product like Zscaler has?

Zscaler has this sort of enterprise to enterprise. Their kind of edge security. Does Fastly have that? Is that doable?

We Learned:
Fastly does not have that today and while the company is always looking at new areas where the company can take advantage of its technology there are no announced plans or intentions.

Okay. And, then my last question is directly about Cloudflare.

We’ve gone through the architectural differences. Browser-based JavaScript engine versus systems level.

Cloudflare has a whole bunch of security products, which I think if you put them together kind of make an end-to-end solution.

I don’t actually cover Cloudflare. You actually probably know them better than I do. But so fundamentally the difference between… I’m not talking about the CDN part, so still want to talk about the programmable network part. Is the fundamental difference, at least at a high level between Cloudflare and Fastly is offering that compute@edge, the architecture is just fundamentally different?

Is that fundamentally the difference, the architecture between the two in this programmable network security realm?

We Learned:
First off, Sean was rather transparent when he noted that he was not an expert on Cloudflare and certainly not at the architectural level.

He was also complimentary of the company — very much so. There was not a hint of denigration.

He respects Cloudflare and didn’t have anything negative to say about them.

He just said that he knows the decisions Fastly has made are the ones that he can’t imagine somebody not doing.

He went further to note that without going systems level, he doesn’t believe that a network provider could scale as Fastly sees necessary in the future, especially for the types of workloads that the company supports today.

I don’t know Cloudflare that well either, but I’m willing to say just out loud that architecturally they’re built on V8. And, so they’re not at a systems level. I could be wrong, but that’s what I’ve read.

Okay. Sean, those are all my questions. Since we’ve talked about products in this realm, is there anything that I don’t know, I didn’t ask that you feel I should have asked, or a thing that maybe you think people should know that they wouldn’t know unless you said it, because I didn’t ask it?

We Learned:
Fastly feels proud of what they’ve built and what it means for its future and that there are a lot of differentiators that will be realized in the future.

It’s my pleasure. Okay. Yeah. I will continue. I think if you probably see what I’ve put publicly, my fundamental belief is that Fastly’s technology due to choices made prior.

Fundamentally put it in a better place than anyone else. I’m not talking about stock prices right now. I’m just talking about technology. That’s my view.

Your answers have reiterated that view just with greater clarity, I think. And, then what happens in the future? I don’t know.

There are a lot of places in the world where the best technology doesn’t necessarily win, whatever win means. But I think when you’re talking about a technology that’s infrastructure that you’re going to want to be in the place with the best technology.

We Learned:
Sean and Fastly have always been, since inception proponents of starting with the technology and moving on from there.

Without the technology, companies are left with marketing.

And, for better or worse, Fastly has always been great about having the tech.

Yeah. And, in particular, the world that Fastly lives in is very technology driven. There are other industries we could talk about. Like let’s say software, which is of course they’re technology companies and it’s not obvious that the best tech has to win in some software realms.

It could actually be the interface and the ease of use. I think we’re not talking about Internet infrastructure and yeah. It’s going to really matter. This is where the best technology should win.

We Learned:
He agreed…

Update: 5-24-2021

OG: Can you expand on the difference between the V8 version of the edge and the Fastly method, architecturally, to go systems level? Or maybe, less stylistically I would ask.. ‘what makes system level more scalable than at the browser level?’

We Learned:
V8 was designed for the browser and that is a totally different compute model.

It was designed for one client that is going to several, but less than maybe, one hundred, servers and applications.

For example, when browsing on chrome that is in fact a single Chrome application running on a single device, no matter how many tabs are open.

That application will usually have sandboxes and connections for potentially a dozen to a hundred “sites.”

There will not be frequent interaction with those sites since people usually interact with a single site at a time.

Turning to the systems level, a large edge compute environment is (i) millions of different clients interacting with (ii) thousands of different applications and this is all happening (iii) at the same time.

The Fastly environment built on a systems level was designed, at its outset, in this environment.

Fastly itself had to support several thousands of distinct services, like Shopify, and then, all of the sub-applications.

In the world of micro services, sites are often composed of several sub-applications.

To serve this world, all of the sites and sub applications have to be segmented separately. And, of course, then there are millions of clients sending requests to all of those sites and applications.

All of this is happening across thousands of edge servers around the globe.

In Sean’s view, in Fastly’s view, the architecture built on V8 is actually not apples-to-apples, but rather apples-to-oranges when compared to the systems level architecture.

This is the scale that Fastly was speaking to earlier in our conversation, and why the firm believes this is in fact not so much a stylistic choice, but a requirement.

One architecture, and only one architecture, can serve these needs, and it has to be systems level, or if you prefer, it cannot by at the browser level, according to Fastly.
End Update

Final Take
We see both Cloudflare (NET) and Fastly (FSLY) as pioneers in edge computing and the two companies will help enable, even usher in, a new version of the Internet.

Each company has its own private network, away from the central cloud, and while the serious lifting, data storage, artificial intelligence and machine learning will happen in the central cloud, more and more of compute will happen outside the central cloud in these new Inter-networks.

We see them each with powerful security offerings, with a slight edge to Fastly (SigSci) if we look at reviews and recommendations, but truly, both are head of the class.

We see similar designs of their programmable networks, allowing for this new Internet.

We finally see Fastly’s choice to go systems level rather than with a javascript engine (Chrome V8) as one of the main differentiators.

That difference means that Cloudflare will be able to release product and iterate product faster, or if you prefer, Fastly will be slower, until it isn’t.

But slower to market might not mean anything when it comes to the ability to succeed in the future – a future we have all seen is always far more complex than we thought.

The circumstantial evidence that Fastly has made a move that is in fact ‘better’ technology is the cold start times registered by compute@edge.

Customers may not ‘care’ about the difference between microseconds and milliseconds, but the compute@edge 100x faster cold start is not the end goal, it’s the canary in the coal mine.

It’s the circumstantial evidence that one architecture dominates the other.

Nobody, not even Fastly and Cloudflare know what will happen on the Internet with these new clouds.

If we know anything about technology, it’s that what we conceive of is far outpaced by what we realize.

For this reason, we are bullish Fastly, and for this reason, we recognize that it will take patience.

The ethos of each company really comes down to the founders. Matthew Prince of Cloudflare is a Harvard MBA and was an adjunct professor of law. Artur Bergman is a technologist with prior work as a CTO and Vice President of Engineering & Operations before founding Fastly.

Both versions of the world could be argued reasonably. For now, we choose the Fastly version of the world, but investors can consider any and all versions.

We’re a research firm, not a recommendation firm.

We maintain our number two Spotlight Top Pick status on Fastly.

All members of the community now understand, hopefully, how we see the company differentiated from its peers, and how there is risk to a ‘tech first’ approach to business.

We were privileged to have the opportunity to share this conversation with you and we truly hope that you, as a member of the CML Pro community, feel the unique position we are all in to speak with the executives at bleeding edge of the technologies we cover.

How fortunate for all of us.

We said last quarter “if the stock dips, so be it, it likely will.” Well, we got the dip part.

We don’t know a lot about the short-term, but the long-term future, that is clearer to us — albeit quite different than Wall Street sees it.

And in our opinion, even as stocks go down, even as panic shakes the investing world, it doesn’t have to shake us.

We just have to accept that stocks go up and down, and it will be scary when the ‘down’ part comes. Look forward.

We see the future of technology, by simply listening to the companies and executives themselves and applying our own expertise.

And all of that research is bullish — maybe not for next week, or even next year, but in 3-10 years, yes, we see a huge shift higher in technology.

Thanks for reading, friends.

The author is long shares in Fastly at the time of this writing.

Please read the legal disclaimers below and as always, remember, we are not making a recommendation or soliciting a sale or purchase of any security ever. We are not licensed to do so, and we wouldn’t do it even if we were. We’re sharing my opinions, and provide you the power to be knowledgeable to make your own decisions.

Get a nice roundup of new retro gaming content once or twice a month.