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 :-).