So, you want to build a cloud service?

Great! Now, you probably have a million questions on which cloud provider, technologies and patterns you should use. And while those questions are important, in this post I want to go through a few more fundamental questions which I’ve found that people often overlook or misunderstand. While each of these questions have technical implications, in many cases the right answer will be influenced more by your business strategy than any technical considerations.

Your subscription or mine?

Possibly the most fundamental question is whether the solution is intended to be run in your own cloud subscription, or in that of your customers.

A solution deployed into your own subscription is normally categorised as a Software as a Service (SaaS) application, as your customers can use it without needing to own or understand the underlying resources (VMs, databases, etc). This is probably the default model for most new cloud services, and it is increasingly the model expected by most customers (although probably not most enterprise IT buyers). Some of the key implications of this model are:

• You (as the owner of the service) need to directly pay for the resources used by the solution
• Your team must be responsible for deploying and managing the production solution, not just building the code
• You can upgrade, monitor and scale the solution as you wish, but you need to manage customer expectations around availability, data retention, privacy etc.
• You won’t be able to cater for any customer requirements that you didn’t explicitly design into the solution.

The other option is to build a solution that is designed to be deployed to a customer’s own cloud subscription. This normally means packaging the solution as one or more VM images, although there are also ways of including PaaS components into such a solution. This approach is often the easiest way to take a “legacy” ISV solution to the cloud, but it can also be a good option for new solutions that may need to be customised or configured extensively by the end customer. Some of the implications of this model are:

• You (as the owner of the service) are not responsible for (and have no visibility of) the resources used by your solution
• You have limited control over if and when customers apply patches or updates (you’ll need to build/leverage some kind of update service to do this). As such you may need to support multiple versions of your application for some time.
• Customers have full control of the resources on which your application runs (VMs, databases, etc) and can tinker with or break them at will.

It’s worth noting that regardless of which option you choose you have the option to promote and monetise your application using the Azure Marketplace. The “Application Services” category is for SaaS solutions that can be “logically” provisioned in a customer’s subscription (even though the resources run in your own subscription), while the “Virtual Machines” category is for VM images that are used to provision VMs directly within the customer’s subscription.

IaaS or PaaS?

Another key question is whether the application should be built on an infrastructure as a Service (IaaS) platform or on a Platform as a Service (PaaS) stack.

IaaS solutions consist of one or more Virtual Machines which you are responsible for deploying and managing. IaaS services are becoming a commodity, with many providers offering similar capabilities. This makes IaaS solutions relatively portable, but it can come at cost of increased complexity and additional management tasks. Some of the key implications of an IaaS based solution include:

• You can choose to use almost any technology in your solution (OSes, frameworks, programming languages, etc).
• The solution can be made to run in different environments (e.g. on-premises, in different cloud providers, or in different users’ subscriptions) with minimal effort
• You (as the VM owner) are responsible for the health of the VM from the OS up, including patching, monitoring, upgrading, etc.
• Implementing High Availability and Disaster Recovery can be very complex.

PaaS is all about providing higher-level abstractions to developers (e.g. websites, queues, databases etc) that hide the details of the underlying Virtual Machines (even though they are still there). This can increase productivity and reduce complexity, but it comes at a cost of reduced flexibility. Some PaaS stacks can run on arbitrary IaaS platforms (allowing them to be run on multiple cloud providers), while others are tied to a single cloud provider. While some people get concerned about the potential for “lock in”, in practice very few solutions are moved from one cloud provider to another. Some of the implications of PaaS based solutions include:

• Features such as high availability, backup and autoscaling are often provided as a part of the service, eliminating additional complexity and costs
• Components don’t need to be individually licensed or deployed
• You will be constrained in which technologies you can use and how they can be configured
• It may not be possible to run the solution outside of the platform it was designed for.

In Microsoft Azure, we’ve seen most people favour PaaS for new development, but they often choose IaaS for migrating existing solutions to the cloud. It’s also worth noting that IaaS vs PaaS is not a binary decision – in many cases the most sensible option is to mix and match the approaches for different solution components (for example, a PaaS Web App talking to a NoSQL database running on a VM).

Single- or Multi-tenant?

The final question for today is whether to go for a single-tenant model (where each customer’s solution components are deployed separately) or a multi-tenant model (where multiple customers are supported by the same set of components).

A single-tenant solution is the natural starting point for an existing on-premises app, or one that is designed to run in customers’ own subscriptions. Typically this results in a solution with one database for each customer, and it may also involve a separate website for each customer. These may be each deployed to their own VMs, or it may be possible to deploy multiple components for different customers to the same VMs. Some of the implications of a single-tenant solution include:

• The solution may make less efficient use of resources (compared to a multi-tenant solution) and hence cost more to run
• Tenants can be deployed, upgraded and scaled independently. This increases flexibility but also significantly increases complexity. For example you could end up having different customer databases running with different versions of the schema.
• Data and code is inherently isolated, making it unlikely that you will accidentally leak data across tenants. However this also makes it difficult to get aggregate data out of the solution for analytics or similar purposes.

Multi-tenant solutions generally require a bit more care to build, as you need to make sure that the solution supports all tenants while maintaining the illusion to your customers that they are the only ones using the app. However the solution should be easier to grow and manage long-term, and as such this is usually the default option for “born in the cloud” apps. Some of the implications include:

• The solution can make efficient use of resources, although you may need to be wary of “noisy neighbour” problems
• The application will be deployed and managed centrally for all customers. This may limit flexibility for users, for example it won’t be possible for some users to remain on an older version.
• You need to be extra careful to maintain data privacy by not sharing any data across tenants (since everyone’s data will be in the same database or other components).

Conclusion

If you’re building a brand new consumer-facing SaaS application, chances are you want to design a multi-tenant PaaS-based solution that is deployed into your own cloud subscription. However many businesses are dealing with challenges such as an existing code base, an existing customer base and evolving business strategies that can mean that other solutions may be more appropriate. In rare cases it may even make sense to build multiple versions of your solution supporting different models, but this should probably only be considered as a part of a short-term transition strategy.

I hope this post has given some useful insight into these questions and the reasons for choosing one model over another.