When cloud computing first came out, a fairly popular view was that it would subsume all computing. A common analogy was the power grid, which (then) had largely done away with decentralized local power generation.
But there are many reasons why public clouds cannot always replace on-premises hardware. In the case of edge computing in particular, it is often desirable to bring data processing closer to the collection of data and the use of this data.
This has become important as machine learning is increasingly used to automate local operations in time-sensitive situations. In addition, acting locally is often not only faster, but also more resilient to connection failures than always depending on a central location.
However, implementing an edge architecture is not always easy. Here are four principles to consider as you take your business to the edge of the network.
1. Automation and management are not optional
It’s not that automation and management aren’t important for almost any IT infrastructure. Of course they are. But the sheer number of Edge devices and the fact that there may not be any local IT staff (or even permanent on-site staff) mean they do to need Automation and Management.
[ Also read Edge computing: 4 pillars for CIOs and IT leaders. ]
Automation uses software to create repeatable instructions and processes that reduce human interaction with IT systems. This in turn can improve IT delivery, configuration management, patching, app orchestration, security and compliance. Automation is typically achieved through automation workflows near the edge endpoints and a centralized control plane. Localized execution guards against high latencies and disconnects, while centralized control provides integrated control of the entire edge environment.
For example, a retail chain could automate endpoints to simplify infrastructure operations, strengthen security policies, and standardize device configuration across stores. Bulk configuration, disaster recovery, branch migration, and actions in response to specific events are examples of roles automation can play in an edge environment.
Closely related to this is management, which involves creating a unified operating environment. This is the key to scaling. As you deploy your standardized image to your environments, from development to production, you should also register those systems with the Edge Management Console. Maintaining security policies is also an essential management function.
2. Do not build random numbers into your business processes
The Fringe can get a bit like the Wild West if you let it. Even when automation and management systems are in place, an architectural commitment is still required to maintain a high level of consistency across the edge (and data center).
One reason for the lack of consistency is that peripheral devices are often smaller and less powerful than servers in a data center. The reasoning then follows that they need to run different software.
But that’s not necessarily the case — or at least it’s not the whole story. You can create system images from the small-core Linux operating system you’re running elsewhere and customize it to add exactly what you need in terms of drivers, extensions, and workloads. Images can then be versioned, tested, signed, and deployed as a unit, so your operations team knows exactly what’s running on the devices.
Staggered and applied image updates can also be configured to occur only on the next reboot or power cycle, ensuring minimal downtime. Downtime can also be reduced with intelligent rollbacks, which can roll back an update in response to application-specific health checks.
While some customization is often required in a hybrid cloud that spans edge devices, it is still often possible to have a consistent core environment underlying any required customizations.
3. The Edge also needs Kubernetes
This consistency can even extend to Kubernetes.
You might be thinking, “Wait…isn’t Kubernetes just for cloud and server clusters?” Not necessarily.
For one thing, edge devices aren’t necessarily that small anymore. For example, in a recent study, senior operations managers at companies say the ability to perform data analytics locally is a significant benefit of edge computing.
While machine learning (ML) model training is often still centralized, model inference is increasingly being marginalized. This can significantly reduce the need for high-bandwidth connections to send all the data home for analysis. This also means that any required local actions (e.g. shutting down a faulty machine or about to do so) do not depend on a reliable and fast network connection.
Even if today’s workload is relatively light, you should keep your options open. Perhaps your workload is increasing. You might want to add a high availability option. Perhaps you choose to be less dependent on a reliable network connection.
However, it can also make sense to adopt Kubernetes for the same reason discussed in the last section: consistency. If you run Kubernetes in your data center, running Kubernetes at the edge helps you standardize software lifecycle management and ensure consistency across your hybrid cloud environment. To this end, a large number of projects are carried out to optimize Kubernetes for a large number of use cases with different footprints, availability and network requirements.
4. There is help out there
There are many sources of information about edge computing. However, I would like to draw your attention to a few open-source efforts that document full edge architectures based on patterns that organizations have already implemented.
Portfolio architectures demonstrate successful deployments of open source software, including edge deployments, and provide architecture best practices, tools, and links to other related resources. This includes high-level abstractions of services and platforms, a schema describing the main nodes and services along with their interactions and network connections, and detailed considerations of specific services.
Portfolio architectures are developed using a common, repeatable process, visual language and toolset, presentations and architecture diagrams. Portfolio architectures focus on combinations of technologies that are effective in multiple deployments and solve a specific, common problem (or set of problems).
Validated patterns are a natural progression from reference architectures.
They contain all the code needed to build an edge software stack to get to a proof of concept faster. A typical pattern includes a data center and one or more Kubernetes-based edge clusters. All steps are fully automated by GitOps to automate deployments consistently and at scale. Users can then change the pattern for their specific application.
In addition, the associated user can share improvements – another example of how the open source development model is applied to both the initial deployment and ongoing operation of a complex, distributed software stack.
Unlike static reference architectures, the validated patterns are continually tested against current product releases to keep your deployment current – reducing risk while still utilizing the latest features.
Validated patterns also take other aspects into account, such as B. Security, which may not be part of the architecture per se, but are important considerations as part of any software deployment. For example, secrets and identity management are essential to most complex deployments. However, they are often omitted from “market talks” or even reference architectures in order to focus on the essential elements.
Because edge computing deployments sometimes must interact with a chaotic physical world, they will always have their complexities and unique aspects. However, by capitalizing on what others have learned and keeping core principles like automation, management, and consistency in mind, you can realize real business value.
[ Discover how priorities are changing. Get the Harvard Business Review Analytic Services report: Maintaining momentum on digital transformation. ]