The Network is the Container

One of the standout features of Spring, with its declarative approach to so-called "cross-cutting concerns", has been to help separate infrastructure minutiae from day-to-day programming and allow a cleaner focus on business logic. However, that only lasts up until the time the application has to be deployed.

With the acquisition of SpringSource by VMWare, the Spring team has set a new goal to abstract infrastructure details away from day-to-day operations.

"VMware and SpringSource plan to further innovate and develop integrated Platform as a Service (PaaS) solutions that can be hosted at customer datacenters or at cloud service providers."

Deploying and managing enterprise applications is hard, and what makes "enterprise" applications "enterprise-y" is not just about how much they integrate or how critical they are to how many lines of business. "Enterprise" applications operate in an enterprise context, that is, they conform to consistent, independent infrastructure capabilities that serve many applications: authentication and single sign-on, authorization, transaction management, fault and performance monitoring, data security, audit compliance, routing, caching and more.

These common capabilities are built to economies of scale such that the net investment required to make them common is a good deal less than the cost for each application to provide them on its own. The downside is they are highly tailored for the local environment, difficult to port into and out of, and create significant overhead for testing and deployment.

The traditional application server is little more than a bridge into this environment; the real "container" for enterprise applications is the network on which they operate, and the promise of commoditized platform-as-a-service will not be realized until more of these common capabilities and their configuration can be virtualized and automated to the same degree as hypervisors have for the O/S.

In his frequently quoted blog entry on the acquisition, Ovum analyst Tony Baer writes:

"The fact is that providing a virtualization engine, even if you pad it with management utilities that act like an operating system, is still a raw cloud with little pull unless you go higher up in the stack. Raw clouds have their appeal only to vendors that resell capacity or enterprise large firms with the deep benches of infrastructure expertise to run their own virtual environments."

And later:

"VMware isn’t finished however. The most glaring omission is need for Java object distributed caching to provide yet another alternative to scalability. If you only rely on spinning out more VMs, you get a highly rigid one-dimensional cloud that will not provide the economies of scale and flexibility that clouds are supposed to provide. So we wouldn’t be surprised if GigaSpaces or Terracotta might be next in VMware’s acquisition plans."

They certainly have already have the strategic relationship with Terracotta. That covers caching, and the earlier acquisition of Hyperic by SpringSource covers operations management to some degree.

It's not clear to what extent outright acquisitions are needed to build out this distributed "container". For example, the Cisco Nexus 1000v is an independent software switch product, and there is even an open source competitor to same (not for for the faint of heart, presumably.)

Another interesting and underrated problem area is data service security. Certificates expire, passwords change frequently, and both tend to be managed through manual processes. That's a serious obstacle to on-premises dynamic provisioning, much less when operating in external clouds. Something like Digital Vault technology from CyberArk might fit the need.

Comments welcome. What else is needed to make PaaS into a product, or suite of products, that can be "installed" on-premises? Can you achieve dynamic database capacity without affecting existing DB-backed applications? Where does identity management fit in? What technologies would have to be acquired, and where will partnerships suffice?

(Disclaimer: The above opinions are mine alone and do not necessarily represent the views of current or former employers.)