What does a traditional on-premises software vendor need to do to build a cloud solution for BYOD? You might think the easiest approach is to run a single-tenant on-premises instance in the cloud.
In this architecture, the vendor would run one instance per customer. The supporting logic for this is that "the how" doesn't matter if you can make the operational aspects transparent to the customer:
(i) Setting up a new tenant
(ii) Adding capacity for scaling the instance
(iii) Doing updates on the instance
(iv) Subsequent troubleshooting (as necessary) on the instance
While this may be a good short-term strategy, it is NOT a good long-term strategy. First, for every new customer, there are often at least seven other organizations that want to kick the tires before final purchase.
Key questions here;
(i) Can operations be automated to essentially throw away seven out of every eight instances?
(ii) Can provisioning procedures be streamlined to recycle those other seven instances cost-efficiently?
(iii) How do you monitor across the cloud to spot when one instance is running out of capacity?
(iv) How then do you add resources to just that instance? Does it need more database space? Does it need more storage? Does it need more processing power?
If that weren’t enough, let’s quickly review update considerations. In a BYOD scenario, an update happens nearly every month - an end user brings in a new device, or an operating system is updated.
(i) Updates across potentially thousands of instances require significant IT resource. Consider just how many engineers will you need to verify that each instance has been properly drained of users?
(ii) Assuming IT successfully completes that, they then need to schedule the update, and hope that each update goes smoothly. (Since there may be thousands of instances there are literally thousands of configurations and in turn, thousands of times when an update may not go smoothly.)
(iii) How do you even test whether an update is going to work?
Last but certainly not least, what about ongoing troubleshooting? How do you know when there is a problem with a particular instance? How does operations get its hands on the necessary log files to trouble-shoot that instance?
Clearly there are significant operational complexities involved, and when compounded across of thousands of concurrent instances, results in an IT resource demand that simply isn’t cost effective. By way of comparison, a single version, multi-tenant code base makes many of the operational aspects significantly easier.
A good multi-tenant solution leverages a single version of code for most if not all customers. A single version of code eliminates the need for provisioning unique storage for each tenant, and eliminates the need for new servers for each new customer. Additionally, shared capacity across all tenants ensures that operations can efficiently monitor the overall capacity and add more capacity as needed. Updates are far simplified in this architecture too, eliminating the need to manage updates across thousands of instances. Testing updates becomes a breeze, since you simply need to test against one system. Lastly, ongoing monitoring for potential problems is far more efficient, enabled by a global view across all shared tenants.
In summary, an on-premises solutions vendor can make a short term cloud solution available by hosting software for each tenant. However, the only viable long-term solution is a single version, multi-tenant architecture. For enterprise mobility, we believe that the right 100% cloud solution is Workspace as a Service.