Intent all of the things: The Power of end-to-end Intent

The tech world is buzzing with talk of intent. Intent based this, intent driven that. Let’s take a look at intent, and where we as an industry want to go with it.

First, and briefly, what’s intent? Intent is fairly simple if you let it be, it’s what you want from the app or service you’re deploying. Think business requirements of the app. Some examples are the apps requirements for: governance, security, compliance, risk, Geo-dependency, up-time, user-experience, etc. Eventually these will all get translated into the technical garbage language of infrastructure, but at some point they’re business decisions, that’s exactly where we want to capture them. For the purpose of this post I’ll focus on using intent for new apps, or app redesign, discovering intent for existing apps is a conversation or ten in itself.

There are several reasons we want to capture them at this level. Here are a few:

• • • • Business intent is the only thing that matters. Underlying infrastructure shouldn’t dictate what I get from my app, my requirements should dictate what the infrastructure provides.
      • Business intent is independent of infrastructure. Your regulators don’t care what your infrastructure can/can’t do, they want your app to meet their definition of the compliance regulation.
      • Capturing intent here, at the business level in the first place removes ambiguity and unknowns later.
      • This bullet is only added for the English and grammar Nazis that will be upset that I said ‘a few’ then followed with four bullets.

Conceptually any intent based, or driven, system will capture this intent at the highest level in a format abstracted from implementation detail. For example, financial regulations such as PCI compliance would be captured in intent. That actual intent will be implemented by a number of different devices that can be interchanged and acquired from different vendors. The intent, PCI compliance, must be captured in a way that separates it from underlying configuration requirements of devices such as firewalls.

The actual language used to define the intent is somewhat arbitrary but should be as universally usable as possible. What this means is that you’d ideally want one intent repository that could be used to provision intent for any application on any infrastructure, end-to-end. We obviously don’t live in an ideal world so this is not fully possible with current products, but we should continue to move towards this goal.

The next step of the process is the deployment of the intent onto infrastructure. The infrastructure itself is irrelevant, it can be on-premises, hosted, cloud, unicorn powered, or any combination. In most, if not all, products available today the intent repository and the automation engine responsible for this deployment are one and the same. The intent engine is responsible for translating the intent description stored in the repository down onto the chosen supported infrastructure. In the real world the engine may have multiple parts, or may be translated by more than one abstraction, but this should be transparent from an operational perspective. This process is shown in the following graphic.

Now’s where things start to get really sexy, and the true value of intent starts to shine. If I have an intent based system with a robust enough abstraction layer, my infrastructure becomes completely irrelevant. I define the intent for my application, and the system is responsible for translating that intent into the specific provisioning instructions required by the underlying infrastructure whatever that infrastructure is, and wherever that infrastructure lives (private, public, hosted, Alpha Centauri.)

The only restriction to this is that the infrastructure itself must have the software, hardware, and feature set required to implement intent. Using the PCI compliance example again, if the infrastructure isn’t capable of providing your compliance requirements, the intent system can’t help make that happen. Where the intent system can help with this is preventing the deployment of the application if doing so would violate intent. For example you have three underlying infrastructure options: Amazon EC2, Google Cloud Platform, and an on-premises private-cloud, if only your private-cloud meets your defined intent then the system prevents deployment to the two public cloud options. This type of thing is handled by the intent assurance engine which may be a seperate product or component of one of the pieces discussed above. For more on intent assurance see my blog http://www.definethecloud.net/intent-driven-architecture-part-iii-policy-assurance/.

This is where I see the most potential as this space matures. The intent for your application is defined once, and the application can be deployed, or moved anywhere with the intent assured, and continuously monitored. You can build and test in one environment with your full intent model enforced, then move to another environment for production. You can move your app from one cloud to another without redefining requirements. Equally important you can perform your audits on the central intent repository instead of individual apps as long as the infrastructures you run them on have been verified to properly consume the intent. Imagine auditing your PCI compliance intent definition one time, then simply deploying apps tagged with that intent without the need for additional audits. Here’s a visual on that.

 

Now let’s move this one step further: end-to-end intent. The umbrella of intent applies from the initial point of a user accessing the network, and should be carried consistently through to any resource they touch, data center, cloud, or otherwise. We need systems that can provide identity at initial access, carry that identity throughout the network, and enforce intent consistently along with the traffic.

This, unsurprisingly, is a very complex task. The challenges include:

• Several network domains are involved: data center, campus, enterprise, and WAN.
• Those domains typically fall into different organizational or functional groups.
•  An identity engine must exist for identification of clients, and assignment of an intent identifier. Ideally this will include user credentials, device type, OS type, and other factors as part of the identification. Maybe Joe gets access, but only on a corporate device with proper security updates.
• Consistent enforcement of intent across vastly disparate systems.
• Legacy device support. Data centers have faster refresh rates for hardware than campus and enterprise. Legacy equipment may not support appropriate abstractions to separate intent from forwarding which makes true intent driven driven architectures more difficult.

The bright side here is that products to handle each portion of this exist. At least one vendor has a portfolio that can provide this end-to-end architecture using several products. The downside or fine print is that these all still exist as separate domain products with little-to-no-integration. I would consider that more of a consideration than an adoption road-block. Custom integration can be built, or bought, and you can expect product integration to be a top road map priority. The graphic below shows the full picture of an intent driven architecture.

Utilizing intent as the end-to-end policy deployment method provides an immense amount of value to the IT organization. The use of intent:

• Enhances portability of application, and user policy.
• Greatly increases the independence of applications from infrastructure.
• Simplifies and centralizes auditing and governance.
• De-risks the enhancement of security.
• Provides consistent outcomes independent of architectural specifics.

While Intent driven architectures are in early maturity levels, they are already being deployed fairly widely in various fashions. As the maturity continues to grow here are some things I’d like to see from the industry:

• Some form of standardization for intent description and repositories. I’d love to know that once I describe intent for my apps and organization, I can use that description with systems from any vendor.
• Separation of intent repository from intent engines.
• Integration between intent platforms. Native would be great, but fully open, royalty and license free APIs is good enough.
• More ubiquitous work by hardware and software vendors to provide abstractions for the purpose of intent driven architectures, and the open APIs to use them as mentioned above.