The proliferation of “everything-as-a-service” acronyms is often confusing, and merits an explanation and simplification. The VMware acquisition of SpringSource is an excellent illustration of the architecture. At the infrastructure level we find Operating System resources, which VMware encapsulates and virtualizes, offering shared hardware multitenancy but very limited elasticity. In order to increase the resource elasticity – which is the key factor of cost savings – virtualization needs to extend to the application level. That is the next layer, and I would expect that a tight integration of SpringSource with VMware would in fact provide this for Java based applications.
This evolution has a lot of similarities to Microsoft’s move with Azure. Whereas Azure offers Cloud enablement for .NET applications, VMware+SpringSource would do the same for Java applications. However, in both cases this applies rather to newly developed applications – existing applications need to be redesigned in order to take advantage of the virtualization and resource abstraction features.
As I have noted in other posts, ISV’s who want to extend their portfolio and take advantage of the growing demand for SaaS need to work across multiple deployment models, where development and maintenance costs can double if they need to create the same application in more than one format.
So the main challenge for most ISV’s is to manage an extended solution portfolio, continuing to service their current customer base with current deployment models while driving growth through Cloud Based deployment. VMware+SpringSource will facilitate this for Java oriented ISV’s, as the announcement states support for both traditional JEE deployments as well as Cloud based deployments.
An alternative to the bottom-up approach of system infrastructure vendors such as VMware or Microsoft, comes from some Application Infrastructure vendors such as SalesForce.com or Magic Software. These vendors provide for some time already PaaS and SaaS/Cloud Enabled Application Platforms (SEAP), which deal with virtualization and elasticity by abstracting system resources from the applications, so that XaaS can be achieved at conventional data centres.
Today I came across an account of a UK based ISV whose been there and done that – successfully, even in the present economy climate. Take a look at the story of FactoryMaster and how they manage take advantage of the new platforms.
Posted in Mindshare, Opinions & Comments
Tagged Application Infrastructure, Application Platforms, Cloud, FactoryMaster, ISV, JAVA, Magic Software, Microsoft, Multitenancy, PaaS, Platform as a Service, SEAP, SpringSource, virtualization, VMWare
I wanted to share with you some results from a campaign we’re just concluding. The campaign targeted at CIO’s and Chief Architects of Switzerland’s large enterprises. We asked them about their interest or experience with RIA and Cloud development and implementations. Over 16% responded positively – are both developing in-house and considering RIA’s.
I think that we see here a fundamental architectural shift, which is more visible perhaps in the SaaS application market but is nevertheless gaining significant foothold as “private cloud”.
It might be useful to segment the SaaS phenomenon between the Usability aspect and the Business Model. Private Clouds and RIA go after the Usability, which I start to think is a stronger driver than the Business Model.
The current controversy that considers SaaS as mutually exclusive with On Premise is, in my view, more related to the current state of technology, than to business or functional issues.
Clearly, if On Demand applications have to be developed and deployed on entirely different platforms and technologies (RIA and multi-tenant) than On Premise applications (Windows and JEE or .NET), then it is difficult, cumbersome and costly to support both.
The topic is not a theoretical issue – I consider it the critical enabler for the growth of SaaS. The majority of ISVs are facing a tough challenge when it comes to offering SaaS as they and their customers are looking to cut costs, yet to offer a SaaS portfolio an ISV is faced with a potentially large upfront investment needed to offer a SaaS version of their products. I will expand on the ISV challenge in a separate post.
That is not a pipe dream – the first application platforms that supported this proposition (Magic Software’s uniPaaS) hit the market almost a year ago, and just recently PaaS provider Longjump announced an On-premise version of their PaaS. There’s even persistent speculation that Force.com would follow suite.Clearly, on-demand business requires a different business approach than on-premise – but I view it rather as a super-set than a mutually exclusive path. And as we see in the SaaS integration business, many vendors offer a SaaS pricing models to on-premise installs – and doing so for applications should not be much different (assuming customers provide a compliant infrastructure and operate it).
Now, consider the proposition in which the same application platform (and consequently application) supports various deployment modes (single and multi tenancy, Fat, Browser or RIA client). The Client appliance aspect becomes immaterial. A software vendor using such a platform can unify its development and support cycles and have a single cycle of updates and upgrades. The SaaS hosting center (and not necessarily only one) becomes yet another “on premise” customer, hopefully with many more users than a “regular” on premise customer. And customers have the power of choice and can evolve and migrate their software usage in accordance with the evolving business requirements.
I think that there is not sufficient distinction in the industry between Situational Applications and more persistent solutions (how would you call that type of apps? Systematic? Core? Persistent?).
I have witnessed the deep frustrations of IT managers who adopted a Situational Apps tool thinking it could be used for any type of solution, and running into walls late in projects, ending up with unsatisfactory solutions both from functional and technical aspects.
That does not mean that Situational is not good – just that one should use it for what it is meant for.
The story (rather history) of Magic Software is quite enlightening in this respect. When we first launched Magic II in the mid-80’s, we were in the midst of the first wave of the situational buzz with data oriented application tools such as Framework, dBase, etc… Magic II innovated by offering a metadata driven environment, which was much easier to master for business professionals than code driven tools. So we happily promoted it to ISV’s and Enterprises, with a silver bullet message and doing away with waterfall or other development models. It worked great for a while, but as applications reached the production stage their design flaws became apparent. I recall being summoned to a large pharma enterprise by the head of their clinical tests department, because the application he proudly developed was gradually slowing down to a halt. It did not take long to discover that the data structure was so convoluted, that some lookups ended up sequentially scanning tens of thousands of records.
The majority of the PaaS offerings today are for Situational Applications. That is quite understandable, since it take a significant effort and time to develop PaaS with highly granular widgets that enable the same power of implementation as coded environments. The danger though, is that the hype and buzz are so high and blinding that many prospects to not perceive the limitations (ending up as I described above).
So my call to action is to offer more down to earth information and transparency about what a technology is good for, so that those in need for situational tools are not overwhelmed with complexity and those looking for persistent and core solutions do not try to implement them on straws.