Taking Policy Management to the Edge (and how it’s different from the cloud)
Most enterprises are well on their way towards a cloud operating model. Many have moved significant parts of their applications to one (or more) public clouds. Yet, many resources will never be destined for a central public cloud — and for good reason. We now see two factors that affect where and how many resources will ultimately be deployed (hint: it’s at the edge).
- As part of retooling for the cloud, companies have repackaged significant parts of their application population into containers. This universal packaging format opens up the opportunity to think a little deeper about where applications should run to provide the most value.
- Companies have a desire to move at the speed of software in all environments (not just centralized clouds) using the processes and tools they have put together for developing and operating applications.
As a result, we expect more and more application and operations teams to be tasked with extending their operational capabilities to include distributed environments — that is, at the edge — across numerous industries.
Edge vs. central environments
As with all new application development journeys, the first phase centers on the question of how to perform basic lifecycle management for applications themselves. This includes the ability to deploy based on declarative targets (location, hardware configuration and the like) as well as how to deliver scalable monitoring and observability. What comes after that is a conversation about which infrastructure services are required to allow applications to run efficiently — and here, this means on the edge.
When looking at the requirements for distributed environments, pinpointing similarities and differences between central and edge environments is key for success.
|
Central environments |
Edge environments |
|---|---|
| Many hosts, few locations | Few hosts, many locations |
| Location doesn’t really matter | Location is key for application placement |
| Rapid elasticity | Application autonomy |
| Movable workloads | Targeted deployments (again, location is key) |
| Perimeter security | Host-based security |
As you can see, the edge has a diverse and distinct set of requirements. Understanding and adapting to the differing attributes between central and edge environments is critical for the efficient management and orchestration of applications running in each location.
Distributed policy management
Of course, when discussing edge deployments (and we know this from experience) the next step in the conversation is around how to do distributed policy management. Because distributed environments should in no way compromise the security posture established for central cloud environments. This is where OPA is a game-changer.
The Open Policy Agent (OPA) project is the clear leader (and pretty much the inventor) in the field of policy-based control for cloud-native environments. By decoupling the policy decision from application code, OPA/Styra cracked the code for truly distributed decisions with centralized review, release and analysis.
Many enterprises rely on OPA for policy decisions and Styra DAS for centralized management of large fleets of OPA instances and policies for their applications in centralized environments.
As application teams now augment their centrally hosted applications with distributed components, there is a growing need to provide cohesive policies across both central and distributed domains. Since the edge is same, same but different — we have worked with our partners in the OPA/Styra team to come up with a blueprint that will allow application and opsec teams to keep building on OPA, but extend the scope to the edge. And do this while meeting the specific requirements at the edge, including survivability, location and context-specific policy decisions and lifecycle management of the OPA agent itself.
Our vision at Avassa is to allow application and operations teams to manage containers across many locations (hundreds, thousands) with the same great experience that centralized clouds provide (when they work well). We have been able to work with some interesting users as they take on extending their operational capabilities to include operating containers across hundreds of sites. Learn more about our edge application orchestration platform here.
About Carl Moberg
Carl has spent many years solving for automation and orchestration. He started building customer service platforms for ISPs back when people used dial-up for online activities. He then moved on to focus on making multi-vendor networks programmable through model-driven architectures. Now CTO and co-founder at Avassa, he spends his days obsessing over how to deliver a distributed edge control plane that developers and application teams love.