The biggest psychological shell game to most SLA’s is the uptime reflected in how many 9′s after 99% do you have, rather then the combination of the trigger how many 9′s after 99% and what do you actually receive in the case the 99.99% uptime is violated. One is a trigger for the other, however most organizations focus on the trigger but not the actual amount of compensation if the trigger is exceeded.

Compensation typically ends up being a days worth of credit or at best a months worth of credit, both of which do not come close to covering the cost of losing services or hindering your business due to a service outage or degradation of several hours or days. Where SLA’s become more important is to set a baseline of what is expected from a service. Though compensation typically is nothing compared to the impact of your business, what is important is that if SLA’s are repeatedly violated you can negotiate out of a service contract, or negotiate better pricing for the service moving forward. Most businesses realize that when they violate the SLA they set, that you will leave at the end of your contract or immediately which impacts there revenue moving forward. Simply put some money is better then no money and as long as there is some margin of profit they would rather keep you then lose you. This is where collecting data over time is important.

When you collect data specifically from a third impartial party you then begin to build your own baseline of reality in regard to service uptime. This helps you in two ways, one by giving you the understanding you are getting what you pay for helping you make decisions on what service provider to use or not use, and two to use the data for negotiating purposes and concessions. Now instead of getting a one day or one month credit on your account that is insignificant you can possibly renegotiate a new service contract at a significantly lower rate which might equal 4 months of credits continually year over year.

The key is to let the data enforce the SLA. Data does not lie especially if collected from an impartial unbiased third party. Most organizations fail to keep the service providers they are using honest, and often times do not realize SLA’s are being repeatedly violated. A service such as Systems Watch helps you get an understanding of whether an SLA is being violated and offers a level of transparency in regard to the services you use. So the next time your read over your Service Level Agreement keep these points in mind.

Classic data center deployments provision resources at a lot slower pace compared to cloud resources and typically only increase by a fixed number of resources that have a pre-determined capped amount. Cloud resources however are elastic and increase and decrease within minutes to a virtually infinite degree.

Current mature monitoring techniques depend on fixed well described resources that rarely ever change and are pre-configured ahead of time with both a client agent and a monitoring server from which the monitoring server is made aware of what to monitor ahead of time. This poses a challenge in the cloud arena for instance when EC2 compute resources provided by Amazon Web Services are not necessarily fixed and can be spun up from an image at will to scale to meet resource demand then immediately spun down after the job is handled.

In the cloud computing world you may end up monitoring a server you do not know the hostname or IP of. Often times the hostnames and IP’s are procured from a pool of addresses and could have been owned just minutes before by an entirely different company. Monitoring in this situation can inhibit your operational process, in that you can spin up more resources immediately but you need to then prior to putting them into production configure monitoring manually for them. Another option is to just rely on monitoring the fixed load balancing VIP for the service port which is not necessarily very insightful.

Other hurdles in monitoring cloud resources are that you have at times no idea where the cloud resource is physically located other then a general geographic location. So when determining routing, you cannot necessarily count on the transparency your own physical data center provides from which you have a direct relationship. You then have to deal with an abstraction layer of the cloud provider which can in itself be a bit slower in explanation or remedy.

In the case of a hybrid cloud to data center interaction, a large amount of architectures have a fixed database resource layer at the physical data center and a elastic application layer from which to scale in the cloud. Routing between the physical data center and the cloud provider over the WAN then becomes very important.

The general thought is that cloud computing (utility computing) is a great resource tool to have for the right situation/application/architecture. However new monitoring methods need to be architected to become more dynamic and less dependent on pre-configuration to meet the ever growing demand of this new era of elastic resources. Auto discovery of resources for monitoring and trending route performance on a geographic scale becomes vital to understanding the health of you systems. With the adoption of cloud computing it is both a scary but exhilarating challenge, but one thing hasn’t changed and that is the need for transparency into your systems and networks.