Sidenote: BEA World and SLA

I didn't get a chance to post last week, primarily because much of the week was divided between the usual POC planning scramble and attendance/exhibiting at BEAWorld2006 in San Francisco. I took notes from some of the Wed. morning keynotes, and I thought I'd share the biggest observations here.

Mark Carges, Executive Vice President, Business Interaction Division, spent an hour talking a little about JRocket and WebLogic RealTime, and a lot about Business Process Automation and Enterprise Service Buses. His primary focus seemed to be to introduce BEA into the "Process as a Service" space, as well as an interesting focus on the on-line, ad-hoc collaboration space (aka "Web 2.0"). They had some cool WIKI/forum/identity tagging tools, for instance. Check their website for BEA Enterprise 2.0 and Workspace 360 if you want to know more.


The "expert panel" discussion included Rob Levy, BEA CTO; Cliff Booth, VP of Enterprise Architecture; Paul Patrick, VP and Chief Architect of Aqualogic; Larry Cable, Chief Architect of WebLogic; and Annie Shum, VP and SOA "visioneer".

The best thing to come out of this discussion was the observation that SOA and BPA are driving organizations to involve their operations groups much earlier in the development/deployment game. The primary reason seems to be the need for innovative infrastructure planning to support dynamic needs. Sound familiar?

I even asked at a later "SOA Reality Check" session where the featured BEA customers saw operations in their development/deployment cycle, and both were very adamant that they are now being forced to consider infrastructure much earlier in the game, not because they need to acquire hardware for each new service, but precisely because it is too expensive to do so.

All in all, a good show. Still a year or two away from SOI and SLA dominating the conversation, but signs that things will get there.

Service Level Automation Glossary

No decent glossary for this subject exists on the web, so here is my stab at the basic terms of interest:

Service - Any function provided by the IT organization on behalf of any "customer", including internal business customers and external revenue customers. In the context of SLA, a service is typically a software application component delivering functionality to humans or other software components.

Service Level - Any measurement of how any component of an IT organization or its infrastructure is performing for its customers.

Service Level Goal - A target or limit measurement against which actual service levels are measured. Typically, service level goals are used to contstrain the acceptable value (or range of values) at which service levels are considered acceptable.

Service Level Automation (or SLA) - Digitally managing IT resources to service level goals without the interventions of humans wherever possible. Adjustments can be made to the deployment, capacity, or configuration of IT applications and infrastructure as needed to meet these goals.

Service Virtualization - Technology that decouples a set of functionality (a web service, an application, etc.) from any of the computing resources required to execute that functionality, regardless of whether those resources are themselves hardware or software.

I will update this as I go, and repost it occasionally. Please feel free to comment on this post with suggestions for terms and/or definitions that should be covered.

Service Level Automation Defined

What is it that businesses really want from their IT organizations? Bill Coleman tells the story of the CIO of a Fortune 500 Silicon Valley firm that put it this way:

"I measure myself on only two things, how many quality services I provide to my business, and how cheaply I do it."

The guts of what IT is all about is service levels. Each organization establishes--either explicity or implicitly--target goals for how IT resources will perform to meet business objectives. Service level goals can be made for any measurable trait of the IT infrastructure, including value, utilization, quality, performance, availability and cost (both to acquire and to operate). These goals can be set at a technical level (e.g. CPU utilization, transactions per second on a database, etc.) or business level (e.g. number of orders processed per day, percentage of orders resulting in a complaint, etc.).

Now, computers are supposed to automate the functions and processes required to meet business objectives. So, why are there so few solutions for optomizing IT processes to meet these same objectives?

A big part of the problem is the tight coupling of software to hardware that I have discussed in several recent blogs. If its expensive to realocate resources to meet new business needs, then we will tend to minimize the number of changes we allow in the datacenter. Optomizing anything manually takes weeks or months of planning, and is usually too little too late anyway.

There are a variety of point solutions to specific steps in the IT process. Provisioning is a good example, as is trouble ticketing. However, none of this automates anything based on meeting service levels, they just cheapen the human processes already in place--processes that tend to be focused more on saving an individual time than in optimizing the datacenter as a whole.

Focusing on adjusting the environment to meet business goals takes a whole new way of thinking. Decoupling software from hardware, etc., is a first step. Once we've done that, we need to leverage relatively recent technological advances that allow us to delivery the software to the hardware in an automated, optimal fashion...

Decoupling software from hardware: a story

Imagine two companies merging into one—two production datacenters, two sets of architecture standards, and two unique installed software baselines.

In any modern corporate merger, one key element of success is using economies of scale to boost the value of each company’s technology property. To achieve this, the combined organizations’ applications must be deployed into the most cost effective operations environment possible.

How would you handle this in your company today? My guess is that your applications remain tightly coupled to the hardware systems they run on, so moving applications also means moving hardware. Achieving an efficiency such as consolidating the combined company’s IT to one datacenter is insanely expensive, as you not only have to deal with the logistics of moving the hardware from location to location, but you have to:

• Find real estate, power, air conditioning capacity, and expertise in the surviving datacenter to support the relocated hardware.


• Configure the surviving datacenter’s networks and storage, as well as the relocated software payloads (including application, middleware platform (if any) and operating system) to allow the applications to actually work.


• Begin the arduous process of consolidating the software stacks of both the indigenous and relocated applications, including porting applications to approved platforms, resolving functional overlap between applications and integrating functionality to meet business process needs.

The unfortunate truth is that that you would put together a large scale project plan involving thousands or millions of dollars for logistics, datacenter capacity and human resources. The capital and operational expenditures would be overwhelming, and this project plan would take months—possibly years—to implement. What an incredible burden on the success of the merger.

Now, consider a model where both company’s software is decoupled from the computing resources they run on. In the ideal example, the application and data images from the decommissioned datacenter would simply be moved into the surviving data center and executed on available computing capacity there. As the granularity being relocated is applications (or even individual services), these components can simply be deployed on the OS/middleware stacks already supported in the surviving datacenter. The business owners of the relocated applications don’t care what platforms the application runs on, as long as they run.

If OSes or middleware need to be migrated as well for technical or business reasons, they too can be simply delivered in portable software payload images that can be simply allocated to computing resources as needed. In fact, each layer of any software stack can be managed and delivered as a separate, portable “building block” that does not need extensive installation or configuration to operate on completely new computing resources.

If additional capacity is needed to support the relocated applications, only the number of systems required to provide that capacity would need to be moved. Only a fraction of the excess capacity from the decommissioned data center would need to be shipped. The rest could be sold or discarded. In fact, as both the surviving and decommissioned data centers would have their own excess capacity for load spikes, failover, etc., it is possible to reduce the number of computing resources in the combined datacenter just by consolidating that excess capacity. (Excess capacity includes unused CPU time, memory, storage and network bandwidth.)

Granted, this ideal is far from being realized (though all of the components are there in one form or another—more about that later), and there are additional fixed costs associated with decommissioning a datacenter. The cost of supporting the relocated software in its new home is also a constant. However, think about how much money was saved in the above example. Think about the amount of time and pain that was removed from a datacenter consolidation effort. This is just one example of the advantages of decoupling software from hardware, operating systems and middleware.

Next I'll talk about what technologies are contributing to decoupling software from hardware today. I'll also connect all of this to the subject of this blog, service level automation. Stay tuned...

Loosening the Bonds Between Software and Hardware

Why is software still so tightly coupled with hardware?

The days when the applications run on a computer provided their own system control software are long gone.

We have introduced operating systems to allow applications to be built without specific knowledge of the hardware it will run on.

We have created software layers to separate the application from the operating system in the quest for write once, run anywhere.

Our operating systems have gotten more intelligent at delaying the coupling with hardware to the last second. Case in point, most *NIX installations can be moved from compatible bare-metal server to bare-metal server and booted without modification.

Lately, we have even introduced a software layer between the hardware and the operating system to allow any operating system to be decoupled from its hardware. (Though now the OS is coupled to virtual hardware instead.) This is critical in a non-portable OS like Windows.

Yet, despite all of these advances, most of us use the following deployment model:

• Take a new server (or remove an existing server from user access)
  
• Install an OS (if its not there already)
  
• Install any libraries and/or containers required for the application(s) (if not there already)
  
• Install/upgrade the application(s)
• Test like crazy
• Put the server in the data center (or allow user access again)

Once this deployment is completed, that server is forever hosting that application or its future upgrades. Almost never do we actually repurpose a server for another application, because the cost of doing each of those steps listed above is so high.

Now, to be fair, virtual server technology is allowing us to be more flexible in how we use physical hardware, as we can move OS/container/application stacks from one machine to another. But I want you to note that this requires that each physical server involved be loaded with a hypervisor for that VM technology; in other words, the physical server remains tightly coupled to the VM environment, and can only be used for VM hosting.

(I've always wondered why we are working so hard to move our systems to commodity physical hardware, but are just fine with deploying those same systems on proprietary virtual hardware, but never mind.)

Ideally, I would like to see us have the capability to move software stacks across physical resources without making those physical resources dedicated to *any* single software technology. In the Linux (and other Unix flavor) world, this is actually somewhat possible, but we are a long way from this in the Windows world. Its going to take standardized HAL (Hardware Abstraction Layer) and power management interfaces, OSes that can adjust to varying hardware configurations, and will ultimately require operations automation tools to take full advantage.

Stay tuned for a vision of what the world could be like if we achieved this level of decoupling...