Many of those surveyed place great value on SLAs (see "SLA Benefits,"). However, SLAs grow more valuable the more precisely they are written and measured. That's where marking and measurement come in. Marking in SLA parlance means the identification of specific services through the network. In this context, measurement means monitoring the marked services.
If an agreement is not written so that work performed as part of the service can be identified and counted, how can you know if you're getting what you paid for? Precise measurements let you confirm to your users and upper management that you have delivered value for the money spent. The more precise the marking and measurement, the more likely you are to know if the service covered by the SLA is meeting your business objectives.
How can you achieve a precise accounting? By marking and measuring the service by traffic or application type. There is a consensus that when you can identify and control services by application type you are in a far better position than when you cannot. There are two basic approaches employed by enterprises.
One is to employ technologies that identify different types of network traffic. In "How Services Are or Will Be Marked", we see that for those that do mark traffic using the technologies listed, the most common service marked is Web services via URL identification. Note that only 23 percent of the respondents use the techniques shown in this figure.
The problem here is twofold: Technologies for identification of services on a network are usually complex to configure and monitor. And unfortunately, there are some services that are not easily pigeonholed or even distinguished on the network. For example, would all voice over IP traffic be important or only that traffic between specific places? The configuration and monitoring associated with this level of specificity could be overwhelming.
Also, many of those surveyed said the separation of services and their metering and monitoring are problems. While companies value information based on application type, for example, they have not for the most part invested in technologies like DiffServ (Differentiated Services) that can provide that data. Instead, they tend to provide dedicated network components and application servers for mission-critical applications.
This brings us to the second, tried and true approach: over-provisioning. Put important services on dedicated hardware with more than enough capacity to do the job. In some cases traffic is run over lines that do not share any other service traffic, which gives you even more control. This approach is also commonly used to guarantee that important services remain up.
While over-provisioning vastly simplifies service-level monitoring, there is a tension between these two approaches. The first model, which typically employs complex technology such as DiffServ, can be expensive to configure, monitor and manage, while the second approach requires a hefty investment in hardware and costly dedicated bandwidth.
Making the choice is difficult, but not impossible; you need to break down costs so you're comparing apples to apples. Cost factors when considering over-provisioning are cut-and-dried: cost of the hardware and incremental bandwidth, and configuration cost of additional resources.
On the other hand, using one or more technologies for controlling traffic on the wire can save bandwidth, server and other network expenses and ensure that your network resources are indeed used for their intended purposes. The drawbacks to this approach include more complex configuration and ongoing data collection to ensure your SLAs, and personnel needed to make this more complex environment work.
Another way to look at this is to evaluate the types of monitoring and measurement necessary to support your SLAs. You'll end up with a cost analysis of over-provisioning versus "high-tech" solutions. Over-provisioning usually wins thanks to the complexity of new technologies, even though the over-provisioning approach may not scale as more and more enterprises use their networks for mission-critical applications that have SLAs associated with them. It is also true, however, that DiffServ and its ilk, while found in some new devices, such as Cisco routers, has a way to go before it can be effectively managed. It's just too complicated for many. Two examples put this into context: In implementing QoS (Quality of Service) within a campus setting, over-provisioning, especially with the coming of 10 Gigabit Ethernet, is a valid strategy. However, when the resource in question is scarce and costly, like WAN connectivity, traffic management may be worth the overhead.
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Download Today
REPORTS
ANALYTICS
Follow 
