Service Virtualization: The Road to Simplification
My first attempt at writing this article failed miserably, mainly due to the fact that I have been involved with so many virtualization projects over the years that my first crack missed the basic questions which the article aimed to answer: What is Virtualization? Why is this term important to you, your organization, and potentially the livelihood and success of your project? Why should you care? Or, should you care at all? Or better yet, under what basic scenarios should you care?
As an architect, system or software, virtualization is very important to the overall architecture of your project. The main question you are asking yourself is, "How can a virtualized [fill in the blank here] reduce the risk of project failure and better ensure on-time and on-budget delivery?" As developers, you need to be aware of this methodology and players in the market to better develop your application. The main question that you as a developer is asking yourself is, "Will virtualization save you development time and shorten your project life-cycle?"
Let me start with the basics for those who are not familiar with the concept of virtualization.
Computer Science theory 1: when in doubt, add [yet] another layer of indirection.
That is all that virtualization does. This is nothing new really. You see and practice this every day as professionals in the field, when you write code, when you are setting up a network, and so forth. Polymorphism is the perfect example of code-level virtualization. For those of us who still like to write code, the name Virtual Functions has a certain ring to it: It is a difficult but very powerful feature that, when used properly, can save lots of coding time. The fact is that everything you have known to be true is one or more layers of abstraction of the underlying pieces (in other words, virtualization). You have seen the ever-growing popularity of the Virtual Machines over the past decade. You are somewhat familiar with the concept, and some of us have actually used a Virtual Machine or two such as the Java Virtual Machine or the Microsoft Common Language Infrastructure.
The fact of the matter is that Virtual Machines have been around since the mid-70's with the good-old IBM super computers (now known as the AS/400) having implemented one so that the software developed for the machine need not be tied to the proprietary hardware and processors of the time. Does this sound familiar to you? To me, that is exactly why the Java VM took off in the early 90's. "Write once—run everywhere" was the motto, if I recall. The same applied with the creators of the OSI stack: virtualizing the physical layer, or the network layer, or now and days the virtualization of the transport layer with Web services. Having covered the basics, you can turn to something more practical and useful. Before you do that, I wanted to add one rather important point. Virtualization can occur for any number of reasons and ways. You can virtualize your storage, your database, your data, your computation and services, and so on. For the purposes of this article, I will simply refer to these as virtualization, and won't distinguish one versus the other unless necessary.
Road to Service Virtualization
As you guess by now, the main goal of virtualization is simplification. Simplify access by users, simplify maintenance while in production, and simplify development for your developers. A service is a self-contained component, but what happens when you have a number of these services that need management and provisioning? As the number of these so-called services increase, so will your cost-of-ownership. One user might need a higher level of resiliency than others; one department might have a higher concern for security; the list goes on. How can you keep up with the demands of your users and still stay under budget? See how virtualization can help along this path.
The chances are that you have a number of services or better known as reusable software components running around your enterprise. As an architect, it is your desire to provide a one-stop access to these services, and maybe add a number of other ones as business requirements tend to change or grow. This will assist your developers with reducing their development cycle because they don't have to re-invent the wheel at every turn anymore and can simply access a remote service. If this sounds like Web services and SOA, it is because it is! The concept behind Web services is virtualization: of network protocols, software components, service interface, and so on. Web services virtualize network protocols by the use of the SOAP protocol; they virtualize software components by the use of UDDI; they virtualize access and use of services by the use of WSDL. There are other requirements, however, that can make your job more difficult as an architect or a developer. Most of these requirements will be part of your Service Level Agreement (SLA) between you—the service provider—and your users .
What if you could have a manger process that has a number of nubs and buttons that you can turn and twist for each user so that you can keep up with the user's demands? The users won't notice anything other than the fact that they are getting what they were promised by the service provider. This manger could potentially have different settings for security, resiliency, and so on. The access to the service itself is abstracted or virtualized by this manger that sits in the middle of the user's access to the service and the service itself. This service could simply be a database service, file storage service, a business process that is exposed as a Web service, or whatever else that you might need across your enterprise. The manger manages both the user and the service from a single point allowing you to gain access of your resources and usage.
There are a number of vendors that provide this manger-type that I just spoke about: DataSynapse with its GridServer product allows service virtualization like what you just learned, IBM and one of its many Websphere and messaging products virtualize hardware components such as servers, EMC virtualizes back-end storage systems, and VMWare virtualizes the OS layer along many others. The question becomes: What aspect of your enterprise needs virtualization and what is it that you are trying to achieve?
Directions to Service Virtualization
"You need to virtualize a resource if ..." You have learned about the road to virtualizing services. The question that I have not yet answered is, "Why is virtualization important to me and why I should care?" Let me emphasize here that this discussion is not a discussion around buy versus build; that discussion would be after you have decided to move forward with virtualization. You can purchase an off-the-shelf product that virtualizes practically any component of your enterprise these days, or if you do not like what is out there, you can certainly take on the task of writing one of your own. Before any of that, however, you need to understand the reasons why.
To me, the reason is very simple. I need to answer the following two questions:
- Do I need sheer performance from that resource? If so, can virtualization assist with scalability or that resource is a single point of the bottleneck?
- How big of an issue is managing that resource to me? For example, do I have a team to manage a single resource and that team is under constant stress and I am still unable to meet my SLAs?
Remember that virtualizing a resource is essentially adding a layer of indirection to that resource. This layer of indirection adds overhead and could potentially slow access time. That is why one needs to determine, before moving forward with the virtualizing, whether performance is a concern and, if it is, how can virtualization assist with scalability? Remember that virtualization can assist you with things like load-balancing the access, so performance can certainly be gained by virtualizing a resource.