Selling an AMI and a CloudFormation template as an alternative to SaaS
We have been selling software through AWS Marketplace since 2019. Selling SaaS is very popular nowadays, and most software vendors are moving to this model. However, we learned that there is a promising alternative to SaaS: Selling software bundled into a virtual machine image (AMI) together with the Infrastructure as Code template needed to run the software in a secure, highly available, and scalable manner.
In the following, I will share our success story and discuss why selling an AMI and CloudFormation is a promising alternative to SaaS, in my opinion.
In 2019, we decided to sell marbot, a Software-as-a-Service solution for AWS Monitoring, through the AWS Marketplace. We liked the idea that the charges for marbot would appear on our customers’ AWS bills instead of requiring a credit card.
Shortly after, we released bucketAV, a solution for scanning S3 buckets for malware, on the AWS Marketplace. In this case, we are not selling SaaS but an AMI together with a CloudFormation template.
In 2022, we released another product: HyperEnv for Jenkins, a highly available and scalable CI/CD infrastructure. The solution is based on an AMI and a CloudFormation template as well.
Over the years, our sales started to grow slowly but steadily. As we bootstrapped our company, we spent most of our time consulting to generate a cash flow. In 2021, selling software has become our primary business, and growth accelerated significantly. We are proudly serving more than 500 customers worldwide. That allows us slowly step back from consulting work those days.
So how does selling software on the AWS Marketplace work?
The AWS Marketplace supports the following product types:
- AMI with CloudFormation template
- SageMaker model
- Professional Services
In the following, we will focus on the AMI with CloudFormation template product type.
The following figure illustrates how selling an AMI and CloudFormation template product works. The vendor provides an AMI and CloudForamtion template via the AWS Marketplace. The customer spins up the infrastructure described in the CloudFormation template by creating a CloudFormation stack and waiting for the automation to create all the required resources like a VPC, an IAM role, an auto-scaling-group, an SQS queue, and many more. AWS charges the additional software fee for each EC2 instance based on the vendor’s AMI.
In the following video, I demonstrate the process of purchasing and spinning up a product based on an AMI and CloudFormation template.
Based on our experience, I will compare selling SaaS and AMI+CloudFormation in the following.
Looking for a new challenge?
From a vendor’s perspective, it is much easier to implement a solution and bundle it into an AMI and CloudFormation template than to build a system to serve SaaS customers.
- No need to worry about multi-tenancy and to isolate the workloads of different customers from each other.
- No need to implement rate limiting and throttling to avoid a noisy customer affecting the experience of others.
- No need to implement quotas or billing for resource consumption like storage and traffic.
There is a huge difference in complexity between our SaaS and AMI+CloudFormation products. An AMI+CloudFormation product is much easier to implement.
SaaS shines when it comes to onboarding new customers. Creating an account and getting started is typically done within a few clicks.
How does onboarding work with an AMI+CloudFormation product? Aren’t we burdening the customer too much by requiring them to provide the entire infrastructure and deploy the software? In former times, the customer needed to go through endless pages of installation instructions. Besides that, each customer had different starting conditions, think of the network architecture, virtual machines vs. bare metal machines, and so on. So each customer ran into different problems during the installation. But today, it’s different! The vendor delivers a CloudFormation template that spins up a production-ready infrastructure tailored to the needs of the software.
For example, getting started with bucketAV takes less than 30 minutes. The CloudFormation template includes all the required resources and spins up the whole infrastructure in about 15 minutes. Only a few manual steps are needed to get the malware scanning for S3 buckets up and running. Even compared to our SaaS product, that’s a pleasant onboarding experience.
In contrast to SaaS, the vendor does not need to operate a production infrastructure for an AMI and CloudFormation-based product. So no need for on-call shifts and also no need to provision and pay for AWS resources.
On the other hand, the customer is responsible for operating the solution. However, Infrastructure as Code and automation allow the vendor to deliver an infrastructure that is very easy to operate. A few examples.
- CloudWatch: alarms and dashboards for monitoring
- Backup: backups to make sure customers are not losing any data
- Auto Scaling Group: highly available infrastructure that is capable of recovering from failure automatically
- KMS: encryption-at-rest to fulfill security and regulatory requirements out-of-the-box
- Auto Scaling Group: auto-scaling to make sure the infrastructure adapts to the workload automatically
What’s left for the vendor is to provide outstanding support in case customers have questions or experience issues.
The customers using our AMI+CloudFormation products are often surprised about the production-readiness of the infrastructure we provide with the help of the CloudFormation template. Our customers rarely need to solve incidents manually. One example is a CloudWatch alarm indicating that the maximum number of instances cannot handle the workload anymore, which requires the customer to increase the parameter.
A challenge of providing SaaS is data gravity. Moving data around is causing traffic costs and engineering efforts. That’s especially a problem for data-intense workloads. As a SaaS provider, you might be able to overcome this issue by deploying your infrastructure close to your customers. For example, by deploying your system into the most used AWS regions. However, doing so increases complexity and costs.
In contrast, when customers deploy an AMI and CloudFormation product into their accounts, the solution lives close to the customer’s data. No need to move data around.
Our product bucketAV processes large amounts of data stored on S3. As the customers deploy our solution to their AWS accounts in the region they are using to store data; network traffic is free of charge.
An undisputed advantage of SaaS is that vendors learn a lot about their customers. Which features are used? What kind of data is processed? The vendor owns the data to answer those questions.
When shipping a solution bundled into an AMI and CloudFormation template, the vendor misses the foundation for data-driven decisions. Collecting the required data is complex and probably not appreciated by the customers.
We know a lot about the customers of our SaaS product. For example, we check for the most common types of monitoring alarms when deciding to implement a new feature. In contrast, the only inputs we have to make decisions about features regarding HyperEnv for Jenkins are our customers’ feedback and support emails.
A vendor should avoid storing and processing sensitive data whenever possible. By the way, the GDPR even requires vendors to store data only when necessary. When vendors deliver their software bundled into an AMI and CloudFormation template, vendors do not need to store any customer data in their AWS accounts. So the vendors are reducing the risk of leaking or losing customer data.
On the other hand, the SaaS model requires a lot of trust, as the customer needs to hand over data to the vendor. Therefore, the vendor needs to build trust, for example, by presenting certifications like ISO, SOC, you name it. On the other side, the customer will ask many questions during the procurement process to find out about the security and operational excellence of the vendor’s system and team.
When providing a solution that the customers deploy to their AWS account, the data does not leave their area of control. Customers have full control and ownership of the data. In my opinion, that’s a big plus for both sides: the vendor and the customer.
The customers of our AMI+CloudFormation products keep telling us that one of the reasons why they decided to use our solution was that data does not leave their AWS accounts.
In my opinion, selling software bundled into an AMI and CloudFormation template is a promising alternative to the SaaS model. From the vendor’s point of view, the complexity decreases as there is no need to develop and operate a sophisticated SaaS-enabled system. Customers like that data is not leaving their AWS accounts, which keeps them in full control.