Licensing by consumption: pricing model of Power Platform online services

On the topic of Dynamics 365 and PowerApps licensing changes coming in October 2019, I earlier wrote about the biggest change in how Microsoft is separating the first party applications and the underlying platform in the new Per App pricing model. There’s another aspect in the coming licensing updates that has also caused a lot of concern among partners and customers: the API call limits. While the existence of limits on how much load one can place on the online service are not an entirely new construct, it’s the first time that the amount of API calls available is directly tied to the type of licenses bought.

In their August 29 blog post, Microsoft stated the following:

“A single, integrated approach for daily capacity limits will be implemented to help maintain a consistent quality of service for customers with PowerApps and Flow plans. These capacity limits should not impact standard or reasonable usage of PowerApps or Flow. Organizations that require additional capacity for heavy usage scenarios will be able to purchase add-on capacity and assign it to specific users or processes.”

Updates to Microsoft 365, Dynamics 365, PowerApps and Flow Licensing

The finer details of the new model are outlined in the PowerApps and Microsoft Flow licensing FAQs for October 2019 as well as the Requests limits and allocations pages over on docs.microsoft.com. You should keep an eye on these documentation pages, since further information will be made available, based on the incoming questions from customers. There have already been a lot of blog posts around this topic and I’m not expecting the debate to die out anytime soon. Rather than speculating about what the exact policies will be, I will instead try to set this new consumption based licensing into context with what’s happening in the Microsoft Cloud.

Users aren’t the only thing that matters

USL, user subscription license, has been the dominant model for pricing applications from Microsoft in the online services era. Of course they’ve been a key component ever since the personal computing revolution started with PCs running DOS, then Windows and many productivity applications like those found in the Office suite. The networked computing era extended the pricing models to server software that wasn’t always purely a per-user play, as the complexity and robustness of your back-end services determined how expensive that side was. In the initial wave of SaaS business applications, we saw a return to the simplicity of just paying a fixed fee like $50 per user and getting all of that server stuff covered for you. Oh bliss! Isn’t this exactly the way the cloud should be sold?

Those first SaaS services also were in themselves quite simple. A replica of the server software you could have either in your own closet or the data center run by companies like Amazon and MS. You just offloaded the complexity involved in managing hardware redundancy, backups, storage etc. and instead payed for all that in the USL. This is all fine and dandy as long as the value from the applications can be closely linked to the number of licensed users accessing it. Using CRM as a simple tool to improve sales person productivity might map into this type of cost-value structure. But how about when you take a step further on the digital transformation path and start to actually replace those tasks carried out by human employees with something that is almost fully automated? Hmm, perhaps the PC business model isn’t optimal for a future that looks like this.

Let’s look at some of the new services in the Dynamics 365 cloud. The commercial launch of Dynamics 365 for Marketing in Spring 2018 was a bit of a shock for anyone who always though these applications are licensed per user. Instead, Microsoft chose the model that HubSpot any many other vendors in the marketing automation space apply, by setting the pricing per contact. Yes, initially they were way off with this thinking by applying the pricing logic to the entire contents of the CRM database, but based on market feedback the model was adjusted to now count only for marketing contacts actually used by the specific application (i.e. where business value should be generated). Also, you actually don’t need any Dynamics 365 user license for those marketing people who build the customer journeys and analyze the results, since free user licenses are available to unlock the door into the system. Licensing is done on the environment level, after all.

Dynamics 365 Customer Insights is a CDP (Customer Data Platform, for those not keeping up with the latest acronyms) that allows customers to bring in customer related data from various different sources and unify them into a “customer 360” profile that links all those activity entries into a single view of the customer. You can then leverage big data processing features of a CDP to generate target segments like customers most likely to churn, select them to be a target group in Dynamics 365 for Marketing customer journeys and preserve your revenue streams by holding on to these customers identified by the intelligent machine in the cloud. How is this service priced? Per number of profiles: starting at 100k profiles for $1.5k, so 1.5 cents USD per profile. Any user in the tenant can be simply authorized to access the application, since the dedicated UI doesn’t have any dependency to the USL construct found on the Model-driven application side.

Forms Pro is a professional version of the personal/team productivity app found in the Office 365 suite, storing its data into CDS entities for process automation and data analysis. Do you need a USL for the Pro features? Nope. The pricing is based on the number of responses to surveys, at $100 per 2k, making it $0.05 per response. If you want to listen to your customers and improve business outcomes as a result of that, it’s not about how many people you have looking at the data but rather how smart and how automated your feedback management processes are.

AI Builder will go GA in October 2019. Guess how that’s going to be priced? That’s right: not per user. You buy a capacity license at $500/month for 1M “service credits”. When it comes to machine learning models as a service, with no pre-packaged Dynamics 365 app on top of them, there isn’t even any concept like contact or survey response that would tie the pricing to the physical world. You literally extract value directly from the data you put in there, with the help of apps and automation that builds on top of and integrates with your unique business processes.

The consumption pricing model is already here. Future products in the Business Applications portfolio are more likely to gravitate towards that, rather than finding a user to attach a price tag on.

Sandcastles in the sky and how to draw the lines

In the cloud era, Microsoft can see everything. No, they don’t have employees looking at any customer’s private data or anything like that. What I mean is they have telemetry data on everything that happens on the service, because they are hosting all the moving parts involved. This gives them the opportunity to be very data driven in analyzing how products are adopted, what people actually do with them. It is essentially their own implementation of the digital feedback loop that you see James Phillips preaching to Microsoft’s customers and partners in every keynote he does. There’s the “transform products” part that is all about aligning product features to meet customer needs, but you can be sure MSFT also want to “optimize operations” when it comes to the logistics of delivering the cloud services and how to price them appropriately.

Dynamics 365 is claimed to be the biggest service running on Azure today. Now, even though at Microsoft they both fall under the Cloud & AI that Scott Guthrie runs, there’s not a single bucket where all the costs would be thrown. The more Business Applications products are built that consume data storage and compute capacity, the higher the bill from Azure will be. The term COGS (cost of goods sold) is being used frequently when talking about the resources needed to keep cloud services up and running on these platforms like Azure. Power Platform is a platform on top of another, and while it often uses higher levels of abstraction that its raw Azure counterpart, API calls from the citizen developer PowerApps do turn into API calls against Azure services. Whatever product is generating this consumption must also front the bill.

The vast majority of Dynamics 365 business today is still done based on user licenses, regardless of what our AI & big data driven future may look like. These are sold as SaaS apps you can just sign up and start using, rather than a complex solution that needs a technical architect to build the blueprint for. As such, the message Microsoft wants to get out there (but isn’t always so good in phrasing) is that the app user license should cover all normal usage for real human beings interacting with Dynamics 365 CE. Yes, anytime a user opens a contact form on a Model-driven app there are around 10 API calls made, which count against the quota for that particular user account. All CRUD operations theoretically count, but for an end user you shouldn’t need to count them. This is not the intention of MS.

What is the idea behind setting the API call limits then? Well, the situation is this: the platform has evolved from the early days of being a simple CRM database for sales user productivity improvement into something that can connect OoB to a vast number of external (non-CDS) data sources and run complex automation on this data without anyone sitting in front of their PC and opening those contact record forms. When sold as Power Platform, there will be a massive amount of this non-CRM style consumption of computing resources running on the platform (unless MS completely fails with capturing this new business potential). Building all of this abstraction on top of the underlying Azure services and then giving it a way with essentially a per-identity flat monthly fee just wouldn’t be a sensible business model.

Steve Mordue said in his recent CRM MVP Podcast appearance that one edge case MS discovered was a Lottery company with 2 users that was burning up API calls like crazy, by using Dynamics 365 (can’t believe it was CDS yet) as a process automation system for output/input to other systems. While it’s surely far from a typical customer, it illustrates the dilemma that earlier there really wasn’t any way to purchase just more computing capacity, since the online environments scaled only based on the number of licensed users. Starting from October, there will be a dedicated PowerApps and Flow capacity add-on SKU that is meant for exactly this. If you have user accounts for data integration purposes, for example, then at $50/month you get 10k API requests to use every 24 hours. Just like with the new capacity based Dynamics 365 products, now there is an actual price that can be used in calculations on how much power you need to extract from the platform.

There’s one additional dimension to these API call limits that has not been said out loud but I think is a fairly obvious target: these will be a key method of how Microsoft will finally technically enforce their licensing terms. The eternal debates on how to put that honor based paper license into practice with the customer’s uniquely configured Dynamics 365 system may eventually be over, if MS can align those terms closely enough to what happens on the API layer. I can’t believe they’ll ever get to 100% enforcement, yet this approach of also counting the API calls from the first party client apps to me is an indicator that the future telemetry collected via this new system will one day turn into technical blockers. I can honestly say that it would be a huge relief if we could actually test a solution design in the cloud service and that service would tell us what license is needed – instead of the consultants having to study every little word of the licensing guides and partner guidance documents like they were the bible.

You can’t manage what you can’t measure

That brings us to the more problematic side of this new licensing model. In the spirit of an evergreen cloud platform with a continuous release policy, sometimes things are released on the Power Platform before they are ready for production. On the product feature side this would be called a preview, but when it comes to licensing terms, I don’t think there’s such a concept – but now there would be a need for one. The thing is that Microsoft has first announced the way how it will charge for the consumption of services from its platform, but they’ve said that there isn’t actually a way for customers to track these consumption metrics yet. It’s coming, but it won’t be there for October 1st.

What’s the natural result of a policy like this? FUD, that’s what. It’s the same as if the city officials would put up speed cameras and set a new limit on all the roads, at a time when none of the vehicles would yet have a compatible speedometer to measure how fast they are going. Sure, Microsoft have been saying that they have no intention to start technically blocking customers that go over these limits, but the mere awareness of limits that exist yet are not measurable is naturally making customers nervous. When the recent storage model change of counting database, file and log capacity usage separately was rolled out, it was a similar story of introducing the new metrics only after the new rules were in place. Sure, there’s always the contract periods that won’t effect existing customers immediately, yet I can’t help thinking that this kind of communication practice is just shooting oneself in the foot.

While the timing of how changes are rolled out could be easily improved, what’s more difficult to fix is the discrepancy between how the consumption based Power Platform service usage is measured and how it is billed. Unlike the pay-as-you-go model that Azure uses, Power Platform follows the commerce model of Office 365 where you have to pay for the services in advance. Even with the flexibility of CSP licensing where the monthly volume of licenses can be adjusted quite freely, you still have the burden of preparing for the projected future consumption.

There are areas in the new licensing model of Power Platform products where this upfront payment model can really rub prospective customers the wrong way. The pricing of PowerApps Portals (also the former Dynamics 365 Portals) is an example where it simply does not feel fair to charge per login, in advance, for the behavior of people that are completely outside of your organization and therefore out of your control. If your customers or partners adopt your awesome Portal and there’s a big spike in logins, did you prepare for this best case scenario in your budget? Similarly, if there is very low usage for whatever reason, how much money did you spend on monthly logins that were never actually performed?

Charging by consumption in general is a very sensible model for the new types of business applications, as I’ve explained. It is, however, a very different world compared to the old days of selling a big CRM suite on a per seat basis. I’m pretty sure that it won’t take long for the service telemetry to be made visible to customers in the Power Platform Admin Center, helping them better analyze what’s the cost of running them & connecting that to the business value produced from the automated processes they enable. It will probably be a longer road before we see the Azure style payment model find its way onto the Business Applications side, due to the complexity of underlying commerce engines and contractual legacy. I bet we’re getting there, too, eventually.