At Firemind we’re incredibly lucky to have a great product team who have worked tirelessly to get PULSE ready for enterprise production as we help existing and new organisations get ahead of the curve for utilising AI in their day-to-day workflows.
Specifically, over the past 3 months, the team have focused on getting PULSE integrated into the AWS Marketplace. The plan being that through the self-service processing that the AWS Marketplace offers, it’ll make it easier for new customers, existing customers, and our partners (such as AWS sales teams) to deploy PULSE into AWS accounts without assistance from Firemind.
This obviously has its challenges, and through these series of blog posts we’re going to explore the business, product, and technical approach our teams have taken to get PULSE fully integrated with the AWS Marketplace.
What is PULSE?
PULSE is Firemind’s popular generative AI toolbox. It allows organisations to quickly get set up with using generative AI across their workflows as short form chat, enriched with a number of connectors and attachments, knowledge bases and integrations, and long form “unlimited” batch IDP processing including visual question and answering (VQA). Find out more here: https://www.firemind.com/pulse/
What is the AWS Marketplace?
The AWS Marketplace is an online software store that makes it easy for AWS customers to find, buy, and immediately start using software and services that run on the AWS cloud. You can access it here: https://aws.amazon.com/marketplace
Why did we choose to integrate PULSE with the AWS Marketplace?
The AWS Marketplace provides software creators (usually referred to as ISVs) with a streamlined channel to reach a large and engaged customer base, while also simplifying many of the operational aspects of software distribution and sales. This allows ISVs to focus on the product itself rather than a lot of the ancillaries such as dealing with subscriptions, etc…
Specifically for us there were several key factors for our decision to integrate with the AWS Marketplace:
- Reduced administrative overhead: the AWS Marketplace handles tasks like customer support, billing, and compliance, reducing the administrative burden on the product team.
- Reach and access to AWS customers: the AWS Marketplace provides us with access to the large and growing customer base of AWS users. This allows us to expand our potential customer reach and sales opportunities.
- Flexible pricing and packaging: the AWS Marketplace allows us to offer PULSE through various pricing models, such as hourly, monthly or annual subscriptions, I’ll talk about this in a future post about how we deal with metering.
- Credibility and trust: being listed on the AWS Marketplace lends credibility to PULSE, as it has been vetted and approved by AWS. This can help build trust with customers who are more likely to purchase software that is available through the official AWS Marketplace, as well as the AWS seller team.
There are many more reasons, but those four specifically focused around PULSE, helped drive the decision to get listed on the AWS Marketplace.
How does one get started with listing on the AWS Marketplace?
Well, you’re in safe hands. Through these series of blogs, I’m going to dive deep into the business, product, and technical approaches that we took to get PULSE integrated.
Firemind luckily have been certified with the SaaS Services Competency, meaning that the team are well versed in building SaaS applications on AWS.
One of the key aspects that SaaS/ISV companies need to consider before they get started is whether their product/tool/service is single-tenancy or multi-tenancy. I won’t go into the detail of the differences as there’s plenty of information online, but these two distinct fulfilment models each come with their own challenges, here’s a brief comparison:
Multi-tenancy
- This generally means that all your customers use the same SaaS deployed into a single AWS architecture (with all the lovely things defined in the Well-Architected framework and SaaS framework such as clear separation boundaries, etc…).
- This means you’re only deploying updates, fixes, new features, to one deployment target, so development becomes a lot easier as there’s generally only one target that’s used by the SaaS platform.
- The challenge here is then resource usage, dealing directly with customers consuming AWS resources that you are accountable for. This includes challenges of noisy neighbours, having to pay cloud costs and then recharge customers, metering, etc…
Single-tenancy
- Generally this means the solution (SaaS, software, etc…) is being deployed directly into your customers’ AWS.
- Technically this is a much harder approach, because you’re deploying remotely and won’t have full control over the services that could be in the radius of your solution. You may not even have access to do the deployment, which could make debugging, updating, customisation a lot harder. Generally this is a much tricker deployment and development process.
- The flipside is then the consumption is occurring within the customers’ AWS accounts and you’re not being charged for it. This leaves you with the ability to then simply charge the customer for your solution instead of all the AWS consumption charges that come with deploying on AWS.
PULSE is a single tenancy application, specifically because we chose the path of ensuring the most secure path when it came to customers’ data.
AWS Marketplace doesn’t natively support single-tenancy full-stack applications like PULSE; by full-stack we mean a frontend, a backend with APIs and asynchronous processes, AWS architecture, and multiple data storage solutions, all built and bundled together to then be deployed via automation.
The best that AWS Marketplace can offer is CloudFormation templates, but that was too simple for our requirements.
So how is PULSE packaged and deployed via the AWS Marketplace?
This was the toughest nut to crack, however, I did say that we’re very lucky to have an amazing team here at Firemind (we’re hiring by the way).
We had to essentially create three types of solutions (including PULSE) to complete the AWS Marketplace integration:
- We had to update PULSE to support a new type of deployment process whereby Firemind were not the ones deploying it via their CICD process. A truly hands off, process that allowed anyone to supply specific information to allow PULSE to be deployed into any AWS account. Furthermore, we had to make updates to PULSE to ensure we capture enough secure telemetry information so that we’re able to correctly meter usage and report it to the AWS Marketplace metering services.
- We had to then create the CICD process as an intermediatory service that acts as an escrow, taking a validated entitlement to a PULSE deployment and fulfilling that entitlement by deploying into a customer’s AWS account.
- Lastly, to allow customers to manage their deployments of PULSE, we had to create a standardised control plane that tightly integrated with the AWS Marketplace to manage all the telemetry information, all the AWS Marketplace APIs, and provide users with full access to manage their PULSE deployments (deploy, update, destroy).
Essentially now, when a customer heads over to the AWS Marketplace and subscribes to PULSE, they will be onboarded onto the control plane, we call this the PULSE Console. From there they’re then able to manage their deployment of PULSE for the entitlement they have purchased through the AWS Marketplace.
In the next post I will dive deep into the end to end architecture of this control plane and how we made certain decisions based on requirements of the AWS Marketplace. In further posts I’ll cover the CICD aspects and also the business implementations such as picking the pricing and fulfillment options, and dealing with metering.
By the way, Firemind has helped a number of our SaaS customers expand their offerings by integrating their solutions into third party marketplaces such as the AWS Marketplace. If you’re interested to see how Firemind can help, head on over to our SaaS offering page and get in touch.