Applications are the means of production for the digital enterprise. Applications rather than infrastructure are the priority for technical executives at most enterprises, taking all the top spots in the technical agenda…provided they can secure their digital assets from attack.
You see surveys such as this in Fortune showing the same pattern we found in our customer validation interviews. The top priorities for technical leaders look like this:
- Cyber: Lead on cyber security, don’t just keep patching.
- Digital: Enable transformation with digital products, subscriptions and automation.
- Big Data: Support customer-centricity with big data, analytics and AI/Machine learning.
- Agility: Improve by promoting pervasive cloud use, innovation, and technical literacy.
Gartner predicted that by 2020, 75% of application purchases will be Build not Buy. Most executives are focused on using applications and have thought little about how an application, once built, gets securely into production so people can use it. This was once included in the messy raft of systems integration services.
Today, development teams are keenly aware that there is a major activity at the end of the Build rainbow called Deploy. Ongoing deployment has become a little more well known, as DevOps.
Reorganizing networking around applications
Networking is on the critical path to deploy an application from test to production. In my industry, this gives the term application-centric networking, practical meaning.
Any networking-based barrier to Agile DevOps puts internal infrastructure teams on a short path to being replaced by a public cloud, which becomes not just infrastructure but also the development and deployment platform as a service.
So, networking professionals are rapidly shifting their skills and orientation from specialized infrastructure operations to continuous software application deployment. The fortunate ones are embedding with development teams who are organized around applications, not around a place such as a data center, campus, or branch.
But isn’t the network a shared asset by definition?
Intent-based networking is another subject that addresses this shared-asset question. First, is the intent the application intent or the corporate intent?
The case for corporate intent includes:
- Networks are shared utilities that have design requirements influenced by many applications and exist in their own expert-programming domain.
- Corporations and regulators have security and routing compliance-type requirements that are outside of the function of any given application.
- Separation of powers improves resiliency, ie a single developer mistake should not compromise the whole application, and a compromised application should not compromise the entire network infrastructure.
On this corporate-intent model, the networking industry built SDN software that interfaces to the applications on one side, the top, and then automatically reconfigures the devices in the network on the other side, the bottom. They inserted two-sided controllers to handle this.
Two years ago, at the SDN NFV World Congress, I myself spoke about applications needing an effective interface to the network. The idea is that sufficiently sophisticated software can translate application intent from many applications into the ideal set of complex configurations in the underlying network.
The challenge for even the best of these systems is that many applications and events drive changes into shared configurations across a huge number of physical and virtual devices. That may be fine for setting networks up. But this simply cannot react and resolve conflicts fast enough to keep pace with modern distributed applications nor with teams practicing Agile and DevOps.
Cloud native solutions to the rescue – Overlays and Underlays
Fortunately, the cloud players, that is the infrastructure-as-a-service experts, have already experienced and solved this problem. See Andromeda at Google. They use sophisticated automation for an underlying shared infrastructure to provision the network. But the applications never interact directly with this SDN, as they call it.
Applications teams assume, like they do for the Internet, that connectivity is available, fast and resilient. But everything else is up the application team to set up in the cloud (VPC) instance, or program into the application.
Within the realm of networking, what is everything else? Limiting access to authorized users/uses, initiating communication flows between specific instances of application functions / services, and controlling the routes that flows traverse.
In the cloud, instead of constantly reconfiguring the underlying infrastructure, the applications interact with a software overlay network to accomplish these tasks. The underlying network passes along – quickly and resiliently - encrypted packets between points controlled by the software-based overlay.
For this overlying layer of networking - instantiating the capabilities relevant to getting a specific application approved and deployed into production - the operative intent is very clearly application intent.
Done right, the answer is: Yes.
Click here for a video with more Bayware thinking about the application to network interface evolution. In my next post, I will break down application intent into tangible capabilities to help define ways to accomplish secure continuous deployment in a hybrid or multi-cloud setting.