PaaS with choice: Motivation for VMware to acquire SpringSource

VMware announced to buy SpringSource yesterday. SpringSource had been a technology innovator focused on the application-centric areas rather than on the hardware-infrastructure focus. Their employees were thought leaders in Apache Tomcat, Apache http server, hyperic, Groovy and Grails. SpringSource’s obsession has been simplifying and automating the build-run-manage lifecycle that all applications go through, and they have done so by attacking similar pockets of complexity. They bring this complexity-busting focus to several areas… high-productivity developer tools and frameworks, lightweight application server runtimes, and application management and monitoring. The end goal is very similar; attack the time and money spent on application complexity and maintenance tasks, shifting the focus to new and more reliably deployed applications.

VMware feels SpringSource enables an evolutionary path for application developers to reach end goals without requiring complete infrastructure or application rebuilds.

Ultimately for VMware the end goal is on vCloud which is aimed at IT applications, not infrastructure - there is an extensive application flavor for the cloud to provide these key features. SpringSource would definitely enable VMware in preaching the right solutions to VMware's customers:

1. Elasticity: automatically scaling up and down the infrastructure to meet the needs of the application
2. Multi-tenancy: being able to isolate resources and applications from one another in a shared infrastructure
3. Simplified provisioning: Isolate the developer from worrying about how is code gets installed and deployed
4. Self-service: allowing developers to gain access to their development infrastructure at any time, in many cases to circumvent the processes and inefficiencies of their typical IT service request processes.
5. Rapid development: go from code to cloud in a matter of minutes, particularly during the development and test phases
6. Simplified (or invisible) management: PaaS offerings typically have built-in application availability and performance management

Topology for Inter-datacenter VMotion

An often asked question in any of the vCloud discussions is about the probability of vMotion across data centers (over wide area network) - it is not an easy thing considering the latencies. The complications are both in terms of stretching the L2 domain between the sites and the shared storage issue across sites.
What are the business requirements for inter-datacenter vMotion?

1. Load balance/Go-green to save power: “follow the sun” or simply consolidate VMs to conserve power.
   
2. Uptimes during maintenance windows: Have a fallback plan for your applications to be available during datacenter shutdowns
   
3. Disaster Recovery/avoidance: This is an obvious reason, to fallback during DR situations

Compared to #2 and #3, #1 could be higher priority as that also gives a provision to use someone else's (like AWS) data center for peak loads (like month end report generations) instead of building up in-house data centers.

Overall, this initiative would lead to consolidation in data centers slowly and bigger players would benefit. Below is the topology of vMotion that would be demoed at VMworld, jointly by Cisco & VMware.