What, exactly, is 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 semitruck 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 a smart home that monitors and keeps us safe, such as by shutting off a stove when a fire is detected or turning on an alarm when it knows you are no longer at home.

All of these are examples of edge computing. Each is an example of a novel use in and of itself. When we think about edge computing, these are the sorts of examples that come to mind. But what exactly is edge computing? Edge computing is taking part of your application and moving it closer to where the action is.

What do we mean by “the action”? By “the action,” we mean the source of interesting data that you want to process. This might be the end user of the application or the system being controlled. Or it might be the thing at the end of your application that represents the reason your application exists…the thing it was designed and built for.

Edge computing is about putting computation close to the need for that computation. 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 human involvement. And when we are talking about a semitruck, it’s about gathering useful information such as where the truck is located, whether it is moving at a safe speed, how much fuel it is using, and what the condition of its cargo is. For an automated home, it’s the intelligence to understand when something dangerous is happening and taking actions to help prevent it from getting worse.

When it comes to architecting for scale, edge computing is different. The rules for how edge services are built are different, the way they scale is different, and the way they utilize infrastructure is different. Let’s take a closer look at edge computing to see how it compares to traditional computing in the cloud and how we need to handle it differently from a scaling standpoint.

Edge Computing Today

These are all great uses of edge computing, but most of these examples are mostly outside of our everyday experiences so far. We don’t yet see automated drones flying overhead, nor do we see the impact of micro weather reports on farming.

But significant, important uses of edge computing do exist today, and more are becoming practical every day. You don’t need to look too far, or too far into the future, in order to see extensive use of edge computing in action:

· 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.

· Look at your local FedEx agent. They are using a scanner to keep track of your package, so you know where it is at all times and when it is arriving.

· Or look at yourself. You click that button on the application for your favorite coffee shop and expect your coffee to be waiting for you when you arrive.

In all these cases, you are using an edge application and are seeing edge computation.

Even closer to home, do you read your email in a smart web client in your web browser? Yep, that’s edge computing as well. The email application has both a server component and an edge component. The edge component is running in your browser. It’s running close to you, the user, in order to give you a better user experience.

Yes, that’s edge computing as well.

All of these are edge applications. All of them are making use of edge software running in edge devices. The details are different, but the fundamental structure of the application is the same. All of these are examples of edge computing.

Why We Care

Why do we care what is edge computing and what is not? Because patterns for building, operating, and scaling edge applications are different than the patterns for building, operating, and scaling cloud-based and server-side applications. The requirements for scaling an edge application or service are very different from the requirements for scaling a cloud application or service. The requirements for keeping an edge application or service operating are also different from the requirements for keeping a cloud application or service operating.

Scaling and availability are both impacted by the type of computation used, whether the computation occurs at the edge or in the cloud.

What Should Be in the Edge Versus the Cloud?

If scaling an application or service and keeping it highly available are impacted by whether or not a service is on the edge, how should we decide whether a piece of computation should be in the edge or in the cloud?

Or put another way, what exactly makes the edge the edge?

To answer this question, let’s go back to the purpose of edge computing. The purpose of edge computing is to put time-sensitive operations closer to where they are needed. This means:

· It’s about controlling the operation of the drone to keep it flying safely in all conditions and circumstances.

· It’s about keeping your browser email application responsive, so when you click a button the application responds immediately.

· It’s about keeping home safety systems working even if the connection to the internet (and hence the cloud) isn’t currently reliable.

· It’s about keeping your mobile application interacting with you in a timely and responsive 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.

Large computing application architecture is all about putting computation where is should be to keep it operating efficiently. This is the key to successful edge computing: putting the computation where it should be to be effective, not necessarily where it is most convenient for developers and operators.

NOTE

What should be in the edge?

Edge computing is all about putting computation where it should be to operate efficiently and effectively, as opposed to where it is convenient for it to be developed and operated.

Why is this so? Because putting computation out into the edge is harder and riskier than keeping it all together in the cloud. Building and maintaining edge software is more difficult than building and maintaining server-side cloud software.

So when we put computation at the edge, we should do it for good reasons.

How Do We Decide? The Driverless Car

So how do we decide whether to put some computation in the cloud or at the edge? To demonstrate, let’s look at an example where both cloud and edge computing are necessary for the application to be successful. It’s also an example that is getting lots of attention today and requires a significant amount of both edge and cloud-based computation: the driverless car.

A driverless car is a unique beast. Building and operating a car that can operate independently of a driver requires a significant amount of software and a significant amount of computation. It’s state of the art in artificial intelligence and data processing.

Let’s take a look at what makes up a driverless car.

A driverless car 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 whether that blob in front of you is (a) the car you are following, (b) a human crossing the street, or (c) a “road closed” barrier. Or is it a ball rolling across the street that just might be chased by a small child? Detecting, determining, understanding, and reacting to each of these possibilities is critical for the car to process in order to make the car safe.

A driverless car also has controls that make the car perform. Of course, it has controls for steering, controls for braking, and controls for applying power. But it also has controls and sensors for monitoring the health of the car itself. Is the motor operating efficiently? Do we have sufficient gasoline in our tank? Is our oil pressure acceptable? Is the passenger compartment cool enough? Should we deploy an airbag right now?

All of this requires computation. 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, and for some of that it is, in fact, mandatory that it occurs in the car itself. Examples of computation that must occur in the car itself are:

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 in front of me?

Collision control

· Do I need to quickly brake and swerve right to avoid a crash?

All of these are time-sensitive calculations that must occur, and in a timely fashion. This processing cannot go offline due to a bad internet connection. It cannot be delayed because a cloud server is busy processing other requests. All of this must occur automatically and immediately and occur every single time on time. It must always be available.

This is computation that must occur in the car itself. This is edge computing for the driverless car.

But there are other calculations that the driverless car needs that can and should occur in the cloud. Examples of computations that can occur in the cloud are:

Driving directions

How do I get from point A to point B? What’s the optimal route?

Road conditions

Is there road construction ahead? What about a detour or changed route?

Traffic

Is there traffic on this route that makes taking another route preferable?

Car efficiency

Can we tune a setting in the car to make it operate more efficiently and, perhaps, safe on fuel or emissions?

Car maintenance

Are we running low on gas? Where is the nearest gas station? Do we need maintenance? Where is the nearest maintenance facility?

Fleet, car sharing, and usage management

Who is using which car? Are we making effective use of our fleet resources? Can we optimize our use of cars to provide better service to our customers? Think about implementing Uber with driverless cars.

All of these things are examples of computations that are important for the operation of the car but are not as time sensitive as the previous list. These items are computations that can, and in fact should, occur in the cloud. These computations typically need access to centralized data, such as maps and traffic information. This information is easier to access in the cloud. Fleet management requires coordinating with other vehicles and other centralized systems. These services need the capabilities available in the cloud that are not easily available in the car itself.

But even more importantly, these computations are not as time sensitive as the edge computation needs are. Determining how to avoid traffic is not as real time as determining whether the person running in front of the car requires you to swerve to avoid them. The performance needs are not the same, and therefore these computations can occur in the cloud.

Software in the cloud is easier to develop, manage, and operate. Cloud software can easily coordinate with other cloud software and can better utilize centralized data and systems.

Software on the edge can respond faster and more reliably to emergent situations. It is more responsive and more adaptable to the particular situation. In addition, software on the edge can provide a higher level of data security given the ability to increase localization of the data and reduce the dependence on centralized data.

Edge Scaling Isn’t the Same as Cloud Scaling

Responsiveness and ease of management aren’t the only distinctions between software at the edge and software in the cloud. Building software to scale is different in the edge than it is in the cloud. Edge software scales horizontally, because adding new users means adding new instances. Cloud software scales vertically, because adding new users means the existing software must handle more requests and must scale more.

Edge scaling is all about instance management. How do I upgrade so many instances of my software? How do I monitor how all those instances are performing? Cloud scaling is all about resource management. Do I have the resources it takes to run my software at the required scale?

For software that runs in the edge:

· Edge software typically runs thousands and millions of instances of the software.

· Edge software runs in a huge number of geographically distinct areas, often one instance per location across millions of locations.

· Each instance of edge software typically is doing only one thing at a time, or managing one device or activity.

For software that runs in the cloud:

· Cloud software typically runs substantially fewer instances than edge software. Yes, cloud software may run on tens or hundreds or thousands of servers and instances, but the number of instances is substantially lower than the number of edge instances.

· Cloud software typically runs in a single location or a small handful of locations. Cloud software runs in server farms.

· Each instance of cloud software typically is responsible for managing thousands of distinct tasks, sometimes simultaneously, in order to handle many different user needs.

These differences result in wildly different scaling requirements. As the total application load increases over time, how each system responds to the different scaling needs is different.

For cloud software, the software must scale as the number of simultaneous users increases. The more the software is used, the more instances that must run. You must design and build the software so that more instances can be brought online quickly to meet higher scaling needs, and resource needs and resource allocation must keep scaling in mind in order for the software to keep up with demand and not buckle under the load. For the cloud, load scales upward as usage increases.

For edge software, however, each edge device typically handles a single user and single set of requests. As demand for the software increases, additional independent instances of the edge software are made available, but each individual instance is autonomous and is unaware of other instances. Hence, the load on the edge software is flat even as the number of users of the application increases. The software is not aware of the need to scale.

However, the absolute number of instances required to operate the software for all users grows linearly based on the number of users of the software for edge computing. If you add one million new self-driving cars, you add one million new instances of the software. Each instance of the software still manages only one car, but the number of instances grows considerably. For cloud software, the number of required instances does grow based on the number of users, but not nearly at the same rate. If you add one million new users to a cloud-based application, you might need to add a few tens or hundreds of servers, but definitely not millions.

What does this all mean? For cloud software, resource management becomes the concern. Making sure sufficient resources are available to operate the software at the required scale is your biggest concern in scaling. For edge software, instance management becomes the concern. Managing, operating, upgrading, and monitoring a huge number of instances of the software becomes the biggest concern in scaling.

Criteria for Using Edge Versus Cloud

If it matters whether a service runs on the edge or in the cloud, what criteria should be used to determine which should be used for a particular service or application?

Here is a specific set of recommended criteria for making that determination:

Criteria	Edge versus cloud
Computation is timing specific, or highly sensitive to delays	Edge
You require highly responsive software	Edge
Need a significant amount of compute resources	Cloud
Use of computation is bursty or unpredictable	Cloud
Highly sensitive to network connectivity issues	Edge
Need access to global data and less individualized data (such as traffic patterns)	Cloud
All other situations	Cloud

Why use the cloud for every other situation rather than use the edge? There are multiple reasons, some of which were hinted at earlier. But specifically, here are several reasons why cloud-based services are preferred over edge-based services when possible:

· Edge services are harder to manage and harder to upgrade.

· Edge has various unique provisioning issues. You may have to deal with edge hardware that has multiple versions and hence different capabilities.

· The edge has software version management issues. It’s very easy to have different edge devices running different versions of the service software.

· Edge software is harder to monitor and manage due to its highly distributed nature.

Eight Keys to Success in the Edge

We’ve seen that managing edge software can be more challenging, especially in a highly scaled application. We’ve also seen why utilizing edge software can be critical for an application. Given this, how can we be successful in using edge computing effectively in our high-scale applications? 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 utilizing edge computing.

#1: Be Smart About What Goes on the Edge

This is a continuation of what was said earlier in this chapter. You must make an active decision about whether to use the edge or the cloud for your computation and storage needs.

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 Ignore DevOps Principles in the Edge

It’s easy to discount DevOps principles when thinking about edge computing. You will often hear comments like “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 about. DevOps is about:

· Ownership and accountability

· Distributed decision making

· People, processes, and tools (most important)

The processes used in edge computing may change, and the tools you utilize may be different. But there will still be processes and there will still be tools. And the people involved are the same.

DevOps works well even in the edge.

#3: Nail a Highly Distributed Deployment Strategy

Often when we are building an application, we don’t think enough about how we will deploy it in production using a highly automated and highly reliable procedure. Instead, we make statements like “we can fix this later.” But while automated and repeatable deployments are critical for all applications, they are significantly more important for edge applications. This is true because of the remote nature of edge applications and the huge number of nodes involved.

Without a reliable, highly automated deployment process, your edge-based applications will suffer and fail.

#4: Reduce Versioning as Much as Possible

Deployments at the edge are hard, so reduce the quantity of deployments you need to make for edge applications.

Deploy less often.

This goes against the traditional motto of DevOps and Agile application development processes. Why does that make sense?

DevOps and Agile processes utilize CI/CD (continuous integration, continuous deployment) principles. These principles encourage making extensive use of more numerous and smaller deployments. This advice is great for cloud-based and server-based software. But for edge software, versioning becomes an issue. Automation of update processes is critical. The scale of the nodes involved in the upgrade process is huge. The demands of a deployment process are much greater in an edge application than they are in a cloud application. As such, there is value in reducing the number of deployments to reduce the amount of versioning.

There is a fine line here, though. You could reduce your deployments too much and therefore make the size and complexity of each upgrade much greater, increasing the risk of a deployment failure. So use this piece of advice carefully. Reduce versioning as much as possible, and no more. Continuous deployment is still a useful strategy, and rapid deployments still have their value. Just balance the effectiveness of this strategy against its increased cost in an edge-based environment.

#5: Reduce Per Node Provisioning and Configuration Options

Given the sheer 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. It is hard to manage the software for these edge devices unless they are running the same software configuration and options. The more diversity in hardware/software settings within the constellation of nodes, the harder it is to manage all these nodes effectively. It’s harder to manage, monitor, and upgrade. All aspects of scaling an edge application become more complicated when more provisioning and configuration options are available.

If every remote temperature probe is running on the same hardware, it’s easier to build and manage the software. If you have twenty different versions of the temperature probe hardware, or different versions built by different manufacturers, managing all those differences becomes much more complicated; it makes the edge software harder to operate and increases the likelihood of encountering problems.

Of course, it isn’t always possible to reduce the provisioning and configuration options. The best example is mobile applications. Mobile applications are edge applications that have to run on a large number of varied hardware/software configurations. This isn’t your choice; it’s your customer’s choice. Having a large number of varied software and hardware configurations is a challenge for all mobile application developers. This problem actually proves my point. Reducing the number of variables makes managing the software much easier. Sometimes this is not possible, but when it is, do it.

#6: Scaling Is an Edge Issue, Not Just a Cloud Issue

Backend cloud scaling is about how much each node can handle and the resource requirements to handle that load. Edge scaling is about how many nodes you can handle.

They are both scaling issues.

Node management is much harder for the edge, and understanding and recognizing that there is a scaling issue with edge software, and how to manage it, is important for building a highly scaled, highly available application.

#7: Nail Monitoring and Analytics

More nodes and distributed nodes mean that understanding how each node is performing at any given time is important. But this is hard to do without good analytics. Edge system management needs a continuous view into the health of every node in a highly scaled system.

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 not of importance to upper management in a typical corporation. But understanding how many automated drones are behaving well versus poorly is considered a higher level of visible importance within most corporations.

#8: The Edge Is Not Magic

Edge computing is 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 for the future of edge computing, however. It means that in the future there will be better edge-focused tooling. There will be services that will be tailored for the edge. We are already seeing some of this occur in cloud providers such as AWS that are offering edge- and IoT-focused services.

But existing tooling today, non-edge-specific tooling, is still appropriate and useful for building and managing edge services and applications. The edge is not magic.

Edge Computing Overall

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.

It’s important to understand what types of applications are best built in the edge and which are best built in the cloud. It’s important to understand the impact on scaling an application when it’s in the edge versus when it’s in the cloud.

It’s all about understanding and managing our modern applications and their components, whether they are cloud or edge components.