What is the modern CDN and why is it important?

Too many developers and companies are dealing with the dark ages of black-box, legacy content delivery networks (CDNs) that weren’t built to provide the real-time observability, baked-in security, and programmatic control needed to deliver the dynamic experiences today’s users and developers demand.

Fastly’s modern CDN is designed to empower developers to create innovative digital experiences that help increase customer lifetime value, improve conversion rates, and drive higher average order value and loyalty. With this capability, businesses are better equipped to succeed when they give developers the tools they need to innovate and maintain secure, competitive sites and applications.

During this webinar, Fastly experts will explore:

The evolution of legacy CDNs and the current state of the CDN industry based on this crumbling foundation.

The benefits of the modern CDN, including real-world applications from Fastly customers, Gannett and Stripe, each with their own challenges to meet and exceed user expectations.

How to select a modern CDN provider and unique differentiators to look for when comparing to your legacy CDN, including ways to achieve return on investment.

After this webinar, you’ll understand why it’s time to reconsider your legacy CDN for one designed for the modern user and developer.

[Leigh Clancy] Hello and thank you for joining us for the “What is a Modern CDN and Why is it Important” webinar.

During this webinar, we will explore the evolution and current state of CDNs, the benefits of a modern CDN – including real world applications–how to select a modern CDN provider, and what to look for. Please feel free to chat in your questions and we will try to answer them during the Q&A at the end. Today, our speaker is Lee Chen. Lee Chen is the vice president in corporate development and strategic partnerships here at Fastly and he assists as the executive sponsor for our media products. At Fastly, he has led a wide range of functions across product, marketing and partnerships he has spent the last 20 years in media and entertainment space pioneering live broadcasts over the Internet. Prior to joining Fastly he founded and led several startups in technology in Esports. And with that I'll turn it over to Lee.

[Lee Chen] Thanks Leigh. Hi everyone, thanks for joining today. Just get the slides up real quick. Everybody should be able to see that, right? Hi, thanks for joining in today. I really appreciate it. I am perhaps oddly excited to dig into this topic today on what is a modern CDN and why is it important. Prior to joining Fastly, as Leigh mentioned, about nine years ago, I was lucky enough in my career to spend time on the infrastructure side of the world and also on the direct to consumer side of the world. So I started my career in telco, early broadband access, and then having worked in the early days of Esports, doing live broadcasts, I saw many of the challenges of sort of real-time interactivity and the scaling of those platforms to millions and millions of users. So when I joined Fastly, it continued to be an amazing journey for me on how to solve problems in Internet scale across a really, really wide range of use cases; so I'm excited to share with you today some of those things that I've learned on the way and why it matters in the modern context about development. 

I'm going to touch on the evolution of a modern CDN as I think that context is really, really important to this conversation. We'll dig them into some of the benefits, talk through some real world examples that I'm really excited about, and discuss how to choose a modern CDN for your particular use case. And then a quick note about why Fastly is a great option but I hope this talk will give you some insights about how you can imagine–reimagine–scaling your app not just for lots of users but also for performance, reach, security and perhaps, most importantly, control. And I'll note that the intended audience is very broad today and the topic is also one that I can spend hours and hours talking about, which probably no one really wants, so we'll try and go pretty quick today. As Leigh mentioned, if you've got questions along the way, please drop them into the Q&A and we'll make sure, we'll make sure to get you an answer.

So let's dig in.

What did companies do before CDNs? In the before times, so in the early days of the internet, there were a number of challenges, particularly as the audience for an app or a site became increasingly distributed or even better wildly popular, those challenges are also true today. I mean, more often than not, when we first build our our first app or site, we don't have a globally distributed edge network helping to deliver our content securely or quickly around the world and so we end up with things like poor user experiences due to slow load times because the latency considerations, or broken sites due to geographically driven sharding. So to solve this problem, and either try and do it up or do it

ourselves by standing up multiple instances of our site or app around the world, but then we'd have consistency challenges around the data sets.

CDNs were born out of these challenges. The early CDNs kind of did the same thing, right, they created copies or the ability to store multiple copies of the same data around the world, call them caches or POPs, with slightly better results because they were building these caches to hold copies of the quote-unquote static content on your on your site or app. Things like images, videos, text, etc. that wasn't really going to change very often, and so the consistent consistency problem was kind of mitigated because the content really didn't change that often. But, [that oops sorry about that] but that didn't really help a whole lot when it came to dynamic content that changed frequently or worse that was personalized per user, like say a login state or the home page of a major news site or even your personal Twitter feed. And then also, in the early days of the internet, the network topology was very different. To be effective, the early CDNs had to put their points of presence, or POPs, deep in the last mile eyeball networks.

So, as things continue to evolve CDNs continued to really struggle and at the scale and prevalence of the internet and everyday use grew exponentially, every year, the problems in the original architecture continued to pile up. Hundreds of thousands of cash servers located deep in the last mile the internet meant hundreds of thousands of copies of the same content around the world; and the first time a piece of content, say an updated version of the home page is accessed, on any, on any one of these cache servers around the world it has to go back to origin meaning your app stack to fetch that content. So, if the app or content is hugely popular it can mean millions and millions of users stampeding back to your origin to get to the latest piece of content. So, the legacy architecture adopters implemented something called mid-tier caching, which you see here, and that meant quote unquote only tens of thousands of servers were acting as origin for the last mile caches, but those were still going back to your origin server in order to get that fresh copy of content or that updated piece of content. And then on top of that, content has become increasingly more real-time. DevOps and continuous integration and deployment has become a thing, not only to improve developer workflows, but also so that businesses could iterate faster and all these factors presented the edge architectures of the past with harder and harder problems to solve. Storing an outdated copy, outdated stale copy of a web page is bad. Having multiple increasingly older and increasing incorrect versions of content, APIs, or even full entire edge applications is way, way worse. So even with these deep last mile caches and the mid-tiers in play, the so-called thundering herd was still headed to your origins more often than not. In a vertical, it's a vertical and horizontal scaling problem that we implemented the CDN Edge to solve for in the first place. Then you add in things like BOTs and bad actors who are out to exploit, scrape or do worse, these applications and things just start to get really gnarly. So the other thing I'll note, is that on this diagram there's actually no observability or visibility, real visibility, in what's happening at the edge. You know these legacy architectures maybe in 24, 24-48 hours, you're going to get a log dump, but that does absolutely nothing to help you diagnose or troubleshoot what's going on in real time.

The other thing that's not depicted here is there's no way to invalidate what's living out at the edge and anything like the time you need as a developer who has the business breathing down your neck to fix the wrong headline, the wrong inventory count, or some other piece of business critical or brand critical data that's living out there on the internet. So enter Fastly. What's different in the modern CDN and on Fastly. First of all, we deploy large POPs located at the major crossroads of the internet, not deep in the last mile, so this is where the internet comes together and interconnects with all the other disparate networks around the world. This means consolidated CPU, disk,  network, and it means greater efficiencies in caching and compute and that translates to better control and availability for you, your website, or your application. And because we are at the major crossroads of the internet, the latency and performance of our network is as good, if not better, than legacy CDNs. You can check this out for yourself in the public third-party stats at Citrix, actually I think if somebody can drop that link into the chat for everyone that'd be great, and you can see the latency metrics for yourself, like this is a third-party independent measurement and so it's not our numbers, it's somebody else measuring everybody out there together, and looking at the dynamic object delivery is probably one of the best ways to get a sense of the latency performance of any given edge network. So the compute density in our mega-POPs means that you can run complex application logic in your configuration scripts or even full-blown apps in our compute@edge product all right at the edge and in line of the delivery request flow of the users touching your apps and websites. You add to that request collapsing, or what we call shielding, and that means that there aren't tens of thousands of mid-tier requests coming back to your origin just one, maybe two requests if you have redundant shielding enabled, so translation is there's no thundering herd. Yet, in security an inline web application API for protection firewall, that's partly it's actually part the request flow back to the app, and have it in blocking mode because it can actually it can actually tell the difference between legitimate users and bad actors. And an API interface to control to all of this that allows you to control the entire edge platform so that you can programmatically access it directly from your developer workflows and having it propagate changes and updates around the world in seconds, not in minutes or hours. Instant purge allows you to cache and validate with an average of 150 milliseconds or less, and you take these two things together and that means that you have near real-time control of not just the copies of your content around the world, but the application, the logic that, but the application logic that dictates how the content will be rendered as well. And then then there's observability, which I mentioned earlier. The ability to see what's actually happening with your app in near real-time so that you can react to it, troubleshoot it, analyze it to improve business outcomes and user experience and it's not just a basic log stream either, but one where you can actually customize pretty much everything. You want to capture a user ID with a given AB test flow, get it in your Fastly logs. You need to latency Telemetry for a given geo region, get it in your Fastly logs. You need an audit trail for compliance, get in your Fastly logs. And that's all customizable and at your fingertips; so taken together, these are enormously powerful toolkits in a modern development environment and that development environment should include your modern CDN.

So what is a modern CDN? I've talked through a lot of many of these capabilities in the earlier slide and a modern CDN should have all these features and more, but the key thing I really want you to take away from this conversation is that a modern CDN should be part of your development process in journey, not an afterthought or blocker, but a toolkit that actually enables you to achieve your goals, business to personal, and not an emergency once you hit scale. Ultimately a modern CDN should enable you and your developer teams to accelerate iterating and innovating. Google's, pay wrench page, page rank algorithms [excuse me] measure page load times which is a function of latency and having content hot in caches, so modern CDN has to be fast and performant to automatically improve your search rankings. It should also be well peered or connected network wise with Google and several of the other search engines that are out there. Again I refer you back to the sodexis page ranks or latency metrics is something that you can quickly use to evaluate performance. You should be able to customize your content at the edge, imagine the AB testing use cases if you could push that out to the edge and dynamically render content depending on the user input and still get all the visibility you need to make the adjustments to the user experience or optimize revenue. Security should be native and at the edge. You should have the ability to do more than the basic caching configuration to truly run application logic and indeed entire application, entire applications at the edge. The list just goes on.

Let's talk about some real world examples.

Gannett is the largest news publisher in the United States and is known for building trusted local communities. It is perhaps most well known for USA Today. In publishing cache invalidation, what we call instant purge, is critical to making the latest headlines and and news always fresh; but consider the possibilities of having 150 millisecond purge time. In a nutshell connect was able to consider Fastly as a direct, near real-time, globally distributed extension of their origin servers. The home page of Gannett might probably be considered uncacheable and served dynamically; it's highly customized, there's lots of content on it that's constantly being updated, the headlines and so on. And so served dynamically means that it's dry it's coming directly from their origin servers in the cloud. And because they always need to have the latest up news and up-to-date headlines, the reality is that they're actually dynamic on an event like, on an event, like a breaking news update or a comment being posted or a like button being clicked. That's an event that can be captured, and programmatically used to trigger a purge request, via API. And so, with purge, and with instant purge, this becomes their new reality; it offloaded a tremendous infrastructure burden, while enabling them to move application logic out to the edge. They saw a 98.86% improvement, percent improvement, in their global configuration push time from their previous setup, and by offloading all that origin traffic too Fastly, they saw 35% cost savings in egress.

Stripe is another favorite example of mine. Processes, they process about a billion dollars a year with really unpredictable traffic spikes from flash sales and holiday searches. Their business requires them to not just be secure, but also highly performant as as introducing a delay in the checkout process can mean a lost sale for their customers and directly relates to revenue for Stripe. Traffic spikes are normal business for them, right, they just have to be able to absorb that, they have to be able to do that, and they have to continue to process transactions for their end customer.  So having an edge platform that could scale to meet those spikes without allowing the stampeding herd back to their origin servers, it was really really key, and that's a lesson that they learned firsthand from their previous provider. On top of that, there's this two-second rule on slow page loads that causes the user that, you know, reportedly causes the user to leave their cart or find the product on another site. So they the the end customer ends up losing a transaction if Stripe is too slow. So Stripe really needs to continually improve in performance in order to prevent loss of sales for their customers, but integrating Fastly into their edge application platform, Stripe was able to reduce their checkout times by 80% and that's an incredible and dramatic Improvement in the customer experience.

So how do you choose a modern CDN? You know here's what to look for before buying; you know the first column here is all about developers. So I mentioned earlier a modern CDN should be part of your development process, right, not something that you think about after the fact, or that you're bolting on later. If you actually take advantage of it from the get-go as you're starting out, the benefits for it are all there for you and the rest of the business, but also impressionable importantly, for your developer teams, which allows them to iterate and innovate faster. And hopefully your developers will really appreciate that from the get-go and it allows you to focus on solving the business challenges and improving user experiences. Control, observability, standards, compliance, and support, and and built-in program programmability for security, these are all key features that you should expect to see. The second column is really about answering the business needs, goals and objectives, that you're faced with. Total cost of ownership always matters, evaluating the impact of cloud egress and how many servers you needed run in EC2 or wherever it might be, you know, to support the cache caching architecture you have, is just as important to the conversation. And lastly try before you buy, right this isn't circa 2000, or 2005, or even 2010 anymore. You have the ability to try before you buy today, and you should evaluate the support. A true edge platform, like a modern CDN, is one that can be integrated and is integral to your business and stack; and personally I try to choose partners and vendors and customers who I can be proud of doing business with.

So there's some numbers on here that that we're really proud of. We've scaled our network to nearly 200 terabits per second, while maintaining the performance of our purge in global deploy times. That's, that's a not a, that's a not insubstantial accomplishment; it's a pretty hard distributed computing problem. And we're pretty proud of the that all of our performance metrics have continued to improve as we choose scale. Our next-gen WAF has over 90% of our customers using in full blocking mode, which means they trust us to actually stop bad actors and bots without turning away real, legitimate users, and that's incredibly important, because if the WAF is just sitting there in monitoring mode, you're going to find out that there was a problem after the fact. Having it in full blocking mode means being able to trust that the technology and the security research behind the WAFF is world class and is actually going to find the bad guys and let the real real good folks through to continue to interact with your app or make that purchasing transaction. But, perhaps most importantly, and the numbers that we're most proud of is that we really genuinely love customers. We've all been customers at one point or another in our lives, and a genuine appreciation for how we want to be treated as customers, means that we try to treat all of you the same way that we want to be treated ourselves. So these customer metrics reflect our ongoing continuing commitment to this philosophy,

So with that, thank you for listening in today, and I'll throw it back to you Leigh.

[Leigh Clancy] Thank you so much. Just as a reminder, please feel free to type in your questions and we will answer those now and if we can't get to them we can follow up with you after, so go ahead and type in any questions that you might have.

[Lee Chen] Drop the screen share while we're ready for that.

[Leigh Clancy] So, I see one coming in, it looks like there was some question, maybe go into more about having that full control for the developer and what that might mean.

[Lee Chen] Yeah that's a great question. So, you know that that can take a lot of different forms. There's two pieces to that, right, control means that you can interact with the the configuration, the cache control headers, the content that's actually living in a cache, there's a wide variety of things that you want to be able to control in a modern CDN and  in an edge caching strategy. So, A) you need to be able to access it, it can't be a black box, right, so Fastly provides that via API or through the control panel which is actually dog fooding the API; but more importantly that when you make those changes that they propagate around the world to every node that's carrying your traffic or your configuration pretty darn quickly. So 13 mil, a 13 second deploy time means that within seconds your configuration changes are propagated around the world and they're being applied as rules to the traffic that we're serving for you. The other piece to it, is what are you controlling and why are you making changes? And so that goes back to observability. If you can't see the impact of the changes that you're making, in near real time, like if you're waiting hours, or sometimes days, for that change to be reflected in logs or any other visibility or observability tooling that you might have, that's actually kind of useless, like you could have a really bad configuration change out there that is maybe not taking the site down but has swapped the logo out for something else that might have a brand impact. So observability and control both have a real-time nature to it, and that is how developers operate today and that's something that we believe in really strongly.

[Leigh Clancy] Also looks like just Fastly support web standards and open source software?

[Lee Chen] We do at multiple levels right like it's baked into the stack so we support quick, HTTP 3, there's a wide variety of web standards that we both support on the platform and we also are active with the ITF and the other standards bodies to help set the standards themselves. On top of that, we also have a really robust open source support program which we're pretty proud of and so this is about supporting the delivery of open source projects, code, repos, and and the other things that you might pull down, right, so NPM and several other major packages are distributed through Fastly, so I think, I don't know the exact context of the question, but I would say that we support it on the platform, so that you can work with it, for the most part, that's well covered in docs.fasly.com. We supported from the perspective of having a voice and lending our experience and perspective to the setting of these standards. And then for the open source projects, we actually offer free services for Delivery to make sure that open source projects are actually being able to be used by the folks that are interested in using them.

[Leigh Clancy] Awesome and I think we have one last one here that I see; is talking a little bit about like live events, as you have those thundering herds and how does Fastly help scale to meet those needs? I know you touched a little bit on that.

[Lee Chen] Yeah. So this problem I live, I've lived personally, and had it go really, really well and had to go really, really bad. You know, when you think of live events and the thundering herd problem, you know, it's the, the first one that usually comes to mind for me is something like the Super Bowl, right, so every year millions and millions of folks tune in for American football and the world championship. And, so, uh, that's very different than say your normal weekend. And so for this four hour block of time, there's millions of people coming in trying to to hit this one video stream across you know multiple renditions and bit rates. So it's a, it's sort of a spike traffic problem, and it's a really big one, right. It's measured in terabits per second, tens and hundreds of terabits a second, but if you peel that back for a second that actually applies to just about any kind of event. Like you can have a piece of content go viral, right, and then all of a sudden you've got a thundering herd problem. You could have a news, breaking news thing, that happens and it can be a thundering herd problem, and it doesn't have to be gigantic and global. It can actually be super local and regional. Something, like a tornado alert could apply to this as well, or a local event that maybe has suddenly a bunch of interest. So the way that CDNs actually handle this is this, is what CDNs were designed for to begin with, right, it wasn't just a distribution problem, it was also a horizontal and vertical scaling problem just by storing copies of cache out there. So every CDN should be able to handle this, and modern CDNs, in particular, should be able to handle it without overwhelming your origin, and that's the final component here, what we call and refer to as shielding, is this idea that we carry all of that traffic at edge because we have a fresh copy of the content, either through our edges or our edge caches, or through our shielded POPs, and so really only one or two requests go back to origin. Legacy CDNs don't have the same benefit there. They have many thousands of mid-tier caches, all of which you need to talk to origin in order to get that piece of content, and then and then push it out to the edges. So the approach that we've taken, we've definitely seen and we've, and our customers, have definitely seen that there's a tremendous amount of benefit when it comes to spike traffic like that.

[Leigh Clancy] Awesome. Thank you so much, Lee, that looks like the last of the questions. So thank you for the presentation and thank you thank you to all of you for joining us. We really do appreciate your time. You’ll be receiving an email with a link to the recording of today's webinar and if you'd like to check out Fastly for yourself you can visit Fastly.com and click on the try Fastly free button. And with that I hope you all have a great rest of your day and thanks again for joining.

[Lee Chen] Thanks everyone, appreciate it; take care.