Why I Really Like VMware's SpringSource Acquisition

Sorry I wasn't able to weigh in when this happened last week. 

The good news: the more I think about it, the more I find this particular acquisition absolutely fascinating.

The usual disclaimer: I'm offering my own opinions, and not speaking officially on behalf of VMware, EMC, SpringSource or any other company for that matter.

But, despite the disclaimer, many of us think this is pretty darn cool.

It's All About Application Developers

If you're not familiar with SpringSource's business, I'd encourage you take a moment to visit their website and get a sense of who they are.

Basically, their target audience is Java application developers in larger corporate settings.  If you're doing enterprise Java development, you probably know who they are, and most likely an enthusiastic user.

Which brings up the question -- why would VMware (or EMC by implication) be interested in this sort of thing?

Of Applications And Clouds

Part of the compelling part of the private cloud story for enterprise IT is that there's no need to re-write or re-think the vast majority of the application landscape to move it to a cloud-like model. 

Anything you can run on an x64 instruction set can be effectively "cloud-ified": desktop and server.

Given that there's about a bazillion lines of legacy code floating around enterprise IT that meets this criteria, this is no small advantage.

That being said, there are new enterprise applications being written all the time.  A significant number of them are being written in Java for obvious reasons.

And, if we can directly expose underlying cool cloud functionality to these application developers -- and do so in a natural and controlled way -- good things can happen.

Atmos and Applications -- An Example

Sorry to do a product dive into the EMC portfolio, but it best exemplifies the concept here. 

Atmos has been tagged as cloud-optimized storage (COS).  Sure, it can support some legacy models up to a point, but its real strength shines through when applications are aware of what it can do on their behalf.

For example, the notion of arbitrary policy generation for stored objects is mind-bendingly powerful once when you think about it.  Atmos storage policies can control ordinary things like number of copies, geographic placement, or even spinning down drives when they're not being used. 

But there's no real limit to the generic policy model they've implemented, including adding an easy external hook for just about anything you'd care to imagine: it can easily be extended to do things like automated content scanning, or enforce compliance rules, or just about anything that involves a storage object.

Application developers are free to use pre-existing policies storage defined by the enterprise (presumably centrally defined and enforced), or create new ones if needed.  And exposing these sorts of cloud-smart storage capabilities to application developers in a natural and controlled way is inherently appealing.

Note: those parts of the industry who are still thinking "file systems" will miss out on all of this.

Of course, there are other non-storage examples of directly exposing unique cloud capabilities to application developers in a natural and controlled manner, but I think this illustrates the point well.

And, please keep in mind, when I use the word "cloud", I'm really thinking about "private cloud", where it can be any mix of internal or external IT infrastructure resources, and not necessarily an external service provider.

Uhh -- Do We Really Need A Legacy OS?

At its simplest level, an operating system coordinates resource access from an application.  Application talks to the OS, OS talks to the hardware. 

Many people realize that, in a world where Java VMs (virtual machines) are running under modern hypervisor, much of the rationale for even having an operating system becomes less obvious.

Now, no one is saying traditional operating systems are going away anytime soon, but certainly we will see less need for them in the future, especially in applications targeted for cloud environments.  Indeed, many people are getting comfortable with the idea of JEOS (just enough operating system).

Obviously, the end goal here is NAOS - not any operating system!

Traditional operating systems tend to add resource and operational overhead.  They consume CPU, memory, disk and network resources.  And they're yet another object that has to be managed, patched, exploit-proofed, etc. 

And, in a world of Java virtual machines running on hypervisors, there's an obvious and compelling incentive to do as little with them as possible.

Platform As A Service

When we look at the broad array of "*aaS" services (infrastructure as a service, software as a service, data center as a service, et. al.), special consideration has to be given to the special attributes associated with any PaaS model.

Any large-scale application development effort requires start-up infrastructure.  Sure, you can spend a bunch of time and money bringing all that IT plumbing into a data center -- or, you can simply subscribe to a PaaS service.

Indeed, this is part of the inherent appeal for Microsoft Azure, Force.com and others.  Nice, fully-featured development platforms on a pay-as-you-go basis.  'Zilla found this intriguing, as did I.

Couple this model with the dynamic relocatability of private clouds, and you can go one better than just about any PaaS model out there: develop your application on the most powerful Java framework, and feel free to move the resulting application just about anywhere: back into the data center, or to another compatible service provider.

Choice is good.

Towards The vApp

VMware is talking a lot about "vApps" -- how enterprise-class applications will be constructed and run in the very near future.

The idea is simple and compelling.  Application developer is presented with a "service catalog" of pre-existing corporate application modules.  Application developer selects the ones that make sense, and may add a few modules of custom logic that interacts with the pre-existing ones.  Each application module presumably runs in its own virtual container.

The developer may need to add in other services as well: perhaps a virtual load balancer, or a virtual firewall, or perhaps a DLP compliance scanner. These are then bound into a "vApp" -- a composite of virtual machines that represents an enterprise application -- all self-contained, all dynamically relocate-able.

Imagine a "bar code" on the outside of the vApp.  This identifies it to the underlying infrastructure in potentially useful ways: desired service level, cost-containment policies, compliance and/or security policies that must be adhered to, etc.

Oversimplified, the bar code tells the infrastructure what to do: run this particular vApp at service level X, not to exceed cost Y, and please comply with the following A, B, C compliance / governance / security constraints. 

The application developer can specify these attributes, or they can be specified externally.  Either way, the analogy of a FedEx box and its associated bar code is a useful one.

Again, exposing this service library / catalog and packaging methodology in a natural and controlled way is a powerfully intriguing concept.

Challenges Ahead?

Of course, aren't there always?  When EMC acquired VMware, we had to run as a separate and independent business whose interests wouldn't always align with the mothership. 

An as I think about VMware acquiring SpringSource, the same thoughts come to mind -- it too will have to be largely open and independent of the mother ship.

But, as in both relationships, there are powerful synergies to be had all around, if you look at it.

Comments

[Tom Maguire]

Great post, absolutely agreed. One other really interesting aspect of the acquisition has to do with management.

Back a few months ago, SpringSource acquired Hyperic (an open source systems management vendor); the interesting part of this is that in the cloud the operational concerns (management and policy) out of necessity become something that needs to be addressable by the developer.

SpringSource coupled with Hyperic and VMware cloud platform makes for a compelling story.

[Scott Waterhouse]

Chuck;

I like the idea of a bar code on the vApp a lot. Now extend the idea to data structures: you could have a data protection bar code (that describes the data protection policy to be applied to the container); I spoke about that here: http://thebackupblog.typepad.com/thebackupblog/2009/06/a-data-protection-taxonomy.html But why not also have a bar code for data replication and availability?

Why make these bar codes objects with inheritable characteristics? Why not make some of the service providers that can act upon the policies contained in the bar code a part of vSphere?

There is a lot of mileage in this approach, in my opinion.

[shiningarts]

We all come with our own background and bias when we are talking about CC (Cloud Computing) in general. Depending on what our various interests are at the moment, our understanding of CC will vary and range widely. Some say it is public, others say private, repackaged, or whatever. For EMC, CC is definitely for storage. For VMW (VMware)*, it is about virtualization. So on and so forth… There would be as many combinations of CC as you can think of. Aside from VCE cloud model, we might need to reckon with IBM’s. Observing nature, IBM has learned and is building next-gen DNA microchips which are, indeed, a radical departure from the silicon based architecture we are currently using:

http://www.reuters.com/article/newsOne/idUSTRE57F1K720090816

When I first start programming in early 80’s, I toiled with IBM’s assembler language. Primitive it may seem, I thought it was real amazing to be able to translate your logic into the assembler language. Now, we are using personal computing devices such as laptop or telco devices. I was using a dump/blue terminal that timeshares cpu cycles with a big blue IBM mainframe machine. Now, we have our own processors that may equal or exceed the mainframe processing power of that time. I think with CC fully implemented eventually, the personal device will not run an Operating System, but a specialized process that translates between human consciousness and the outer world that may well be located behind CC. Nonetheless, Moore’s law would be still applicable to this circumstance as microchips are getting miniaturized into nanochip sizes as the DNA/nanotechnology is realized in due course.

Contrary to VMW / SpringSource / EMC’s belief of the mother ship relationship to baby boats, they may need to pull the ships into battle formation to prepare for the ultimate mother-of-all titan clashes as the industry braces for a major paradigm shift in not-so-distant-future. Please check the comment here:

http://www.brilliantleap.com/blog/2009/07/is-it-a-game-changer.html#comment-6a01156e8fc966970c0120a4e74a22970b

* Some may have noticed that I have unwittingly been using the term "VMWare." However, I have discovered that an official name of the company is “VMware.” This seems to fly against the general naming protocol for companies that specialize in a localized area of software, which should have been to name it “~Ware” instead of “~ware”. I am not trying to second guess here why VMware is named such as it is. Since I may not comfortably call it as VMware as the company does not completely represent all of the VM World technologies out there, from now on, I will use its ticker “VMW” instead whenever I have opportunity to refer VMware in my comment.