Share via

The "Service Delivery Platform"

  • Article

Gianpaolo has recently published his summary from SaasCon '07 here.  Even though our session was about the "Anatomy of a SaaS Application", and that is mainly how to build an efficient SaaS solution, at the end of the presentation we did cover a little bit of our thoughts on the "hoster side for SaaS".

As I'm sure you all already know, the goal of SaaS delivered apps is to increase efficiency and lower costs by achieving high levels of economy of scale. And this of course is not free and has to be explicitly architected into the solution.

One typical design pattern to drive economies of scale is “single instance multi-tenancy” as demonstrated in LitwareHR sample app.

But there is another opportunity for increased efficiency through higher reuse and that is through the use of an underlying Service Delivery Platform (SDP) .

This is of course not new. A lot of existing as well as new actors in the hosting space are quickly building very compelling capabilities (like the Apprenda folks I met during SaasCon)

Similarly to what an Operating System (OS) offers to applications (providing common and general purpose subsystems like storage management, execution, memory, communication, etc) an SDP will provide the common infrastructure and services required by SaaS delivered solutions to operate with agreed SLA and with maximum efficiency.

We've been doing this for ages, haven't we?. Developers are constantly factoring out common components from their solutions into “horizontal” application frameworks, and then many of these eventually land on a "platform" like .NET as illustrated in Figure A.

Our argument is that leveraging this common underlying infrastructure allows ISVs to spend more time on the domain specific part of the application which is by the way, what their customers are paying for. Have you ever bought a solution just because it excels in runtime exception handling?   

Figure A: Factoring out components into a common "platform"

An SDP seems like a natural evolution in this direction then, becoming an "OS for SaaS delivered apps" and providing what every SaaS solution of a given family needs: billing &  services, onboarding, provisioning, etc. but also normalizing an application architecture (Figure B).

For example, there are no apps out there without runtime exception handling and logging (well, there shouldn't be at least :-) ), however if App A and App B decide to handle and log exceptions in a different ways (say App A logs to a file and App B logs to the Windows Event Log) the ability the hoster has to efficiently manage these apps is decreases.

It's not that the hoster can't manage them, the key word is efficiency. Each App is an exception and therefore hoster processes can't scale.

There's a quite an interesting set of services that can be factored out and offered in a SDP:

Notice that this trend implies some restrictions. In this scenario, the ISVs will appear to have less control of how things are architected.  This is true, but ... so what?

If an ISV needs an esoteric and specialized hardware and software configuration they will have to pay for it (either to someone to do it for them or by self-hosting). If an ISV can adhere to the hoster architecture (the SDP), they will benefit for much lower running costs:

 

I sometimes hear ISV developers say that "you (me) are advocating for less creativity, you are cutting my creativity wings". And I'd argue that I'm advocating for refocusing creativity on the part of the app that your customers really care about and pay for. If you want to write a ThreadPool class, well... apply for a job at Microsoft :-).

Comments

  • Anonymous
    May 09, 2007
    A couple of my colleagues from across the pond have recently blogged about SaaS and the so-called Service

  • Anonymous
    May 15, 2007
    I've heard that comment about architecture conformance... clipping my creative wings. I tend to push back with the perspective that an architecture structure helps focus the creativity into areas where it will have the greatest affect as opposed to being creative in areas that have been addressed by many before. It still amazes me the number of people who think they have "created" two-phase commit. Every time there is a large shift in technology, half the time is spent reinventing the technologies of the previous generation. Sorry, that's not creativity.

  • Anonymous
    May 15, 2007
    The comment has been removed

  • Anonymous
    May 18, 2008
    king Joe pace <a href= http://joe-pace.barerube.cn >pace Joe worship</a> [url=http://joe-pace.barerube.cn]pace Joe worship[/url]

  • Anonymous
    May 22, 2008
    shake Joe pace <a href= http://joe-pace.barerube.cn >Joe pace the</a> [url=http://joe-pace.barerube.cn]Joe pace the[/url]

  • Anonymous
    May 25, 2008
    shake Joe pace <a href= http://joe-pace.barerube.cn >Joe pace the</a> [url=http://joe-pace.barerube.cn]Joe pace the[/url]