More Functional APIs Pose Problems for ISVs
Last October, I wrote about the introduction of new Microsoft Graph APIs that come with a consumption meter. On June 2, Microsoft announced that the billing rates (Figure 1) attached to the meters will come into effect on July 5, 2022. No doubt the ISV community heaved a massive sigh of relief and pleasure when they read Microsoft’s text. Or maybe not.
The Graph Export APIs for chats and channel messages are more functional when it comes to extracting information out of the Teams Cosmos DB-based message store. They avoid the need for backups to copy the compliance records captured by the Microsoft 365 substrate and stored in Exchange Online user and group mailboxes. The Export APIs solve the problem in tenant-to-tenant migrations where it’s been possible to move channel conversations from one tenant to another, but not chats.
Consumption Meter Running
The problem isn’t that Microsoft will charge tenants to use these APIs. ISVs must register their app with a valid Azure subscription before their code can use the APIs in a tenant for purposes like backup or tenant-to-tenant migrations. It’s that no one understands the cost implications of using the APIs for an ongoing purpose (like regular backups) or a once-off but extended activity (like a tenant-to-tenant migration).
Tenant administrators can get some idea of the message volume generated by Teams, but the rubber hits the road when consumption meters rack up costs that must be paid. Costs only become evident when bills arrive. With no hint that they think anyone might have a problem, Microsoft says: “you can manage your billing account and monitor and analyze consumption costs” by reading their documentation. So that’s OK then.
Backups Without Restores
Speaking of backups, although the Export APIs for Teams are now generally available and can stream chat and channel messages out of Teams, there’s no matching import (restore) API. In other words, you can export to your heart’s content, but when the time comes to fix a problem and restore some messages, it’s up to the ISV to figure out how to inject messages back into Teams.
Restoring messages is a big deal. Teams is already the most difficult Microsoft 365 application for backup vendors to deal with. Reassembling the content of a chat, conversation, or meeting can involve data from multiple sources, all connected by links that need to point to the right place and have the right permissions. Allowing high-fidelity export of Teams data, even for payment, without delivering equivalent import capability is just bizarre. In fact, it’s off-the-scale bizarre.
Creating a paid-for metered API to move data out of Microsoft 365 might seem like perfect business sense to the folks in Redmond. The logic is probably that the export causes demand on the service (which Microsoft throttles if it is too high) and those who create the demand should pay for the resources that they consume, especially when Microsoft has done the work to create the API. As we know with Microsoft licensing for cloud functionality, anything that Microsoft can charge for will appear with a price tag. Wall Street and the average revenue per user (ARPU) metric must be satisfied.
Learn more about the challenges involved in a Teams migration in this eBook: Teams Migration: Overcoming the Key Challenges.
The API Inflation
The long-term issue that’s evident here is that if Microsoft introduces consumption-based paid-for Teams APIs for fundamental operational processes that customers need to use for Teams migrations or backups, they’re quite likely to do the same for other workloads like Exchange Online and SharePoint Online. And then extend to workloads like Planner and Yammer that cause real problems in tenant-to-tenant scenarios. The credit cards attached to Azure subscriptions will make the pain go away and Microsoft results will be better. It’s all good.
Of course, you don’t have to use the APIs. No one forces tenants to do backups, nor do they force organizations into corporate restructuring. Keep all your data inside Microsoft 365 and you don’t have to pay a red cent but think about exporting and different rules apply.
Pain for Customers
In reality, ISVs will pass the cost problem to customers. They’ll have to because there’s no other practical way to sort out the cost, and anyway, customers must pay for whatever is clocked up on the meter through an Azure subscription. That subscription can be a dedicated one created for a project or an ongoing subscription for long-term use.
I’m sad to see Microsoft going down this route. I had hoped that some sense would prevail after Microsoft launched these APIs in preview and ISVs had the chance to test the APIs and figure out where the real costs lie. Whatever feedback went back to Microsoft seems to have fallen on barren ground.
The bottom line is that the data Microsoft exports belongs to customers. If customers want to move that data to somewhere else for operational or commercial reasons, Microsoft should help and not hinder that process. After all, customers pay enough for Microsoft 365 and Office 365 licenses, so much so that Microsoft now has an annualized run rate of $93.6 billion for its cloud services. Charging $0.00075 to export a message isn’t going to move the cloud services needle, but it will make ISVs and customers believe that Microsoft is nickeling and diming on their backs in an attempt to keep up with Amazon.
Excellent article. Our team has multiple Enterprise grade tenant to tenant migrations on the go at any one time. It’ll be interesting to see how the costing for this works out, since noone can accurately forecast any of this when assessing the overall migration cost of a project for a prospective customer.
Spot on again! It’s frustrating to develop solutions based on API’s and the Power platform just to realize that the cost to the customer is completely unacceptable in terms of licenses needed or impossible to predict consumption rates. Again, we can only hope that MS will listen to the frustrations of partners and customers.