VMWare fuels SpringSource's stratopheric journey

For the last year, the SpringSource team has been intently focused on bridging the gap between development and operations. The team has also been moving quickly to re-tool their platform to become a Cloud-native. Cloud-native platforms are built to exhibit cloud computing characteristics (i.e. self-service, elastic and scalable, virtualized, and dynamic) compared to the 'earthborn migrant' runtime stacks which are simply traditional application platforms hosted on cloud infrastructure without application container and framework modifications.

Cloud-native platforms enable users (including non-developers) to customize pre-built templates. They offer abstractions for workload granularity that lighten the developer’s burden for many scalability and operational concerns. While Cloud-native platforms will attempt to transparently address scalability and elastic provisioning/de-provisioning, the platform will assume that an application is already horizontally scalable, or can be redesigned to conform to Cloud application architecture restrictions that facilitate a scalable solution. Moving to Platform as a Service forces architects to fundamentally re-examine their application architectures.  Tackling parallelism and single points of bottleneck (usually database access) will become paramount.

With a new programming model, developers can approach solving problems that are resistant to traditional application architecture practices.  Democratizing the process of building massively scalable web applications and delivering high-quality applications in a superfast time to market are two examples that are becoming mainstream concerns. SpringSource, a framework innovator, is well-positioned to address the programming model evolution.

Attenuating the feedback loop between VMWare's vSphere and SpringSource's application servers will enable finer grained application footprints and timely elastic scaling. Imagine the ability to dynamically provision a specialized stack (i.e. container, framework, application meta-data and code) to handle a discrete unit of work (e.g. web request, transaction, resource query), intelligently pool the stack, and tear it down when not needed. SpringSource's investment in OSGI, inversion of control, lightweight containers, and application management interfaces establishes a necessary foundation to re-think and shrink run/manage away from monolithic systems (e.g. hardware virtual machines, application servers, and applications) and towards discrete business services.

Comments

[Patrick McKlear]

I don't really understand what in SpringSource is vertically scalable. The Spring framework is an excellent set of application APIs, but to me this has nothing to do with scalability and virtualization. I didn't find in this post any evidence for such statements.

[Chris Haddad]

Hi Patrick, The post never stated SpringSource application servers are inherently 'vertically scalable'. Most Cloud implementations focus on scaling horizontally and using commodity hardware instead of big-iron. The short blog post doesn't intend to fully explain SpringSource's efforts to re-factor their application server line-up to support Cloud characteristics, but simply identify a few fundamental changes in-progress.

[William Louth]

Investment in "application management interfaces".

What exactly would that be? I would hope that this would not a reference to Hyperic itself which in fact was undergoing a complete rewrite at SpringSource after this had already been attempted at JBoss (twice). How many hints does one really need to see that something is inherent broken?

I expect the focus to be on the cloud computing programming model and platform with Hyperic finally put into the sunset club.

[William Louth]

[vertically scaling]

SpringSource lacks a distributed data & compute grid technology. I had expected SS to acquire this technology (GigaSpaces, Terracotta, GridGain,...) before they sold out but this offer is more than their actual worth and a great deal for the guys at the top of the food chain in the Spring community.

[Patrick McKlear]

Hi Chris,
The way I look at this is that SpringSource message to VMWare execs is that they support dev/run/manage cycle, which is appealing for enterprise app servers. Actually, all they have right now is the dev piece ready and the rest is myriad of integrations.
I claim that VMWare execs are missing a broader PaaS picture. SpringSource does not add run-time/management value there at all. They will soon realize that they need additional components such as cloud-enabled data stores, cloud-enabled event-driven run-time and will have to acquire complimentary run-time and monitoring capabilities. Spring tc-server and dm-server will be dropped for dynamicaly scalable run-time with spring framework as the development glue on top.

[Derik Pereira]

I think with a PaaS feeding frenzy we are now in danger of developing apps that depend on a particular PaaS framework, model, language(s), etc ... all the same, the whole stack is now getting many moving parts and thus complex even though all the moving parts are simple to begin with ... anyhow, many PaaS choices are good ... we do need to define our outcomes before going with a PaaS vendor ... hopefully, cloud adoption happens with an enterprise architecture and governance ... otherwise, all our apps, code and data will be like the Excel spreadsheets on USB drives that we now can't live without (at least, the global economy).

[William Louth]

Hi Patrick,

You are right there is nothing at all at present in the way of cloud specific technology @ SS. Their monitoring is system level based which seems dated in light that most vendors are moving to fine grain (activity) metering (not just monitoring) to solve both performance management and cost management requirements of both private and public clouds.

http://www.jinspired.com/products/jxinsight/meteringthecloud.html

[sj]

you can use spring dmserver