Lessons from the Edge
Travel light and live off the land
I love the story of the 1912 race to the south poke between Roald Amundsen and Robert F. Scott.
Robert Scott brought everything you could ever possibly need for a polar expedition—enough food and supplies to last months. It was so heavy and cumbersome that Scott and his entire team perished.
Roald Amundsen brought a dogsled and a shotgun. He and his small crew hunted fir food, instead of trying to carry it all with them. Amundsen bear Scott to the South Poke by 13 weeks, and lived.
Living on the edge of the network has more in common with trekking. to the edge of the Earth than it may first appear.
But first, what is edge computing, and why is it interesting?
The edge is the part of the cloud that’s closest to you
The edge is often thought of as being the part of the network that’s furthest from the cloud.
But that’s a backwards way of looking at it.
The edge is the closest part of the network to you.
Why run at the edge?
Lower latency. Higher throughout. Lower transport cost. And somebody else foots the electrical bill.
The edge is not new
Content delivery networks (CDNa) like Akamai have run at the edge (closest to you) forever
Edge computing is what’s new
The idea that third party cloud native application can run at the edge of the network (close to users) is called edge computing, and it’s rekatmiveky new.
Apps that benefit from edge. deployment
Games. Collaboration apps. IoT. Augmented reality.
Server-side page rendering, ie. CDNs for non-status web pages. Thus is the bulk of what AWS edge lambdas and CloudFlare edge workers are used for.
Edge computing == Kubernetes at the edge of the network
The infrastructure guys are like, now you can run containers on the edge, so mission accomplished, right?
The Cloud is uniform; the Edge is not
Every cloud is divided into regions, with three data centers per region, and equivalent racks of machines per datacenter. Every edge is different.
The homogeneity of the Cloud is deeply baked into distributed application architectures
Databases assume multi-region replication. Application servers assume any database node can answer any query equally.
The assumption for the past 30 years has been that the topology of the network dies not matter. And that assumption has fundamentally shaped nearly every piece of mainstream infrastructure software.
Cloud native apps are the opposite of self-sufficient
Back to Amundsen and Scott. Cloud native apps have a high fixed infrastructure cost. Every region needs databases, brokers, job executors, app app servers.
The fixed overhead is manageable when spread across one, maybe two, rarely three regions.
But there are hundreds of edge computing zones. And the overhead of 500 database deployments, 500 kafka deployments, 500 yarn deployments, and 500 wen servers—per application—just isn’t going to happen.
The software fat cats will starve to death on the edge.
Edge computing benefits hugely from vertical integration
If you can take care of yourself: provide your own persistence, messaging( compute scheduling, and APIs, you have what it takes to thrive at the edge. Like Roald Amundsen, you can travel light, and live off the land.
Live off of locally attached disks connected to edge compute nodes, instead of centralized blob stores.
Live off of more modest edge CPUs.
There’s nit enough memory at the edge fir your memcached servers, so you better be stateful and locally persistent.
Embrace the topology of the network, instead if ignoring it.
There’s a dam upstream of the data lake
All data passes through the edge on its way to Amazon. Edge infrastructure providers would love for SaaS vendors to move their applications upstream, taking that sweet web services revenue for themselves.
The holdup is that cloud native apps don’t run well at the edge. Containers aren’t enough.
The value isn’t the container, it’s what goes into the container. Vertically integrated stacks like Swim are what goes into the edge containers.