The Art of Avoiding Eyes Glazing Over

As a descriptive term ‘IT agility’ has, like ‘cloud computing’, ‘virtualisation’ and ‘SOA’, become so widely used that finding a common definition is difficult.  Especially when many people use the term to describe something that they have always done and are simply trying to reframe something so it is more meaningful and up to date.

To take two of these: to me, agility and cloud are interchangeable. If you are agile, you can react to change. Unlike an oil tanker you can change course very quickly. For business, this means that you can respond to changes very quickly. If you need to deploy a new application, fast, you can. If you need to allow your entire UK workforce to work from home again this winter, it is possible to enable this.

If your infrastructure is agile, your path to cloud will be a lot easier.  Likewise, if you have adopted some sort of cloud architecture your business, by definition, is more agile.

But when I speak to customers, and I mention agility, their eyes will glaze over. They only look interested when I explain what it can mean for them.  What does this mean? We need to go beyond the tag line and look at the detail.

How it used to be

Applications were deployed in separate silos, which were usually over-provisioned. These silos were sacred and could not be touched.

Then came virtualisation, so we had a shared compute platform, and an application could be provisioned on its own shared hardware.   Still these were over-provisioned, and were configured to cater for peak demand.

In all this the constant was always the network, the static, inflexible network. To get around the static network we need to add application intelligence to the network. The network needs to know about the user, the application and apply context to the traffic. Once we have this intelligence in the network, all of a sudden we have the ability to become agile.

Now, we can abstract the application from the servers, the application from the network, and we can abstract the application from the data centre. We are now delivering a service to a user, irrelevant of the infrastructure or location.
What is in it for the network team or application architect? Let's talk through a couple of use cases and pose a couple of questions.


1. Imagine your application is deployed with multiple servers or instances of the application. Now you can provision more resource based on CPU or memory.  But what do they have to do with user experience or application performance? 
What if you could - based on response time for your application - provision more resource? What if you could move unused instances to less expensive resource when they were not in use, or even suspend them? You can do this currently but you are flying blind in my opinion. Without the knowledge of what is going on in the network how can you determine if users are experiencing performance issues, or even if there are any users using the app?   That is why you need this window of intelligence into your network.

How do you tell users that these new instances are available?  Do you email them?


2. What about pulling in resource from your other data centres? What if you could incorporate what is happening in your network to your provisioning system?  You need a lot of processing power in the UK to process your end of day transactions.  Before, you made sure you had enough hardware in place. But what if you had a data centre in Asia that was not being utilised yet? What if you could replicate your application in this data centre?

Is that all possible? If you do that, how can you get traffic there?


3. What if you deliver a service and you experience a sudden spike in demand that you cannot cater for?  You can "burst" to the cloud, but how do you manage the traffic overflow from your application to the instance running in the cloud?

To be able to react to changes such as those described above and to do so while maintaining service delivery is, in my opinion, the definition of agile in the context of IT.

To become agile you need a platform, a service delivery platform that will make the network as agile as your virtual applications. This platform understands the applications and the users and, as I have said before, can apply context to the traffic.

It knows what resource is available and where it is, directs users to the best resource for their connection, even if it is in another data centre. It can detect changes in applications and react, it can inform other services of the change and they can all react with the knowledge of the context of the traffic.

This platform is BIG-IP. It allows you to provision services, independent of the servers, independent of the data centres and ensures that these services are secure, fast and available.

Technorati Tags: BC, Cloud, DR, f5, F5 Networks, Agility, IT Agility, Dynamic, Provisioning

Published Sep 01, 2011
Version 1.0

Was this article helpful?

No CommentsBe the first to comment