This article originally appeared in the November 2010 issue of INTERNET TELEPHONY

To date SLAs have been the bane of the cloud industry, limiting total, mass scale adoption by enterprise customers. This isn’t the fault of the cloud providers; it’s more a function of the cloud architecture of shared resources across the entire infrastructure, a phenomenon that isn’t seen with traditional hosting providers.

Why can my hosting provider guarantee SLAs, yet my cloud provider – which offers me more operational flexibility – can barely tell me why I had an outage, much less guarantee that it won’t happen again? Ironically, it’s that same flexibility from the cloud that’s killing SLAs; and, unfortunately, the flexibility and failure point is shared between the apps and the network.

Some highly focused providers can offer enterprise-class SLAs today; and, eventually, all cloud providers will follow. Until SLAs become a common buy requirement for cloud services, there are tools available today to the enterprise to take control and ownership of application availability in the cloud.

One such tool is a tried and true method to manage application access, one that works just as well in the clouds as it does in the data center – application health monitoring. It involves checking the status of an application to make sure it’s up and responding as expected. The standard for application health today is to communicate actively with the application, routinely simulating a real world client connection and programmatically judging if the response is up to par.

One side effect of cloud computing is that it actually costs money to health check an application from outside the cloud. Health checks inside the data center are free; you can ping and make advanced monitoring checks (with large payloads) all day in your own data center and only have to worry about taxing the applications, not about paying for the resources used to check those apps. Apps in the cloud, however, don’t get any freebies. If you run routine app health checks to your cloud app from your data center (where your management platform lives), you may end up paying for CPU resources (the app will be spinning cycles to answer the health request), data transfer costs (such as asking the app to pull DB data), and bandwidth charges (sending in the health request and sending out the application response).

One way to avoid this is to move the health checks into the cloud as well, the same cloud network where your apps reside. Although some providers do charge for internal bandwidth between applications, many don’t (depending on how your cloud environment is configured). By running the health checks locally in the cloud and then only pushing out alerts when there’s an issue, you are able to limit your cost exposure. The downside to this solution is losing some real-world end user transactional data by moving artificial data requests inside the same network you’re trying to monitor. If there’s a failure getting to the app, your internal checks won’t necessarily see that (and your pushed notifications out may not make it to you, either).

Another option is to monitor passively real world application traffic as it moves in and out of the cloud network. No new application traffic is generated in this manner, but it does require that some type of application proxy be in place between users and the application. In a cloud deployment, passive monitoring would typically be handled at the same time as application delivery decisions are made, and can usually be performed by a virtualized instance of the application proxy that’s natively integrated with your cloud environment and applications. This is typically the preferred approach for internal and cloud-based application monitoring, yet it does require the most up-front architecture and design.

Eventually, PaaS providers and architects can begin baking in application health at the platform level, exposing critical health information to the cloud management platform directly from the application itself. At this level, the platform becomes self aware, connecting both the infrastructure and the application and will have the ability to push status updates natively. This model will allow both application and cloud developers to think about application health and SLAs from the design phase. Application health can be built in and exposed as part of the core system, maybe in the way of health APIs – developers can present the data to the platform that they feel is most critical to the health of their applications.

As the cloud matures and the line between the infrastructure, platform, and software services begins to blur, using the application as a gauge for SLAs makes the most sense. The app knows best how well it’s responding, and in the cloud it should become the key factor in full control over SLAs.

Alan Murphy is technical marketing manager of management and virtualization solutions with F5 Networks (News - Alert) (www.f5.com).