Let's Level Set at the Edge

Introduction

Typically when people hear the word edge, everyone gets a little apprehensive of what that means. So Josh, Andy, Martin and Chad got together to collaborate on what that means from their collective experiences across multiple industries. In this blog we will cover what the difference is between the near edge and far edge, as well as give some examples of what we have seen in these environments across multiple industries.

Near Edge

Near edge typically refers to distributed deployments of “scaled-down” IT-like services to support business operations outside the core data centers and public cloud providers. This includes anything from retail stores, branch field offices, manufacturing facilities, warehouses and distribution centers that generally have stable connectivity. 

Traditionally, these have been referred to as remote offices or branch offices, with the common acronym ROBO, but there are far more examples of this deployment pattern. Consider the following:

• A point of sale system or back office processing at a retail location.
• A localized authentication/authorization source for badge access to a manufacturing plant.
• A file share located locally to a University’s extension office that’s replicated over an unreliable connection.

These are all examples that fit under our definition of near edge: scaled down IT services being operated closer to the consumers of those services.

Another way to identify these types of deployments is to look for datacenter-lite assets, such as rack mounted servers, scaled down networking gear typically focused on the access layer, and small pockets of storage for localized consumption. These are all things found within a traditional datacenter, however significantly scaled down to fit far lighter requirements and space/power/cooling availability.

These edge deployments also run a very common set of services, such as:

• Networking (wired and wireless)
• A hyperconverged virtualization cluster (at least two servers for high availability)
• DNS/IPAM
• Proxies
• WAN Acceleration
• IDM (Identity Management)
  • An Active Directory domain controller
  • LDAP server 
• Applications running on Windows or Linux machines
• Lightweight Kubernetes deployments depending on maturity of organization
• Firewalls

Existing environments most likely have individual teams that support each component listed above, along with their own practices on how they are supported, which can slow down how long it takes to deploy a site. 

Far Edge Deployments

Far Edge is an environment where we are seeing the convergence of IT and OT (operations technology) as part of the Industry 4.0 world (1.0 Steam, 2.0 Electricity, 3.0 Computers, 4.0 smart machines/IIOT). This is where we talk less about “IT systems” and services, and more about things such as individual sensors/motors and more, as well as industrial control systems. These various components are typically networked together, but kept far outside of the purview of traditional or central IT. 

What this means is that people that have deep knowledge of how the OT systems in industrial/process controls, SCADA systems, manufacturing, oil and gas, etc. are starting to work with IT concepts to manage their systems. They have traditionally relied on a completely separate IT organization to deploy all of their servers, networking, storage and firewalls, which was always a pain point as this was a very slow process. DevOps was born from a very similar issue in traditional organizations, so we could think of this as the next evolution of DevOps for OT applications.

Closing

Each of us has done this before at large companies in different verticals, so I’m sure we can all agree that it takes a lot of work to build an automation strategy. Large companies who have built a strategy around Red Hat Ansible Automation Platform have seen great success in building, maintaining and securing their edge environments. Making all of your existing processes and group components available using a tool like Ansible Automation Platform allows you to go from multiple people manually deploying an edge site to building a workflow in Ansible Automation Platform to request to deploy, patch or validate security at an edge site. 

Learn what Ansible helps you do at the edge →

Alternate:

You can migrate your existing automation processes - especially the setup and maintenance scripting, including patching that is common in edge environments -  into Ansible Automation Platform with relatively little effort. Doing this will create a centralized “source of truth” available to all of the teams involved in edge deployments and maintenance, which will simplify and streamline edge deployments. Ansible Automation Platform also supports integrations with ticketing and workflow systems to provide visibility that security processes and business processes need.

*other contributors to this blog include Josh Swanson, Martin Jackson, and Andrew Block