VMware acquisitions: signal of a full stack evolution?

Aug 31, 2010 by Sinclair Schuller

During the VMworld keynote today, VMware announced that it was acquiring Integrien and TriCipher. Clearly, M&A activity is a good indicator that the acquirer is pursuing change and hoping to achieve specific strategic goals, but what they buy is always an interesting indicator of corporate direction.

VMware, not too long ago, picked up SpringSource and associated technologies, painting a clear Java stack play. But looking at Integrien and TriCipher, we’re starting to see real building blocks around application level services that are well beyond the bounds of a VM. This is all extremely interesting; it points to the notion that VMware is evolving to see the application layer as the key battleground of the future. I know it seems obvious, but looking at all the moving parts, it’s always amazing to see things like this come together. I personally believe that we’ll see full blown stack analogs in the cloud, along with best of breed semantics, creating a true set of “cloud stacks” that offer huge amounts of value to the application tier, and not just focus on solving infrastructure level problems (which is what a huge amount of cloud tech as focused on to date. Not all, but a large amount)

If you were VMware, what other application level services an components would you see as critical in building a complete stack offering?  At what point would the VMware stack evolve into something unique rather than just the sum of its parts?

read more

Today’s PaaS Offerings: Pragmatic or Unrealistic?

Jul 12, 2010 by Sinclair Schuller

Although my focus in life right now is CEO of Apprenda, I come from a software development and architecture background (I needed to put my Math/Comp Sci. degree to good use at some point in my life). Anyone who has written software in any “old” (in this case, the double quotes are for sarcasm) platform technology like Java or .NET can assure you the writing software goes far beyond writing code and then running it. There are three major inflection points in the life of a piece of software:

1. The first time it is run
2. The first time it is tested under duress
3. Use in the real world

When people envision others writing code, they envision dozens of programmers writing text, deploying code, and using it. If it only were so simple. This make-believe scenario assumes that the only tool a developer uses is some sort of text editor/development environment. This is far from reality. Writing software typically requires the use of a number of advanced tools and techniques: debuggers (with the ability to work with real, running code), performance profiling tools, memory profiling tools, tuning tools for database queries, abilities to change the underlying runtime mechanics of your platform – you get the point. The reason for all of this is that code does not run as we expect it to, and this becomes painfully apparent at the three inflection points I described.

Interestingly, the general complexity of business software has been increasing. That is, business apps try to tackle more complex problems as each company tries to outdo their competitors by offering the market more value. This means that code also becomes more complex, tooling becomes more important, and visibility into an application becomes key.

Why then, did PaaS offerings (think Force.com style abstract PaaS offerings, particularly in the Apex only days) start off with such a “lowest common denominator” platform? Since business apps are becoming increasingly complex, and PaaS offerings presented a layer much less sophisticated than traditional platforms like .NET, how pragmatic are they for ISVs? As a tool for extending a CRM system, Force.com is clearly great stuff. It offers a simple way to provide new value to an existing system. But as a platform for serious ISVs who need to build complex offerings  - that’s a stretch. The complexity required of a serious development platform just isn’t there, and most software companies should recognize that. There are so many questions that are currently unanswered that make modern PaaS offerings unrealistic for many, many scenarios. Interestingly, these questions are unanswered for at least one (if not all) of the lifecycle inflection points I defined earlier:

1. How can I debug a live Force.com (as in real, “attach to the code and see what’s going on” debugging)?
2. My customers are complaining about speed, how can I performance profile and tune the application?
3. How can I optimize around certain types of resource consumption?
4. I can I use new architecture techniques if the PaaS is too limiting (think Apex before asynchronous calls – a concept that has existed in mature platforms for quite some time)
5. My application is not working as expected in production, and my developers need access to system specifics and the running code to assess what’s going on, how do I get to the live runtime?

I could go on for a long time.  Fundamentally, PaaS offerings seem far too trivial with VERY immature tooling. Yeah, yeah – you’ll here the “In PaaS X, you’ll never have to worry about Y.” The fact of the matter is, code rarely meets expectation at those inflection points, and developers need to dig deep to make magic happen. PaaS offerings really trivialize this. It reminds me of the days when WYSIWYG editors were going to “revolutionize” how websites were made (think Frontpage, Homesite, etc.) and that web design would be democratized, and no one would have to touch HTML, JavaScript etc. We all know how that turned out. The concept of “everything can be written for you, no need to “hand tweak” has never worked at scale, and typically has failed miserably. The best web properties are still written “low level” (relative to web technologies), and complex tools and libraries for JavaScript, Flash, and Silverlight are flourishing.

“Old” runtimes can do a far better job than PaaS when coupled with purpose-built middleware for SaaS and cloud infrastructure like EC2. Developers can capture complex requirements and systems with the right languages and have all the real world tools needed to properly build, test, and evolve software.

Do you feel that PaaS offerings nailed it, or do you agree that they missed the mark and currently cannot support high levels of complexity and real software development life cycles? Is PaaS currently a reflection of WYSIWYG web editors and we’ll instead see a cloud stack evolve that doesn’t try to “solve everything” in one silo?

read more

The Cost of Sustained Market Leadership as a SaaS Company – New Whitepaper

Jun 17, 2010 by Jesse Kliza

Hi everyone,

We just yesterday released a brand new white paper entitled “Understanding the Cost of Becoming a Sustained Market Leader in the Software Business Through Software as a Service”, that we thought the community might be interested in. It’s vendor neutral, no product pushing, etc, and we’ve gotten great feedback thus far.  As always, we’d love to hear your thoughts, so please speak up! :-)

You can access the full white paper here.

Topics covered include:

- What it means to be a SaaS provider
- The importance of highly efficient SaaS architecture
- Optimal strategies for achieving the SaaS stack maturity necessary to become a sustained market leader

The paper begins with an overview of providing a SaaS offering, the primary infrastructure and delivery costs, and the requirements for market leadership before proceeding into the complexities and benefits of single-instance multi-tenancy and a critique of several compensatory strategies. The paper then concludes with an explanation on how cloud middleware can solve these architectural problems thereby achieving the benefits of building your own multi-tenant stack without the onerous upfront R&D costs and long time-to-market or the poor customer management and lock-in deficiencies normally associated with leveraging Platform as a Service (PaaS) offerings.

Here’s the link again to access the full white paper.

Should you have any questions or feedback on the whitepaper, please let us know.  We hope you find it to be a useful and informative read!

- Jesse

read more

Fundamentals of Being a SaaS Provider on GigaOM

May 23, 2010 by Sinclair Schuller

For those interested, an article I wrote was published on GigaOM that gives a high level description of the bare necessities required to become an on-demand player. I won’t rehash the details here, so definitely check it out!

read more

A Future of Cloud Stacks or Cloud Silos?

May 11, 2010 by Sinclair Schuller

When thinking of the cloud, there are two sides to the coin: those who build SaaS offerings and those who consume them. For those who build SaaS applications, we’ve seen a glut of tools crop up to help engineer, architect and deploy SaaS offerings. Some are “horizontally” aligned (think EC2 on the IaaS side, SaaSGrid on the application server side, etc.) while others are “vertically” aligned holistic silos (think Force.com on the PaaS side – even with the recent VMForce announcement) and some are in a mid-silo middle (think Google’s AppEngine and Microsoft’s Azure, both “up to the runtime” PaaS stacks).

Given that there is so much velocity, tumultuousness and general confusion (acronym hell coupled with taxonomical conflation – aka the “everything and everyone is a platform” syndrome), we’re bound to see some order evolve in the future where the evolution will be motivated by what people actually use and adopt rather than the current landscape which is driven by who can yell the loudest.

The big question is what will the future of cloud architecture look like: a stack of interchangeable layers that allow one to choose best of breed or a group of incompatible but highly specialized “holistic silos?”

Looking at the history of infrastructure middleware, the answer seems to be quite clear. Typically, the trend has been that layering functional best of breeds into stacks provides the best combination of “lowest common denominator” coupled with the necessary functional value to “get things done” and keep risk minimal. For example, I can choose servers made by HP, a Windows OS, Java and JBoss, and build a killer enterprise app. If I so decided, I could have swapped Windows for Linux and essentially had a compatible stack experience.  Why, then, are silos cropping up in the market?

Silos like Force.com have their appeal. They promise a world where all your needs, ranging from hosting and execution runtimes in the cloud all the way through development frameworks and distribution channels. The problem, however, is that the software market cannot be addressed as a broad stroke.

The needs of software companies vary wildly: ISVs in the healthcare space may care more about hosting certifications than someone in the CRM space, while those in business intelligence need low latency, high compute availability and the others who altogether care very little about the hosting and it’s all about what middleware they are going to use. The number of needs permutations is staggering.

To think that Platform as a Service vendors that own the full stack, from hosting through runtime and even UI components, can ever optimize for each of these scenarios is ludicrous.  Furthermore, the silo providers ask for something huge in return for a suboptimal solution:  control of the ISVs destiny in all regards. That’s a high price to pay for a promise that can’t be fulfilled.

	Cloud Stack	“Half Stack”	Cloud Silo
Operations Management	SaaSGrid		Force.com, Quickbase
SaaS Middleware		Microsoft Azure, Google AppEngine
On-Premises Runtimes	.NET, Java, etc.
Cloud Infrastructure	EC2, Rackspace Cloud,  GoGrid

I’m a firm believer that most if not all software will be delivered online. It’s the only way to achieve true ubiquity, and it requires superior delivery. Each ISV is going to have to make lots of decisions as they move to the SaaS delivery model. Those decisions are going to focus on how to best solve all the critical problems associated with becoming a service provider. The only logical conclusion is that each ISV will look for best of breed tiers in a stack form that would allow them to create an optimized outcome. I don’t see a grand future unfolding where thousands of ISVs worldwide commit to incompatible silos that require taking on relationships that amount to single points of failure and risk. As a stack becomes more vertically consolidated (i.e., more siloed), the higher the risk grows for an ISV. If ISVs take on piece-meal stacks composed of highly compatible tiers, the walk away with the best of both worlds.

What do you think? Do you think that the next generation of business applications will be split across walled silos, or will the market adopt levels of commonality by converging to a stack approach with solutions provided by a few key companies at each layer, allowing for a “composable” stack approach that we’ve grown accustomed to?

read more