Tuesday, November 15, 2011

VMware’s vFabric; Enabling Application Development for the Cloud

vFabric aligns with VMware’s cloud strategy specifically around PaaS.  There are generally three types of cloud architectures recognized in the industry; Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and SaaS (Software as a Service).  VMware is the only vendor that has clear defined products in all three categories ready for sale. 

vFabric is targeted towards development for a new breed of applications, namely ones that demand Cloud scale.  Traditional application development makes planning for a burst in demand and a subsequent contraction not only difficult to resource but problematic when it comes to licensing the infrastructure.  Essentially VMware's targeted competitors force licensing on maximum utilization which makes it both expensive and inflexible. 

The development is all based on Java and specifically the Spring source platform which VMware believes offers significant flexibility over competitors like Oracle or IBM Websphere platforms.

The basic make up of application development has undergone an evolution; for example, even the most powerful of databases are considered bottlenecks when developing Cloud scale applications. Instead multiple individual database objects which live in memory and can be duplicated and scaled quicker running on a lightweight JeOS (Just enough OS) are used.

In VMware’s vFabric the SQL database objects (SQLFire) are an extension of GemFire. In addition vFabric includes production grade and tuned versions of Apache, Tomcat and RabbitMQ for messaging. In order to provide visibility, Hyperic is used to provide transparent performance management.

The value that VMware is promoting is enabled by licensing vFabric in a way that allows the combination of components to be quickly changed and reconfigured based on requirements. This ability, which is provided largely through infrastructure virtualization allows development to happen quicker using a new set of building blocks tuned for mobile on demand applications. This enables customers to go to market quicker than their competitors.

In addition to vFabric which can be deployed in-house on private cloud infrastructure, VMware offers CloudFoundry which is a provided as a PaaS Cloud Service. VMware sites a number of customer use cases that are largely based on applications developed for the financial industries which require real time information which have no tolerance for any delay.

Monday, November 7, 2011

Multiple Different Hypervisors; Should You?

From a service perspective, I have had the experience of delivering different vendor Hypervisors into a single customer environment. The original justification used by the customer was to reduce costs. What was quickly apparent though, is that the upfront cost benefit did not come anywhere near covering the increased operational costs and complexity experienced post deployment. In addition, neither one of the vendor management platforms was considered adequate by the customer; VMware's being exclusive and Microsoft's requiring integration of multiple solutions. Although Microsoft has gotten better, VMware is extremely good at managing their hypervisors. There was also a strong push back from the operational team once they experienced the management of a mixed hypervisor environment without a single targetted toolset to deal with both.

I suspect that the split in hypervisors happens as much for political reasons vs. real cost reduction. In the history of Virtual Desktop Infrastructure (VDI) the idea of having a server virtualization team manage desktops has typically been an under considered decision by IT teams. The server virtualization team is eager to approach the new technology but less eager to adopt desktop support. This is the stake that is wedging a 2nd hypervisor into the mix. IT teams force separation of servers and client side virtualization onto separate platforms to ensure ownership by one group or another.

The 2nd pressure I believe is cost justification. I recall being at a Financial firm when they introduced IBM blades in addition to HP blades to reduce costs. The capital costs savings was offset by the operational overhead in supporting the two platforms. As the support cost was a soft cost and not visible in a single bucket the executive 'cost cutting' decision carried the day and we became a dual platform environment. I believe that from an accounting perspective the organization did benefit from having two vendors in play when it came to renewal but the overhead was definitely felt by support.

When introducing an additional virtualization vendor you must consider what the true benefit is from running a mixed hypervisor environment?

  1. Cost; Capital vs. Operational?

  2. Should you have different hypervisors for virtual desktop and servers?

  3. What is the benefit of avoiding vendor Lock in?

What are the road blocks you will likely face in implementing a mixed hypervisor environment?

  1. Current Maturity of Toolsets

  2. Cost and benefits of having not just two hypervisors but perhaps an additional management platform

  3. Do your virtualization vendors provide a single point of management or is another software product required?

There can be many benefits to running a mixed mode environment. It is important to consider the decision carefully to avoid adding complexity without any return on the investment.