Where the enterprise edge ends, where the far edge begins and what, if any, are the various points of intersection?
What do AWS Outpost, Azure Stack, Google Anthos and IBM Cloud Satellite have in common? Each one of them is essentially an extension of their public cloud offering into an enterprise’s on-premises location or edge facility. This is, in fact, the hybrid cloud platform paradigm.
Each vendor has their offering nuances. They even support different hardware for building the on-premises components of a hybrid cloud infrastructure. But the end goal is to combine the compute and storage of public cloud services into an enterprise’s data center — what some might call Enterprise Edge. It is worth pointing out that IBM Cloud Satellite is built on the value of Red Hat OpenShift Container Platform (RHOCP). This blog post will discuss where the enterprise edge ends, where the far edge begins and what, if any, are the various points of intersection.
To reiterate from previous blogs in this series, edge encompasses far edge devices all the way to the public cloud, with enterprise edge and network edge along the way. The various edges (network, enterprise, far edge) are shown on the left side of Figure 1 along with the major components of a platform product that include the cloud region, the tunnel link, a control plane, and different remote Satellite locations:
Note that one would need more than one control plane only. For example, a telco location for the network team and a development location for deploying edge services.
Please make sure to check out all the installments in this series of blog posts on edge computing:
- Part 1: “Cloud at the edge”
- Part 2: “Rounding out the edges”
- Part 3: “Architecting at the edge”
- Part 4: “DevOps at the edge”
- Part 5: “Policies at the edge”
- Part 6: “Models deployed at the edge”
- Part 7: “Security at the edge”
- Part 8: “Analytics at the edge”
- Part 9: “5G at the edge”
- Part 10: “Clusters at the edge”
- Part 11: “Automation at the edge”
- Part 12: “Network slicing at the edge”
- Part 13: “Data at the edge”
- Part 14: “Architectural decisions at the edge”
- Part 15: “GitOps at the edge”
- Part 17: “Storage services at the edge”
- Part 18: “Cloud services at the edge”
- Part 19: “Distributed cloud: Empowerment at the edge”
- Part 20: “Data sovereignty at the edge”
- Part 21: “Solutioning at the edge”
- Part 22: “Connected products at the edge”
- Part 23: “Foundational models at the edge”
Edge components
As we have mentioned in our other blogs in this series, there are three main components in an edge topology, no matter which edge we are talking about:
- A central hub that orchestrates and manages edge services deployment.
- Containerized services or applications that can run on edge devices.
- Edge nodes or devices where the applications run, and data is generated.
Some edge solutions do not use agents on edge devices, while others like IBM Edge Application Manager require an agent installed on each device. An agent is a small piece of code running on edge nodes or devices to facilitate the deployment and monitoring of applications. Refer to “Architecting at the Edge” for more information.
Which cloud?
In most cases, these platform products that bring public cloud services to an on-premises location work with one cloud provider. AWS Outpost, for example, is a hardware solution only meant to work with AWS. IBM Cloud Satellite, on the other hand, has certain connectivity and resource requirements (CPU/memory) but is agnostic to the hardware. The requirements generally begin at the operating system level (Red Hat) and leave the hardware purchasing to the customer. The Red Hat hosts provided can even be EC2 instances in AWS or other cloud providers. This means IBM Cloud Satellite can bring IBM Cloud services to remote locations as well as services from AWS, Azure, Google Cloud and more that are planned.
IBM Cloud Satellite
IBM Cloud Satellite extends its public cloud control plane to hardware running in your data center or server rooms. Simply put, it extends the IBM Cloud control plane to locations. Locations are places outside of the IBM public cloud where you can run services and applications. Each location is populated with hosts to run cloud services and applications. Hosts are Red Hat Enterprise Linux machines from your data center or the edge. A location connects to IBM Cloud by using a link. See Figure 2, which was originally published here.
You can find the IBM Cloud Satellite architecture in the Knowledge Center:
Satellite Link is an OSI model layer 4-6 proxy with additional security features. It does not operate or require layer 3 solutions but works with existing customer infrastructure solutions for layer 3.
Jason McGee, VP and CTO of IBM Cloud Platform, explains more about IBM Cloud Satellite in the following video:
Platform components
There are certain core components that are common to these Platform-as-a-Service (PaaS) products. Figure 2 shows the main components in IBM Cloud Satellite.
- Satellite hosts (hypervisor-agnostic Red Hat hosts)
- Cloud control plane (part of the IBM Cloud Satellite that is not managed by the customer)
- Secure tunnel link (automatically installed on the control plane with other control plane components)
- Satellite location control plane (minimum of three Satellite hosts that orchestrate the Satellite location services)
These components will build and deploy IBM Red Hat OpenShift Container platform hosts for IBM services and for customer use.
Overlapping or complementary technologies?
We hear the phrase “cloud-out” when describing the compute moving out toward the edge. But what we see from Figure 1 is that the services brought on-premises from the public cloud cannot quite be extended out to the far edge devices. That is where one would require a product like the IBM Edge Application Manager to deploy and manage services at scale.
A common challenge of edge workloads is training the artificial intelligence (AI) and machine learning (ML) models and using predictive model inferencing. An IBM Cloud Satellite location can act as the platform in close proximity where data can be stored and accessed, and AI/ML models can be trained and retrained before they are deployed on to edge devices. Or the apps running on the edge nodes could access a suite of AI/ML services via the Satellite location. Thus, low latency and data sovereignty are two major reasons why enterprises would want to deploy such solutions. Compliance and other security requirements are easier to implement when the cloud object storage or database is physically located on-premises.
It is easy to envision a use case where a retail chain would use a product like AWS Outpost or IBM Cloud Satellite to establish a satellite location in a city. That satellite location could then provide the required cloud-based services to all its stores in that city. These could be a common set of services like AI/ML analytics, access policies, security controls, databases, etc. — providing consistency across all environments. Consistency and access to a large set of powerful processing services are additional advantages of such deployments.
Another common example is with telecommunication service providers that are looking to monetize 5G technology by offering cloud services to their customers. Figure 3 shows a Telco MEC (Mobile Edge Computing) topology making use of IBM Cloud Satellite, IBM Edge Application Manager (IEAM) and Red Hat OpenShift Container Platform (RHOCP):
To provide a bit more context, MEC effectively offers localized cloud servers and services rather than depending on a larger, centralized cloud. This basically means the edge/IoT devices will communicate with more, smaller data hubs that are physically closer to them (i.e., on the “edge” of the network). Rather than online games having to send data to a distant central server, process it and send back a response — all of which slows down overall communication speeds — they will be able to access more power, closer to the gamers.
Wrap-up
In addition to the millions of devices, IoT and edge computing have the challenge of accessing and storing data in the “last mile.” Products like AWS Outpost, Azure Stack, Google Anthos and IBM Cloud Satellite complement IoT and Edge topologies. In fact, the IBM Edge Application Manager Hub is often deployed in a Satellite location or resides in the cloud. The combination of the two technologies provides a compelling solution that companies in healthcare, telecommunications and banking can use. The agnostic nature of IBM Cloud Satellite even allows it to not only bring IBM Cloud services to remote locations but also services from AWS, Azure and Google Cloud.
The IBM Cloud architecture center offers up many hybrid and multicloud reference architectures including AI frameworks. Look for the IBM Edge Computing reference architecture here.
This blog post talked about bringing cloud services to the edge in what is commonly called distributed cloud or “cloud out.” It offers the best of both worlds — public cloud services and secure on-premises infrastructure. The folks at mimik have a very interesting notion of “edge in,” wherein they describe a world of microservices, edge-device-to-edge-device communication and creating a sort of service mesh that expands the power of the edge devices toward the cloud.
Let us know what you think.
Special thanks to Joe Pearson, David Booz, Jeff Sloyer and Bill Lambertson for reviewing the article.
Please make sure to check out all the installments in this series of blog posts on edge computing:
- Part 1: “Cloud at the edge”
- Part 2: “Rounding out the edges”
- Part 3: “Architecting at the edge”
- Part 4: “DevOps at the edge”
- Part 5: “Policies at the edge”
- Part 6: “Models deployed at the edge”
- Part 7: “Security at the edge”
- Part 8: “Analytics at the edge”
- Part 9: “5G at the edge”
- Part 10: “Clusters at the edge”
- Part 11: “Automation at the edge”
- Part 12: “Network slicing at the edge”
- Part 13: “Data at the edge”
- Part 14: “Architectural decisions at the edge”
- Part 15: “GitOps at the edge”
- Part 17: “Storage services at the edge”
- Part 18: “Cloud services at the edge”
- Part 19: “Distributed cloud: Empowerment at the edge”
- Part 20: “Data sovereignty at the edge”
- Part 21: “Solutioning at the edge”
- Part 22: “Connected products at the edge”
- Part 23: “Foundational models at the edge”
Learn more
Related articles
Was this article helpful?
YesNo