Temperature probes monitoring crops? Micro drones monitoring wind speed in the atmosphere? You don’t have to turn to these novel uses to see edge computing in action, look no further than the Point of Sale device at your local grocery store or the app on your mobile phone that is letting you order a cup of coffee.
Edge computing is all about taking the specific timing-sensitive parts of your application and moving them closer to where they are needed…whether that need is an end user or a source of interesting data, it’s all the same thing.
What really is the edge and how do we deal with it? How do we decide what computing should occur at the edge and what computing should occur in the cloud? How do you verify that your application is doing what it is expected to do? How do you know if you are meeting your performance expectations in the edge? How do you keep visibility in your entire application, whether it’s in the cloud or at the edge?
The edge is monitoring weather and drought conditions on a farm, to ensure optimal crop production.
The edge is an automated drone, flying solo, taking photographs or gathering environmental or geographical data.
The edge is a semi truck, transmitting information about where it is, its load, and its operating condition to a central transportation system.
The edge is a smart home appliance, that automatically knows when you are running low on something and assists you with ordering more.
The edge is smart home monitors that keep us safe, such as shutting off a stove when a fire is detected.
All of these are examples of edge computing. And they are all novel uses in and of themselves.
They are often what we think of when we think of edge computing.
{c}But what exactly is edge computing?
Edge computing is taking part of your application, and moving it closer to where the action is.
{c} By ”the action”, I mean: the source of interesting data you want to process, {D}or the end user of the application, {D}or a system being controlled.
This is what edge computing is all about.
Edge computing is, quite simply…
…putting computation where it belongs.
So, when we are monitoring drought conditions on a farm, we are gathering tons of data from far reaching locations.
And when we are talking about an automated drone, we are talking about keeping it in the air and free from the impact of wind and weather, without a human involved.
And when we are talking about a semi truck, it’s gathering useful information such as where is it located, is it moving at a safe speed, how much fuel is it using, and what are the conditions of its cargo. All automated…
And for the home automation, it’s the intelligence to understand when something dangerous is happening and taking actions to help prevent it from getting worse.
These are all great uses of edge computing, but these are mostly outside of our everyday experiences. We don’t yet see automated drones flying overhead, nor do we see the impact of micro weather reports on farming.
But edge computing is a lot closer to us today than you might think. You don’t need to go this far in order to see edge computing in action.
All you need to do is go to your local grocery store… the scanner is gathering data for the Point of Sale machine to determine how much you owe, before sending the results to the cloud.
Or the FedEx agent that is keeping track of your package so you know where it is, and when it’s arriving.
Or even closer and more personal, when you order a cup of coffee from your smart phone before walking into Starbucks or Dunkin to get it.
In all these cases, you are using an edge application.
Or everyday, every single day, when you are reading your email in a smart web client in your web browser.
Yes, that's edge computing as well.
All of these are edge devices, and all of them are examples of edge computing. Whether you are talking about the autonomous drone, the micro climate weather sensors, or your email inbox and mobile applications. All of these are examples of edge computing.
The edge is nothing to fear, the edge is nothing new or complex. The edge has been with us for a very long time and it is normal application development as we know it today.
So, if all of these things are examples of edge computing.
What exactly makes the edge, the edge?
Why is some computation edge computing and some of it is cloud computing?
The whole purpose of edge computing is to put time sensitive operations closer to where they are needed. It’s about controlling the drone to keep it flying safely. It’s about keeping your browser email application responsive. It’s about keeping home safety systems working even if they aren’t well connected to the cloud. And it’s about keeping your mobile application interacting with you in a timely manner.
This is opposed to the centralized computation that is typical in normal cloud computing.
This centralized computation is where data collection and analysis can be done. It's where order processing occurs. It's where communications with other people and systems happens.
Edge computing is all about putting computation where it should be to operate efficiently…
…as opposed to where it’s convenient for developers and operators.
Because, putting computation out into the edge is harder and riskier than keeping it together in the cloud. So, when we put computation at the edge, we should do it for good reasons.
So, how do we decide whether to put some computation in the cloud or at the edge?
Well, to demonstrate, let’s look at a fun and modern example. An example where both cloud and edge computing are necessary for the application to be successful. And an example that is getting a lot of attention today.
{c}Let’s talk about a driverless car.
A driverless car is a unique beast. It has lots of sensors and lots of controls. It has sensors to detect where obstacles might be located and where the road is located. It’s got cameras to detect if that blob in front of you is the car you are following, or a human crossing the street, or a road closed barrier. ***Or a ball that just might be chased by a small child…
It has controls that make the car perform. It has controls for steering, for braking, and for applying power. But it also has controls and sensors for monitoring the health of the car itself. Is the motor operating efficiently? Is the passenger compartment comfortable? Should we deploy an airbag right now?
Cameras and sensors. Steering and control. Engine health and passenger health. Passenger safety and community safety.Some of this computation has to occur in the car itself, but some of it can occur in the cloud. Which is which?
Some things are natural to perform ***in the car itself***, and are in fact mandatory that they occur **in the car**.
Image recognition (is that a person or another car near me?), Threat detection (is that person running in front of me or is that car in front of me applying its brakes?).
Road management (where is the edge of the road, is that a stop sign?). Collision control (quick, brake! Swerve right!).
All of this is time sensitive calculations that must occur and must occur timely. This processing cannot go offline due to a bad internet connection. It must always be available.
It is computation that must occur in the car itself. This is edge computing for the driverless car.
But there is other computation that the car needs that can and should occur in the cloud.
How do I get from point A to point B? What’s the most optimal route?
Is there road construction or a changed road?
Is there traffic on this route that makes taking another route more preferable?
Can we tune a setting in the car to make it operate more efficiently and, perhaps, save fuel?
Speaking of fuel, do we need to get gas? Where is the nearest gas station? Where is the nearest maintenance facility?
How do we manage a fleet of cars and manage upgrades and track usage of the cars and by whom? (why own a car when you can borrow one that’s nearby … the ultimate Uber).
These things are computation that can and should occur in the cloud. They typically need access to centralized data (such as maps and traffic information), and need to correlate lots of information from other sources to complete the computation.
And, even more importantly, the computation is not highly time sensitive.
These are important things to consider and distinctions that are important to remember.
But how does the computation itself differ between the edge and the cloud?
Well, computation in the edge is typically harder to manage than computation that occurs in the cloud.
Think about upgrading software, diagnosing a problem with the software, or monitoring how it is performing.
All of these are easier when the software is centralized, and harder when it is distributed and remote.
Software scaling is *different* in the edge than it is in the cloud.
Software scaling is important to both cases, but it is very different.
Edge software typically runs thousands and millions of instances of the software in a highly distributed manner, but each instance is typically only doing one thing or managing one device.
Cloud software typically runs a few instances (yes on multiple servers, but fewer in general), but each instance is typically doing actions for thousands of users.
Edge software requires managing thousands or millions of instances running in thousands or millions of locations.Cloud software requires a small number of instances in a small number of locations.
For the edge, load is linear or flat as the number of users increases. For the cloud, load scales upwards as the number of users increases.
For the edge, management difficulty scales upwards as the number of users increases. For the cloud, management of an application isn’t drastically different based on the number of users.
Edge has certain advantages, namely:
It provides more time sensitive processing. This is something I mentioned previously.
It provides a higher responsiveness to stimulus/response.
It allows a reduced reliance on network connectivity, which increases reliability in the face of unknown connectivity.
It allows more dedicated processing to a single specific task.
But edge computing has its challenges, mostly due to the large number of nodes required and how distributed geographically they can be:
Managing deployments across a fleet of edge devices can be very challenging. Whether that’s cell phones or flying drones, it’s still a problem.
Monitoring usage and analyzing how the software is performing is harder.
Debugging problems remotely is difficult.
Understanding when something is going wrong at a system level, versus a single node level, is much more difficult.
So, what criteria do you use to determine edge vs cloud?
There are several:
When computation is timing specific or highly sensitive to delays, use edge.
When you need high responsiveness, consider edge.
But when you need a significant amount of CPU and your use of it is quite bursty and unpredictable, use the cloud.
When you are highly sensitive to network connectivity issues, consider the edge.
If you need access to more global data and less individualized data (traffic patterns vs current car speed), use the cloud.
But, everything else aside, unless you have a compelling reason to use the edge, then use the cloud. When all else is equal, use the cloud.
Why use the cloud instead of the edge? {P} Well…
The edge is harder to manage
The edge is harder to upgrade
The edge has version management issues (are we sure all nodes are running the same version of our software?)
The edge has variable and unique provisioning issues (we’ll talk more about that shortly)
The edge makes monitoring and managing software harder and more complicated
So, edge is more challenging and harder to manage. How can we be successful in using edge computing effectively?
There are eight keys to being successful in building edge computing into your application. They are all simple but very valuable pieces of advice for success in the edge.
We’re going to talk about each in turn.
#1 Be smart on what is in the cloud vs the edge
This is a continuation of what I said earlier. Make sure you make an *active* decision about whether to use the edge or the cloud for your computation and storage.
Remember what the edge is good for, and remember what the cloud is good for.
And remember the disadvantages the edge has over the cloud. When in doubt, use the cloud. Only use the edge for computation that is best optimized for the edge.
#2, Don’t throw away DevOps principles in the edge.
It’s easy to discount DevOps principles when thinking about edge computing. You hear comments like this: “Edge computing is highly specialized computing”, and “New processes and procedures are needed for the edge”. These are common messages.
But remember what DevOps is all about. DevOps is about 1) Ownership and accountability, 2) Distributed decision making, and most importantly 3) People, processes, and tools.
The processes may change, and the tools may change, but there will still be processes and tools and the people are the same. DevOps works well even in the edge.
#3 Nail highly distributed deployments.
Often, when building an application, we don’t think enough about how we will deploy it in a highly automated way. We say “we can fix this later”. But while automated and repeatable deployments are critical for all applications, they are significantly more important for edge applications, due to the remote nature and the huge number of nodes involved.
#4, reduce versioning as much as possible.
Deployments at the edge are hard, so reduce the quantity of deployments you need to make. Deploy ***less*** often.
Reduce the number of deployments. We keep hearing today about the value of increasing the number of deployments. So this advice of reducing the number of deployments seems opposite from that of standard best practice principles and CI/CD strategies. But, it’s not different.
CI/CD says automated deployments are critical, and automated upgrades are critical. It’s all about **automation**, and that is even more *important* for edge computing. It’s just that the scale of nodes demands that we manage expectations for deployments differently than for the cloud.
You should not assume you can deploy to the edge as fast or as often as you can to the cloud.
#5, reduce the provisioning and configuration options available for each node as much as possible.
Given the shear number of nodes involved in a large edge deployment, it is hard to manage the software for these edge devices unless they are all running the same hardware and hardware version. Same configuration and installed options, and same software configuration.
If every remote temperature probe is running on the same hardware, the easier it is to build and manage the software. Of course this isn’t always possible…the best example is mobile apps, which have to run in a large number of varied hardware/software configurations. This is a challenge for managing this software and actually proves my point. Reducing the number of variables makes managing the software much easier.
#6, understand that scaling is still an issue for the edge as it is for the cloud.
Backend (cloud) scaling is about how much each node can handle.
Edge scaling is about how many nodes can you handle.
As such, node management is much harder for the edge.
In the edge, all scaling is horizontal scaling. Vertical scaling (increasing the size of individual nodes to scale) is typically less important.
More nodes…not bigger nodes.
#7 Nail monitoring and analytics.
More nodes and distributed nodes means understanding how each node is performing at any given time is important, but hard to track without good analytics.
System management needs a continuous view into the health of every node in a highly scaled system.
But also high level reports containing analytics of edge node health **tend to be viewed** at higher levels within your organization. How an individual server in the cloud or your data center is performing is typically not of high level management import, but understanding how many automated drones are behaving well vs poorly is of a higher level of visible importance.
And finally, #8, the edge is not magic.
It’s not new, it’s not “special”. We’ve been doing edge computing for years, we’ve just called it something else. We might have called it a “browser application”, or a “mobile application”, or a “Point of Sale” device. But it’s all just edge computing.
The edge is not a new form of computing. The edge is, however, a new way to categorize and label an existing class of computation.
THIS new categorization and labeling is **good** and **encouraging**.
>>It means in the future there will be **better** edge-focused tooling.>>There will be services that will be **tailored** for the edge. >>But **existing** tooling today – non edge specific tooling – is still appropriate and useful.
These are the eight keys to being successful in building edge computing into your application. Together, they are a simple but very valuable strategy for success in the edge.
But remember, edge computing is the same as today’s mobile and browser computing.
It’s all about management of modern applications, and their components, whether they are cloud or edge components.