I recently had a conversation with a start-up company that was planning to launch its software in the cloud. In our conversation, we talked about different business models for cloud software. The conversation stuck with me, and I’ve been thinking about the different business models and the impact of them since.
In the past two and a half years, I’ve worked with a number of independent software vendors (ISVs) bringing their software to the cloud. The decision on how to bring their software to the cloud is often a hybrid discussion between technology and business. Choosing a business model has implications on the technology, and the technology can have implications on the business model. I wrote this post to structure my thoughts about it, and to hopefully inspire ISVs building cloud applications.
Although most of my technical writing is focused specifically on Azure, the models presented in this post are cloud-agnostic. You can apply these equally well to Azure, AWS, GCP, Oracle and IBM cloud.
This post is targetted torwards independent software vendors building cloud application, less towards customers buying cloud software. The goal of this blog post is to share my thoughts about cloud business models, and I’m hoping to spark a discussion about the different models. Feel free to reach out to me on Twitter and/or LinkedIn with your thoughts.
Any examples used in this post were obtained using public information. None of the vendors mentioned in this post have sponsored.
Different business models in cloud software
From a high-level perspective, there are four different business models to deploy cloud software. There are alternative and hybrid models possible that will be discussed after the four models are discussed.
In this model to compare the different business models, we’re looking at them through two lenses: one is the lens as to who provides the cloud infrastructure (account/subscription) and who manages the software. Both can either be provided by the customer or can be offered by the software provider.
Going from bottom left to top right, these are the four models:
- Licensed software: In this model, the software provider only provides the software, potentially with deployment templates or a marketplace offering. The customer is responsible for managing the software and infrastructure and also provides the cloud infrastructure. Very typical examples of this business model are network virtual appliances, such as a Palo Alto Networks or a Barracuda Firewall. Another example of this is the self-managed deployment of Elasticsearch on Azure.
- Managed hosting: This model is an uncommon model, where the software provider provides both the software as well as the cloud infrastructure, but the customer is responsible for managing the software and infrastructure. I didn’t find a public example of this offering, but I have worked with companies that offer this as an option to customers.
- Managed service: In this model, both the software itself as well as the management of the software is provided by the provider, while the customer is responsible for providing the cloud environment (account/subscription). These offerings can be made available as a managed service through the marketplace, or managed services can be sold as an add-on by the provider. It’s common to see a partnership here between the software company and a managed service provider. Examples here are for instance Dynatrace Managed, ChaosSearch VPC (being software provider managed), and the Managed vWAN by Vandis in the Azure marketplace (being partner managed)
- Software as a Service: Finally, in a software as a service model, both the software as well as the cloud infrastructure are provided and managed by the provider. Within the SaaS business, there are two popular deployment models, either multi-tenant/shared, or single-tenant/dedicated. While consumer SaaS companies often don’t disclose which cloud provider is used, some B2B SaaS companies share which provider they are using; and some even provide their customers the option to select on which cloud provider to deploy their instance of the SaaS software. There are numerous SaaS providers out there, including Elastic cloud, Snowflake and many others.
Licensed software and software as a service are by far the most popular models out there. Based on my experience, managed services are gaining more and more traction in the cloud as well. It is preferred by some customers, typically in highly regulated environments, because this allows them to gain more control and visibility into the software they’re running, while not having to deal with the day-to-day operations and management of the software and its infrastructure. The managed hosting model is a niche solution that I don’t come across very often.
There are hybrid models possible. One of the examples that comes to mind is Citrix Cloud. With Citrix cloud, Citrix manages the control plane of a typical Citrix deployment as a SaaS, but the actual worker VMs are hosted in a customer’s cloud environment or on-premises and managed by the customer themselves (packaged software).
Another hybrid model is that of ChaosSearch. They offer an ELK stack ( Elasticsearch, Logstash, and Kibana) as a service (SaaS) while keeping data within your own object storage buckets (not even packages software, it’s just using your own storage bucket).
Now that we’ve explored the different possible business models, let’s have a look at a number of important considerations.
Considerations for cloud business models
In the previous section, we’ve explored the different cloud business models through a simplified view, that of who provides the cloud platform (account/subscription) and who manages the software.
There are important considerations for each of these business models:
- Data ownership: Depending on what type of business you’re in, data ownership could be very important to your customers. If you are a data and analytics company, your customers might be very uncomfortable handing over their data to you. In some cases, it might be easier for you to offer your software in a customer’s cloud account (i.e. licensed software or managed service), rather than to convince your customer to trust you with their data.
- Performance management / scaling: Maintaining adequate performance of your softare can take on a couple of different forms. In its essence, performance management means making sure you can consistently deliver the expected performance to your end-users. When your customer is managing your software, they are responsible for making sure the performance is up to par; whereas if you are managing the software, you are responsible for its performance. When you need to scale out an environment, somebody needs to pay for the additional infrastructure costs.
- Security risk: In the cloud, security is a shared responsibility between the cloud provider and its customers. If you as a software vendor provide additional managed services, you are taking on part of the security responsibilities and risks. If you manage or host critical customer data, you are responsible (at least in part) for the security of the data. In the case of a data breach or any other potential incident, you might be responsible for that incident and held liable for its impact.
- Cloud cost management: At the end of each month, somebody has to pay the cloud bill. This will either be your customer directly or you as a software company. If you as a software vendor provide the cloud infrastructure, you take on the responsibility to pay the cloud bill. Typically, SaaS pricing is provided irrespective of infrastructure spend. For instance, you license your software on a per-user basis, while cloud providers charge you for infrastructure. If one of your customers causes an unexpected higher service utilization, you as the provider are responsible for that bill.
- Management overhead: When you provide the management of your software, there is a certain overhead involved. If you provide your software only in a multi-tenanted SaaS environment, you’ll incur less overhead versus offering your software as managed services in each of your customer’s cloud accounts. This can have a major impact on your ability to be profitable with your managed services. This management overhead ties in closely with the ability to standardize your offering.
- Standardization: If you offer your software as a SaaS platform, you have the full capabilities to standardize your offering across all of your customers. If you however deploy in an existing customer’s environment, you’ll need to make your software work within their environment. Customers might have certain policies and network architectures in place that limit some of the deployment models. For instance, it’s a common practice for customers to route inbound/outbound traffic in their VPCs/VNETs through a 3rd party firewall. If you deploy and manage your software in such an environment, you’ll need to make sure you can define which rules need to be present in those firewalls, and have a procedure in place to verify those rules are in place in case of a potential network outage.
- Economies of scale: An economy of scale refers to a decrease in unit cost when scaling an operation. The more you sell something, the less each of that something will cost you. If you consider this for instance in a SaaS model, there typically are certain fixed shared costs for running a platform, and the more customers you have on your platform, the lower the unit cost will become. The economies of scale exist in each of the business models, with the biggest economy of scale existing for licensed software. Whether you sell 100 copies of your software, or you sell 100.000, since there’s almost no direct increased cost, you have a great economy of scale. Economies of scalies can also be found in cloud packaged software, managed services and SaaS platforms.
As you might have deduced from this list of considerations, there isn’t a one-size-fits-all best approach for distributing your software. For some ISVs and for some customers, a SaaS platform might be the best approach to sell your software. For other businesses and other customers, licensed software or managed services approach might be best.
I recommend companies to analyze the different business model options and pick the one that works for their business and that resonates with their customers.
The risk of offering multiple different business models
In the last section, we discussed different considerations for the different business models. There isn’t a one-size-fits-all perfect business model.
Some companies offer their software using different business models. For instance, they might be selling both a managed service in a customer’s environment as well as a full SaaS platform. Although there’s nothing limiting you from selling your software in multiple different models, there are risks of selling your software in multiple models.
As an example of this, let’s look at Azure DevOps. Azure DevOps is offered in multiple models: either as a full SaaS platform (Azure DevOps) or as licensed software (Azure DevOps server). Let me address some of the risks I see with offering different models for customers through the Azure DevOps lens:
The first risk is the toil of having to manage those different business models of your software. For instance, when you have code updates, you’ll have to figure out how to get those code updates to all your modalities. In a SaaS platform, all of this is under your control, whereas in other models you’ll have to work more closely with your customers to deliver software updates.
Next to code updates, you’ll need to provide the right documentation, procedures, and support per version to your customers. A SaaS platform requires a different set of processes as compared to a platform where your customers see/manage the underlying infrastructure.
Azure DevOps handles this by continuously keeping the SaaS version of Azure DevOps up to date, and publishing updates for Azure DevOps Server approximately every three months. There also is dedicated documentation for Azure DevOps server.
Another risk is the risk of competing with yourself and/or confusing your customers with different pricing models. Selling SaaS means you’re selling an end-to-end service, including cloud infrastructure. This might make it seem more expensive for customers to buy your SaaS version versus buying only the software or even buying the software + managed services since in that case, the customer is paying for the cloud infrastructure.
In the case of Azure DevOps, the SaaS version is sold on a per user basis. Azure DevOps Server 2019 can be bought either month-to-month through Azure or via classic software licenses which requires a 3-year commitment. Also, in the server variant, customers need to provide the infrastructure a Windows server license.
Offering different models for your customers can be an advantage since it allows you to overcome potential blockers – but it comes with increased overhead for your organization. When deciding to offer multiple models for your customers to buy your software, make sure you weigh the benefits of overcoming blockers with the costs of increased toil.
Summary
In this post, you found some of my thoughts related to business models for cloud applications. We started with the four typical business models I see in working with software companies and then discussed considerations for you as a software company when choosing a business model for your software. In the end, you found some of the risks linked to picking multiple business models for your software, instead of relying on a single one.
As I mentioned in the introduction, I’d love to get a discussion going around this topic. Feel free to reach out to me on Twitter and/or LinkedIn with your thoughts.