What the f*** is the edge?
arcentry.com
arcentry.com
Which is exactly why we the cynics say we've come full circle.
Also, while the cyclical nature of client/server design seems to be a thing, unfortunately underlying ownership is not cyclical. For instance, a cycle or two ago, the "edge" computer meant software I bought running on my machine. This cycle, it means software I don't have any stake in running on machine I lease and have little control about.
This is the part of the trend that's worrying to me. Cycles of thin/thick clients are irrelevant. Disenfranchising end users is a problem.
You are free to choose from a great number of useful and fun pre-approved apps that you love. The possibilities are limitless!
(Of course, you must choose the same apps as everyone else. You are a loyal citizen, aren't you?)
flash/sliverlight then html5 then wasm.
soap then rest then json api.
Flash/Silverlight/HTML5/WASM - this, to me, is a story of a technology being useful, then growing to give too much power to web publishers - who tend to abuse any given power - then reverting to a weaker technology in order to unscrew the web. Rinse, repeat - HTML5 is already rapidly approaching peak Flash, and introduction of WASM isn't going to help here.
Soap/REST/JSON API - you could call it a story of simplification, but I don't get how it even came to be. That is, how XML gained so much popularity, given that simpler and better tools for almost all of its uses were already available and known.
I don't quite get this part.
Both HTML & XML cater for DOM models. I think this is & was appropriate.
Browsers had support for executing XSL stylesheets because it made sense for a lot of use cases.
1. You could represent it as a nested structure of your language's standard lists & maps, which you already know the API of, which you could directly operate on. For dynamic languages, this is much faster to stick a prototype together, even if it bites you in the ass eventually. But by the stage, you've already chosen JSON.
2. It was less characters to manually type.
3. Particular uses of XML were extremely verbose. The S in SOAP stood for Simple, which looks ironic in retrospect.
4. In a time when payloads didn't routinely use compression, the closing tags could be a noticeable increase in size.
5. The vast majority of communication that now uses JSON didn't benefit significantly from XPath (people prefer to navigate data structures using their language features, not a generic API), namespaces, DTDs, XML Schema etc.
In about that order.
You could argue that much of this is superficial, and it is, but the industry has shown time and again that lowering the barrier to entry, even in ways that make little difference in the long run, usually wins out.
6. Too easy to accidentally reinvent Lisp via xml.
I thought it was funny the first time I ran into an instance of it happening, which quickly turned into horror. Not only was the logic split, but it meant mentally parsing this:
<If><RegEx string="{AZ*}"><Register /></RegEx></If>
1. No one actually knows where it is or what it means.
2. It conjures images of classical ‘edge compute’ use cases like the self driving cars in the article. Those use cases tend to be exceptionally specialized (or just silly).
3. Edge implies a core or origin exists, and maybe it doesn’t need to.
We would rather imagine a world where we embed the compute directly into the network, putting hundreds or thousands of points of presence within a few ms of everyone on earth. We imaging moving all the compute and storage there, not just some fraction which needs ultra speed. If it is easy to run code close to your users, and it’s affordable, there’s no reason everyone shouldn’t run everything as close to the consumers of the Internet as possible.
In this case, I think of the network is the computer. It's been for a while, but not yet completely, but it's becoming even more so as time passes.
Not only is the network essentially imbricated with/in the market, but recognizing the market in the role of the computation also means recognizing the roles of all of the different functional components, not just the mechanical/computational "atoms". Basically, I think that thinking this way lets us treat supply-demand basically as a messaging layer.
You can't abstract out supply and demand, at least, not forever. Abstraction is something you do to things so that you don't have to cognitively deal with them, they're predictable.
Humans will act predictably for as long as it makes sense for them to do so. Your business model will eventually fail because nobody will want your product / service anymore. Or they won't want exactly how you're delivering it. Or they'll have decided that X company is more reliable.
Someone has to keep on top of what the people supplying the business with life-sustaining revenue actually want. It can't ever be a machine, unless those machines actually become sentient, which is a completely different discussion. The person can use machines, but they can't actually be a machine.
People spend money, not algorithms. People may delegate to algorithms, but it's always a person in the end.
> Abstraction is something you do to things so that you don't have to cognitively deal with them, they're predictable.
The word "predictable". What does it mean to be predictable? Are periodic trends with micro-variations considered to be predictable? In that sense, might it not be possible to Fourier-decompose some time-series into a sufficiently-"predictable" set of frequencies?
But actually, I'm not even sure if this qualification is needed. If an abstraction is basically just a way to treat a bunch of events as a single idea, then what if the abstraction isn't something telling you how you should act, but instead something telling you how you should react?
Another assumption, I think, is that the market is human, i.e. because there are affective dimensions and bounded rationalities in the economy that make it unpredictable. This is true right now, but is that inherent to the market? You can argue that even an automated agent has "humanity", in the sense that it is essentially imprinted with their creator, but how much longer will this hold? It's asymptotic, but won't there be a threshold at which the humanity of machines made by machines, with many steps removed, becomes negligible?
For example, the pet market is absurdly large. What drives this market? The actual needs of animals? Of course not. It's the wishes of humans that make that market as big as it is.
It doesn't even have to be that humans are smart enough to control the new market-playing agents. It can also be that human desire can so vastly dwarf whatever external agency has a wish to be in the market that the whole industry ends up catering the wishes of the humans.
Right now, human desire drives the market for robots. Can you even imagine a point at which robots could develop enough agency to even come close to supplanting the human desire for more and better robots? When does the tail stop wagging the dog here?
People sometimes forget the sheer scale of human economies. Sure, maybe your pet non-human agent might be able to command a few hundred thousand in market activity. Is it even going to be notable over all the other existing types of non-human agency already on the market, like pets and HFT?
A little bit OT: I don't think acting and reacting are separate things in the real world. We're always only reacting.
Yes. You do not do hard real time over the public Internet.
(I've actually had the experience of driving a full-sized vehicle over WiFi. When we built our DARPA Grand Challenge vehicle in 2004, we had the test capability of driving it remotely over WiFi, from a control station with a game steering wheel and pedals. Worked fine technically, difficult to drive. 100ms of no signal and the stall timer slammed on the brakes. Self-driving in the "cloud" is not where you want to go.)
Supercomputers were designed and built to be used to capacity (otherwise they would be a waste of money). Modern mobile phones and laptops are not.
Maybe borrow from physics to call it the Egress Horizon.
I can guess what you intended but would be interested in the specifics.
It's a cool phrase though so we should definitely use it
At present, the closest capability to computing within the network fabric itself is Fog Computing. Cisco's IOx-enabled line of products (https://www.cisco.com/c/en/us/products/cloud-systems-managem...) pair a high-end router with decent computational capabilities. Other companies, like Nebbiolo Technologies (https://www.nebbiolo.tech/) or Fog Horn (https://www.foghorn.io/) provide Fog platforms that are not as locked to specific hardware.
If you would like more information on how Cloud, Edge, and Fog differ, I'll shamelessly plug our blog post from earlier this year:
You don't have to be cynical -- merely to have either been in, or have read about, IT trends over the past few decades would suffice to understand that it's all cyclical.
The cynical observation is that fashionable management trends and/or the market's eagerness to engage in ill-considered change as a convenient substitute for thoughtful progress, manifesting as regular vacillation between a centralised and a distributed approach to compute & storage, 'keeps us all in jobs'.
The applications delivered by those systems, traversing low-speed (9600bps) links over many hundreds of kilometres felt (and probably were) more responsive than the HTTP-based applications that have, 30 years later, mostly replaced them. Soon after that there was the trend to distribute file & print servers to every branch office, and maintain a breathtakingly large library of desktop applications. A blink later and I was at a Gartner shindig in 2000 where they were convinced the Sun Ray was going to be The Next Big Thing. (It wasn't.) Rinse and repeat.
And due to diminishing returns + economies of the scale, as the market starts investing in one, the other side starts to make more sense..
Also, if the market leans more towards network or compute (I'm not sure that's a useful distinction, but I'll run with it for now) wouldn't the economies of scale necessarily continue to accentuate the initial trend, rather than induce an oscillating pattern?
Cycles oscillate some, depending on compute speed and network latency.
But there isn’t as much oscillation as people think. 80’s/90’s style non-networked personal computing was a rare exception to the usual rule of networked centralisation with smrt-ish terminal access.
This seems like that, modulo Poe's law.
Here're two quotes taken from wiktionary
> Thus, the underlying structure which I would assign to Navajo will be identical, modulo word order, to the one that we found to be projected in all of the languages studied in chapter 3. 1990, Margaret Speas, Phrase Structure in Natural Language, p. 281
> Moreover, in the role of consumer, each individual (modulo his location) faces the same array of goods and services on sale to anyone who can pay the purchase price[.] 2002, Richard Arneson, "Egalitarianism", in The Stanford Encyclopedia of Philosophy
Mathematically, these expressions could be modeled in a vector space where "word order" or "location" are dimensions that are ignored. It's somewhat like saying: left and up are the same modulo rotation; [1 1 0] and [1 1 4] are the same modulo [x y lim(z->0)], if that makes any sense.
I can't speak for AWS, but for GCP there are many more Edge and CDN points of presence than there are datacenters:
https://cloud.google.com/about/locations/ (flip to Network tab in map)
And in Google's case "Edge" simply means where you exit the public internet and get on to Google's own network:
https://peering.google.com/#/infrastructure
Although there are also "edge nodes" (caches) located within ISPs outside the Google network.
Disclaimer: I work at GCP, but not on networking.
Or do you mean they might not be owned by aws (or Google)?
https://peering.google.com/#/options/google-global-cache
> Once registered and qualified by Google, we will send you a simple agreement for joining the GGC program. After you have electronically signed this agreement, Google will ship you servers that you install in your facility and attach to your network. Google will work with you to configure the servers and bring them into service.
It can be multiple buildings over a few square miles forming a resilient "region", or a single building, or all the way down to just some servers running in some rented rackspace in someone else's colo.
All the major clouds rent space like that for their CDN and smaller pops, and sometimes they even start smaller regions that way until they acquire or build their own structures.
Why in the world would/should a car in London be relying on a cloud computer in SF to tell it how to make real-time decisions...?
But the other way around seems insane.
It's reminiscent of the way people have switched from "human drives, computer deals with emergencies" to "computer drives, human deals with emergencies" as though it was no big difference.
The big deal is the lack of reliability on that connection.
Comparing a single component latency in technology to human reaction time is a complete straw man i see far too often. (I'm not blaming you, you are probably just repeating it). 150ms _is_ a good human reaction time, but in technological terms that includes sensor, network, processor, network bus, actuator and finally any physical latency of action being achieved.
A better and contextually relevant comparison here would be: human pressing a button after light turning on vs autonomous vehicle turning it's wheels 1 degree after seeing a light turn on. I bet you they are very similar, and I would not be surprised if the vehicle was slower.
150ms of network latency is significant because it's on top of the existing latency in the _whole_ system that makes up the car, including the sensors, the actuators whatever bus' inbetween them all. When you stick it's brain in the cloud and add 150ms of latency it's like a human trying to drive a car through a VR webcam, it will make it so much harder, 150ms latency between action and sensor is _very_ noticable even in humans, this is the same reason why cloud based FPS gaming (as in piping the result of the render over the network) doesn't work... no one is going to stick the brain of an autonomous vehicle behind 150ms of _additional_ latency.
Being 'noticable' is a totally different thing. A human can notice single digit millisecond differences in timing. With adding control latency, there are two main problems, and neither one affects a system designed for remote control.
One is that you're not used to it, and you have to undo a lifetime of learning to adjust. This goes the other way too, it would be very disorienting to magically make someone's body react 100ms sooner to every attempt at movement.
The other big problem is that your movements and button presses no longer line up with the audiovisual feedback. It's really disorienting, and is going to make you miss a lot of shots in that FPS. If you could detach your hands and put them at the other end of the link somehow, that problem would be a lot easier. You already understand how to compensate for the latency of your fingers. You'd still have to get used to it, though.
The point wasn't that a car would ever do this. The point is that it would be absolutely ridiculous to do real time computation with such a high latency. Unless your question is rhetorical, there is no answer except "you would not do that"
Some people out there for sure have no idea that the cloud is still bound by the constraints of physics and spacetime and that there is latency based on how close your servers are.
A real time controller in car would be perfectly fine with 150ms cycles, it just depends what is controlled. An engine controller is fine with 500Hz, a GPS controller with 10Hz, Formula 1 has 10Khz controllers, ...
So if a costly central computing service is fine to control something in a car, it might be done. But obviously not as described in the article, they are not stupid. A central service would be async and not RT of course. Updating maps, traffic warnings, eg.
This! In other words it is determinism. It should be highly deterministic. Most of the real time controllers even suggest to disable cache to be highly deterministic.
If that was the deal then you could have connectivity built into the road or road furniture and if the car detected a lack of connectivity it should come to a safe stop or revert to manual control.
It seems like we could benefit from a technological principle of Subsidiarity. https://en.wikipedia.org/wiki/Subsidiarity
I don't believe safe real time and 5G cellular networks can be combined at reasonable scale. The latency is enough for some use cases, but reliability/connectivity/safety is not enough. So we still agree here.
[0] https://www.bosch-mobility-solutions.com/en/highlights/autom...
It is a question dedicated to find out if you yourself think the product is good enough or how well you think it positions itself with the competition. Maybe it's just me being stupid here, but I find it funny how the whole discussion here has turned into a technical debate, which the original customer's point IMHO clearly wasn't.
There is no edge. You define the edge by what you believe in.
Watching it as engineer can be especially painful, because you already know that the other thing is not that much better. And more often this b.s. starts with the optimal trade-offs and turns into exactly what was carefully avoided with good architecture and decision making.
Sometimes I really think some of the managers are sitting there thinking "Yes, I know that you are smarter than me. But that is your disadvantage. Just to get some leverage I will now push for the stuff you told me to avoid again and again over the last 3 years, and you can't beat me in that approach because everything in you is fighting against this."
As in the customer wants to buy modern technology that makes their company look hip, their developers happy, and gives them an advantage against the competition.
Some rant about CDNs, or where the edge of the network is, seems inappopriate here.
Given a promising enough vision and execution there's no shortage of interested VCs and the challenge is in picking the right one for the long term. All VCs offer money, but many offer value beyond that. As the VC(s) you'll choose will hold a significant stake including board seats and voting rights you'll want someone with a deep enough understanding of your industry, technology, market, sales or operational model.
Even if we were talking about selling to a customer here I would argue that one's better off providing long-term value (and forfeiting a deal if one can't) than just catering for any buzzword-driven expectation and watch the whole edifice crumble a few months down the line
Your blog post sent me far into memory lane. I still remember a case where I was a starting entrepreneur and I was selling a website remake. The customer asked me if our CMS's database was relational. He clearly did not even have a clue what that actually meant, but neither did I :) I knew it was "most probably totally irrelevant" to the whole case (just as you seemed to ponder), but my uncertainty showed. I was maybe under my 20s then, though I was very confident I could deliver. But I was no salesman, more of an enthusiast geek with a vision.
What he was basically asking me was "why should I pick your product instead of all the others? Is this person credible?". It caught me so off-guard, that I kind of froze back then and wasn't able to bring the conversation to a level where our product would be compared to the competitors. Focus on the good things etc. Maybe he did it just check, if I was actually aware of any competition!
I didn't get that contract. I still remember it as a lesson learned in many levels and your blog post somehow reminded me of that moment. Can't really say if they are comparable, but there you have it :)
ps. My first thought today could be more like "what is this person scared of the most in this situation, where does this kind of question stem from?". A great sales rep might ask that question directly back. Cheers!
Kind of? If by "datacenter" they mean the things they said earlier that AWS had 18 of, then no, not really. There are many more Cloudfront points of presence that there are AWS regions (over 100 of the former). In practice unless someone lives very close to a proper AWS region (like I do here in DC), odds are there's a Cloudfront PoP much closer to them than a "datacenter" (i.e., AWS region).
The bit about self-driving cars talking to a server to make split-second decisions is laughable but this right here just makes you want to flip the table.
If you're requirements are so extreme that you need to be on "the edge" you can do that today, it's called client-side development.
I kid. Mostly. Most sane people would agree with you. However some people can't see the forest for the trees. Has "buzzword-driven development" become a phrase yet?
But the rest of the article talks about the location of data and servers and it's relationship with the word "edge". Am I missing something? Why is the anecdote unrelated to the article?
I believe the author intentionally wanted us to believe it was "the edge" based on your definition, but then wanted to make a point that "the edge" is now "the physical edge".
Another explanation would also be that a couple years ago the stereotypical technically-limited VC would ask if this app would be in "the cloud". The author used the same stereotype and adapted it to "the edge".
Personally, I immediately knew it's about cloud!edge, even when I saw the title. If you pay attention to current trending buzzwords (as I unfortunately do, skimming the things some people I work with post on company Slack), you'll learn that "edge computing" is the most recent buzzword in the cloud space.
There is, however, a (growing?) number of VCs with a purely financial background that approach investment decisions by establishing a framework of future trends/ developments (Crypto, Blockchain, Edge, Sharing Economy, E-Mobility and so on) and then vet potential investments based to how well companies align with these trends as well as basic suitability criteria (founding team, execution, traction etc.)
This isn't a bad thing per se as it might add a less biased view to investment decisions than the one made by the tech-founder-funds-tech-founder echo chamber, but it can lead to the level of detachment with the fundamentals of what one's talking about displayed in this article.
Why would IoT metric processing be latency sensitive? Whether my thermostat processes the temperature in 3 milliseconds or 30 milliseconds seems immaterial.
5G's secret weapon against other wireless technologies is reliable ultra low latency (up to 1 ms, at a low failure rate). It's enough for network automation in factories and factory robotics.
For customer applications it would make a sense to but graphics processors that can do VR, AR, games and machine learning inference very close to customers. It's and more practical for mobile users cheaper to get computing power as service than carry it around.
https://aws.amazon.com/cloudfront/details/#infrastructure
And you can do compute in CloudFront POPS with Lambda@Edge:
https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.htm...
The older usages of "edge" are from the networking world, where infrastructure and technologies have a relatively sharp distinction between "core/backbone/trunk networking" (large trunk lines, intercontinental fiber links, etc.) and "edge networking" (last-mile telco infrastructure, routers handling one building or campus of a company, etc)
From this networking perspective, both the end-users local device and the centrally-hosted server are at the edge, though AWS will have more reliable and lower-latency connections to the internet core than your cell phone.
Especially if you look at the latency of one-server-per-continent, which is still extremely far from "edge": you get something like 50ms or better. That's easily good enough to control anything a human could control by hand.
For AWS: a Lambda at the edge, for example, may be a Lambda behind an API Gateway that acts as the public entrypoint into infrastructure behind a VPC. That Lambda is at the edge.
https://portal.etsi.org/Portals/0/TBpages/MEC/Docs/Mobile-ed...
It is one of the definitions of edge computing, any comments?
Keeping "the edge" in sync with a centralized system-of-record via intelligent Excel add-ins is beginning to look like our big bet for 2019 (and beyond?)
also very nice plug to put your diagrams into the story
Not sure why everyone assumes the question was regarding networking.
Did she ask about your cache headers as well?
Nuxtjs and nextjs are “the edge” apps. But the server being centrally located especially for global ecommerce needs to go the way of the dodo.
Shopify being one. Some plus clients are near $800,000+ a year. Yet still no database or app servers outside the US.
Also, I can appreciate how some might feel like we are in a "fat client" world again and in some cases I am sure we are - it will depend on who is wielding the hammer as to whether it is used "properly" or the "most efficiently". I love how the modern cloud allows us to deploy computational power to the source of the data - if we so choose/need to.