Azure Marketplace series: A deep dive into the billing system

In the previous article of this series, "Azure Marketplace: How to list your cloud offering successfully", we generally introduced how to publish your SaaS offerings on the Azure Marketplace. In this article, I will dive deeper into Azure Marketplace’s billing system to help you understand how you can let Azure know end users’ usage and bill them properly.

The billing model

As mentioned in the previous article, you need to configure your offering information in the Microsoft Partner Center. This applies to the billing information as well. Before you get started, here are some concepts related to billing that you must understand.

The offer: The SaaS offer that you are about to launch. The following picture is an example of all the offers that we have created.
Plans of the offer: A plan defines an offer’s scope and limits, and the associated pricing when applicable. One offer may have multiple plans, which will be shown to end-users upon their purchases.
Pricing models: The pricing models of each plan can vary from business model to business model. You can choose recurring subscriptions or usage-based pricing. Please note that if you choose a usage-based pricing model, you can only configure up to 30 billing metrics, and you cannot modify them after the offer has been launched.

Simply put, once you have configured the offer, offer plans, and pricing models, and published your offer, Azure will bill users based on the usage you have uploaded to it.

Basic billing settings should be enough for simple SaaS offers. For example, for a news service with a fixed monthly subscription fee of $20, the developer only needs to create a monthly plan in the Azure portal that charges every subscriber $20 per month.

There are also slightly more complex situations. For instance, an instant-messaging service, where there is a fixed monthly setup fee of $10 and each new message exceeding the quota is charged $0.001. Under this circumstance, the setting is now as complicated, you simply need to set up the basic monthly fee and add a few more usage metrics.

But for vendors that want to offer infrastructure software in the Cloud the situation of a lot more complicated. Database as a service (DBaaS) is essentially part of SaaS, but the pricing model of DBaaS is more complicated, especially for distributed database systems like NebulaGraph.

Here are some of the challenges we had faced.

Vendors often need to provide different types of instance options to meet the needs of users in a combined manner according to their different levels of data volume. Different instance options also mean different usage metrics for us. For example, NebulaGraph adopts an architecture that is called “the separation of storage and compute,” and each storage or computing layer should be running on their according to the types of instance.
As a software vendor running in the cloud, our cloud service will use a lot of cloud vendors’ resources, and the consumption of these resources will eventually need to be paid by end-users. For example, the size of the disks used will be different according to the amount of data, and then the amount of data stored will be different according to the frequency of access, and eventually, the use of network traffic will be different, similar to the usage metrics billed based on on-demand use. This leads to a problem: it is difficult for ISVs to charge these on-demand resources to a fixed amount per month for users to pay. And it is not a good idea to add more billing metrics based on that, because you can only add 30 billing metrics.

These are the real issues we encountered when launching NebulaGraph Cloud on the Azure Marketplace. As a partner, we also gave Microsoft feedback on some of the issues we encountered, but this will be a long-term process, so we have to look for workarounds. For example, regarding the limit of 30 billing metrics, what you can do is merge and abstract existing billing metrics. For example, different instance configurations, whether it is 4 cores 16GB, or 8 cores 32GB, if you see it from a perspective based on instances, you will need as many metrics as the number of your instance configurations. But if you abstract it, the metrics are simply the number of cores, and the size of RAM, and the storage, significantly reducing the billing metrics.

Reporting user usage to Azure

After defining your product plans and the billing model of each plan, you need to find a way to tell Azure how much a billing user has used in each billing period. This step is done by Azure’s Metering API, using which you can send usage data of each user in a fixed timeframe and Azure will deal with the billing. This means that ISVs don’t need to deal with the calculation of the charge, and what they only need to do is to report users’ usage to Azure properly.

In the previous article of this series, I mentioned that you have to update users’ usage data to Azure’s billing system within 24 hours and that one billing metric can only be updated once within one hour. You may encounter a duplicate error if you try to update twice within an hour. Other than that, the more important thing that ISVs have to pay attention to is the accuracy of users’ usage. Here are some of our tips.

Use Azure’s API directly to get the usage of its resource data, and do not store the usage data yourself. This sounds simple, but we need to know explicitly the current resources used by each user, and whether there is a ready-made cloud vendor interface for us to call to get to. Once we can't get it, we need to be prompted to modify the current way of allocating the use of resources based on users, which often requires modifying the service architecture.
Although it is technically feasible to store the usage data by yourself, the cost of just keeping records of the data used by users will take up a lot of overhead. Plus, compared to Azure, your own usage data will probably become inaccurate, resulting in inconsistent data with vendors on both sides.
Pay attention to those usage data reported on demand, such as traffic, blob object storage. Even in an hourly usage cycle, the actual usage interval of these data will have many cases. For example, if a user uploaded a file in a certain hour, and then deleted it immediately after finishing using it in a few minutes, you need to accurately record the usage of the user to avoid that they may be overcharged.

Sales and discounts

For newly-released SaaS products, vendors usually want to reach the first users as early as possible, so they often adopt sales or discounts as a way of promotion. For example, selling services at a discount of 50%.

However, there is no way that you can configure discounts in the Microsoft Partner Center. The only workaround you can find is to add a new plan that has a price of 50% of the original plan. But this is not sustainable, because if you only want to offer the discount to users for the first year of their service, there is no way that you can change the pricing of their purchased plans afterwards.

Our solution to Azure’s inflexible billing system is adding a standalone billing metric called “service credit” on our end. This billing metric is different from the billing metrics we defined. It solely serves as a buffer metric that enables us to control users’ usage more flexibly. For example, if we want to give new users a 30% discount for one year, we will give them service credits that are equivalent to 30% of their billing amount so that they are essentially paying 70% of the amount of their bills.

This feature is achieved by taking advantage of the fact that we can report resource usage data to Azure. When our service credits can offset part of the resource consumption, we choose not to report the amount of resources offset, so that the user will not be charged for the amount.

Conclusion

In summary, Azure Marketplace provides a backend configuration system that can be adapted for all types of SaaS products. But a general-purpose platform like Azure cannot take into account the more detailed and specific needs of each SaaS product beyond the most basic general requirements.

Ultimately the decision you need to make is either to simplify your SaaS product to better fit the backend configuration and billing model it currently provides, or to add a workaround logic layer between you and the Azure platform based on your needs. In my personal practice, I prefer the former, because the platform itself is being improved and enhanced, and adding workaround code too early is not very easy to maintain once the platform is updated.

But the reality is always less than ideal. Sometimes you have to use workarounds to meet the needs of your product. I would advise you to think ahead about how to maintain your workarounds when building them in case the platform's rules change.🤝

NebulaGraph Cloud is currently available in the Azure Marketplace and it is in a beta period that offers a generous 70% off for beta users. Sign up here to get the offer if you are interested.

About the author

Jerry Liang is a technical lead at NebulaGraph’s Cloud division. He and his team are behind a series of NebulaGraph’s visualization tools such as Nebula Dashboard, Nebula Explorer, and Nebula Studio.