Today’s PaaS Offerings: Pragmatic or Unrealistic?
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:
- The first time it is run
- The first time it is tested under duress
- 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:
- How can I debug a live Force.com (as in real, “attach to the code and see what’s going on” debugging)?
- My customers are complaining about speed, how can I performance profile and tune the application?
- How can I optimize around certain types of resource consumption?
- 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)
- 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?
Related Posts
Tags
Share This
Your blog posts are interesting, thanks for keeping at it though there isn’t much of a response in comments. I have found your site interesting and informative. I disagree with your whitepaper’s contention that the revenue from on premise licensing is 100% margin…. you would be SHOCKED by the COGS when you have a direct sales force. It is SUBSTANTIAL. COGS excluded development effort and some other things as well, so was a tiny bit naive (no offense). As for the badges… you missed a golden opportunity to borrow from Seinfeld… how about “I’m a SaaSman”?
T,
Thanks for writing. It’s hit or miss on the comments – sometimes I’ll get 2 or 3, other times 10 or 20. The subscriber base and our LinkedIn group are pretty good indicators that there are around 3,000 people who follow SaaSBlogs off and on, definitely keeping things fun;-)
I agree – a direct sales force is fantastically expensive, but it cannot be characterized as COGS (from an accounting point of view). COGS refers to variable unit costs with a direct relationship to delivery or production. A good definition, which discusses excluding operating costs such as R&D and sales, can be found here: http://en.wikipedia.org/wiki/Cost_of_goods_sold. You’ll find similar definitions everywhere.
It’s easiest to understand it in terms of a manufacturing company. If I sell nails, the metal and labor required to create the nail is considered part of COGS, but efforts to sell the nail are not. If I make 10 nails, the total COGS is the unit cost input times 10. If I make zero nails, I have zero COGS, but I still pay my sales people who have tried like heck to sell them. The key here is that if we calculated COGS the way you suggested, we would actually be stating COGS on our income statement even if we didn’t sell any nails. This seems in gross violation of the “goods sold” part of the COGS acronym. The sales, development effort, etc. are simple operating expenses, not COGS.
Since a sales person and associated operating expenses do not vary with the number of customers that sales closes or the size of those accounts, you never find these things in the COGS lines on an income statement. The only component of sales that can be characterized as COGS is commission, but since that is typically doled out as a % of revenue, it is proportionally consistent regardless of on-premises or SaaS.
COGS is supposed to exclude all the things you enumerated, so I don’t feel terribly naive, particularly given the accuracy of our white paper and for remaining consistent with standard accounting definitions;-)
Thanks again for the comment!
Hi,
I’m interested to see how PaaS technology evolves. I like your comparison to WYSIWYG webpage tools. I suspect you might be right.
I’ve been researching the options available to me, as a developer wanting to move as much of the logic and function onto online services as possible, and the services tend to fall into two groups:
1) they want to do it all for you. They almost exclusively end up looking like Salesforce, with tabs and database metaphors all over the place;
2) they have APIs to do common tasks and let you get on with writing code to bind them all together.
I don’t really want to write code, but I can’t help feeling that the drag-n-drop approach is not really any simpler than writing some simple code to bind services together.
If the development of PaaS is like the development of code editors, we’ll see lots of little tools released that help you not have to re-author the same thing for each project: I wonder what the PaaS version of jQuery or Ruby on Rails will be…
J.
Jonathan, excellent breakdown. It reflects my own personal view.
I’ve found that development stacks that trivialize the available solution set require a flexibility trade-off that reduces ones ability to be creative and to tackle large, evolving domains of problems. Outside of simple data pushing and retrieval, most business problem domains are fairly complex and require that software companies have as expressive a tool set as possible.
Thank you for your posts I keep on coming here to read them.
Like you I feel that PaaS just isn’t reach enough (yet?) to really be an alternative to “old school” developemnt. But, following your example, although it’s true that tools like front page and other wysiwyg tools didn’t succeed as expected some very nice sites were build with them. So, although it would be too much to expect PaaS to fulfill all it promises, we can expect many nice applications to be written with it.
Following on from my earlier comment, here is the summary of the research I was doing at the time: http://jaybyjayfresh.com/2010/08/24/paas-a-mid-2010-survey/
good article, well written, thanks for the information.