Hi Everyone,
I'm extremely excited to announce VMware's intention to acquire SpringSource, a 5 year-old company rapidly becoming a leader in enterprise and web application development and management. The goal of this blog is to explain the complementary benefits of this merger to longtime VMware fans as well as to the vibrant Spring community who may know less about us. First, a quick introduction to SpringSource...
SpringSource began as the commercial development team leading the innovative Spring portfolio of open source projects, an effort focused on providing a simpler, lighter-weight alternative to the Java EE (J2EE) standard. Led by Rod Johnson (author, enterprise java authority, and SpringSource CEO), Spring has become the de facto standard programming model for modern enterprise Java, rich web, and enterprise integration applications. Over the last couple of years, SpringSource has expanded their purview across an even broader range of offerings, employing the thought leaders within the Apache Tomcat, Apache HTTP Server, Hyperic, Groovy and Grails open source communities.
(Read Rod Johnson's Blog Poston the SpringSource blog .)
A Common Mission: Simplify IT
Since our founding 11 years ago, VMware has focused on simplifying IT; removing the rigidity baked into today's desktop and datacenter infrastructure to save on capital and operating expenses while simultaneously allowing enterprises to move faster towards their business needs. Companies typically spend 70% of their IT budgets just on keeping their datacenters going... replacing failed components, troubleshooting outages, repelling security attacks, and doing other tasks that are focused on keeping the lights on. Our mission (and in fact, the promise of "Cloud Computing") has been to shift the spending of this 70% budget towards activities that move the business forward... creating new applications that generate revenue, make them more competitive, or just improve the bottom line. The most recent deliverable on this mission is VMware vSphere 4 . This is our datacenter offering that simplifies IT by severing the tentacles that unnaturally tie software to hardware and reaping the encapsulation, flexibility, and automation benefits that follow. (For those of you new to vSphere and its goals, we have a (somewhat marketing-y) overview video here .)
SpringSource has also been a technology innovator with a very similar mission, but focused on the application-centric areas of IT rather than on the hardware-infrastructure focus that VMware is associated with. 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. SpringSource summarizes this mission with the following picture:
This shared mission is what brought us together in initial partnering efforts late last year. As a combined entity, the existing efforts and missions will continue, but we'll also work to jointly sever a whole new collection of tentacles... the ones that unnaturally tie an application to the rigid way it must be deployed and managed.
How do VMware and SpringSource intersect?
VMware has traditionally treated the applications and operating systems running within our virtual machines (VMs) as black boxes with relatively little knowledge about what they were doing. However, whether it's around speed of deployment, application performance guarantees, or providing resiliency in the face of component outages, we will be able to provide even more capabilities as we bring even more knowledge of the application and infrastructure layers together. We will do this by adding interfaces into vSphere that SpringSource offerings (and other application frameworks) can take advantage of and by extending our management and automation capabilities to be aware of these interactions. A lot of our early "vApp" thinking has been based on this separation of application code from the requirements it has on the infrastructure on which it will be running.
Developer frameworks already separate out a lot of the hardware and software infrastructure requirements from the application code itself, and we'll focus on building on and extending these capabilities. For example, as a developer packages up their Java application for deployment, they can indicate at a higher-level how this code will interact and communicate with other hardware and software components. At deployment time, the virtualized infrastructure can automatically provision the database and application server VMs required by this application, wire the VMs' network connections together, and program vShield Zones to open up only the appropriate network ports between them.
At runtime, even more exciting things can happen. Information from the frameworks and tools such as Hyperic can pinpoint slowness in the service, and we can remediate the problem areas by altering settings of VMware DRS , cloning another instance of the web server VM, or even interacting with the traffic managers of the datacenter to balance out the load. And on the runtime availability front, backing all of this are capabilities such as VMware Fault Tolerance and VMware HA, which can help the components survive hardware failures or automatically restart as appropriate.
The above is a fairly naïve and simplified example, but hopefully it gives you a flavor for where these combined efforts can go. And we absolutely must go on this journey with a continued emphasis on openness and in delivering value in an evolutionary way.
Choice
VMware has always emphasized choice; choice in which operating systems you leverage, which applications you run, and which hardware you run VMware products on. We've also proactively pushed on industry standards (such as OVF ) that make it easier to choose non-VMware virtualization solutions if so desired. This openness is good on several fronts:
- customers will more aggressively pursue solutions that don't restrict their future options,
- it enables and accelerates competition, which pushes vendors to continuously innovate and add value, and
- it enables a more evolutionary path to reaching end goals versus requiring complete infrastructure or application rebuilds.
As we bring application-related assets into VMware, we know that we must double-down on our focus on openness and choice. We want to enable all applications, both existing and new, to reap the full benefits of running on vSphere, and we will make the same virtualization and management layer interfaces available to other application frameworks and middleware components. We have early efforts underway around .Net, PhP, Ruby, and J2EE, and will continue to focus on expanding these as well as newcomers in the rapidly evolving development world. This picture attempts to show how this all comes together around vSphere:
Furthermore, we will continue our openness at the vSphere management layer, making the interfaces to the applications and infrastructure easily available for non-VMware management tools to access and interact with.
SpringSource also has a huge focus on openness and choice. SpringSource employees are stewards of Spring, Tomcat, Hyperic, and their other offerings, but their respective successes are the result of the vibrant communities that have grown up around them. Furthermore, this space is characterized by customers who wish to pick and choose which of these components they want to use and easily blend them together with other IDEs, programming methodologies, application servers, and management tools.
Let me be absolutely clear on this... our commitment to openness will continue and even grow. And In particular, the Spring framework will continue to be as open and portable as ever. We'll continue to target it at non-SpringSource middleware and management tools, and we will also continue to enable and support deployment on non-VMware virtualization offerings and even (gasp!) physical hardware. Rod Johnson himself will make the decisions as to where Spring goes and how it remains as open as it is today.
On a personal note, I'm as excited about the community aspects of SpringSource's offerings as the opportunity to work with Rod Johnson and the other smart people and cool technologies at SpringSource. I believe many of the existing VMware products will benefit from the lessons of openness and community-building that SpringSource has learned.
And what about the whole "cloud" thing?
This openness, and in fact the complementary nature of what our two companies are doing, makes even more sense in the context of cloud computing. We have spent a lot of time discussing our views of cloud computing and launched the vCloud Initiative to realize this vision (more detailed videos and slide shows are available
here and here ). Our approach to the cloud is threefold:
Deliver software to the enterprise that brings the salient traits of cloud computing to their on-premise datacenters. These traits include resource elasticity, simplicity at scale, self-service portals, and the option of charging internal customers based on their resource usage. Building the "internal cloud" has been the focus of our vSphere and vCenter product lines.
Offer software to hosters, service providers, telcos, outsourcers, and other owners of external datacenters that lets them offer computational capabilities to the enterprise. We base this software offering on vSphere and vCenter as well, and the beauty of this approach is that it is compatible with what companies are doing within their own datacenters. VMs are completely portable to these "external clouds", and they'll get the same levels of availability and performance guarantees when they run them here. This is the focus of our VMware Service Provider Partner Program .
Connect internal and external datacenters together to create what is increasingly referred to as the "private cloud". We are working with our partners to connect the internal and external clouds on a number of fronts such as how to migrate applications to and from the datacenters and a common management view of application assets regardless of where they're running. In this way, we hope to provide an evolutionary path for companies to leverage externally provided datacenters on their own terms and as they're comfortable with compliance, security, SLAs, data placement, or other concerns facing their business.
This is the canonical picture we use to illustrate the vCloud initiative:
So why did I just babble on about this? The key is in how SpringSource and other application frameworks enable and support this same view of the world as virtualization, modern application frameworks, and cloud computing converge.
PaaS with choice
Our common goal is for developers to easily build their applications and move from coding to production execution as seamlessly as possible... regardless of whether they will be deployed to a small internal datacenter for limited use or to a completely external cloud provider for much larger scale audiences (and the hopes of achieving Facebook application stardom!). This end state has a lot in common with what is today referred to as "platform as a service" (abbreviated PaaS). Salesforce.com's Force.com and Google's AppEngine are two of the best known examples of PaaS today.
PaaS simplifies IT infrastructure and accelerates application development by providing a self-service, self-managing utility for building, deploying, running, and managing applications. As we see it, the key characteristics of PaaS are:
- Elasticity: automatically scaling up and down the infrastructure to meet the needs of the application
- Multi-tenancy: being able to isolate resources and applications from one another in a shared infrastructure
- Simplified provisioning: Isolate the developer from worrying about how is code gets installed and deployed
- 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.
- Rapid development: go from code to cloud in a matter of minutes, particularly during the development and test phases
- Simplified (or invisible) management: PaaS offerings typically have built-in application availability and performance management
With vSphere, we are providing the elasticity, multi-tenancy, and simplified provisioning traits. On the self-service front, we are aggressively extending our VMware Lab Manager product to be a more general self-service portal for both internal and external clouds. And when we combine vSphere with the Spring framework, Spring runtime components, and Hyperic management capabilities, we add rapid development models and simplified management to the mix.
One key difference between our offerings and existing offerings will be centered on choice. By severing the tentacles that today tie what you want to run to where you want to run it, VMware can provide the benefits of PaaS, but with significantly more customer choices. Combined SpringSource/VMware PaaS offering can be hosted at customer datacenters or at external service providers. For example, customers can achieve many of the efficiencies and developer productivity gains of PaaS without requiring the applications to be run outside of their walls. Today's PaaS offerings often force you to simultaneously commit to both a programming model and to a vendor who will host the applications written to this model. With VMware's strategy, any vendor in the vCloud ecosystem will be able to offer a SpringSource-based PaaS offering, allowing customers to select the partner that best suits their changing needs.
And one last point on openness of relevance here. SpringSource will continue to seek out and embrace other virtualization and cloud offerings that suit their customers and development community. Likewise, we will focus on extending the above goals and capabilities to non-SpringSource development frameworks. It certainly makes engineering work trickier, but maintaining choice is an absolute requirement these days as VMware continues the quest to simplify IT.
So pull it all together and what do you have... a morphing of our two canonical pictures :-).
In verbal form, our shared vision is smarter infrastructure in which the virtualization platform collaborates with application framework, server and management software to ensure optimal efficiency and resilience. And we will do this regardless of whether you run these applications inside or outside of your datacenter.
And what's next?
Whew... I've well exceeded the amount one should attempt to squeeze into a single blog entry. There's a lot more to talk about, and you'll see the combined vision and deliverables further gel in the coming weeks. I'll close with a shameless plug for VMworld where we'll share additional details and show some demonstrations of how SpringSource and VMware can work together to simplify IT.
Thanks for reading this, and here's to an exciting future!
Steve
