Announcing Cedexis Netscope: Advanced Network Performance and Benchmarking Analysis

The Cedexis Radar community collects tens of billions of real user monitoring data points each day, giving Cedexis users unparalleled insight into how applications, videos, websites, and large file downloads are actually being experienced by their users. We’re excited to announce a product that offers a new lens into the Radar community dynamic data set: Cedexis Netscope.

Know how your service stacks up, down to the IP subnet
Metrics like network throughput, availability, and latency don’t tell the whole story of how your service is performing, because they are network-centric, not user-centric: however comprehensively you track network operations, what matters is the experience at the point of consumption. Cedexis Netscope provides you with additional user-centric context to assess your service, namely the ability to compare your service’s performance to the results of the “best” provider in your market. With up-to-date Anonymous Best comparative data, you’ll have a data-driven benchmark to use for network planning, marketing, and competitive analysis.

Highlight your Service Performance:

  • Relative to peers in your markets
  • In specific geographies
  • Compared with specific ISPs
  • Down to the IP Sub-net
  • Including both IPv4 and IPv6 addresses
  • Comprehensive data on latency or throughput
  • Covering both static and dynamic delivery

Actionable insights
Netscope provides detailed performance data that can be used to improve your service for end users. IT Ops teams can use automated or custom reports to view performance from your ASN versus peer groups in the geographies you serve. This lets you fully understand how you stack up versus the “best” service provider, using the same criteria. Real-time logs organized by ASN can be used to inform instant service repairs or for longer-term planning.

Powered by: the world’s largest user experience community
Real User Monitoring (RUM) means fully understanding how internet performance impacts customer satisfaction and engagement. Cedexis gathers RUM data from each step between the client and any of the clouds, data centers, and CDNs hosting your applications to build a holistic picture of internet health. Every request creates more data, continuously updating this unique real-time virtual map of the web.

Data and alerts, your way
To effectively evaluate your service and enable real-time troubleshooting, Netscope lets you roll up data by the ASN, country, region, or state level. You can zoom in within a specific ASN at the IP subnet level, to dissect the data in any way your business requires. This data will be stored in the cloud on an ongoing basis. Netscope also allows users to easily set up flexible network alerts for performance and latency deviations.

Netscope helps ISP Product Managers and Marketers better understand:

  • How well users connect to the major content distributors
  • How well users/business connect to public clouds (AWS, Google Cloud, Azure, etc.)
  • When, where, and how often outages and throughput issues happen
  • What happens during different times of day
  • Where are the risks during big events (FIFA World Cup, live events, video/content releases)
  • How service on mobile looks versus web
  • How the ISP stacks up v. ”the best” ISP  in the region

Bring Advanced Network analysis to your network
Netscope provides a critical data set you need for your network planning and enhancement. With its real-time understanding of worldwide network health, Netscope gives you the context and actionable data you need to delight customers and increase your market share.

Ready to use this data with your team?

Set up a demo today


Introducing the All New Sonar: a cloud-native synthetic testing tool for any infrastructure

I never guess. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.
Sir Arthur Conan Doyle

Synthetic monitoring built for hybrid cloud
Sonar tests all of your endpoints: in your public clouds, private clouds, data centers, or CDNs. This provides a comprehensive and uniform view of the overall health of your applications delivery, no matter what the status of your various infrastructure components happens to be.
Sonar’s proactive testing acts like a virtual end user, testing to see how an application, video, or large file download would be experienced by your global customers. Being able to test your app from nine locations worldwide helps ensure your data has incredibly low latency, and therefore is actually usable for your app delivery strategy.

Ultra-low latency Synthetic monitoring, refreshed up to every other second
Public cloud users are probably used to having access to some sort of synthetic app testing functionality, as a core part of the services offered by the individual cloud provider. Where many cloud services offer services that check for availability every 30 to 120 seconds, Sonar offers checks as frequently as every two seconds. Data that’s updated every few minutes really isn’t meaningful for a solution that need to make real-time, automated delivery decisions. Not to mention the question of data objectivity when source information comes from the provider of the infrastructure being monitored.

Monitoring is passive. Cedexis is insight + action.
What makes Sonar different to other synthetic testing agents is that Sonar data can be used to shape application delivery decisions in real-time. Data collected by Sonar feeds directly into the Cedexis application delivery platform, which uses fully user-configurable algorithms to route traffic to the endpoints that deliver the highest customer experience at the lowest operational cost. Owing to the frequent health checks, and the rapid calculation of optimal traffic routes, Cedexis provides the lowest-latency cloud-based application delivery service available, with automated delivery decisions being made to route around traffic congestion less than 10 seconds after problems initially arise. By contrast, most cloud services, with less frequent synthetic checks and slower decisioning engines, may be expected to take as much as two to four times as long to respond to emerging issues.

Better data means better decisions.
Delivering applications over the internet, like all interactions with complex, dynamic systems, ultimately meets success or failure based on the data you use for making decisions. In this case, decisions are the “real-time” application delivery choices your platform makes to ensure apps and video reach your customers in a way that produces a great user experience. Using real user monitoring like Radar – the world’s largest real-time user experience community – provides data you can use to make automated delivery decisions on your hybrid infrastructure. But to enable your application delivery logic to fully understand and optimize delivery for all of your customers and potential customers worldwide, you need to proactively test networks. That’s where Cedexis’ Sonar functionality comes in.

The three pillars of Application Delivery
Cedexis application delivery platform is powered by three powerful services:

  • Radar: the world’s largest community of instantaneous and actionable user experience data
  • Fusion: a powerful 3rd party data ingestion tool that makes APM, Local Load Balancer, cloud metrics, and any other dataset actionable in delivery logic
  • [NEW!]: Sonar: a massively scalable and architecture-agnostic synthetic testing tool that is immune to the latency issues of proprietary cloud tools


The Cedexis application delivery platform automates and optimizes the customer experience for apps, video, and static content while minimizing cloud and content delivery costs. This is done by combining billions of real user data points from over 50,000 networks, Sonar synthetic testing data, and any other dataset you use to optimize delivery based on real user data from our entire network (not just your customers).
If you haven’t created a Cedexis portal account yet, now’s the time. You can set up your global application delivery in a few minutes and see how Sonar works for yourself.   

Why CapEx Is Making A Comeback

The meteoric rise of both the public cloud and SaaS have brought along a strong preference for OpEx vs. CapEx. To recap: OpEx means you stop paying for a thing up front, and instead just pay as you go. If you’ve bought almost any business software lately you know the drill: you walk away with a monthly or annual subscription, rather than a DVD-ROM and a permanent or volume license.

But the funny thing about business trends is the frequency with which they simply turn upside down and make the conventional wisdom obsolete.

Recently, we have started seeing interest in getting out of pay as you go (rather unimaginatively often shortened as PAYGO) as a model, and moving back toward making upfront purchases then holding on for the ride as capital items get amortized.

Why? It’s all about economies of scale.

Imagine, if you will, that you are able to rent an office building for $10 a square foot, then rent out the space for $15 a square foot. Seems like a decent deal at 50% margin; but of course you’re also on the hook for servicing the customers, the space, and so forth. You’ll get a certain amount of relief as you share janitorial services across the space, of course, but your economic ceiling is stuck at 50%.

Now imagine that you purchase that whole building for $10M and rent out the space for $15M. Your debt payment may cut into profits for a few years, but at some point you’re paid off – and every year’s worth of rent thereafter is essentially all profit.

The first scenario puts an artificial boundary on both risk and reward: you’re on the hook for a fixed  amount of rental cost, and can generate revenues only up to 150% of your outlay. You know how much you can lose, and how much you can gain. By contrast, in the second scenario, neither risk nor reward is bounded: with ownership comes risk (finding asbestos in the walls, say), as well as unlimited potential (raise rental prices and increase the profit curve).

This basic model applies to many cloud services – and to no small degree explains why so many companies are able to pop up – their growth is scaled with provisioned services.

If you were to decide to fire up a new streaming video service, say, that showed only the oeuvre of, say, Nicolas Cage, you’d want to have a fairly clear limit on your risk: maybe millions of people will sign up, but then again maybe they won’t. In order to be sure you’ve maximized the opportunity, though, you’ll need a rock solid infrastructure to ensure your early adopters get everything they expect: quick video start times, low re-buffering ratios, and excellent picture resolution. It doesn’t make sense to build that all out anew: you’re best off popping storage onto a cloud, maybe outsourcing CMS and encoding to an Online Video Platform (OVP), and delegating delivery to a global content delivery network (CDN). In this way you can have a world-class service, without having to pony up for servers, encoders, points of presence (POPs), load balancers, and all the other myriad elements necessary to compete.

In the first few months, this would be great – your financial risk is relatively low as you target your demand generation at the self-proclaimed “total Cage-heads”. But as you reach a wider and wider audience, and start to build a real revenue stream, you realize: the ongoing cost of all those outsourced, opex-based, services is flattening the curve that could bring you to profitability. By contrast, spinning up a set of machines to store, compute, and deliver your content could set a relatively fixed cost that, as you add viewers, would allow you to realize economies of scale and unbound profit.

We know that this is a real business consideration because Netflix already did it. Actually, they did it some time ago: while they do much (if not most) of their computation through cloud services, they decided in 2012 to move away from commercials CDNs in favor of their own Open Connect, and announced in 2016 that all its content delivery needs were now covered by their own network. Not only did this reduce their monthly opex bill, it also gave them control over the technology they used to guarantee an excellent quality of experience (QoE) for their users.

So for businesses nearing this op v. cap inflection point, the time really has arrived to put pencil to paper and calculate the cost of going it alone. The technology is relatively easy to acquire and manage, from server machines, to local load balancers and cache servers, and on up to global server load balancers. You can see a little bit more about how to actually build your own CDN here.

Opex solutions are absolutely indispensable in getting new services off the starting line; but it’s always worth keeping an eye on the economics, because with a large enough audience going it alone is the way to go.

Optimizing for Resources and Consumers Alike

One of the genuinely difficult decisions being made by DevOps, Ops, and even straight-up developers, today is how to ensure outstanding quality of experience (QoE) for their users. Do you balance the hardware (physical, virtual, or otherwise) for optimal load? Or track  quality of service (QoS) metrics – like throughput, latency, video start time, and so forth – and use those as the primary guide?

It’s really not a great choice, which is why we’re happy to say, the right answer to the question of whether to use local or global traffic management is: both.

It hasn’t been a great choice in the past because, while synthetic and real user measurements (RUM) overlap pretty broadly, neither is the subset of the other. For instance, RUM might be telling you that users are getting great QoE from a cluster of virtual servers in Northern Virginia – but it doesn’t tell you if those servers are near their capacity limits, and could do with some help to prevent overloading. Conversely, synthetic data can tell you where the most abundant resources are to complete a computational, storage, or delivery task – but they generally can’t tell you whether the experience at the point of consumption will be one of swift execution, or of fluctuating network service that causes a video to constantly sputter and pause as the user’s client tries to buffer the next chunk.

Today, though, you can combine the best of both worlds, as Cedexis has partnered with NGINX and their NGINX + product line to produce a unique application delivery optimization solution. Think of it as a marriage of local traffic management (LTM) and global traffic management (GTM). LTM takes care of routing traffic that arrives at a (virtual or physical) location between individual resources efficiently, ensuring that resources don’t get overloaded (and of course, spins up new instances when ready); GTM takes care of working out which location gets the request in the first place. Historically, LTM has been essentially blind to user experience; and GTM has been limited to relatively basic local network data (simple “is-it-working” synthetic monitoring for the most part).

Application delivery optimization demands not just real-time knowledge of what’s happening at both ends, but real-time routing decisions that ensure the end user is getting the best experience. Combining LTM and GTM makes it simple to

  1. Improve on Round Robin or Geo-based balancing. For sure, physical proximity is a leading indicator of superior experience (all else being equal, data that has to travel shorter distances will arrive more quickly). By adding awareness of QoE at the point of consumption, however, Ops teams can ensure that geographically-bounded congestion or obstructions (say, for instance, peering between a data center and an ISP) can be avoided by re-routing traffic to a higher-performing, if more geographically distant, option. In its simplest iteration, the algorithm simply says “so long as we can get a certain level of quality, choose the closest source, but never use any source that dips below that quality floor”.
  2. Re-route around unavailable server instances. Each data center or cloud may combine a cluster of server instances, balanced by NGINX +. When one of those instances becomes unavailable, however (whether through catastrophic collapse, or simply scheduled maintenance), the LTM can let the GTM know of its reduced capacity, and start the process of routing traffic to other alternatives before any server instance become overloaded. In essence, here the LTM is telling the GTM not to get too carried away with QoE – but to check that future experiences have a good chance of mirroring those being delivered in the present.
  3. Avoid application problems. NGINX+ lets Openmix know the health of the application in a given node in real-time. So if, for instance, an application update is made to a subset of application servers, and it starts to throw an unusual number of 50errors, the GTM can start to route around that instance, and alert DevOps of an application problem. In this way, app updates can be distributed to some (but not all) locations throughout the network, then automatically de-provisioned if they turn out not be functioning as expected.

Combining the power of real user measurements, hardware health, and application health, will mean expanding the ability of every team to deliver a high QoE to every customer. At no point will user’s requests be sent to servers approaching full use; nor will they be sent to sprightly resources who can’t actually deliver QoE owing to network congestion that is beyond their control.

It also, of course, will create a new standard: once a critical mass of providers is managing its application delivery in this capacity-aware, consumer-responsive, application-tuned way, a rush will develop for those who have not yet reached this point to catch up. So take a moment now to explore how combining the LTM and GTM capabilities of NGINX+ and Cedexis might make sense for your environment – and get a step up on your competition.

Which Is The Best Cloud or CDN?

Oh no, you’re not tricking us into answering that directly – it’s probably the question we hear more often than any other. The answer we always provide: it depends.

Unsatisfying? Fair enough. Rather than handing you a fish, let us show you how to go haul in a load of blue fin tuna.

What a lot of people don’t know is that, for free, you can answer this sort of thing all by yourself on the Cedexis portal. Just create an account, click through on the email we send, and you’re off to the races (go on – go do it now, we’ll wait…it’s easier to follow along when you have your own account).

The first thing you’ll want to do is find the place where you get all this graphical statistical goodness: click Radar then select Performance Report, as shown below

With this surprisingly versatile (and did we mention free) tool, you can answer all the questions you ever had about traffic delivery around the world. For instance, if I’m interested in working out which continent has the best and worst availability. Simply change the drop down around the top left to show ‘Continent’ instead of ‘Platform’, and voila – an entirely unsurprising result:

Now that’s a pretty broad brush. Perhaps you’d like to know how a different group of countries, or states look relative to one another – simply select those countries or states from the Location section on the right hand side of the screen and you’re off to the races. Do the same with Platforms (that’s the cloud providers and CDNs), and adjust your view from Availability to Throughput or Latency to see how the various providers are doing when they are Available.

So, if you’re comparing a couple of providers, in a couple of states, you might end up with something that looks like this:

Be careful though – across 30 days, measured day to day, it looks like there’s not much difference to be told, nor much improvement to be found by using multiple providers. Ensure that you dig in a little deeper – maybe to the last 7 days, 48 hours, or even 24 hours.Look what can happen when you focus in on, for instance, a 48 hour period:

There are periods there where having both providers in your virtual infrastructure would mean the difference between serving your audience really well, and being to all intents and purposes unavailable for business.

If you’ve never thought about using multiple traffic delivery partners in your infrastructure – or have considered it, but rejected it in the absence of solid data – today would be a great day to go poke around. More and more operations teams are coming to the realization that they can eliminate outages, guarantee consistent customer quality, and take control over the execution and cost of their traffic delivery by committing to a Hybrid Cloud/CDN strategy.

And did we mention that all this data is free for you to access?


Caching at The Edge: The Secret Accelerator

Think about how much data has to move between a publisher and a whole audience of eager viewers, especially when that content is either being streamed live, or is a highly-anticipated season premiere (yes, we’re all getting excited for the return of GoT). Now ask yourself where there is useless repetition, and an opportunity to make the whole process more efficient for everyone in the process.

Do so, and you come up with the Streaming Video Alliance-backed concept of Open Caching.

The short explanation is this: popular video content is detected and cached by ISPs at the edge; then, when consumers want to watch that content, they are served from local caches, instead of forcing everyone to pass a net-new version from origin to CDN to ISP. The amazing thing is how much of a win/win/win it really is:

  • Publishers and CDNs don’t have to deliver as much traffic to serve geographically-centered audiences
  • ISPs don’t have to pull multiple identical streams from publishers and CDNs
  • Consumers get their video more quickly and reliably, as it is served from a source that is much closer to them

A set of trials opened up in January, featuring some of the biggest names in streaming video: ViaSat, Viacom, Charter, Verizon, Yahoo, Limelight Networks, MLBAM, and Qwilt.

If this feels a bit familiar, it should: Netflix have essentially built exactly this (they call it Netflix Open Connect), by placing hardware within IXPs and ISPs around the world – some British researchers have mapped it, and it’s fascinating. And, indeed, they recently doubled down in India, deploying cached versions of their catalog (or at least the most used elements of it) all around that country.  The bottom line is that the largest streaming video provider (accounting for as much as 37% of all US Internet traffic) understands that the best experience is delivered by having the content closer to the consumer.

As it turns out, ISPs are flocking to this technology for all the reasons one might expect: this gives back some control over their networks, and provides the opportunity to get off the backhaul treadmill. By pulling, say, a live event one time, caching it at the edge, then delivering from that edge cache, they can substantially reduce their network volume and make end customers happy.

And yet – most publishers are only vaguely aware that this is happening (if you’re all up to speed on ISP caching, consider yourself ahead of the curve). Part of the reason is that when ISPs cache content that has traveled their way through a CDN, they preserve the headers – so the traffic isn’t necessarily identifiable as having been cached. And, indeed, if you have video monitoring at the client, those headers are being used, potentially making the performance of a given CDN look even better than it already is, because content is being served at the edge by the ISP. The ISP, in other words, is making not only the publisher look good, with excellent QoE – they’re also making the CDN look like a rock star!

To summarize: the caching that is happening at the ISP level is like a double-super-secret accelerator for your content, whose impact is currently difficult to measure.

It’s also, however, pretty easy to break. Publishers who opt to secure all their traffic essentially eliminate the opportunity for the ISP to cache their content, because the caching intelligence can’t identify what the file is or whether it needs caching. Now, that’s not to say the challenge insurmountable at all – APIs and integrations exist that allow the ISP to re-enter the fray, decrypt that secure transmission, and get back to work making everyone look good by delivering quickly and effectively to end consumers.

So if you aren’t yet up to speed on open caching, now is the time to do a little research. Pop over to the Streaming Video Alliance online and learn more about their Open Caching working group today – there’s nothing like finding out you deployed a secret weapon, without even knowing you did it.


Don’t Be Afraid of Microservices!

Architectural trends are to be expected in technology. From the original all-in-one-place Cobol behemoths half the world just learned existed because of Hidden Figures, to three-tiered architecture, to hyper-tier architecture, to Service Oriented Architecture….really, it’s enough to give anyone a headache.

And now we’re in a time of what Gartner very snappily calls Mesh App and Service Architecture (or MASA). Whether everyone else is going for that particular nomenclature is less relevant than the reality that we’ve moved on from web services and SOA toward containerization, de-coupling, and the broadest possible use of microservices.

Microservices sound slightly disturbing, as though they’re very, very small components, of which one would need dozens if not hundreds to do anything. Chris Richardson of Eventuate, though, recently begged us not to assume that just because of the name these units are tiny. In fact, it makes more sense to think of them as ‘hyper-targeted’ or ‘self-contained’ services: their purpose should be to execute a discrete set of logic, which can exist in isolation, and simply provide easily-accessed public interfaces. So, for instance, one could imagine a microservice whose sole purpose was to find the best match from a video library for a given user: requesting code would provide details on the user, the service would return the recommendation. Enormous amounts of sophistication may go into ingesting the user-identifying data, relating it to metadata, analyzing past results, and coming up with that one shining, perfect recommendation…but from the perspective of the team using the service, they just need to send a properly-formed request, and receive a properly-formed response.

The apps we all rely upon on those tiny little computers we carry around in our pocketbooks or pockets (i.e. smart phones) fundamentally rely on microservices, whether or not their developers thought to describe them that way. That’s why they sometimes wake up and spring to life with goodness…and sometimes seem to drag, or even fail to get going. They rely upon a variety of microservices – not always based at their own home location – and it’s the availability of all those microservices that dictates the user experience. If one microservice fails, and is not dealt with elegantly by the code, the experience becomes unsatisfactory.

If that feels daunting, it shouldn’t – one company managed to build the whole back end of a bank on this architecture.

Clearly, the one point of greatest risk is the link to the microservice – the API call, if you will. If the code calls to a static endpoint, the risk is that that endpoint isn’t available for some reason; or at least, is unavailable at an acceptable speed. This is why there are any number of solutions for trying to ensure the microservice is available, often spread between authoritative DNS services (which essentially take all the calls for a given location and then assign them to backend resources based on availability), and application delivery controllers (generally physical devices that perform the same service). Of course if either is down, life gets tricky quickly.

In fact, the trick to planning for highly available microservices is to embed locations that are managed by a cloud-based application delivery service. In other words, as the microservice is required, a call goes out to a location that combines both synthetic and real-user measurements to determine the most performant source and re-direct the traffic there. This compounds the benefits of the microservice architecture: not only can the microservice itself be maintained and updated independently of the apps that use it, so too the network and infrastructure necessary to its smooth and efficient delivery can be tweaked without affecting existing users.

Microservices are the future. To make the most, first ensure that they independently address discrete purposes; then make sure that their delivery is similarly defined and flexible without recourse to updating apps that use them; then settle back and watch performance meet innovation.

Live and Generally Available: Impact Resource Timing

We are very excited to be officially launching Impact Resource Timing (IRT) for general availability.

IRT is Impact’s powerful window into the performance of different sources of content for the pages in your website. For instance, you may want to distinguish the performance of your origin servers relative to cloud sources, or advertising partners; and by doing so, establish with confidence where any delays stem from. From here, you can dive into Resource Timing data sliced by various measurements over time, as well as through a statistical distribution view.

What is Resource Timing? Broadly speaking, resource timing measures latency within an application (i.e. browser). It uses JavaScript as the primary mechanism to instrument various time-based metrics of all the resources requested and downloaded for a single website page by an end user. Individual resources are objects such as JS, CSS, images and other files that the website pages requests. The faster the resources are requested and loaded on the page, the better quality user experience (QoE) for users.  By contrast, resources that cause longer latency can produce a negative QoE for users.  By analyzing resourcing timing measurements, you can isolate the resources that may be causing degradation issues for your organization to fix.  

Resource Timing Process:

Cedexis IRT makes it easy for you to track resources from identified sources, normally identified through domain (*, by sub-domain(e.g., and by the provider serving your content. In this way, you can quickly group together types of content, and identify the source of any latency. For instance, you might find that origin-located content is being delivered swiftly, while cloud-hosted images are slowing down the load time of your page; in such a situation, you would now be in a position to consider a range of solutions, including adding a secondary cloud provider and a global server load balancer to protect QoE for your users.

Some benefits of tracking Resource Timing.

  • See which hostnames  – and thus which classes of content – are slowing down your site.
  • Determine which resources impact your overall user experience.
  • Correlate resource performance with user experience.

Impact Resource Timing from Cedexis allows you to see how content sources are performing across various measurement types such as Duration, TCP Connection Time, and Round Trip Time. IRT reports also give you the ability to drill down further by Service Providers, Locations, ISPs, User Agent (device, browsers, OS) and other filters.

Check out our User Guide to learn more about our Measurement Type calculations.

There are two primary reports in this release of Impact Resource Timing. The Performance report, which gives you a trending view of resource timing over time and the Statistical Distribution report, which reports Resource Timing data through a statistical distribution view.  Both reports have very dynamic reporting capabilities that allow you to easily pinpoint resource-related issues for further analysis.  

Using the Performance report, you can isolate which grouped resources are causing potential end user experience issues by hostname, page or service provider and when the issue happened. Drill down even further to see if this was a global issue or localized to a specific location or if it was by certain user devices or browsers.  

IRT is now available for all in the Radar portal – take it for a spin and let us know your experiences!

Why The Web Is So Congested

If you live in a major city like London, Tokyo, or San Francisco, you learn one thing early: driving your car through the city center is about the slowest possible way to get around. Which is ironic, when you think about it, as cars only became popular because they made is possible to get around more quickly. There is, it seems, an inverse relationship between efficiency and popularity, at least when it comes to goods that pass through a public commons like roads.

Or like the Internet.

Think about all that lovely 4K video you could be consuming if there was nothing between you and your favorite VOD provider but a totally clear fiber optic cable. But unless you live in a highly over-provisioned location, that’s exactly not what’s going on; rather, you’re lucky to get a full HD picture, and even luckier if it stays at 1080p, without buffering, all the way through. Why? Because you’re sharing a public commons – the Internet – and its efficiency is being chewed away by popularity.

Let’s do some math to illustrate this,

  • Between 2013 and January 2017 the number of web users increased by 1.4 billion people to just over 3.7 billion. Today Internet penetration is at 50% (or put another way – half the world isn’t online yet)
  • In 2013, the average amount of Internet data per person was 7.9G per month; by 2015 it was 9.9G, with Cisco expecting it to reach over 25Gb by 2020 – so assume something in the range of 15Gb by 2017.
  • Logically, then in 2013 web traffic would have been around 2.3B * 7.9G per months (18.1t exabytes), by 2015 it would have been  3.7B * 17Gb per month (62.9 exabytes)
  • If we assume another billion Internet users by 2020, we’re looking at 4.7B & 25Gb per month – or a full 117.5 exabytes

In just seven years, the monthly web traffic will have grown 600% (based on the math, anyway: Cisco is estimating closer to 200 exabytes monthly by 2020).

And that is why the web is so busy.

But it doesn’t describe why the web is congested. Congestion happens when there is more traffic than transit space – which is why, as cities get larger and more populous, governments add lanes to major thoroughfares, meeting the automobile demand with road supply.

Unfortunately, unlike cars on roads, Internet traffic doesn’t travel in straight lines from point to point. So even though infrastructure providers have been building out capacity at a madcap pace, it’s not always connected in such a way that makes transit efficient. And, unlike roads, digital connections are not built out of concrete, and often become unavailable – sometimes for a long time that causes consternation and PR challenges, and sometimes just for a minute or so, stymying a relative handful of customers.

For information to get from A to B, it has to traverse any number of interconnected infrastructures, from ISPs to the backbone to CDNs, and beyond. Each is independently managed, meaning that no individual network administrator can guarantee smooth passage from beginning to end. And with all the traffic that has been – and will continue to be – added to the Internet, it has become essentially a guarantee that some portion of content requests will bump into transit problems along the way.

Let’s also note that the modern Internet is characterized less by cat memes, and more by the delivery of information, functionality, and ultimately, knowledge. Put another way, the Internet today is all about applications: whether represented as a tile on a smart phone home screen, or as a web interface, applications deliver the intelligence to take the sum total of all human knowledge that is somewhere on the web and turn it into something we can use. When you open social media, the app knows who you want to know about; when you consult your sports app, it knows which teams you want to know about first; when you check your financial app, it knows how to log you in from a fingerprint and which account details to show first. Every time that every app is asked to deliver any piece of knowledge, it is making requests across the Internet – and often multiple requests of multiple sources. Traffic congestion doesn’t just endanger the bitrate of your favorite sci fi series – it threatens the value of every app you use.

Which is why real-time predictive traffic routing is becoming a topic that web native businesses are digging deeper into. Think of it as Application Delivery for the web – a traffic cop that spots congestion and directs content around it, so that it’s as though it never happened. This is the only way to solve for efficient routing around a network of networks without a central administrator: assume that there will be periodic roadblocks, and simply prepare to take a different route.

The Internet is increasingly congested. But by re-directing traffic to the pathways that are fully available, it is possible to get around all those traffic jams. And, actually, it’s possible to do today.

Find out more by reading the story of how Rosetta Stone improved performance for over 60% of their worldwide customers.


Better OTT Quality At Lower Cost? That Would Be Video Voodoo

According to the CTA, streaming video now claims as many subscribers as traditional Pay TV. Another study, from the Leichtman Research Group proposed that more households have streaming video than have a DVR. However accurate – or wonkily constructed – these statistics, what’s not up for grabs is that more people than ever are getting a big chunk of their video entertainment over the Web. Given the infamous AWS outage, this means that providers are constantly at risk of seeing their best-laid-plans laid low by someone’s else’s poor typing skills.

Resiliency isn’t a nice-to-have, it’s a necessity. Services that were knocked out last week owing to AWS’ challenges were, to some degree, lucky: they may have lost out on direct revenue, but their reputations took no real hit, because the core outage was so broadly reported. In other words, everyone knew the culprit was AWS. But it turns out that outages happen all the time – smaller, shorter, more localized ones, which don’t draw the attention of the global media, and which don’t supply a scapegoat. In those circumstances, a CDN glitch is invisible to the consumer, and is therefore not considered: when the consumer’s video doesn’t work, only the publisher is available to take the blame.

It’s for this reason that many video publishers that are Cedexis customers first start to look at breaking from the one-CDN-to-rule-them-all strategy, and look to diversify their delivery infrastructure. As often as not,this starts as simply adding a second provider: not so much as an equal partner, but as a safety outlet and backup. Openmix intelligently directs traffic, using a combination of community data (the 6 billion measurements we collect from web users around the world each day) and synthetic data (e.g. New Relic and CDN records). All of a sudden, event though outages don’t stop happening, they do stop being noticeable because they are simply routed around. Ops teams stop getting woken up in the middle of the night, Support teams stop getting sudden call spikes that overload the circuits, and PR teams stop having to work damage control.

But a funny thing happens once the outage distractions stop: there’s time catch a breath, and realize there’s more to this multi-CDN strategy than just solving a pain. When a video publisher can seamlessly route between more than one CDN, based on its ability to serve customers at an acceptable quality level, there is a natural economic opportunity to choose the best-cost option – in real time. Publishers can balance traffic based simply on per-Gig pricing; ensure that commits are met, but not exceeded until every bit of pre-paid bandwidth throughout the network is exhausted; and distribute sudden spikes to avoid surge pricing. Openmix users have reported seeing cost savings that reach low to mid double-digit percentages – while they are delivering a superior, more consistent, more reliable service to their users.

Call it Video Voodoo: it shouldn’t be possible to improve service reliability and reduce the cost of delivery…and yet, there it is. It turns out that eliminating a single point of failure introduces multiple points of efficiency. And, indeed, we’ve seen great results for companies that already have multiple CDN providers: simply avoiding overages on each CDN until all the commits are met can deliver returns that fundamentally change the economics of a streaming video service.

And changing the economics of streaming is fundamental to the next round of evolution in the industry. Netflix, the 800 pound gorilla, has turned over more than $20 billion in revenue the last three years, and generated less than half a billion in net margin, a 5% rate; Hulu (privately- and closely-held) is rumored to have racked up $1.8B in losses so far and still be generating red ink on some $2B in revenues. The bottom line is that delivering streaming video is expensive, for any number of reasons. Any engine that can measurably, predictably, and reliably eliminate cost is not just intriguing for streaming publishers – it is mandatory to at least explore.