Explore insights on real-time edge computing, AI, and cloud solutions. Learn how our technology optimizes performance across industries.

Blog

Contributed by EDGE GRAVITY from their new blog series: 

. This collection of blogs will focus on new technologies and industry leaders in the 

 as way to educate a broad IT audience in the future capabilities at the edge.

Macrometa Global Edge Fabric is an Edge Native Platform as a Service (PaaS) for building distributed applications and APIs for the web, mobile devices, 

, gaming and more. It delivers instant, low 

 stateful data for Single Page Apps (SPAs), Progressive Web Apps (PWAs), and more.

Chetan Venkatesh, CEO at Macrometa on how edge will generate an entire new class of services based on proximity to customers, location awareness, and the ability to co-ordinate data and services that don’t work in a centralized cloud. The edge requires a paradigm shift from the current architecture of databases as edge demands the processing of massive amounts of data in real-time to present the customer with instant responses.

Challenges of edge computing for application developers:

Real-time data analysis at significant volume

To see more thought leadership videos from the Global Edge Forum event visit the EDGE GRAVITY YouTube playlist: 

Reprinted with permission. Original source at 

Building Applications For The Edge With A Datacentric Model

Life happens in the HERE and in the NOW. The HERE and the NOW are defined by where we are and what interactions, events are going on around us and with us. These events and interactions occur in the real world and not some far off data center a thousand miles from us. Similarly every interaction we do typically involves “state” or data about the interaction that combines with other state to create “context” which is essential for us to create and understand meaning from all the interactions we have . But we store this state (data) 1000s of miles away in far remote locations - cloud data centers.

This is like interacting with someone who either doesn’t remember from one sentence to the next sentence (aka stateless) or someone who has to travel 1000s of miles to respond to us each time (aka centralized state stores). If we put it this way, it certainly sounds silly, doesn’t it?

But this is what is presented as a normal way of doing things at the edge with stateless apps and centralized databases. There has to be a better way!

 and streams that provide data at the edge, can scale across tens and hundreds of locations worldwide, and yet act in concert to provide a single coherent multi master database or stream.

It means we need to design systems that work on the internet with its unpredictable network topology, maintain causality over networks that are lossy, and avoid centralized forms of consensus - while still arriving at some shared version of truth in real time. Can this be done? This is the the question that piqued our interest and started a new journey at Macrometa.

There are many good distributed database (sql, nosql,..) and streaming systems out there. So why can’t these systems enable us to have state locally at the edge?

Note: There are some NoSQL/NewSQL databases that can span 3 or 4 or 5 regions, but are not exactly a true geo-distributed or edge native database.

 is something that allows reads and writes locally in all locations in parallel and does not require a user to magically know which data should be placed in which location or require that user to redesign the schema every time they want to add/remove a location.

Coming back, so why can’t the current generation of databases and streaming systems handle multiple locations?

One problem with most of the current distributed databases and streaming systems is that they rely on consensus protocols like Zab (zookeeper), or Raft or Paxos as their foundation. These are certainly beautiful protocols; but these protocols are meant for running inside data centers where the networks are ultra-reliable and low latency.

These protocols (and thereby the systems built on these) are not a good fit for WAN environments where the network is lossy, jittery and high latency. What we need database and streaming systems that are coordination-free and offline-first.

Let’s say you go to a nice restaurant with your partner and order a wine and dessert. Let’s say you ordered wine from the bartender and your partner ordered dessert from the waiter. How would you feel if the restaurant serves you nice folks only one i.e., wine or dessert but not both?

It certainly does not make sense. But that is how most current generation NoSQL databases work with their last-writer-wins approach. In other words, when two edge locations receive writes in parallel (i.e., not causally related), then only one change gets picked up and other change is lost.

What makes more sense is for both of your orders converged and the restaurant serves everyone both wine and dessert. In other words, what we need are databases that can intelligently converge changes in real-time at each location without coordination, but all come to the same definite version of truth.

If interested you can look at CRDT research for more info on this. CRDTs are objects that can be updated without expensive synchronization/consensus, and they are guaranteed to converge eventually if all concurrent updates are commutative and if all updates are executed by each replica eventually.

Similarly, there are some use cases like the double-spend problem where strong consistency is a must. But that does not mean that other use cases are penalized to support this subset of use cases. What we need are databases that can support various levels of data consistencies so that developers can make their choice depending on the use case.

Imagine you went to a coffee shop with your colleague. Your colleague orders one `Cafe Latte` Tall. You order something like below :

1/4 teaspoon vanilla extract - mix in after cycle is complete

You can imagine how the coffee barista looks at you. You might get a similar look from your colleague as well. The reality is both you and your colleague ordered the same thing i.e., `Cafe Latte` but what is different is the abstraction level of the order.

In recent years, there is significant progress on CRDTs and CRDT related technologies. But much of the research is about data types like Counters, OR-Sets etc. That probably makes sense from an academic perspective. But what developers need is `Cafe Latte`. Not the ingredients.

What is needed are higher level abstractions that developers can work with and quickly be productive - like databases with various consistency semantics, query languages etc.

When you choose a database today, you’re not choosing one piece of technology. You’re choosing three i.e., storage technology, data model, and API/query language.

For example, let’s say you choose Postgres. What you are choosing actually is the Postgres storage engine, a relational data model, and the SQL query language. Similarly if you choose MongoDB you are choosing the MongoDB distributed storage engine, a document data model, and the MongoDB API.

A fundamental problem with many of the current generation databases including the above mentioned ones is that they are below big monolithic systems with features interwoven between all of the layers. Monolithic databases continue to be useful pieces of technology, but they are evolutionary dead ends. They are the products of a smaller, less-connected era, and their shortcomings risk becoming liabilities for your business as it evolves.

Document databases, column-oriented, row-oriented, JSON, key-value, etc. all make sense in the right context, and often different parts of an application call for different choices. This creates a tough decision: Use a whole new database (and licenses, etc.) to support a new data model, or try to shoehorn data into your existing database.

What we need is layered model that decouples its various layers - data storage, data organization, data manipulation and data model.

This allows a single database system to support multiple data models against a single, integrated backend. Document, graph, relational, and key-value are examples of data models that may be supported by a multi-model database.

Support multiple data models against a single, integrated backend,

Employ a unified query language to retrieve correlated multi-model data such as Graph-Json-Key/Value etc in a single platform and

Support multi-model ACID 2.0 transactions.

Data privacy is a big issue and rightfully so. GDPR is one big step in that direction and I would imagine more regions and countries will follow this path in future. Database and Streaming systems (being holders of data) fall right into middle of this.

Most databases and streaming systems currently do not address this. The databases that attempt to address this typically use techniques like Geo-Partitioning (break the dataset into multiple subsets or partitions) and keep each subset in a different region.

While on the surface it looks right, this approach creates few problems. For example, it requires customers to know which subset of the dataset will be used in which region and then partition the dataset so that the partition falls into that region.

Similarly if a business is doing well and their customer base expands to other regions, this approach would require deep schema changes to support proper placement of data.

What is better? A database or streaming system that can geofence the data natively with strong isolation and does not require schema changes when a business expands to more regions.

The above are some of the fundamental issues with current database and streaming systems. We cannot address these by doing more of the same. We need to build systems with architectures that address these problems natively. Is it possible?

Certainly yes! We have built Global Date Network that addresses the above and other issues natively. It is currently running in 25+ locations worldwide with scheduled expansion beyond 100 by end of the year.

Clearly, more databases and streaming systems will emerge to address these fundamental problems. The important point is that the technology is available today, and provided by 

Why Global Data Network? Or Why We Built A Truly Coordination-Free Distributed Database For Edge Computing

“Do we need a next generation of game consoles?”

Guest post by Gaming Industry veteran Justin Keeling who has held senior leadership roles at Fox Interactive, Disney, and many other amazing industry leaders.

GameSpot recently polled their readers and asked them the following question:

With 5G on horizon and end-to-end fiber optic pipelines, how close are we to a future where gamers can just stream everything?

75% of readers chose: “Not remotely close”.

The skepticism is understandable. Since 2009, cloud gaming platforms like OnLive and Gaikai have been hyped as the disrupters of the traditional gaming console. I played the first OnLive demo at GDC 2009: Crysis running on a mid-range laptop. Most gaming desktops couldn’t run the game at the time and OnLive felt like black magic.

Outside of the demo environment - and in the real world- it couldn’t live up to the hype. Neither OnLive or Gaikai still operate, although some of their core networking technologies made it into current platforms like PlayStation Now.

But even a decade later nothing yet offers the invisible controller-to-cortex response that most games require.

Over the next 18 months, the game streaming experience is set for a resurgence. Microsoft’s xCloud and Google’s Project Yeti have fired the first shots by leveraging their parent companies’ end-to-end ecosystems to build platforms designed around streaming. Amazon and PlayStation are also cooking their own solutions. And all of the top five game publishers are betting heavily on a game streaming future.

What’s different today, is that an industry-wide critical mass of telcos, CDNs, hardware makers, tool providers, content creators – and crucially– a new generation of deep tech researchers are working in coalition to finally make game streaming a reality.

Edge computing is one of the jigsaw pieces needed to make this all work. Simply put; the Edge is a post-cloud network architecture that is hyper-local, decentralized, and much more efficient than the current, monolithic cloud infrastructure that is behind the current digital ecosystem. And the implications for gaming go far beyond just streaming latency.

I’ve been advising Macrometa for a little over a year to understand the implications of their offering to the 

, and I’m excited that Macrometa is attacking one of the most significant parts of the problem at the intersection of 

. This holds the promise of radically transforming the experience of both gamers and game developers. Macrometa has recently emerged from stealth with its planet scaling serverless edge cloud – the Global Edge Fabric. I had an opportunity to speak with Joshua Petty, Macrometa’s Vice President of Products about their potential impact on gaming. He quickly agreed that edge computing offers incredible potential to easily create this new breed of streamed games.

“The team realized early on that there were many benefits to relocating game processing, logic, and analytics closer to the end user. Burying the infrastructure in traditional cloud architectures and databases is costly and severely limits the ability to create truly global, immersive environments for all users. What was missing was a powerful data and messaging platform at the edge that allowed developers to quickly create applications and games using a pre-built and flexible backend for managing dynamic data and content. So we decided to build it as a simple service for developers to consume. Moving everything closer to the end user was the obvious approach to resolve issues of performance and scale.”

“We also realized that improving the experience of developers required more than just providing a global multi-model database or data platform. We went to work at making the developer experience simple and seamless, combining a flexible and globally scaled edge database with serverless functions, containers, Streams that unify pub-sub messaging, and the ability to expose your data models and content as GraphQL or RESTful APIs automatically. The result is a simple backend delivered as a service supporting Unity and Unreal engines, along with java, Python, and other common web languages and runtimes.”

This type of approach could have a significant impact in the near term on some of the bigger challenges faced when attempting to build a ‘streaming everything’ game experience.

Millions of gamers play Fortnite, but the experience is segmented across different platforms and multiple devices. Recently, progress has been made by stitching together some elements of these ecosystems (thanks Microsoft, Nintendo, Epic).

However, Fortnite is a special case. It’s the world’s biggest game, the users have spoken, and “stitched” is the operative word here. PlayStation is still holding out. For most other games, forget it.

Users clearly want the Netflix & Spotify account experience. Cueing a track at home on an Echo, transitioning seamlessly to phone during a commute, and back onto a laptop at work.

The decentralized architecture at the core of Edge Computing, and platform providers like Macrometa that eliminate backend complexity for developers will help to enable this same seamless user experience for high bandwidth games.

2. Next-Generation Match-Making & User Management

There are plenty of back-end-services out there for multiplayer gaming. If you’re looking for the basics of match-making, leaderboards, and friends lists you’re already covered.

Larger game communities are magnitudes more demanding and require custom built tools – entire studios dedicated to live ops management and custom network architecture.

For example, Activision subsidiary Demonware helps build the multiplayer architecture for millions of concurrent players throwing mountains of real-time data at games like Call of Duty and Destiny 2. Under the current limitations of a centralized cloud/CDN internet architecture, it is a miracle these teams have made it work as well as it (usually) does.

But often it doesn’t work well, especially at scale. Destiny 2’s matching has been the source of community frustration for years. The game’s sluggish inventory systems are constantly lagging. Meanwhile, the PlayStation Network achievement ecosystem is bewilderingly slow to sync. Legacy cloud-based database architectures simply can’t keep up with increasing data and state management demands for much longer.

We need a better core solution for this. As we transition into the upcoming generation with more ambitious game designs, more users on the network, and more data flowing through that network, systems built on hyper-local Edge architecture can dramatically improve match-making accuracy and multiplayer user experiences across the board.

As much as we love Pokémon Go, the sheer volume of users and location data made for a laggy launch experience. It still gets sluggish around high data focal points.

Edge Computing’s architecture is tailor made for a new generation of challenging, high bandwidth AR games. Distributed platforms like Macrometa let developers synchronize player activity in much smaller groups based on location data, and then can automatically trigger functions that respond to local gameplay actions on a peer-to-peer basis.

The states of all in-game entities are also stored in real time at Edge locations much closer to the user than current centralized cloud servers, letting developers execute much more complex AR simulations, and with much less lag.

4. New frontiers in Real-time Data driven gameplay

 can sync local game world and player states in real-time, this also has huge implications for game design. If you’re designing experiences with a fixed, or intermittently updated version of what the game world is and what the player’s doing in it, you’re limited to a much less dynamic set of options

Edge Computing also manages data not just in real-time but in context– designers can use this contextual data to create custom experiences based on actual player progression. That opens up exciting new possibilities for truly persistent game play in online worlds, while actually lowering the processing and network overhead on a gamer’s console or device back home.

As we approach gaming’s next generation – our industry’s 10th– we collectively have an opportunity to harness the potential of Edge computing. The applications promise not only to solve age-old problems, but also unlock new experiences for developers increasingly frustrated by an infrastructure built for an older paradigm. 10 years on from the OnLive experiment, it’s time to embrace that future.

Macrometa is a global platform created from the ground-up on the Edge, powering the next generation of planetary scale games and apps. To arrange a demo at GDC or Google Next, contact: 

Beyond The Cloud: Edge Computing Opens New Frontiers For Online Gaming

OK, I admit. This is a controversial statement. After that admission, I can honestly say that as a 

, cloud computing doesn’t matter. It doesn’t make any difference where my apps live. Now, to the fun part…

I recently joined Macrometa for reasons that were fairly clear to me. My professional life has been largely spent waiting. Waiting for responses from customers, waiting for responses from colleagues, but worst of all - 

waiting for responses from applications and websites

What really matters to me? Performance. Content availability. Dynamic data delivered in real time. What do all three of these things have in common? From an application perspective, the only way to deliver them is with edge computing.

Edge computing is all about running applications closer to where I am accessing them, and eliminating latency and hops between my Mac and wherever the app happens to call home this week… AWS, Azure, anywhere. If you imagine the internet and by extension cloud computing as a hub and spoke architecture, AWS and similar services are the hub. I’m at the far end of the spoke, with points of presence (PoPs) in the middle. The PoP is the first piece of the app-enabled network that I access.

Until recently, the PoP had very limited value. It connects me to apps living hundreds (if not thousands) of miles away, and also had resident Content Delivery Networks (CDNs) running locally. The CDNs cache the static content and graphics I use from commonly accessed websites, but as soon as I make a weird content request (which I’m known to do) it is forwarded light years away to a sub-basement of a cloud datacenter and served up with the most fantastic latency possible. If all I did was browse Buzzfeed articles, this would be fine. But I’m actually trying to use web applications to 

Here is where edge computing comes in. The operative word is 

. Moving application logic, analytics, and content closer to me improves my experience. Moving cached content closer to me doesn’t help once I navigate away from Buzzfeed’s “30 Items for Valentine’s Day” article. Having said that, once I navigate to ‘open source games with Python APIs’ I’m on my own in a wilderness of cold storage and waiting for the page to load.

Macrometa is a company that really understands this problem. They’ve created an easily consumed PaaS for developers that blends a globally replicated database with all of the developer tools necessary to get a globally distributed application ready for distribution in minutes – not months. That application’s compute resources live 10 miles from my house or in my browser, not a thousand miles from me. The result is the best possible (and shamelessly selfish) user experience, while retaining enterprise management and distribution.

It may be too early to say that Macrometa is the “

”, but I can honestly say that it is definitely not the “

” that most of my web apps (including CRM) are currently delivering.

If you’re a developer, this is the new “

” platform. If you’re a consumer of apps, cross your fingers and hope that in the near future your apps will be delivered on this model. Cloud is no longer new, or optimal. It’s all about edge computing.

Cloud Computing Doesn't Matter In 2019

We are told that low latency and imagination are the only prerequisites for building tomorrow’s edge applications. Tragically, this is an incomplete and false hope. In order for robust, world-changing, enterprise applications to emerge, Macrometa believes we must first solve the very hard problem of bringing stateful data to the edge. Without stateful data, the edge will be doomed to forever being nothing more than a place to execute stateless code that routes requests, redirects traffic or performs simple local computations.

At Macrometa, we have created a cloud service for Web, Mobile, IoT and Augmented Gaming app builders to create sophisticated, real-time, globally distributed, edge applications. Much like how CDNs bring static content closer to end users making websites quick to load, the Macrometa Global Data Network (GDN) moves cloud based SaaS, web, mobile, IoT and database apps & APIs to the network edge. We enable anyone to build & run globally distributed, synchronized, fault tolerant applications powered by dynamic, query able data milliseconds away from users and devices across major cities and urban metropolitan regions worldwide.

During our beta program – customers built new e-commerce, mobile, IOT, gaming apps and interactive web experiences enhanced with real-time edge located dynamic data, enhanced their static CDN with our dynamic content engine delivering instant database results via GraphQL and REST, created distributed, high frequency analytics apps with edge based stream processing, solved complex GDPR problems by geo-fencing data with automatic consent compliance tracking. They have augmented (and even replaced) apps & API backends that were built on Google Cloud Spanner, AWS DynamoDB, Firebase, MongoDB, Kafka, & more.

We are excited to announce our exit from stealth with a server less edge cloud that spans 25 global metropolitan regions offering a “global database, global stream processing & function/container” as a service platform. Our edge cloud will expand to over 50 regions in 2019 and we plan to expand service to over 100 regions by mid 2020.

Turns out that that imagination is the only prerequisites for building tomorrow’s edge applications with Macrometa - Learn more at 

Macrometa Exits Stealth With A Planet Scaling Serverless EDGE Cloud - The GDN

Macrometa CEO and Co-Founder Chetan Venkatesh sits down with the brilliant & funny CEO of RackN systems Rob Hirschfeld and CMO Stephen Spector to talk about Edge Computing on the Latest shiny podcast.

We talked about how cloud architectures will evolve to create a true edge cloud capable of complimenting and perhaps even replacing public clouds some day.

Livin On The Edge @L8istSh9y Podcast

We are told that low latency and imagination are the only prerequisites for building tomorrow’s edge applications. Tragically, this is an incomplete and false hope.

In order for robust, world-changing edge native applications to emerge, we must first solve the very thorny problem of bringing stateful data to the edge. Without stateful data, the edge will be doomed to forever being nothing more than a place to execute stateless code that routes requests, redirects traffic or performs simple local calculations via serverless function. This would be the technological equivalent of Leonard Shelby in Christopher Nolan’s excellent movie Memento. Like Shelby, these edge applications would be incapable of remembering anything of significance, forced, instead, to constantly look up state somewhere else (e.g., the centralized cloud) for anything more than the most basic services.



 problem. It’s more than simply a distributed compute problem. It’s full power cannot be realized by simply spinning up stateless compute on the edge. Conventional enterprise-grade databases systems cannot deliver geo-distributed databases to the edge while also providing strong consistency guarantees. Conventional approaches fail at the large globally-distributed scale ng because our current database architectures are built around fundamental tenets of centralizing the coordination of state change and data.

To continue reading this article, please click here

Edge Computing Is A Distributed Data Problem

CDNs have been an important cornerstone of Internet infrastructure for the past two decades. By storing and serving popular static content (video, pictures, static web code) from close proximity Points Of Presence (POPs) to users around the world, CDNs have made the Internet usable by de-centralizing and distributing some aspects of the highly centralized architecture of the Internet and the applications that run on it.

The web has of course not stayed static. Web content has become increasingly dynamic, as users expect instant and personalized experiences while using any kind of web or mobile application or service. Delivering personalized content to users requires that significant parts of the content shown by the web application or sites are dynamically assembled - just in time - by looking up things like the user's preferences, history, interests, social connections etc. While we stare into our screens and jump from one click to the next, there's a complex ballet conducted behind the scenes where a co-ordinated dance of services do things like look up databases to fetch your data, analyze the data to extract insight to recommend what song to listen to, what movie to watch or what to buy.

CDNs unfortunately seem to be getting smaller and smaller parts to perform in this dynamic ballet.

 Since CDNs can't handle most types of dynamic content (i.e anything that involves a look up of data or state from a database or a key/value store), they essentially act as bumps on the wire that forward the request to the origin where code and databases work together to perform the numerous lookups, transformations, aggregations and code generation that power modern web applications. (authors note - it is another matter that CDNs have been forced to focus on areas like web security, application firewalls, DDOS protection etc to stay relevant and rightly so. It is analogous to an over the hill ballet dancer now moonlighting as the usher or bouncer at the theater because they are not important to the show anymore)

So why can't CDNs handle dynamic content?

The answer to that is dynamic content requires the storage and manipulation of persistent state (data) at the edge. Most web applications need to store the data that users create or manipulate them somewhere. This somewhere is usually a database like MySQL or Postgres or Oracle. Sometimes they are NoSQL databases like MongoDB or Cassandra, and other times they are cloud databases like Google Big Table or Amazon's DynamoDB. Almost all these databases centralize the web applications data i.e. they put it all in one giant pile in one of their regions or data center locations and every single request to create, lookup or change that data means that your web application has to send a call to that database in that one location where its stored and processed by the database.

Now CDN's can't help here because they cannot cache the contents of the database on their POPs since this data changes very frequently. CDNs run into a classic old distributed systems problem called cache coherency, i.e. keeping a local copy of the data in sync with changes that might be happening elsewhere.

Now there are lots of viable ways to address coherency and certainly using an eventually consistent (or never consistent) database will work for some situations (lots of reading with low frequency of update or that it doesn't matter if the data differs slightly between two copies of the data) but they fall short in situations where a lot of data is written or changed frequently. Almost all these approaches are designed to scale a database out within a datacenter and not across data centers over the WAN or internet because WAN and internet latency is high and network routing is unstable and unpredictable.

CDNs have a very different architecture - for one they are inherently a distributed infrastructure where the CDN service stitches together hundreds of locations into one content acceleration service. Users access their data from anywhere and the CDN secretly serves the data from the POP or location closest to the end user. This means that they don't run in one location - they run in hundreds of locations all at once. Therefore conventional databases don't work to solve the dynamic content look up and generation problem since they only run in one location (and CDNs run on many) and they need a very different and special kind of database. One that is designed to run across all the POPs or edge locations all at once and somehow keep all the copies of the data in sync as it changes across all these edge locations, allowing a user to access or change data anywhere, and the location closest to that user can handle the data operation.

Technically speaking we are describing what is called a 

 system that can work as one logical database across at-least a few hundred locations (ideally across thousands but that is for another blog post in the future) while keeping hundreds or thousands of copies of the same data on different servers in sync with each other, as fast as possible and while providing adequate consistency guarantees of the state of the data. Consistency means resolving what data operations happened (create, update, replace, delete), in what order, by whom and then somehow, every copy of the database arriving at one single version of truth after syncing their latest updates with each other.

As an example, such a mythical database would let a user in in Tokyo change a particular item in the database and it would automatically propagate the change to a hundred other locations while handling any situations where someone else (such as say in Boston) might have changed the same exact item to something different (while the user in Tokyo was also changing it) and doing this sync as fast as the network latency between the two locations will let it.

In short, this kind of a mythical database doesn't exist* and therefore CDNs can't handle dynamic content that involves looking up state.

3rd party independent CDN vendors are confronting an existential threat - public cloud providers are now integrating and delivering CDN capabilities with their own offerings. Cloud providers have a distinct advantage as the origin servers (web server, application logic, database etc) are already running

on their clouds (albeit in a centralized fashion and in one location chosen by the customer) and therefore providing a CDN at the edge is a simple extension for them. More worrying is that AWS for one, already has the ability to run simple apps as serverless functions at the edge on its CDNs with 

. If a customer is willing to roll up her sleeves, has a million dollars or more to experiment with, and is ready to hack at it for six months with a few senior database engineers hired from places like Facebook or Google (hence the million dollars), she might even be able to roll her own dynamic 'content at the edge' solution using AWS DynamoDB's global tables to get some shared data state replicated between regions (albeit limited to 5 regions which is the maximum number of regions supported by global tables - not particularly useful as a data base for CDNs that serve hundreds of global locations).

But CDN vendors have their own strategic advantage - deep capillary networks already in place unlike cloud vendors. Like capillary blood vessels distribute blood from the arteries to even the smallest, most distant parts of the body, CDN vendors distribute content from origin servers to the most distant and remote locations. While cloud vendors boast of having a dozen regions worldwide, typical CDN providers have hundreds of POPs around the world where they run their servers and systems for content delivery and web security. That is a huge advantage for CDN players if they can leverage their deep capillation infrastructure to push not just static content but dynamic data, server side application code to the edge. That now brings the most vital parts of the public cloud to the edge itself and creates multiple scenarios where the need to go to the public cloud to serve dynamic content are eliminated. That is revenue that used to go to the public cloud - now flowing to the CDN provider instead.

The broad global footprints of CDNs along with technology that enables data and dynamic code generation at the edge is a strategic moat for CDN operators. And if they push ahead to this new and exciting frontier of database and dynamic code on the edge - the sky is the limit for their edge clouds.

Public Cloud Is The Apex Predator Of The Internet - CDNs Need To Evolve To Stay Alive

Over the course of the last couple of months, I've had the opportunity to talk to senior leaders in major telecom companies in North America and Europe. In almost every conversation, I'm reminded of the myth of Sisyphus, the Greek king of Corinth, who, because of his deceit, was condemned by the gods to push a large rock up a steep hill, only to see it roll back down again when he got it to the top, and to repeat the same task endlessly till the end of time. Like Sisyphus, telecom operators seem condemned to an endless task of investing magnificent sums of money in bigger, faster pipes with denser capacity, to bring new services over their networks to their customers, only to see it all roll down the hill when Over-The-Top (OTT) providers swoop in with their apps and commoditize the telecom network to just bit pipes and take revenue directly from the end users bypassing the telecom provider entirely.

So what is OTT? Simply put, OTT is telecom parlance for any online service you use over the network of your internet service provider (ISP), whether cable, fixed line or wireless (on your phone or on your computer). Most of us already use OTT services like Netflix, Hulu, YouTube, Spotify, WhatsApp, Skype, iMessage, and Facetime without actually realizing it. OTT services built on cheap, elastic public clouds deliver voice, messaging, and streaming audio/video content directly to consumers over the internet, and are dominating the media and telecom markets today. In core telecommunication services, messaging and voice apps like WhatsApp, Viber, and Apple’s iMessage account for more than 80 percent of all messaging traffic on their networks, while Skype alone accounts for more than a third of all international voice traffic minutes (and is the world's largest long-distance voice provider). This pattern has led to steep declines in the average revenue per user; with minimal revenue growth; and ever-tightening margins for telecom providers in their core business.

With data, the story is even more frightening (especially if you are a telecom executive or shareholder). Almost every telecom operator, whether wireless or wireline, has been pushed to become just another bit pipe provider. Almost 70% of the data traffic of a telecom provider is video content coming from OTT services, like Netflix, YouTube, or social media. And it’s a perfect catch 22 situation for the telecom provider: either provide a fast bit pipe to keep your customers or see them go to a competitor willing to live on thinner margins. What makes OTT a particularly challenging contender to deal with is that it’s built on the public cloud and thus enjoys a very strong set of economic benefits in being able to scale up and down without the need to own any of the infrastructure needed to deliver the OTT service. OTTs are just one of the many manifestations of the disruption that the public cloud has created in telecom providers’ core business by enabling applications to be built cheaply and quickly with little to no dependence on the underlying infrastructure.

To remain relevant in this hyper-disruption unleashed by the public cloud via OTTs, telecom providers need to identify new growth areas that combine the great potential of a brand new addressable market and telecom providers’ existing core competencies. Edge computing sits squarely at the intersection of these two criteria, and telecom providers who embrace it could possibly end up successfully surfing the tsunami unleashed by OTT apps and services on top of cheap public cloud computing.

 that edge computing has the potential to eclipse what we call cloud computing today: a centralized architecture built on hyperscale data centers located in places with access to cheap and abundant power and, conversely, far away from most humans and devices and therefore unfit for emerging applications that need low latency, that process large data streams in real time closer to the data sources, or that have bi-directional traffic (instead of just downstream cloud-to-client traffic patterns). Edge computing, unlike the public cloud, will be built on either infrastructure owned by telecom providers or on new bespoke microdata centers with direct access to Radio Access Networks (RANS) (like 

Vapor IO's incredibly exciting vapor edge offering

) in dense urban environments where most humans and their devices are within 50 ms of latency.

Turning the Edge into a strategic weapon against public clouds and OTT apps

To succeed with edge computing, telecom providers need to co-opt application developers away from public cloud platforms to using their edge platforms to write future applications and to pre-empt OTTs from commoditizing their next generation infrastructure.

These edge native applications can then be delivered as managed services by the telecom vendors themselves, creating new revenue streams and competitive moats to fend off the threat of public clouds and OTT apps and services.

Co-opting the developers away from public clouds will not be an easy problem and will require telecom providers to solve three key technology challenges, either by acquiring or partnering suitable software providers:

: The edge, unlike centralized hyper-scale data centers, is a geographically distributed and massively decentralized infrastructure (with no single locus of centralization) and at its core is a massively scalable decentralized and distributed database. Today's distributed database and storage systems are not sufficiently scalable to solve the data consistency and consensus when running across thousands of distributed nodes as a single logical programmable database (I plan to make a future post to elaborate on this aspect).

: The edge must be programmable like a public cloud by offering a Container or Platform As A Service (CAAS/PAAS) abstractions for application developers to work with while hiding the complexities of the distributed architecture across apps running and storing states on tens/hundreds or even thousands of edge nodes. This is the central technology problem that will need to be unlocked to truly turn edge computing into a mainstream offering and a contender to take on the current model of centralized public clouds and OTT apps and services that run on them.

: Telecom providers, by their nature, are regional and don't operate globally the way public cloud providers do (due in part to the legacy of deregulation and licensing of the spectrum). Therefore telecom providers will need to form one or more global alliances to provide one contiguous global service across networks for edge computing and to hide the complexities of disparate networks and infrastructures from end users. The good news is that the telecom providers already have deep expertise in this: global roaming, for example, is one way that telecom providers currently provide seamless voice and data connectivity across national boundaries for their subscribers.

Bringing together such an edge cloud architecture that tightly couples (1) a globally available database with (2) a rich CAAS/PAAS platform in (3) a global federation of edge clouds stitched together to provide data and code mobility would enable telecom providers to provide a true alternative to public clouds for app developers, but with the benefit of allowing applications to run in very close proximity to end users and devices—an advantage that hyperscale centralized public clouds will find very hard to compete against. With such a combination in place, telecom providers would serve as the critical platform for the complex data flow that links machine sensors to back-end services, in real-time analytics or cybersecurity, and the transportation supply-chain infrastructure to navigation, factory floors, social media, online multiplayer gaming, and autonomous consumer and business logistics apps (such as self-driving vehicles). Machine-to-machine revenues are projected to grow by double digits over the next few years, so they could potentially create massive new revenue streams in areas that are core to telecom providers and provide new greenfield opportunities to build and fortify activity away from public cloud providers and their OTT offerings.

But let me end this post by pointing out the obvious: the edge is too important for telecom providers to ignore. In the previous innings of the cloud game, everyone (including yours truly) underestimated the potential of the public cloud to change how we consume media and apps, and was taken by surprise at how quickly it went mainstream as an application development platform and created brand new billion dollar OTT businesses while rapidly commoditizing and disrupting so many incumbents (I will spare you the recanting of various tales, such as Blockbuster vs. Netflix or WhatsApp vs. SMS). Telecom providers cannot afford to make that mistake with the edge. It's now the proverbial bottom of the 9th innings, the bases are loaded, and the telecom providers are at the bat—it’s anyone's game to win.

Telecom Providers Need To Win The Battle For THE EDGE To Be More Than Just Data Pipe Providers

Macrometa is the hyper distributed cloud platform for enterprises building global applications at the Edge. 

PhotonIQ

Global Data Network

Learning Hub

Case Studies

Developer Hub

Demos

Support

About

Partners

Press

Careers

Contact Us

Terms of Service

Privacy Policy

Trust Center

Announcing PhotonIQ: The New AI CDN For Accelerating Apps, APIs, Websites and Services

Archive