Server OEMs tend to be missing part of one index finger because they tend to tap it on the table and say, “This year the blade computer will take off.” It hasn’t happened yet, but virtualization just might be the reason why they might finally be right.

Blades are a very interesting type of system. More than a decade ago, they were the big buzz in the industry. The idea of discreet computing resources allocated independently of each other, with great flexibility in scalability, and providing the ability to mix needs and prices accordingly was very promising. In the end, the market has seen that the only way to fully realize the potential of a blade-based environment is to have a fully saturated rack of the devices.

Today, however, a new picture is taking shape. A company embracing private cloud computing, with a need for a high-density datacenter as their architecture, can easily benefit from blade servers. In other cases, traditional rack-mounted servers are a better option. For example, a single rack (using DELL’s 600 series) could host between 3000 to 5000 VDI sessions in theory (scalability estimated using 6 to 10 instances per core; depending on the number of simultaneous applications per instance, the networking and storage architecture will most likely reduce the number ).

In a recent conversation with Rob Mallicoat from Quest Software (www.quest.com), he mentioned an interesting model his company has been working on, managing blades to address the limitations of traditional desktop virtualization approaches.

Desktop virtualization refers to the use of virtualization technologies for session virtualization (Terminal Services), application virtualization (application sequencing), or hosted desktop systems (VDI), and possible combinations of these technologies. In Microsoft’s world, this would be RDP, App-V or Hyper-V as options.

Application compatibility is a limiting factor in many of these solutions. Not all applications work well in a session virtualization environment or they can’t be sequenced. VDI solves many of those problems, but it has limitations on performance due the added layers provided by a hypervisor and limits on the number of VMs per core available in the physical machine.

What Rob has done with some of his customers is to have a full rack of blades, with a different operating environment per blade if needed. Rob lets the end users connect to this environmetn via a thin client session (like Remote Desktop on Windows).

On the negative side of this solution, we have the cost per blade, many OEMs build them as servers, and then it is a solution justified by a high-performance requirement. Once you select a manufacturer, you tie yourself to them for the full rack.

The benefits of this approach are:

• There is no application incompatibility; applications are running in a full OS and system environment.
• There is no performance penalty; the OS is running on bare metal.
• It is ease to reach a full rack situation, so the economies of scale start to pay off for the blade architecture.
• Since you can mix different types of blades and add resources independently, you can scale each user’s environment according to their specific needs (more cores, memory or disk, different CPU architectures or OS).
• There is centralized management of high-performance systems
• There is “cloud” enabled access.
• You can mix server, full desktop, and virtualization solutions in a single rack.

That last point, I think, is the one that makes the solution attractive: As applications evolve to be more virtualization friendly, blades can be re-purposed as needed.

I have been listening to the announcements from different vendors about how they “get” cloud computing and how each is the best vendor to drive it. It’s interesting to see how many of those messages are rich in “benefits” and claims about each vendor’s magnificent management tools. Yet there is little substance on why (not how) to use cloud offerings, nor on the processes you need to enable the transition from decentralized operations to a centralized, off-premises, or hybrid, model for cloud computing. However, there is already a model that has been around a long time: Despite its flaws, the IBM Systems Network Architecture (SNA) may be one of the best examples of a managed end-to-end architecture for distributed, cloud and on-premise solutions.

With SNA, everything, from the communication paths to inter-process communication, was defined and monitored in a hierarchy of physical and logical units. When something failed, it was possible to follow the track along the different components to know where the problem was. This was not an automatic process. But IBM created a resilient system and paired it with a quite extensive library that explained how to operate and keep the behemoth alive and well.

Then came the first economic shift, mini computers (DEC VAX, HP 1000 and 3000 series, IBM AS/400, for example) came to life and started to break the tyranny of the datacenter, not only by providing cheaper and simpler systems, but also by unlocking the communication paths for new and more flexible protocols.

Finally, the big revolution happened. Computing power entered the free market, running on top of a socialized network (thank you, DARPA). This revolution produced the personal computing world, with its easy-to-access resources, but also a communications model that was open to everybody.

The bad side of this accelerated change was the decline of the well-managed datacenter philosophy. The decline in itself was not a big problem. The horizontal scalability at the core, coupled with the decentralization of the middle- and lower-tier components of the architecture ina distributed network made failures on one side less costly or too far removed to justify fixing them in person. Problems were solved either by adding more hardware or applying a patch or service pack.

As more layers of the application moved to the end points, and these grew in numbers, remote management tools appeared. Their goal was mostly to continue the patching process, not to solve core issues.

Soon the problems with this approach started showing up in the form of cyber-attacks: An unmanaged system is the door to your or your company’s bank account. I should point out that social engineering attacks (like knowing a friendly and trustworthy Minister in Nigeria) are a separate issue.

In response, today, we are moving toward a regulated computing model. Resources arebeing  brought back into a managed datacenter environment, taking advantage of low cost (as compared to mainframes) hardware, an open set of communications protocols, and access interfaces between services, processes, and end users ona myriad of devices.

In other words: Welcome to the Cloud.

One attractive promise of the cloud environment is the return of the hierarchical model, which brings back end-to-end monitoring. The error is to rely on technology to make it happen, following the bad habits of the old free-for-all model.

Back in the ancient times of computing, mainframes were great, and the processes around them were even better. I suggest that we need to look back at the way we did things in those old days and adapt them to today’s needs. So the first step an organization needs to take in embracing cloud computing is simple: You need to review your existing operational procedures, policies, and regulations. Look for gaps and start building a catalog of services and processes.

A good place to start is looking into existing information—frameworks like the Control Objectives for Information and Related Technology (COBIT) or the Information Technology Infrastructure Library (ITIL), and the IBM Redbooks library. There is no need to apply the new operations procedures to the old architecture, but knowing the need and planning for it in preparation for the move to the cloud will result in more efficient cloud environment.

For more information, here are some links (thank you Wikipedia):

IBM Redbooks library: http://www.redbooks.ibm.com/

IBM SNA: http://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture

COBIT: http://en.wikipedia.org/wiki/COBIT

ITIL: http://en.wikipedia.org/wiki/ITIL

When is it time to change your IT platform? How do you decide if a point solution in your architecture should follow your current vendor offerings or that it’s time to add something new? Let me give you my perspective on this important question.

I recently worked on a project for a large company that was considering upgrading components and services in its infrastructure portfolio. The issue was whether to expand the footprint of the existing vendor’s solutions or replace some technology with a third-party solution that would eventually replace large portions of the infrastructure.

From the technical point of view, both possibilities satisfied the need. So that area was irrelevant in the discussion.

Investing more in a particular platform would increase the size of the company’s datacenter and consequently increase the desktop footprint. This translates to a higher cost of moving away from that platform. 

The cost comes in two areas. One of them is operations expertise and training: The more I have of one vender, the less I will know about the intricacies of another solution. In addition, if this is a solution that involves desktops, the cost of training end users on new systems will also grow.

Another cost comes from implementation when you’re replacing an existing solution (the cost of implementation for both solutions per se is a given). Replacing a datacenter solution tends to be simple, particularly in a cloud computing environment (for example with a hosted services provider), where little or no touch to the end users’ environment may be required.  When it comes to the desktop, even with centralized configuration management tools, the cost can quickly add up.

Therefore, at this point, keeping the current vendor and expanding the footprint seems like it may be the right direction. Of course, there is the long-term penalty of being tied to the platform, but in the short term, it makes sense as a cost-conscious solution.

So what other factors can aid in the decision? Use the value equation, where value equals the benefit of the platform divided by the total cost of ownership (TCO). In this case, the analysis differs from a traditional value case in the sense that we want to understand the benefits of replacing a dominant infrastructure vendor on our platform.

TCO is an overused term. Every single vendor claims its platform does better than anybody else’s. Here, it simply means “my cost of operations in the current environment.” If that cost constantly crosses above my replacement cost (as described above), the time has come to replace the platform.

Now, it’s obvious to say that, in a perfect world, the new solution would have an equal or better TCO. However, the cost of adding more to the existing platform and therefore creating a deeper dependency on a single vendor may offset a less-than-desirable initial TCO with the new solution. 

Benefit is more elusive, since as I mentioned before, both solutions were technically speaking equal and both satisfied the business needs IT asked for.  This is where you need to do a business analysis of the vendors that are looking to provide the solution. You need to get answers to questions like the following:

 ·         Where do I go for additional technology components?

·         Who provides support or licensing terms or models?

·         What is the supplier’s business viability?

You need to think about such considerations from a long-term point of view. Thinking this way provides reassurance that whatever your decision is, especially if you’re switching, you will not create a problem when you expand the new platform.

In summary, as indicated, pure datacenter decisions are easier. You may already have an unequal mix of vendors in place, and in that case, the effects of migration can be limited to the IT organization.  It is in the best interest of the vendor—and not yours—to expand the footprint, increasing the cost of replacement and locking all other solutions out. Multiple platforms imply a more educated (and expensive) IT staff, but this cost can be offset by having a broader set of technology options to choose from (and more negotiation power). On the other hand, when end users are involved, the cost of training them may surpass any benefit. This can be an argument, then, in favor of private cloud computing, centralizing services and applications into the datacenter while standardizing the user interface into a browser.