Interesting. I still remember Ben pitching me the idea of cloud services in 1999. I thought he was insane at the time. I retain this as the proof that I can't reliably evaluate a business idea ;)
I can't wait for the traditional centralized cloud to fade out. I've been anticipating a model I call PAO [1] for several years—personal application omnipresence. By that I mean applications that run for you personally and are available on all your devices simultaneously.
We've seen gradual movement away from the traditional cloud with several models I call "proto-PAO," such as Microsoft's Continuum. And many applications provide one-off PAO-like experiences by connecting multiple clients to a central server you administrate. But there is so much more to do. I am definitely getting excited, though, that the centralized cloud will likely be replaced in my lifetime.
I suspect something similar to this will come to pass, as well.
The cloud is appealing for a number of reasons. The two biggest seem to be it takes care of the infrastructure and some of the stack. When and if those become trivial accomplishments, I can see a shift.
Very interesting. I've been thinking of a similar application platform from the perspective of design/preferences/configuration. We've seen only a very limited amount of "personalization" like "personalized search" (or cross-device attribution tracking, call it what you will). But I ask you to consider an omnipresent personal user interface. Now I'm thinking a generation after VR (to a stage where we can generate visual stimuli and recognize thought/movement that manipulates it). Wouldn't it be nice if this interface weren't a hodgepodge of Siri/Google Now/Alexa (all linked to their proprietary systems so you can access their walled garden). I imagine a space for middleware dedicated to serving me, not serving me ads.
strangely enough, I've been expecting that as well, but reading your blog post, I differ on how it will be realized.
I think it's more likely people will instead carry identities that describe the applications they have access to, and be able to load those on devices for their identity only, down to the point of being able to walk up to a new PC, attaching the identity, and then having access to the apps on that new PC.
It'll be a 90% solution that's forced to deal with DRM and safe enough remote execution, but it'll also allow you to access your documents from anywhere with a connection.
I know you specifically disagree with the idea of synchronization, but that's more feasible than what you're suggesting imo. synchronizing a document is going to be as simple as saving it into the cloud and fetching a delta at the endpoints.
This will necessarily not work for certain types of applications, no one is probably going to try and do actual CAD work on the go, although they may view it. But for most things it'll work well enough.
I thought your article was actually much better than the video linked. I had vaguely thought of something similar before but not in as much detail. If you made a follow up post about what you see as other companies moving towards this PAO and posted it here I think it could spark a really good discussion.
Very interesting and while I think the title is a bit "clickbaity" it has some interesting points. He is not claiming cloud computing is going to disappear, he is claiming that due to real-time requirements and amount of data, computing power at the edge will grow, while SaaS and central data analytics will not stop being centralized in the cloud. He claims the cloud won't handle the vast amount of sensor data and I'm not sure he is right, but can't prove him wrong. In any case it seems that cloud providers are already aiming for this direction. AWS has project greengrass for example: https://aws.amazon.com/greengrass/
While certainly thought provoking I'm not certain that he is exactly correct. What is going to happen is that there will be a lot of devices where a peer to peer model makes more sense. It doesn't mean that cloud computing is going to go away but it will instead change over time.
I am more in agreement with the idea that data analysts jobs will grow. Also think that a lot of apps will have their own databases but instead of ignoring the cloud they will need to occasionally sync with the cloud as opposed to real time access.
I think that RESTful data services will become more of a commodity and that most developers will need a data service, an authentication service, a telecom service and a payment service (and perhaps a few more) to construct a program.
We're not too far off from it happening and the opportunity exists for an ambitious company to offer a Microsoft Office style suite of services to developers. I'd personally prefer it be Stripe or Twilio as opposed to Microsoft or Google that ends up doing it.
In every case he described current devices (cars, watches) - they are increasing in 'cpu/storage' - but they always have been doing this.
Is their something that inherently changes the topology?
Not really.
Cars will be able to id stop signs - which is naturally a local function, just like 'backup cameras' are a local function today ... but some things like messaging, gps services, customer data, big data - it's going to be on a server somewhere.
Why would your car need to talk directly to your blender?
'The cloud' has really more to do with local/small/office servers moving into consolidated centres with virtualization.
'Logical organization' has not changed: some stuff on 'servers' , some stuff done 'locally'.
So we started with centralized mainframes, because it was too expensive for everybody to have their own computer. As hardware improves, computers become cheaper and more powerful and then everybody can have their own, and we move to a distributed model. Then as internet speeds improve, it becomes practical to bring all the compute back in to centralized data centres and communicate with them over the internet from small, less powerful devices. Then as the hardware improves again, the small devices become powerful enough to perform their own computation.
In the talk, he says that the reason we need to do the compute "on the edge" is because the latency between the cloud is insufficient for real-time devices. So what happens when network speeds improve again (better fibre infrastructure, LiFi, etc.)? Will we bring the compute back in to centralized data centres? Will we continue to bounce back and forwards forever, as network and hardware technology leapfrog each other? Is one model better than the other?
> In the talk, he says that the reason we need to do the compute "on the edge" is because the latency between the cloud is insufficient for real-time devices. So what happens when network speeds improve again (better fibre infrastructure, LiFi, etc.)? Will we bring the compute back in to centralized data centres? Will we continue to bounce back and forwards forever, as network and hardware technology leapfrog each other? Is one model better than the other?
Well, for one thing, a lot of the examples such as self-driving cars, drones, and any wearable clearly don't allow for use of fiber. Lifi may have some use cases, but again I don't see how Lifi could help something like a drone or self-driving car.
But another point is availability. Wireless connections can drop in and out and our vulnerable to being slowed down by increased demand. Not to mention that the centralized service itself may fail, due to catastrophic power failure, DOS attacks, or any number of other reasons.
If that centralized service or choppy wireless connection is providing you with your todo-list or family photo album, its probably not a big deal to have occasional outages. If the system is making decisions for self-driving vehicles, that will be an unmitigated disaster.
Even if it is only enough logic to help an unconnected car pull over to the side of the road, a self-driving car needs to be able to operate offline, so one way or another, these cards will need powerful computers inside.
And of course, distributed nodes can also fail. A single car's computer may fail, and that's not good. But the AI of every car in an entire area failing simultaneously because power to the local radio tower goes out is going to be way worse.
The other thing, is that as we have with processing speeds, we will eventually hit limits in bandwidth. Using bandwidth efficiently will become a larger priority (as scarcity increases, so will the cost) and the centralized model clearly has a drawback in terms of bandwidth usage.
So, all in all, I don't think it's just a pendulum that swings back in forth forever, but that the future will be a hybrid, but heavily distributed world out of necessity.
I agree that not all computation would move back to centralized data centres, but then not all computation is done in the cloud now (vs on your mobile phone). 20 years ago, people would have thought it was insane to send data packets over the internet to edit a document, or any number of other tasks now serviced by SaaS products. Of course there are still some tasks that are better done locally, notably real-time or life-critical tasks. And these SaaS services only became feasible when the connection reliability and speed allowed them to.
All I'm suggesting is that future improvements to connection reliability and speed will give way to another round of SaaS products, perhaps then able to service real-time needs but still not preferred for life-critical tasks. As much as I hate to say it, the first example that comes to mind is surveillance/tracking.
If you think very long-term, like say data-transfer-via-quantum-entanglement, then you could imagine data transfer being insignificant compared to compute time for real-time requirements, so you will naturally offload the compute to the biggest most powerful computer you can get your hands on.
> Wireless connections can drop in and out and our vulnerable to being slowed down by increased demand. Not to mention that the centralized service itself may fail, due to catastrophic power failure, DOS attacks, or any number of other reasons.
Not to mention how wireless connections themselves are vulnerable, jamming radio frequencies is easy and cheap.
I'm an advocate of edge computing for sensor data aggregation. I don't think round trip computation will be viable for soft real time applications for quite some time, unless that computation requires operating over large datasets (where it's prohibitive to store all it locally). Just my opinion (and some experience), hardly an authority.
> Will we continue to bounce back and forwards forever, as network and hardware technology leapfrog each other? Is one model better than the other?
It actually is task-dependent. There will always be tasks that work best at a centralized mainframe (e.g. weather forecast requires a supercomputer), while others will benefit from distributed local processing (moving the pointer on the screen following mouse input).
For the tasks in between, the changing ratios between processing and transmission speed in the distributed points will influence where it's most practical to do the computing, which is the effect you have seen.
There is no better. Assuming dirt-cheap photonic connection speeds and handheld supercomputers, there will be tradeoffs regardless of the hardware limitations.
Ex: you could watch anything on YouTube or Netflix but someone will always be knowing when you start, pause, stop, and possibly the volume you set. Or you could download all of YouTube onto your God-phone and watch to your heart's content without realtime surveillance.
As hardware improves on both ends, the decision between centralized and decentralized will rely less and less on the constraints of the hardware, and more on things like consumer preferences.
Bandwidth & latency are different things. It doesn't matter how fat you make the pipe, the speed of light prevents certain types of computations from being run remotely.
This doesn't matter so much for AI in apps, but certainly for self driving cars all critical computation needs to be on the edge. Once you have every car carrying multiple GPUs, the distributed computing power in cars probably is pretty comparable to a data center. You can run a lot of things in the idle time while the car is parked if you need to do training or things of that nature.
It's an interesting thought experiment but I tend to disagree overall.
I don't think a self driving car is a data-center on wheels. It will not have 100(!) servers built in it. It will have one (or two for redundancy) PCBs with just the right enough of processing power in whatever form makes sense, multiple cores, ASICs, etc. (which would be less than 100 server worth).
I would agree that the more compute cycles will move out to the edge. This is already have been happening with smartphones and will continue with other intelligent devices. The more computers we have in our environment the more the overall portion of cycles move to the edge. The depiction of a smartphone as a dumb terminal isn't that accurate. A smartphone can and does do a lot of things locally. My bet is there is a lot more compute power in all the phones today than in AWS EC2. (though maybe not compute $'s)
The comments on machine learning don't make sense. There is a lot more data for machine learning in the aggregate of all the devices so it will naturally happen in some centralized location. While there can be some machine learning in the edge machine learning is a lot more effective on the aggregate centralized data. So data from the edge will get pulled to central large scale systems. The result of this learning can be pushed back out to the edge to be applied (e.g. in the car).
EDIT: He later on modifies his statement about machine learning happening in the edge and rather some "selection" of the data will be used for machine learning in the cloud... Still doesn't quite add up.
The solution is obvious. Cache not only data, but functions as well.
I should be able to download entire systems on local devices (a cache hub, a router, a personal cache hotspot, a smartphone), and have them work offline if necessary.
However, this will require a new computing paradigm altogether, powered by a new language. This kind of seamless caching demands a language with superior semantics (API auto-discoversbility) and logic-programming influence. I imagine some kind of predicate store should do the job.
Do we really need a new language for this? We already have things that run on both server and client, javascript being the obvious one, where there's already a blending of computation for webpage rendering happening (pre-rendered on the server then the code for updating sent to the client).
Is cloud dead? No! Will it die? Probably not because not everyone wants to deal with some of the complexities involved with building the hardware and networks required to achieve near perfect resilience.
What will certainly going to happen is that we will see more devices online and many of them will be IOT. ESP8266 can be bought for at little as the cost of a double espresso. The hobby electronics industry is booming in the face of Arduino and Raspberry Pi. It is happening.
We will reach a point eventually where it will take a lot of investment to deduce if a hardware component contains backdoors. The firmware of the ESP is opensource through.
"Edge intelligence" is not going to happen in place of the cloud, simply in addition to it. When storage gets smaller in form factor, maybe we will be storing 100s of TBs in a car, but there will still be a data center storing 100s of PBs.
37 comments
[ 3.4 ms ] story [ 58.2 ms ] threadWe've seen gradual movement away from the traditional cloud with several models I call "proto-PAO," such as Microsoft's Continuum. And many applications provide one-off PAO-like experiences by connecting multiple clients to a central server you administrate. But there is so much more to do. I am definitely getting excited, though, that the centralized cloud will likely be replaced in my lifetime.
[1] http://tiamat.tsotech.com/pao
The cloud is appealing for a number of reasons. The two biggest seem to be it takes care of the infrastructure and some of the stack. When and if those become trivial accomplishments, I can see a shift.
PAO concept seams neat, and actually buy it - it will happen to some degree.
BUT - many features are inherently 'centralized' in their nature, and will be service oriented, and thus they will stay on the cloud.
I think we'll see more 'cloud/personal' and more 'IoT' - but the traditional cloud will continue to grow quite rapidly.
I think it's more likely people will instead carry identities that describe the applications they have access to, and be able to load those on devices for their identity only, down to the point of being able to walk up to a new PC, attaching the identity, and then having access to the apps on that new PC.
It'll be a 90% solution that's forced to deal with DRM and safe enough remote execution, but it'll also allow you to access your documents from anywhere with a connection.
I know you specifically disagree with the idea of synchronization, but that's more feasible than what you're suggesting imo. synchronizing a document is going to be as simple as saving it into the cloud and fetching a delta at the endpoints.
This will necessarily not work for certain types of applications, no one is probably going to try and do actual CAD work on the go, although they may view it. But for most things it'll work well enough.
I am more in agreement with the idea that data analysts jobs will grow. Also think that a lot of apps will have their own databases but instead of ignoring the cloud they will need to occasionally sync with the cloud as opposed to real time access.
I think that RESTful data services will become more of a commodity and that most developers will need a data service, an authentication service, a telecom service and a payment service (and perhaps a few more) to construct a program.
We're not too far off from it happening and the opportunity exists for an ambitious company to offer a Microsoft Office style suite of services to developers. I'd personally prefer it be Stripe or Twilio as opposed to Microsoft or Google that ends up doing it.
In every case he described current devices (cars, watches) - they are increasing in 'cpu/storage' - but they always have been doing this.
Is their something that inherently changes the topology?
Not really.
Cars will be able to id stop signs - which is naturally a local function, just like 'backup cameras' are a local function today ... but some things like messaging, gps services, customer data, big data - it's going to be on a server somewhere.
Why would your car need to talk directly to your blender?
'The cloud' has really more to do with local/small/office servers moving into consolidated centres with virtualization.
'Logical organization' has not changed: some stuff on 'servers' , some stuff done 'locally'.
Sure.
But my car does not need to talk to my blender. :)
https://en.wikipedia.org/wiki/Peripheral_nervous_system
In the talk, he says that the reason we need to do the compute "on the edge" is because the latency between the cloud is insufficient for real-time devices. So what happens when network speeds improve again (better fibre infrastructure, LiFi, etc.)? Will we bring the compute back in to centralized data centres? Will we continue to bounce back and forwards forever, as network and hardware technology leapfrog each other? Is one model better than the other?
Well, for one thing, a lot of the examples such as self-driving cars, drones, and any wearable clearly don't allow for use of fiber. Lifi may have some use cases, but again I don't see how Lifi could help something like a drone or self-driving car.
But another point is availability. Wireless connections can drop in and out and our vulnerable to being slowed down by increased demand. Not to mention that the centralized service itself may fail, due to catastrophic power failure, DOS attacks, or any number of other reasons.
If that centralized service or choppy wireless connection is providing you with your todo-list or family photo album, its probably not a big deal to have occasional outages. If the system is making decisions for self-driving vehicles, that will be an unmitigated disaster.
Even if it is only enough logic to help an unconnected car pull over to the side of the road, a self-driving car needs to be able to operate offline, so one way or another, these cards will need powerful computers inside.
And of course, distributed nodes can also fail. A single car's computer may fail, and that's not good. But the AI of every car in an entire area failing simultaneously because power to the local radio tower goes out is going to be way worse.
The other thing, is that as we have with processing speeds, we will eventually hit limits in bandwidth. Using bandwidth efficiently will become a larger priority (as scarcity increases, so will the cost) and the centralized model clearly has a drawback in terms of bandwidth usage.
So, all in all, I don't think it's just a pendulum that swings back in forth forever, but that the future will be a hybrid, but heavily distributed world out of necessity.
All I'm suggesting is that future improvements to connection reliability and speed will give way to another round of SaaS products, perhaps then able to service real-time needs but still not preferred for life-critical tasks. As much as I hate to say it, the first example that comes to mind is surveillance/tracking.
If you think very long-term, like say data-transfer-via-quantum-entanglement, then you could imagine data transfer being insignificant compared to compute time for real-time requirements, so you will naturally offload the compute to the biggest most powerful computer you can get your hands on.
Not to mention how wireless connections themselves are vulnerable, jamming radio frequencies is easy and cheap.
It actually is task-dependent. There will always be tasks that work best at a centralized mainframe (e.g. weather forecast requires a supercomputer), while others will benefit from distributed local processing (moving the pointer on the screen following mouse input).
For the tasks in between, the changing ratios between processing and transmission speed in the distributed points will influence where it's most practical to do the computing, which is the effect you have seen.
Ex: you could watch anything on YouTube or Netflix but someone will always be knowing when you start, pause, stop, and possibly the volume you set. Or you could download all of YouTube onto your God-phone and watch to your heart's content without realtime surveillance.
As hardware improves on both ends, the decision between centralized and decentralized will rely less and less on the constraints of the hardware, and more on things like consumer preferences.
This doesn't matter so much for AI in apps, but certainly for self driving cars all critical computation needs to be on the edge. Once you have every car carrying multiple GPUs, the distributed computing power in cars probably is pretty comparable to a data center. You can run a lot of things in the idle time while the car is parked if you need to do training or things of that nature.
I don't think a self driving car is a data-center on wheels. It will not have 100(!) servers built in it. It will have one (or two for redundancy) PCBs with just the right enough of processing power in whatever form makes sense, multiple cores, ASICs, etc. (which would be less than 100 server worth).
I would agree that the more compute cycles will move out to the edge. This is already have been happening with smartphones and will continue with other intelligent devices. The more computers we have in our environment the more the overall portion of cycles move to the edge. The depiction of a smartphone as a dumb terminal isn't that accurate. A smartphone can and does do a lot of things locally. My bet is there is a lot more compute power in all the phones today than in AWS EC2. (though maybe not compute $'s)
The comments on machine learning don't make sense. There is a lot more data for machine learning in the aggregate of all the devices so it will naturally happen in some centralized location. While there can be some machine learning in the edge machine learning is a lot more effective on the aggregate centralized data. So data from the edge will get pulled to central large scale systems. The result of this learning can be pushed back out to the edge to be applied (e.g. in the car).
EDIT: He later on modifies his statement about machine learning happening in the edge and rather some "selection" of the data will be used for machine learning in the cloud... Still doesn't quite add up.
Whatever. Down with the cloud!
I should be able to download entire systems on local devices (a cache hub, a router, a personal cache hotspot, a smartphone), and have them work offline if necessary.
However, this will require a new computing paradigm altogether, powered by a new language. This kind of seamless caching demands a language with superior semantics (API auto-discoversbility) and logic-programming influence. I imagine some kind of predicate store should do the job.
What will certainly going to happen is that we will see more devices online and many of them will be IOT. ESP8266 can be bought for at little as the cost of a double espresso. The hobby electronics industry is booming in the face of Arduino and Raspberry Pi. It is happening.