PULSE’s console
In the last post we explained why Firemind made the decision to have PULSE as a single tenancy application. This created a number of hurdles with AWS Marketplace as the fulfilment options do not include the ability to just deploy a single tenancy application with ease. Therefore, given that there is a SaaS fulfilment (delivery) option, it was clear that we had to build a standardised control plane (console) for the administration of PULSE deployments.The fulfilment flow
In the previous blog post we mentioned how an entitlement to PULSE allows one to deploy PULSE into an AWS account of their choosing. This approach was specifically chosen to allow the integration with third-party marketplaces such as AWS Marketplace.
The flow is quite straightforward:
- A transaction occurs, for PULSE this is based on a contract with a minimum usage baseline, we’ll refer to these as dimensions in future blog posts.
- Fulfilment then validates the transaction and completes the contract.
- Entitlement is then created based on the fulfilled transaction, its contract and usage baselines.
- A deployment is then possible per entitlement. Metering then occurs through this deployment to update the usage baselines on a daily basis.
What AWS Marketplace manages for PULSE
In simple terms AWS Marketplace just handles the transactions on our behalf. This means the initial contract setup, all billing (contract and metered).
AWS Marketplace does not handle any of the onboarding, customer sign up, CRM submissions etc…
Think of it similar to what Stripe or PayPal do, but instead of asking the user for payment details, payment is completed via AWS account billing, creating a simple consolidated experience.
This means that any fulfilment process requires the developers (specifically relating to SaaS products) to create the onboarding experience for their customers.
Race conditions
In the AWS documentation there is some ambiguity around how successful transactions notifications are provided to the SaaS service, in this case the PULSE control plane.
What AWS doesn’t document here is that the SNS notification and the customer’s postback are actually a race condition. If we review some of the example code provided by AWS:
According to this code, it expects that there’s a DynamoDB record to exist that we then update when the SNS notification is received into our consumer service.
And with this code, we can see the initial creation of the database record is part of the customer post-back from the AWS Marketplace transaction process.
However, this isn’t the case. There is no guarantee that the user or the SNS notification could come first or second, so one gotcha to be aware of is you need to expect this race condition.
For example, if the customer were to transact on AWS Marketplace and then immediately complete the setup by pressing the postback link, then the postback process would have to create the initial database item.
However, if the customer were to not immediately press the postback link, let’s say because they had a meeting or something happened, then the SNS notification consumer would receive the notification ahead of the postback, and therefore create the initial database item.
So the approach that we take here at Firemind with PULSE is to create a standard library helper that does an “upsert”.
End of contracts
One of the key purposes of the SNS consumer (specifically about passing the messages into SQS), there are number of messages that allow us to then deal with any billing changes that occur on the AWS Marketplace side.
These messages ensure that we are able to deal with any contract changes, and when there’s a cancellation, this requires the concept of having to pull down a deployment of PULSE and look at removing the entitlement that was made available when the AWS Marketplace transaction was fulfilled.
In the next post I will dive deep into the CICD aspects and also the business implementations such as picking the pricing and fulfilment 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.