In-house vs. external hosting

An ISV that wish to start offering an application throug a SaaS delivery model could choose to move down the stack and host the application in-house (sometimes referred to as “self-host”), requiring the ISV learn how efficiently and securely operate a data centre for thousands of application tenants. A friend of mine is the CEO of an ISV that has sold 80,000 copies of an application as on-premise installation to customers with an average of 2 users. The company is used to send upgrade CDs out and do support to end-users at small businesses. Moving to a SaaS delivery model their skills would have to shift to operating a data centre 24*7 with 160,000 concurrent users and application tenants constantly subscribing an unsubscribing to services. These are obviously two very different skills sets.

Self-host could mean to actually have the data-centre in-house or to have a bunch of dedicated servers located in the data centre of a “classic” hoster who provides very basic services (sometimes referred to as “ping, power & pipe”).

Another option is outsource the hosting to a SaaS hosting provider that offers a complete SHP-for-rent and provide services at a higher level (i.e. providing an application level SLA as opposed to machine or network level SLA).

Some ISVs may even start by buying these services in the start-up phase and then bring these services in-house as they grow their business. As an example a small ISV startup may want to host its application with an application hosting provider in a shared environment (shared load balanced web servers, shared security services, shared database cluster etc). As the ISV grows in size or requirements for isolation get higher, the ISV may move to dedicated hardware within the same data centre or even choose to move the hosting in-house.

Recently we have also seen examples where ISVs that have chosen the in-house hosting model, quickly getting the required knowledge, people and data centre by acquiring a hosting provider.

Build or buy the shared services 

The SHP is both an application run-time platform as well as a set of shared services. For the shared services, the ISV has a variation of the classical “build vs. buy” choice. In the SaaS world, “buy” really means “use/rent with a SLA”. This means that the ISV has a lot of options:

·         build all the shared services (with self-host or outsourced hosting)

·         “buy” the shared services from the same hosting provider that provides the application run-time platform

·         “buy” some of the shared services from the same hosting provider that provides the application run-time platform (such as monitoring) and other services (such as catalog, order fulfillment and billing) from a re-seller or aggregator

·         “buy” some of the shared services from external service providers (example; one SaaS application could send usage data to another SaaS application that implements a billing service).

·         Any combination of the above

Reasons for building the shared sources in-house include:

·         Better and more tailored BI on customer profiles, usage patterns, retention, targeting

·         Higher level of control with features and service level iH

·         Complex tenant management features – multiple levels of tenant relationship (resellers etc)

·         Desire to keep customer and business information away from third parties

·         More cost effective to build and operate this capability themselves

·         Regulatory requirements that cannot be satisfied by third party hosters

Reasons to using shared services from of the application hoster or other SaaS ISVs:

·         Allows to focus on application features to get to the market faster

·         Need market presence and visibility that SaaS aggregators can provide

·         More cost effective to outsource this capability

There are a couple of trade-offs involved in this decision. One tradeoff is about choosing between sharing and isolating. Should the services be shared between multiple ISVs or should it be isolated for a single ISV.

The second is about choosing between developing the shared services in-house and buying, or renting, the shared services.

These trade-offs are never black or white, but instead, it’s more of a continuum, with many variations that are possible between the two extremes.

As an example of sharing vs. isolating, an ISV may choose to share the security services, but not the data services. As an example of in-house vs. outsourced shared services, an ISV may choose to develop the operation support system in-house, use someone else’s billing system.

From an application architecture perspective it’s therefore important to abstract the underlying implementation and location of the service provider away behind a stable contract/interface in order to support changing business requirements.