I remember when we first started talking to customers about the concepts of applications driving networks, about three years ago (This was a very different conversation from other networking era’s where we talked about ‘intelligent’ networks that could better understand and adapt to applications.) While most customers loved the concepts of a scale-out network that leveraged dynamic photonic connections instead of hard-wired paths, most of them also told us that they “didn’t really know (or want to know)” about the applications at all. Some even said they didn’t want their networks to understand the applications at all!

Hmm.. this was very strange. After all, we were talking to Data Center networking folks, and wasn’t the purpose of the data center network to provide connectivity solutions for applications? How could the folks in charge of these networks not know (and worse, not want to know!) about the whole purpose of their network in the first place?

But of course, it wasn’t really strange. After all, networking, like many IT disciplines, had developed into a nice neat silo that defined nice neat operational boundaries that allowed folks within those boundaries to say “I don’t know, and I don’t want to know.” Of course, we knew we would get this reaction. And more importantly, the networking vendors were more than happy to provide silo’d products that kept customers in their silos.

We also knew it would start to change. Slowly at first, but we knew we would get to a point where even telling this story would not resonate with people – i.e. most people would forget that there was a time that we thought like this!

Now, at least half of the conversations I have with customers – with actual networking folks – are discussions about how to create enough hooks into the networking infrastructure to allow basic networking constructs (things like VLANs) to be automatically configured based on knowledge from the application or application orchestration system. Now this may not sound like much, and in the grand scheme of what’s possible, it isn’t actually much. But what is significant is the change in thinking about what is actually important, which signifies that the “… and I don’t want to know” part might be starting to change.

I recently spoke to a customer who described to me the intricate process of “systems engineering” a new application. Systems engineers are a group in this company, 100’s strong, that are given new applications from developers and tasked with engineering the physical environment the application will run on – the servers, load balancers, firewalls, storage, operational software, and of course the plumbing. The process requires knowing intricate details about an applications expected performance, data privacy requirements, connectivity requirements, and uptime requirements, and of course on the flipside requires knowledge of the capability of the various infrastructure components. The model is extremely heavy weight and doesn’t fit with how the customer wants to be able to roll out more new applications, faster.

In addition, the applications are being written to be more tolerant of individual component failures and are “scale-out” from the start – i.e. they expect very little in the way of handcrafted highly purposed infrastructure underneath them. They just need “a bunch of compute instances” that can be dialed up or down, or the same for storage.

The customer wants to push responsibility of documenting application parameters back into the developers to be expressed as application meta-data – that is of-course machine-readable. They then expect that machines be able to read this policy and be able to auto-deploy the software on the infrastructure – which of course requires an infrastructure that can – ta da – understand application requirements.

And not surprisingly, this customer sees this as an opportunity. An opportunity to change this heavy weight and slow systems engineering process to something that allows them to deploy new applications onto bare infrastructure in a small fraction of the time that it takes them today. Now they say to their networking vendors – “It’s the Applications, Stupid!”

In part 2 of this blog, we’ll talk in more detail about the application policy and infrastructure implications.

The post It’s the Applications, Stupid (Part 1 of 3)! appeared first on Plexxi.