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

SaaS for the ISV Masses through SaaSGrid Express

Jun 7, 2010 by Sinclair Schuller

When my partners and I co-founded Apprenda, we had a number of very specific goals when it came to SaaS enablement and we wanted SaaSGrid to embody those goals. My co-founders and I all came from technical backgrounds where we were responsible for SaaS engineering efforts. We learned early on that when a SaaS application is engineered properly, its architecture is drastically different than plain old web applications (think multi-tenancy and scale-out) and that a huge number of auxilliary tools and subsystems (think billing, application life-cycle management, infrastructure management, subscriptions, identity federation, etc. and then some) are necessary for managing and operating a SaaS offering and business.

When you combined these “SaaS specific” aspects of a SaaS offering, the upfront and ongoing time and money investment required far eclipsed that of the application itself (the actual thing your customers want to pay you for!), and causes huge competency distraction. Taking on the build out and maintenance of a mature “SaaS stack” is akin to a software company deciding that it’s in their best interest to build and maintain their own DB technology in support of their business application.  Surely, most people buy RDBMS tech (like SQL Server) or download it (like PostgreSQL) to help ensure succcess, and firmly believe that they need not build their own. When we created SaaSGrid, we had some very specific things we wanted it to do:

1. Allow for the use of traditional stacks (in our case, the Microsoft .NET platform) and the wealth of tools and components already in existence for these stacks. New languages are best created in support of new modeling paradigms or changes in the ways we capture solutions, and not in support of a new delivery model. Traditional runtimes simply needed to be “enhanced” to really sing in an on-demand scenario.
2. Have it be comprehensive and not require a “paper mâché” approach to piecing together disjointed capabilities. Imagine that an operating system required that you find your networking substack from here, and a graphics subsystem from there, and then require that you mash them together. That would be sub-optimal in many ways.
3. Have SaaSGrid provide even the most complex capabilities, like multi-tenancy, as transparently as possible to the application code that runs on top of it. As technologists, we hate having technologies adulterate our code, so to the extent possible, we wanted SaaSGrid to be as low impact as possible.

We accomplished our goals and some, and our customers benefit wildly from SaaSGrid. But late last year, we were thinking about a number of things related to the market and to SaaSGrid. As a company, we’re committed to not only supporting the transition to SaaS, but to catalyzing it. I think great strides have been made with respect to software company adoption of the new delivery model, but the fact of the matter is, most ISVs are still not SaaS. Furthermore, those that want to become serious SaaS players have a tough time understanding how they can get there and what tools are available to them.

Enter SaaSGrid Express!

Anyone that follows my company Apprenda knows that we recently made a new product announcement with SaaSGrid Express. SaaSGrid Express is a freely downloadable application server that captures nearly all of the value of our tried and true SaaSGrid, and that can be used by anyone just to experiment or even to build a revenue producing business. Our goal with SaaSGrid Express is to let everyone experience the value that SaaSGrid has to offer, and more importantly, to democratize a highly complex SaaS architecture in hopes of moving the industry forward.

Phil Wainewright recently offered some excellent insight in his recent blog post regarding SaaSGrid Express; the goal of democratization also means that some people might get there hands on a technology but are simply not prepared to build their own clouds. But as Wainewright went on to point out, those same people would have gone down that path with or without SaaSGrid, so we’re happy that they’ll be able to walk away with such a robust starting point. Giving SaaSGrid Express to the world means that more people than ever before can experiment with and commit to a proper SaaS architecture, which will definitely help satisfy our vision of catalyzing the space. As Dana Gardner suggested, SaaSGrid Express opens up the potential for a “cloud standard” architecture and SaaS stack. If we accomplish that sort of de-facto standard, then the industry is definitely off to a good start. Having a de-facto SaaS stack means that people are not focusing on complex architectures, but on business value for their customers – which would be a huge win for everyone.

Something Special for YOU!

For those loyal SaaSBlogs readers that have an interest in downloading SaaSGrid Express and building an application, we’d like to offer you something special:

For the first 5 SaaSBlogs readers that sign up for SaaSGrid Express with the intention of building an application, or migrating your existing .NET offering, we’ll commit 1 hour of time from one of our engineers to personally work with you, and get you up and running with your project!

Just mention that you’d like to take us up on this special SaaSBlogs community offer in the comments section of the sign up form.

read more

What is VMForce?

Apr 20, 2010 by Sinclair Schuller

If you haven’t heard, Salesforce.com and VMWare plan on making a joint product announcement on April 27th at http://www.vmforce.com. Clearly, this piqued the curiosity of many, including myself. Thinking about Force.com, Salesforce.com’s strategy around the platform to date, and VMWare’s activity and intent to become more entrenched in the Cloud, my best guess is that it’s an Infrastructure as a Service (IaaS) offering, and maybe some sort of Spring-based framework layer that’s tightly integrated with Salesforce.com. Furthermore, it might even offer the ability to run native Force.com code/apps on top of it (I could see something like Spring being used  to create a harness of sorts to load Force.com apps on a native Java runtime)

Force.com is a high order abstraction requiring the use of a new programming language and a heavily diluted (read crippled) runtime. As a platform for extending the CRM functionality of Salesforce.com, it’s an amazing platform. As a general purpose platform for business applications, I think it’s too trivial of a runtime (anyone who’s read this blog before knows my position on this). Most mid-large ISVs solve complex problems addressable only through mature, expressive languages and complete runtimes and stacks. VMForce might be a step in the right direction – so let’s wait and see!

PS: For the literalists out there, one thing I noticed is that VMForce.com describes  it as a “product announcement” instead of “service announcement”. Maybe it’s some sort of special VMWare on-premises integration to the Salesforce.com Cloud?

What do you think VMForce is all about? Any drastically different theories?

read more

Great Interview on the Benefits of Multi-tenancy

Feb 5, 2010 by Devon Watson

This is a very good podcast of Phil Wainewright from The Connected Web interviewing Rick Nucci, CTO of SaaS integration vendor Boomi on the impact of multi-tenant architecture on the operational cost of delivering software in a SaaS fashion.

Two choice excerpts:

“SuccessFactors recently gave a speech, [by CEO] Lars [Dalgaard], talking about their architecture and their approach. They have something like over a thousand customers per physical server when you net it all out and aggregate it. Andthat‘s the marginal utility, that’s the scale that you need to get to — because you need that op-ex in your business as a SaaS ISV to be in the five percent type of range. And it’s not going to happen if you’re doing a per-customer expenditure.”

“And that‘s the marginal utility, that’s the scale that you need to get to — because you need that op-ex in your business as a SaaS ISV to be in the five percent type of range. And it’s not going to happen if you’re doing a per-customer expenditure.”

Continue reading the transcript or listen to the podcast here.

read more

Not All Clouds Are Created Equal…

Jun 11, 2009 by Abe Sultan

Just a quick note: I just published an article in Datamation titled “How to Be a Cloud Computing Vendor”. The article focuses on clarifying the jargon that exists on using Cloud Computing Providers as substitutes to SaaS Platforms. 

Check it out and let me know what you think!

Cheers
Abe

PS: If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 2130+ members and is growing every day; make sure you’ re not missing out and join today!

read more

What’s the long term cost of not using a PaaS?

Apr 3, 2009 by Sinclair Schuller

If you’re an ISV considering SaaS as a delivery model (whether it’s for a new product or migrating an existing one), you’re going to inevitably bump into SaaS platforms as a potential means of building your service. Once you do, you’re presented with two options: (1) build a fully integrated SaaS offering yourself which includes your actual offering (say, an HR solution) and the underlying SaaS mechanics (relevant SaaS delivery components like multi-tenancy, onboarding and provisioning, high availability architecture, web services API, etc.) or (2) build your actual offering (the same HR solution) atop a purpose built platform as a service (PaaS) offering that does the SaaS heavy lifting in your architecture. When faced with these two options, the astute decision maker will inevitably ask:

“Well, a PaaS seems to save us a ton of upfront effort and cost. In fact, it might cut our costs down from $600,000 and 14 months to $200,000 and 4 months. However, if we go with a PaaS, we’ll have an ever present operational expense that never goes away. If we go with option 1 and just bite the bullet, sure we’ll spend the money and time upfront, but that’s just a one-time investment. Won’t we experience ROI on that 10 months and $400,000 rather quickly?”

My answer is an emphatic no! Now, don’t take the platform guy’s (me) word for it: let me put some substance behind my claim. To understand why I say no, let’s really understand the question. Starting from the top and irrespective of the aforementioned question, an ISV is deciding to deliver software functionality to the web. That functionality is valuable to their customer base. The better the ISV is at their core competency of capturing value for their customer, the better off the customer is and the more likely the business is to succeed. If you’re building an HR app, every minute and dime your company invests in HR functionality could yield added value for your customer and higher revenue for you.  At no point does this suggest that somehow the delivery model is the core value offering to your customer, or that your competency is in constructing a delivery model. In fact, it’s a distraction to the primary goal. Now, going with option 1 with a notion that we have to “Build it here because it’s a one-time investment and we’ll make a return” assumes that it is in fact, a one-time investment. This couldn’t be farther from the truth. Realistically, you’ve in fact decided to take on the burden of whole product line and its lifespan. I’ve constructed a conceptual diagram to capture the rough notion of relative cost between your actual offering (an HR app), the “home built” SaaS delivery model stack, and opportunity cost (all of which I’ll discuss)

At the start of your SaaS journey, option 1 means that a huge chunk of your development time and money (40% – 70%) will be focused on solving SaaS delivery model problems and not on the value proposition you plan on delivering to customers. This is what accounts for the added 10 months and $400,000 in our initial scenario. Now, if the buck stopped there, our decision maker might be right: ROI is right around the corner. Realistically, you’ve made a first attempt at building a SaaS delivery model and have rolled out a very immature SaaS support stack. Once you launch your product, you’ll start your first maintenance and “new feature” phase of your offering. During this period, you’ll find that the most bugs and changes are coming from deep SaaS architecture problems and change requests. Your time will most likely be diverted away from product change requests (read: innovation) by SaaS stack repair. If you’re successful, you hit some “scale event” and feel a massive “cost pinch” and risk point. The scale problems in this case are most likely a result of poor assumptions in the SaaS stack, or the coupling of your actual application to the underlying delivery model machine. This cycle of maintenance effort and scale events will likely happen a couple of more times, and a couple of years down the road, with thousands of man hours and lots of money spent on the SaaS stack, you’ll reach a point where the stack effort starts to decrease, giving you some breathing room. At that point, you’re done battling fires with the fits and starts of big problems and maintenance phases, but opportunity cost ambiguity kicks in; are you going to exert effort on your core product or boost value in the delivery stack? Odds are you’ll forgo improving the stack (despite the massive value it can inject in your business) in favor of responding to customer demand on domain functionality need in your nifty HR app (since you’ve been distracted by the SaaS stack for so long). Those opportunity costs mount, and potential added revenue or savings opportunities disappear. Think of simple examples like giving your customers the ability to download data backups: is that an application specific problem or a “horizontal” problem for which a stack should be responsible? Do you want to waste effort on this or would it have been wiser to build on a PaaS that either has this functionality or that would introduce it faster than you would? I guess it wasn’t a one-time investment after all! In fact, it seems to be a massive ongoing investment with little predictability or bounds. This discussion hasn’t even touched on the maturity concept (for example, a “home built” SaaS stack will bump into security problems, bugs, etc. that get resolved in PaaS offerings much quicker because of the speed at which they scale due to aggregation, and the fact that PaaS providers focus solely on solving these problems).

When looking at a PaaS offering like SaaSGrid, you need to understand that paying a utility fee gives you a fully maintained delivery model without the ongoing headaches; one that will evolve much faster than you can imagine, constantly adding value to the guest applications that depend on it. If this isn’t enough, history has shown us great analogies. For example, why don’t people write application servers each and every time they write an on-premises web app? Because it doesn’t make fiscal or logical sense! You just download JBoss or buy WebSphere and go about your business! It’s very difficult to argue that a “home built” stack would be more powerful, less costly, and more able to keep up with market change.

What’s your opinion on PaaS vs. building it all yourself? Does the application server analogy resonate well with you? I’m interested in your feedback!

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 1775+ members and is growing every day; make sure you’ re not missing out and join today!

 

read more