Application Policies: Are they the most important thing we make?

Many current IT trends, such as cloud or SDN have two key drivers: increased IT agility and reduced operational overhead. It makes pretty good sense. If you can use an abstracted, virtualized infrastructure then you save all that ordering, racking and stacking of a traditional infrastructure. Automation and ‘Software Defined Stuff’  reduce tedious and error-prone configurations steps.  Your time to deploy an application (or ‘time to value’ as some of my more marketing focused colleagues will insist on calling it) goes down and so does your operational expenditure. You can see why it’s a popular trend.

The thing is, applications and networks often still need some additional layer 4-7 services to help them. You can see that as a bad thing (shouldn't it all just work?) or a good thing (food on the table for my hungry brood), but it’s still the truth. Now, that these rich, high value services are just that -  rich in features and possible configurations because different applications need different services. Organizations want the benefits of increased automation and reduced complexity, but can’t sacrifice the features of these application network services - such as security or acceleration. The problem is, automation tools cannot be expected to control every possible configuration setting across all infrastructure layers the application relies on. They would become bloated and just too complex. I can think of dozens of features I could enable, tune or program on even a simple BIG-IP HTTP configuration. This is great because I can really improve the delivery of my applications, but it’s sure a lot to remember each time I deploy one. If you were to have to select and configure these settings in your automation tool each time you deployed another application, you may as well have done it by hand in the first place.  

What is needed  is an abstraction layer.

You don’t want to know the grimy details of all the settings to get the best application performance, security or availability. What you do know what sort of application you are deploying (e.g. HTTP, mail, Oracle, VMware Horizon View) and who the users are (internal, external, partners) – so you know what kind of policy you want to be applied to the traffic. Application policies provide a solution by allowing services to be optimized for a specific application without exposing the implementation details upstream.  All you have to know is the type of application you have and the details of your specific instance.  Your orchestration tool can retrieve the list of the required data from a catalog of policies and supply only the information that’s really needed for this specific instance (often just some IP addressing and service names). This results both in simpler automation and improved application mobility, without losing functions applications rely on.  Want to fire up another instance in another cloud or datacenter? Just use the same policy and your application gets the same services wherever it is running.

F5 have realized much of this vision with our iApp templates and integration with frameworks like Cisco ACI and VMware NSX. They’re really good, but I’m still out spreading the word  about their true value within the organization. So far my “iApps are the most important thing we make” speech has almost universally been met with suspicion (except for the by the team the writes and supports them, funnily enough). Then I explain how the technology allows us to deliver the great application layer functionality they are developing  and keep the simplicity that automation tools need and our customers want.

Nine times out of ten I leave a convert behind. I won’t say what happens to the one in ten.

A small update  after a conversation with my management team: I was wrong. It’s money. Money is the most important thing we make. Still, I think that iApps are still a close second.