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.

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.

vSphere 5: virtual networking revisited

One of the less touted features of vSphere 5 is the improvements in virtual networking. The visibility into virtual networking has traditional been a enigma in virtual environments. This was significantly improved due to the partnership with CISCO and the introduction of the distributed and managed switch options into the vSphere 4 environment.

With vSphere 5, VMware has started to support standard discovery protocols to allow more interaction between physical and virtual switching environments. In addition it is now possible to 'tag' and prioritize traffic in the virtual environment through QoS support.

VMware did not stop there in beefing up the transparency in the networking stack. You can enable NetFlow on a distributed to switch and pass it to a collector. This provides the opportunity to understand network traffic flow and bandwidth utilization between vms located on the same hosts, different hosts and between the vms and the physical environment.

Why is this significant? Many customers are now dealing with internal multi-tenancy issues in which virtual clusters are often the demarcation points between business units that are reluctant to 'share' resources. The visibility and prioritization allows the IT team to make policy based decisions to logically separate the environment and then demonstrate it through granular reporting all the way down to traffic flow. This allows them to collapse clusters of 'parked' resources that could be better utilized.

This is the same problem that cloud providers often struggle with. It is difficult to provide visibility into traffic flow down to the vm level. This in turn leads to issues in deriving SLA's that can be measured in real terms. Interestingly these features and the pain points they address are not well represented in the promotional material from VMware. I find this unusual as it clearly distinguishes the vSphere 5 platform from their competitors.

If you have not looked at these features yet, it is a good idea to give them a thorough review. As your environment scales, these technologies become increasingly important in ensuring you have end-to-end visibility and manageability of your virtual environment.




- Posted using BlogPress from my iPad