More than 10 years ago, Marc Andresen published his famous article "Why Software is "Eating" the World" in the Wall Street Journal. From an investor's perspective, he explains why software companies are taking over entire industries.
As a company founder, our company's business is to support GraphQL at the edge, so I wanted to share my thoughts on why the edge is "eating" the world. We'll quickly look back at the past, look down on the present, and use first-principles reasoning based on current observations to get a glimpse of the future.
let's start.
A Brief History of CDNs
Web applications have used the client-server model for over 40 years. A "client" sends a request to a server running a web server program and returns the content of the web application. Both client and server are just computers connected to the internet.
In 1998, five MIT students observed this and had a simple idea: let's distribute these files to many data centers around the world, working with telecom providers, to use their networks. And just like that, the idea of a so-called Content Delivery Network (CDN) was born.
CDNs started storing not only images, but also video files and any data you could think of to store. By the way, these outlets (PoPs) are the edges. They are servers scattered around the world—sometimes hundreds of thousands of servers are all about storing copies of frequently accessed data. Because the original focus of a CDN was just to provide normal infrastructure, and the goal was "just make it work," it's been really hard to use over the years.
In 2014, a developer experience (DX) revolution around CDNs began. Website files and CDN files are directly packaged and bundled together, so people no longer need to manually upload website files and then link with CDN. Connected with a CDN, the two parts are packaged together. Automated deployment tools like surge.sh, Netlify, Vercel (now called fka Now) were born.
By now, distributing static websites via CDN has become an absolute industry standard. So we've now moved static assets to the edge. But what about computing? And what about dynamic data stored in the database? Can we reduce latency by placing it closer to the user? If so, how can we do it?
welcome to the edge
Let's take a look at the two advantages of the edge:
① Computation
② Data
In both areas, we are seeing incredible innovations happening that will completely change the way applications work in the future.
calculate
What if an incoming HTTP request didn't need to be routed all the way to a distant data center? What if it could be provided directly next to the user? Welcome to edge computing.
If we move data from one centralized data center to many distributed data centers, the more we need to deal with a new set of trade-off decisions. At the edge, you don't need a "luxury" configuration, and you don't need to add a powerful machine with hundreds of gigabytes of RAM to your application. Imagine your application being able to be deployed at 500 edge locations, all close to your users. And it's obviously not economical to buy 500 powerful machines each at your user's side.
Because the cost is too high. What we're going to choose, of course, is a smaller, simpler configuration scheme.
An architectural pattern that fits these constraints well is the serverless pattern. You don't need to buy managed hosting yourself, just write a function and the intelligent system will execute automatically when needed. You don't need to worry about the abstraction of a single server; you just write functions that run basically infinitely scalable.
As you can imagine, these functions should be small and fast. How can we achieve this goal? What is a good runtime environment for those fast and small functions? Currently, there are two common answers in the industry: use JavaScript V8 isolates or use WebAssembly (WASM).
JavaScript V8 isolate, commonly used by an American company called Cloudflare . It allows you to run a full JavaScript engine on the edge. This new simplified computing model was first made available to the edge in 2017 when Cloudflare introduced this working mechanism.
Since then, including Stackpath, Fastly and our excellent Akamai, have also released their edge computing platforms - a new revolution has begun. Compared with the V8 JavaScript engine, another computing model that can perfectly adapt to the edge, WebAssembly.
First introduced in 2017, WebAssembly is growing rapidly; big companies like Mozilla, Amazon Cloud Technology, ARM, Google are using it heavily, and Microsoft and Intel are investing heavily. WebAssembly allows you to write code in any language and compile it into a portable binary. It can run anywhere, whether in the browser or in a variety of server environments.
WebAssembly is without a doubt one of the most important developments on the web in the past 20 years. It already drives chess engines and design tools in browsers, runs on blockchains, and is likely to replace Docker.
data
While we already have some edge computing products, the biggest obstacle to the edge revolution is how to bring data to the edge. If your data is stored in a remote data center, you won't gain anything by moving your computer to the user's side - because that "distant" data is still the bottleneck. You also can't find solutions for data distribution at the same time in order to deliver on the main promise of the edge and speed up users.
You might be thinking, "Can't we just replicate all the data on Earth to our 500 data centers and keep it up to date?" While there are new ways to replicate data all over the world, such as Litestream, which recently added fly.io.
Unfortunately, it's not that easy. Let's say you have 100TB of data to run in a sharded cluster of multiple machines, it's simply not cost-effective to replicate that data 500 times. What we really need is the ability to store "tons" of data while still bringing it to the edge.
In other words, with limited resources, how can we distribute data intelligently and efficiently so that we can still get it quickly at the edge? Constrained by limited resources, two approaches are being used (and have been for decades) in the industry: slicing and caching .
whether to slice
Slicing divides data into multiple datasets based on certain criteria. For example, choosing a user's country as a way to segment data so that it can be stored in different geographic locations.
Implementing a general slicing framework that works for all applications is quite challenging. There has been a lot of research in this area over the past few years. For example, Facebook came up with their slicing framework, called the shard manager, but even then it only worked under some specific conditions and required many researchers to run it. We're still going to see a lot of innovation in this space, but it's not the only solution to bringing data to the edge.
Cache is king
Another approach is caching. If you can't store all of your 100TB database at the edge, put an upper limit, say, a 1GB limit, and only store the most accessed, frequently accessed data. In computer science, keeping only the most common data is easy to understand, and the LRU (Least Recently Used) algorithm is one of the most famous solutions.
You might ask, "why don't we use LRU to cache data at the edge and then finish the job?" Not so fast. We want the data to be correct and up-to-date: in the end, the data also needs to be consistent. But wait, caches have a range of advantages when it comes to data consistency: from "weakest consistency" or "eventual consistency" all the way to "strong consistency". There are also many layers in between, for example, "Consistency in reading my own input data."
The edge is a distributed system. And when dealing with data in distributed systems, the CAP theorem applies. This means that if you want your data to have strong consistency, you have to make a trade-off. In other words, when writing new data, you never want to see the old data from before.
To maintain such a high level of consistency in a global setting, there is only consensus among the parts of the distributed system on the data information just sent, or at least once. This means that if you use a globally distributed database, it still needs to send the message to every other data center around the world at least once, which inevitably introduces latency. Even a great new SQL database like FaunaDB cannot avoid such delays.
Honestly, there's no free lunch here: if you want high consistency, you have to live with that, including some latency charges. Now you may be asking, "But do we always need strong consistency?" The answer is: it depends. The functionality of many applications does not require a high degree of consistency. For example, there's a small online store you've probably heard of: Amazon.
Amazon Cloud Technologies created a database called DynamoDB, which operates as a scalable distributed system, however, is not always completely consistent. As DynamoDb says they don't guarantee high consistency, Amazon Cloud uses a lot of clever ways to "keep as much consistency as possible".
I believe that all applications of this generation will be able to achieve good consistency eventually. In fact, you probably have some use cases in mind: social media feeds can sometimes be a bit outdated, but it's usually very fast and usable. On blogs and newspapers, there is a delay of milliseconds or even seconds to publish an article. As you can see, there are many situations where eventual consistency is acceptable.
If we assume eventual consistency is accepted: what do we get out of it? What this means is that we don't need to wait until everyone accepts the change to do this. Because if we accept the change now, the latency fee is gone when the data is distributed globally.
Ultimately, however, achieving "good" consistency is not easy. Because, there is also a little problem called "cache invalidation" to deal with. When the underlying data changes, the cache also needs to be updated accordingly. Yes, you guessed it: this is an extremely difficult problem. Its level of difficulty has made it a joke in the computer science community.
Why is this so hard? Because, not only do you need to keep track of all the data that is cached, you also need to properly invalidate or update the underlying data source when it changes. Sometimes there are even issues where the underlying data source cannot be controlled at all. For example, imagine using an external API like the Stripe API.
At this point, a custom solution needs to be built to invalidate this data. In short, that's why we're building Stellate so that this tough problem can become more acceptable and even solved by equipping developers with the right tools. If GraphQL (a strongly typed API protocol and schema) didn't exist, I can be frank: we wouldn't have created this company. This problem can only be solved under strong constraints.
I believe that shards and caches have to adapt more to these new needs, and no one company can "solve the data problem", we need the entire industry to work on it. There is still so much to say on this topic, but right now, I feel that the field has a bright future. I'm excited about what's to come in the future.
The future: it's here, it's now
With all the technological advancements and technological bottlenecks, let's look to the future. But it would be rude not to mention Kevin Kelly.
At the same time, I admit that it is impossible to accurately predict the future direction of the technological revolution, nor to know which specific products or companies will lead the way in the next 25 years. There may even be an entirely new company emerging in the edge cloud space . However, some trends are predictable because they are already happening.
Kevin Kelly published The Inevitable in 2016. In the book, he discusses twelve technological forces that will shape the future. As the title says, these are bound to happen in the future, and here are eight of them:
Cognition: Cognition of things, that is, making things more intelligent. For this to happen, more and more computing power needs to be provided directly where computing is needed. For example, it would be impractical for a self-driving car to classify roads in the cloud, right?
Flow: We will have more and more real-time information flow, and people will rely on these real-time information flow. The problem of latency is crucial here: let's imagine if we were to control a robot to perform a task. You wouldn't want to send control signals halfway around the world if you didn't have to, would you? However, for a constant stream of information, chat applications, real-time dashboards or online games, it is critical that there is no latency, so we need to use the edge.
Screen reading: More and more things in our lives will have screens. From smartwatches to refrigerators and even your digital scale. And just like that, these devices are often connected to the Internet frequently, forming a new generation of edge.
Share: In the future, large-scale collaborations will inevitably grow. Imagine you are editing the same document with a friend from the same city. Why send all this data back to a data center on the other side of the world? Why not store the documents in place with you both?
Filtering: We will use strong personalization to predict our desires. This may actually be one of the biggest drivers of edge computing. Since personalization is for individuals or teams, this is the perfect use case for running edge computing next to them. Using the edge can speed things up, and milliseconds saved equal profit. Not only are we already seeing personalization in social networks, but we're also seeing greater use of it in e-commerce.
Interaction: By becoming more and more immersed in the computer, people can be more connected to others. And that immersion will inevitably be personalized and run directly or in close proximity to the user's device.
Tracking: Inevitably, we will be tracked more. There will be more sensors on everything, and they will all be collecting massive amounts of data. But this data cannot always be transmitted to a central data center. Therefore, real-world applications need to make real-time decisions quickly.
Start: Ironically, last but not least, this is the "start" factor. The past 25 years have been a crucial plateau. However, don't count on those trends we got a first glimpse of. Let's embrace them so we can create the greatest good. Not just for us developers, but for humanity as a whole.
I predict that in the next 25 years, today's "nonsense" will become a reality. That's why the edge is said to be "devouring" the world. As I mentioned before, the problem we programmers face is not in the interests of one company, but in the industry as a whole.
Tim Suchanek, Chief Technology Officer, Stellate.
Compilation: The Edge Computing Community @Julian
Original link:
https://venturebeat.com/data-infrastructure/why-edge-is-eating-the-world/
The Shenzhen Station of the Global Edge Computing Conference ended successfully. The link above is the video playback and PPT download link. Thank you for your support to the edge computing community. Welcome to the Global Edge Computing Conference Shanghai Station !