We’re entering a brave new world of infrastructure and DevOps.

We still use language like “application architecture”, “network” and “service.” But now we have new phrases like “software defined networking” (SDN) and “network function virtualization.” (NFV)

It means we can meet the needs of applications much more quickly. We are able to deploy application architectures in seconds - using OpenStack, Amazon and Juju.

We can also quickly define and deploy virtualized networks over which an application architecture runs - using OpenFlow and VIRL.

In short, virtualisation and automation cut cost and speed deployment.

But there remains a chasm - one that has remained substantially unchanged since programmers first produced apps on networked machines and called them fat clients.

Imagine, if you will, two large blocks - side by side. Call one block “Applications” and the other “Infrastructure”.

Between those two blocks is the chasm I’m talking about.

Now, with virtualized infrastructure, imagine a rope bridge spanning the chasm. Applications people cross to the infrastructure side and automate lots of stuff we used to do by hand.

Thus we end up with a bunch of programs (let’s not call them applications) which try to guess what the applications back on the other side might be trying to do, and generate config to match.

It’s all back to front, actually - but we’ll get to that in a minute.

To help them do this we use a picture we call the “application architecture”, positioned like a kind of customs shed somewhere halfway across the rope bridge.

This normally shows the layout of technical artefacts like databases, middleware, servers and whatnot together with links between them. Thus it’s often drawn as various boxes and lines, saying this thing talks to this other thing over that link.

The application architecture serves as a kind of map or blueprint used by infrastructure folks to provision the kit, virtual or otherwise. It’s pretty much a static thing, and normally there’s one of it per application.

Now, this form of blueprint was originally needed because the physical objects that constitute the system had to be unpacked from crates, installed, connected, powered up and configured - likely by people other than the application programmers.

An enterprise today will have hundreds of these blueprints in various stages of decay. They have a collective noun: nightmare.

Frivolity aside, nobody denies an application architecture is, and always has been, a country mile away from the original business need. That’s not to say it doesn’t have business value - it’s just annoyingly opaque.

You can’t look at an application architecture and derive the purpose of the application that runs on it. Besides, in our brave new world there’s no unpacking, no installing, no connecting and no powering up. We’re left with various flavours of configuring.

At SPARKL we’d go so far as to say that better abstractions are needed. Ideally, ones that aren’t back-to-front, and which tie the application and its logic directly to infrastructure.

Not only is the static application architecture opaque, it also exhibits really poor combinatorial behaviour. As an abstraction over many systems and applications, it fails to encourage fast changing, heterogeneous, short-term solutions and instead rewards homogeneity and inflexibility. At this point, the cart is driving the horse and IT slows the business down.

One global investment bank has spent over a decade building custom middleware in an attempt to provide this homogeneity. Successful in the way the castles and moats were successful, these things work - but they are very expensive and clearly a product of their time.

We believe SPARKL provides one way forward. Although perfectly happy within traditional static application architectures, it gently encourages a new abstraction which aligns infrastructure directly with application flow - not just physical artefacts.

This new abstraction is transparent and allows dynamic, secure, reliable and auditable provisioning of heterogeneous anything. From network link to entire server, and driven by individual application flow events, it is completely agnostic to application lifetime, technology, type or structure.

We believe the benefits of this better abstraction include increased security and resilience, reduced reputational risk, reduced cost, increased speed to market and flexibility to deal with business or environmental change - not to mention a whole new level of provable audit and compliance.

Something for everyone, in fact.

Image courtesy of Warner Bros