订阅内容

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


关于作者

Chad is a Senior Principal Product Manager, Ansible, where he brings over 20 years of experience building enterprise automation architecture for anything in IT from Infrastructure to application delivery and lifecycle. Chad previously worked for ExxonMobil, AAFES and Tandy/Radioshack where he helped internal customers architect, deploy, manage and automate their applications, business processes and infrastructure. He resides in The Woodlands, TX (for now) with his wife and cats.
Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

按频道浏览

automation icon

自动化

有关技术、团队和环境 IT 自动化的最新信息

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

open hybrid cloud icon

开放混合云

了解我们如何利用混合云构建更灵活的未来

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Original series icon

原创节目

关于企业技术领域的创客和领导者们有趣的故事