|
VMware to acquire SpringSource
 Posted by Steve Herrod
Chief Technology Officer and Senior Vice President of R&D
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.
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
A SpringSource
Timeline
| November 2002: |
Rod
Johnson (SpringSource CEO) publishes “J2EE Design and Development” including
30,000 lines of code that are the starting point on the Spring framework.
|
| February 2003: |
Beginnings
of the Spring Framework open source project.
|
| July 2004: |
SpringSource
founded by the core Spring developers.
|
| Jan 2008: |
Acquires
Covalent Technologies, which provides services for users of Apache Software
Foundation projects. These include the Apache Tomcat and Geronimo application
servers and the Apache Axis Web services framework.
|
| April 1, 2008: |
Microsoft
buys SpringSource in an April Fools’ Day stunner .
|
| November 2008: |
Acquires
G2One Inc., the company behind the popular Groovy and Grails technologies.
|
| May 2009: |
Acquires
open source system monitoring vendor Hyperic to provide availability monitoring
for hardware and operating systems, VMs, databases and application servers, and
is targeted at web infrastructure. |
|
