Thoughts on Fastly acquisition of Signal

Investment Analysis Clubs Saul’s Investing Discussions
1

So as we all heard Fastly will acquire Signal Sciences for about $775M. I had little knowledge of Signal Sciences before the release and how it would benefit FSLY. So, I took some time today to look into it and thought I’d share my impressions.

  • Signal Sciences has 85% gross margins as compared to Fastly’s current 61% gross margins. So, it’ll help Fastly expand its security products while improving the combined company’s margins. Overall, should the blending of the two work smoothly, the acquisition may quicken FSLY path to profitability.

  • FSLY paid $775M which works out to 28x current revenues actually slightly below FSLY’s current P/S multiple so this deal is not dilutive.

  • Signal Sciences has an impressive list of enterprise customers (about 60) with just a few that I can see overlap FSLY’s 300+ enterprise base. So, it should broaden FSLY’s overall enterprise base. You can see Signal’s list here: https://www.signalsciences.com/customers/

  • On the business side, Signal Sciences gives FSLY a stronger security offering. This could make the launch of Secure@Edge and Compute@Edge more enticing to enterprise customers.

Hopefully, someone with more knowledge of the technology can chime in as I’m by no means an expert on the tech side. We don’t have much financially to work with at this point but given the current information, I can’t see an obvious downside. Of course, the real challenges are in the integration of the teams and technology.

Be well,

34 Likes
2

- On the business side, Signal Sciences gives FSLY a stronger security offering. This could make the launch of Secure@Edge and Compute@Edge more enticing to enterprise customers.

I believe this to be the most important long term synergy. If it weren’t for bad actors there would be little need for security. Security is a non-productive expense just like clean restrooms, but you can’t run a business without it. By incorporating security into CDN and Edge, Fastly makes life easier for customers. Security built in instead of added on. One less vendor to deal with, one less point of failure.

Thinking long term, I believe Fastly’s future is more in Edge than in CDN. This is a 2016 article and Fastly is just getting there:

The future of the edge
Published August 24, 2016

The following post is based on CTO Tyler McMullen’s talk at Altitude, which focused on the future of the edge. Read the full recap of our customer summit here.

CDNs are stuck. We’re doing the best that we can with the current model CDNs use: we’re able to pass through writes and pull content from origin, which lets us cache static assets and content that changes frequently. What we can’t do is (effectively) cache responses that change on every request, that are different for every user, and that modify state at the origin. That is, we can’t do anything with writes. Where does that leave us?

In this post, I’ll explore “the future of the edge,” or the next logical step in how we streamline online experiences. In order to keep up with the direction things are headed, we need to combine logic and data at the edge. Logic without data, without state, is insufficient.

https://www.fastly.com/blog/future-edge

Technical detail: “Logic without data, without state, is insufficient.”

The WWW protocols (HTTP, HTTPS) are “stateless” meaning that every request is uncorrelated like the next roll of the dice. The WWW has no memory. I have no idea why it was designed that way. All manner of devices have been created to give the WWW a memory where to store the “state” of things. The most immediate are cookies!

Some might remember the discussions about “transactions” in MongoDB threads, the discussions about ACID.

In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties of database transactions intended to guarantee data validity despite errors, power failures, and other mishaps.

https://en.wikipedia.org/wiki/ACID

ACID is a very complex way to “remember the state of the database” before the transaction was processed in case the transaction fails and has to be reversed.

State is a huge problem, a huge differentiator, and therefore a huge opportunity.

Denny Schlesinger

25 Likes
3

"The WWW protocols (HTTP, HTTPS) are “stateless” meaning that every request is uncorrelated like the next roll of the dice. The WWW has no memory. I have no idea why it was designed that way. …

These are transfer protocols. They govern communication so remembering state wouldn’t make sense. To be tongue-in-cheek about it, this would be like asking the air to remember what I just said to you so you can hear it later instead. A recorder or your brain would be better at the job. Each receive the communication and process it and store it in different ways for different use-cases, right?

A transfer protocol is simply an agree upon pattern so both sides know what to expect when receiving data. It could be a human protocol (I will send you an email then you will tell someone about it) or, in the case of HTTP, a message composition protocol. For example, say I want to make a streaming service.

A) I can create a protocol like:

  1. I will send you a message (a string of text)
  2. I will make the first 10 characters of the string numbers that tell you how long the string of text will be so you know when I’m done sending you things.

B) Then when you write a receiver (client), the logic will be something like:

  1. Because of the protocol I made, you know you can read ONLY the first 10 characters to get the length of the incoming message and then start listening for the rest.
  2. You decide to receive the message in 1000 character chunks until you have the whole message (that last chunk will be a partial one for the remainder. You can do this because you know how much to expect so you know if you have it all or it just paused sending for some reason. Then you stop listening and do something else. Reading the stream in chunks will allow you to process the message as it is arriving rather than wait for the whole thing. Or if the message is HUGE and you don’t have enough memory to hold it all at once, you can keep passing it along to something else to process (like starting to stream a part of a movie as soon as you get a little of it on your end).

I’m simplifying but that is all HTTP is. An agreed upon message format.

There is no need for state in such a protocol. If you want to remember things, you do that on the ends where the communications are handled. Note: when the word “state” is used it generally implies meta data, or information about the information. Storage of the actual data is usually a different thing (files, documents, etc). For example if you are watching a move on Prime, the state the player wants to know is where you are in the movie so it can show you what actors are in the scene. It will also store what you have watched so you can start from where you left off. That sort of thing. Databases also have state but I think that is a different topic…really anything that can mutate can have a state, which is also why some things are not allowed to mutate…another different topic.

Hopefully that made sense to moderate-techies. I’m no Computer Scientist, but I have created a protocol and client/server before.

Now imagine all the places you need tech for security if you want to hide what is being communicated. Even more so if the communication is bouncing around between devices, various edge nodes and origin servers AND all the software layers that get to have access to do some small part of the job. Security has to be everywhere and also not get in the way AND be a network of specialized applications that operate as a single blanket of protection. It is a huge problem and that is why CrowdStrike, Okta, Fastly, Cloudflare and others can co-exist as partners and still overlap and compete at the same time.

8 Likes
4

The WWW has no memory. I have no idea why it was designed that way. ...

These are transfer protocols. They govern communication so remembering state wouldn’t make sense.

Thanks! Communications were never my field, all I knew was that it was complicated. My area was application software, specializing in user interfaces.

Denny Schlesinger

1 Like
5

There is no need for state in such a protocol.

The exception to this is passing parameters, e.g., an initial message may contain login information and the server uses those and passes back a token to identify the session and the second message returns this token.

6

Now imagine all the places you need tech for security if you want to hide what is being communicated. Even more so if the communication is bouncing around between devices, various edge nodes and origin servers AND all the software layers that get to have access to do some small part of the job. Security has to be everywhere and also not get in the way AND be a network of specialized applications that operate as a single blanket of protection. It is a huge problem and that is why CrowdStrike, Okta, Fastly, Cloudflare and others can co-exist as partners and still overlap and compete at the same time.

A question from a non-techie. If the message were encrypted wouldn’t that obviate the need for additional security at each node or transfer point?

7

Speed is the issue.

Look at EdgeCompute and Cloudflare Workers. Spawning speed is mindcrushingly fast, code execution is very fast. Just setting up encryption and then encrypting/decrypting defeats the speed. Adding many resources to load during the spawn moment is a dealbreaker. Some of our best encryption is predicated on being slow, to avoid mass-hacks.

Separating the trust layer from the applications makes it possible to go fast, somewhere. If nothing trusts then everything is slowed, and improving the trust mechanisms is located everywhere (lots of work to deploy new trust solutions)

Hope that helps.

3 Likes
8

They govern communication so remembering state wouldn’t make sense.

I disagree. Since is somewhat OT, although I think I put it into perspective for our companies at the end.

The truth is that Tim Berners Lee and the other people working on this were not thinking shopping carts or lots of things sending data to and from each other, they were merely thinking of delivering hypertext, which is the name for non-linear text storage systems - essentially text snippets and links within and to the snippets. The communication protocol was invested to deliver content within that system based on queries and the following of links to other snippets of text.

HTTP actually stands for “Hyper Text Transfer Protocol.”

The idea was to transfer hyper-text snippets, not to conduct e-Commerce, not to run applications remotely, not to support IoT workflows or distributed databases. Heck, images weren’t even considered in the original proposal (and may be indicative of why TMF’s boards today still don’t support images).

Here’s Tim Berners Lee’s original proposal from 1989: https://www.w3.org/History/1989/proposal.html

Here’s his “short history” of the World Wide Web (as of 1998): https://www.w3.org/People/Berners-Lee/ShortHistory.html

And here’s some Q&A from the early 21st century: https://www.w3.org/People/Berners-Lee/FAQ.html

If one were redesigning the web from scratch, one would certainly:
• Provide for state storage and expiration.
• Provide for security to assure identities of both sender and receiver.
• Provide for encryption/decryption of partial or complete content.
• Provide for distributed database access.
• Provide for assured email headers to eliminate the possibility of spam, or at least being able to hide the identity of those sending spam

Probably more, but alas, we have to use the tools we have at our disposal. Since we don’t have such a system with built-in capabilities, we have companies like Cloudflare and Zscaler and Snowflake and numerous others that build those capabilities on top. So, I guess you say that it’s because the web is so poorly designed for the 21st century that there are profitable opportunities to make it more suitable.

8 Likes
9

This probably is getting off-topic since it is general rather than about one of the companies. I’ll keep it short:

I want to point out I am not a web developer or computer scientist and there IS a point where this information will descend in to areas that are about engineering the web itself. There are technologies that transfer information beyond sending text.

A question from a non-techie. If the message were encrypted wouldn’t that obviate the need for additional security at each node or transfer point?

You can’t work on encrypted data directly. You have to have some or all of it decrypted, handled and encrypted again to send onward. Each time you you have to be authenticated in some way, like a secret key or authentication test. There are techniques that can do neat things in this area though, like give you some part of data to work on where you can’t know enough to harm anyone with just your bit of knowledge (anonymizing data). Needless to say there are people who specialize in this area of computer science and mathematics.

“There is no need for state in such a protocol.”
The exception to this is passing parameters, e.g., an initial message may contain login information and the server uses those and passes back a token to identify the session and the second message returns this token.

That is not state. It is just data transmission followed by a response that carries more data. There is no persistent state storage, just a package sent and another one received. The communication protocol itself is not storing and mutating state over time. The state is still managed locally or remotely based on interactions and communication between them.

To the general point about redesigning the web to have built in security. I’m not sure how that would change things. You would still need to authenticate somehow. Security would still be a thing. It was needed back when people only had swords as a tool to get your loot. I’m sure it will still be needed when people have custom AI to get your loot. Having more capability would make things better for sure, but I don’t think the basic need ever goes away, ever.

I think our companies are safe from this moat attack vector. I would expect them to be the first to recognize changes and adapt, since they are the experts and will probably be driving said changes anyway. In fact, companies that specialize in trying to detect threats will be more important than ever as technology advances.

3 Likes
10

There is no persistent state storage,

You snuck in the word “persistent”. :slight_smile: Obviously, a message cannot involve persistent state because the message is not persistent. That doesn’t mean that the message cannot communicate state. Something like a login token is a way of connecting a new message with a persistent state on the receiver.

2 Likes