In-Depth
Will This be the Year of Storage SOA?
How much noise will users have to make to get vendors to listen?
In this inaugural 2006 column, we turn our attention to one of the “hot topics” in IT—Service Oriented Architecture (SOA)—as it pertains to storage. If you haven’t been thinking about SOA until now, get ready for a blitz from storage vendors, many of whom have taken to re-spinning their marketing messages around the increasingly popular acronym.
While EMC, IBM, Network Appliance, and others have jumped on the bandwagon in their storage speak of late, SOA is actually as old as the hills. As originally conceived, it was shorthand for the straightforward tenet of good IT that infrastructure should be built with the requirements of applications in mind and should provide appropriate services to applications—with “appropriate” defined by the application itself and the business milieu in which it operates. That was Data Processing 101 stuff when I was in school.
Over the past decade, the idea of SOA took root in many companies more as a function of expediency than a quest for architectural excellence. For example, when IT planners confronted a need to keep older infrastructure in play when faced with new technologies, they often leveraged middleware and other components that originated in the world of Service Oriented Architecture. Web application servers, for example, were introduced, in part, to preserve investments in legacy hosting platforms in the new Internet Age. In effect, SOA became synonymous with middleware tools and Web services—a corollary to the axiom, “If it ain’t broke, don’t fix it.”
For other companies, interest in SOA was spawned by a desperate need to integrate the newly acquired infrastructure (especially databases) of another company with production IT following a business merger. The thinking was that if you could cobble together some sort of combined user interface for data entry, use some kind of middleware to normalize the output from disparate applications, or simply enable an electronic data exchange on a routine basis between system back ends, you could meet business service-level requirements while buying yourself some time to plan and budget a formal consolidation. This remains a big driver of SOA, especially in companies that are consolidating infrastructure to reduce complexity as well as management expense.
Software vendors have contributed to the “dumbing down” of the idea of SOA, making it sound like a product rather than the set of infrastructure design techniques it is. “SOA in a box” has long been the mantra of customer relationship management (CRM), enterprise resource planning (ERP), and manufacturing resource planning (MRP) software products. The main idea of the marketspeak is that deploying a suite of application software linked together by middleware can completely eliminate costly and time-consuming design and integration problems.
Michael Alvarado, an independent IT consultant based in San Jose, CA, summarizes the situation succinctly: “All the big players in the software market today claim to have a solution to all your business problems, whether it is a front-end customer relationship management solution or the back-end manufacturing resource planning solution. In essence, they seem to claim they are the one-stop-shop for all your business problems and they claim to be the best solution out there.”
The problem, according to Alvarado, is one of integration. First, he argues, there is no single solution that is “best of the breed” in every aspect of the business software.
“If Siebel or Salesforce.com shine as a CRM solution,” he notes, “SAP has unique benefits in the ERP software, Selectica has the best Configurator solution out there, and somebody else might have the best prices.” At the end of the day, businesses must choose from among a handful of software suites (some of which include modules or components that are decidedly less than best of breed) and then undertake the customized integration of these products with existing applications that might not be supported out-of-the-box, such as homegrown apps or less popular products from third party software vendors.
This has led to a new meaning for SOA, Alvarado says: standards-based inter-application middleware that enables peer-to-peer communications between disparate parts. He notes, “SOA addresses the problem of integration by [facilitating] open-communication using standards and protocols like XML, Web services, and service registries.” While this has helped with some of the application and database integration issues, it has generally produced solutions that are very domain-specific, such as the various service-definition repositories specific to different industries.
So, what has all of this to do with storage? Maybe everything.
Storage remains the red-headed stepchild of SOA, often because storage is itself regarded only as a peripheral device connected to an application-hosting platform. Despite a decade’s worth of development in “networked” storage architecture—beginning with the appearance of NAS appliances and continuing with Fibre Channel fabrics and burgeoning IP SANs—storage components are still not considered as peers in a peer-to-peer service-oriented environment.
In their defense, the most prominent SOA theorists have not needed to concern themselves with storage up to now. Early “networked storage” offerings, such as NAS and FC SANs, have been little more than server-attached arrays writ large. With the advent of IP storage, however, this is bound to change.
Storage, like any other costly infrastructure layer, must bow to the realities of price and performance. The utilization efficiency of storage infrastructure—a ratio of cost and capacity and the type of data stored on a storage platform—remains abysmally poor in distributed environments: under 20 percent, according to Fred Moore, founder of Horison Information Strategies in Boulder, CO. Allocation efficiency, how well the sheer volume of data is distributed across storage platforms, is improving with the virtualization of storage infrastructure, but it is still well below that of mainframe DASD farms.
These statistics reflect two things. First, the concept of a real SAN—a peer-to-peer network of storage and server platforms—has not yet materialized. What we call a SAN today is a channel fabric, which supports the automated (de)allocation of resources and automated management of data movements only on a very basic level. Second, we lack a sufficient understanding of applications and the data that they create and use to create a truly intelligent or policy-based engine for managing resources or data movements.
In storage terms, SOA means realizing the original value proposition of SANs as articulated in circa 1997 Compaq Corporation white papers that described ENSA: Enterprise Network Storage Architecture. ENSA envisioned a true storage network featuring an any-to-any relationship between heterogeneous servers and heterogeneous storage devices. What’s more, the SAN would be vested with sufficient smarts to give applications not just “a drink of storage” but the specific quantity and type of beverage that the application required for optimal performance. For that to happen there will need to be significantly more embedded intelligence, and much better communication between applications and storage infrastructure, than the so-called SANs of today are capable of supporting.
SOA principles ought to be paramount in storage design today. We need to start at the beginning, with the business processes and applications themselves, to understand data. Developing application-specific data profiles that cover everything from frequency of access and update to security requirements and retention periods and criticality need to be created. Then we need to understand what those profiles mean in terms of provisioning (where we write the data and how we migrate it over time) and protection (how we replicate the data to prevent loss and secure it from disclosure) services.
That done, SOA would have us configure both applications and infrastructure to communicate with each other on an ongoing basis in order to better manage resource supply and demand. An intermediary service layer might be required to translate requirements into actions—one of the original goals of CIM/WBEM/SMI at SNIA. This intelligent service layer could then be used to realize the goals of allocation and utilization efficiency in storage.
The need is abundantly clear. Getting to success, however, is going to require finding a way to get the industry to work and play well together. This can only be accomplished by a user community that makes demands in a clear, united, and very loud voice.
Will storage SOA happen in 2006? The real question is whether users will find their voice in 2006, which in the final analysis amounts to the same thing.
Your comments are welcome at [email protected].