This post was inspired by a post from James Urquhart.

One of the key challenges with public cloud, as far as perception is concerned, is the multi-tenancy problem regarding security, reliability and data privacy.

Multi-Tenancy Defined

Of course, the definition of multi-tenancy in a cloud platform itself is confusing.  Is something multi-tenant at the application, platform, virtual or physical infrastructure, level?  Each of these has potential benefits and concerns depending on a customer’s requirements.

Security- Software as a (Single Tenant) Service?Depending on the customer and the application requirements, it may be quite possible to run parts of it using multi-tenant infrastructure at an application level (e.g. DNS, e-mail), but have a need to run other parts in a single tenant infrastructure (e.g. the database or web server). 

Realistically, no customer just wants IaaS intending to run all services themselves.  It wants one consistent platform through which it can consume services in a utility like manner.  This is something service providers just starting to roll out IaaS need to wise up to fairly quickly. 

Multi-Tenant Challenges

The challenge until now has been that if you want to run anything at an application level, single tenanted manner you have to build and deploy the application yourself on top of a raw infrastructure platform, unless you can find an ISV offering that service. So to remove the (perceived or otherwise) risks of multi-tenancy, you unfortunately remove some of the benefits around scalability, risk management, knowledge required, etc.

You might then ask what happens if you need to run a database service, but lack the skills/time/willpower to do so, but equally don’t want a completely multi-tenant shared service for it? Or, if you are an ISV with a traditional software architecture, looking at the possibility of building out a SaaS solution, there could be significant investment and business risk required to develop this.  Put simply the ability to move from a single tenant to multi-tenant architecture is not a simple one.

As an ISV moving to a model like this, as well as the technical overhead, you have the issue of how to bill for the service.  Rather than a fixed fee, you need to look at ways of monetizing your software on new usage models and bundles.

Another Option – Software as a Single Tenant Service

What if there was a third way a ‘software as a single tenant service’ if you pardon the pun? For example, the ability to deploy, upon demand, a single tenant application e.g. Hadoop, MySQL or a load balancer, which you could then consume as a service with your specified security, privacy or performance settings specific to your business, all without having to worry about either the management overhead or multi-tenancy problem.  You could then combine/compose multiple sets of these services into a platform upon which to build your application, with one single portal and bill from the service provider for your entire usage.

Equally the ISV involved could then get real world usage data back from its customers enabling it to look at new monetization models that would be successful in a SaaS model.

This is a step above existing virtual application deployment capabilities, as the management responsibility is shifted to the service provider (or a trusted third party/ISV of the service provider), which truly enables it to be delivered ‘as a service’. 

Is this the natural next step to close the gap delaying cloud deployment for some companies? Does this help ISV’s wanting to move ‘into the cloud’, or is looking backwards rather than forwards?  Let us know your thoughts.





 

 

 





 

Image provided by StevenTom 

 

 

Tags: , ,