Cost of Consumption Models Could Affect How ISVs Charge for Solutions Like Backup
I have often commented about the difficulty of backing up the myriad pieces of data generated by Microsoft Teams and its associated apps. The data is distributed across many Microsoft 365 repositories and no suitable APIs exist to retrieve some information, all of which makes backing up Teams challenging and restoring Teams even more so, especially if you want everything to fit together properly after a restore.
Graph Export API for Teams is Generally Available
The recent announcement of the general availability of the Graph Export API for Teams messaging seems like it is a step forward. The API is available to process chats and channel messages along with “hosted” content like files, images, and stickers associated with messages. Because the Export API can access personal data, Microsoft regards it as a protected API and requires those who wish to use it to seek approval by describing their intended use. Once access is granted, ISVs can incorporate the Export API for Teams in their products, and all should be well.
But some complications exist which deserve consideration by both app developers and their customers. Message center notification MC287036 (23 September) introduces concepts for two APIs (Teams DLP and Teams Export) like seeded capacity and consumption models to handle different usage scenarios.
Microsoft divides usage of the Teams APIs into security and compliance (model A) and other uses (model B). App developers declare their usage by passing the model they wish to use in the Graph API queries to fetch data from Teams.
Licensing is a major difference between the two models. If you want to use an app based on model A, users need Microsoft 365 compliance licenses (like Office 365 E5 or Microsoft 365 Compliance E5). Guest users are exempt from licensing requirements, as federated users (Teams or Skype users in another tenant), but consumption limits still apply. Microsoft won’t enforce the licensing requirements immediately as a 6-month grace period applies for existing customers (using solutions developed with the beta APIs) from October 5. However, new users need an E5 license to access Teams messages via the Export API.
The Model B (not security and compliance) scenarios have “no specific license requirements” but “the API is charged per message exported.” We’ll return to that point later.
Different Access for Models A and B
Another difference between the two models is the way data is consumed. Products like data loss prevention, security scanning, or archiving solutions need access to Teams messages quickly. For instance, there’s no point in waiting for 15 minutes before a DLP solution can examine the content of new channel messages to decide if they violate an organization policy. Accordingly, the Teams DLP API makes a webhook available for applications to learn about new content so that they can retrieve and process that content.
Applications built using model B are more focused on bulk processing, such as exporting messages created in a team over a period. Bulk export could be construed as “backup,” but I am not sure. First, there’s no complementary restore capability that I can see. Second, Microsoft has included a charging mechanism in the API. This is where seeding comes in. Holders of E5 licenses receive a certain “seeded” transaction capacity to make sure that they can use the API for security and compliance purposes. The limits cover different types of transactions, like change notifications for chat messages and are in the range of 800 to 1,600 transactions per user per month per app (Figure 1). After a user or app exceeds the seeded capacity, the API’s consumption meters start running and Microsoft begins charging at $0.00075 per message.
Teams administrators can monitor seeded capacity and usage through the Reports section of the Teams admin center.
Consumption Costs are Coming
Microsoft is quite clear that it is “the responsibility of the tenant owner (not the app owner) to ensure users are properly licensed.” In other words, tenants need to be aware that the use of an app might incur cost. And the thing about backup-style scenarios is that they tend to process a lot of data, and if Microsoft charges $0.00075 individual message, that insignificant individual cost could accumulate to a large amount.
To get an idea of the rough cost, you can use the Graph usage APIs to see how many chat and channel messages users generate today (here’s a script to extract the usage data) and do the math.
Of course, we don’t know how apps will use these APIs in practice and it’s possible that Microsoft will adjust their pricing model based on their discussion with ISVs. In addition, model B usage is free at present. However, Microsoft says that “in the future, apps will pay based on the number of messages they consume.” The intent is clear. If an app processes data using the Teams Export API, the organization using the app is clicking up cost.
Microsoft will post a new message center notification when consumption meters become available. Apart from saying that “app owners will be charged for all API calls they make on a monthly basis,” no other details are currently available about how Microsoft plans to charge for API consumption. It might be as simple as an addition to the monthly licensing bill for the tenant or you might need to buy some Azure credits.
No information is available about the prospect of other Microsoft APIs embracing a similar consumption pricing mechanism to process information. If the approach proves successful with the Teams Export API, I wouldn’t be surprised to see it used elsewhere.
Migration Difficulties
Once consumption pricing is in force, ISVs operating in the migration space, such as Teams tenant to tenant migrations, will have some decisions to make about how they price projects. Although the responsibility for paying Microsoft for messages moved using the Export API will lie with the tenant, it’s inevitable that customers will want to know what the cost of migration will be. Coming up with those estimates will be “interesting” if the tenant doesn’t know how many messages are involved.
No Backup Panacea
The general availability of the Teams Export API is welcome. It will enable new solutions and tools to exploit the Teams ecosystem, but I don’t think the capabilities and cost implications of the API mean that it’s a solid foundation for backup processing. Anyway, the restore issue is still there.
All of which means the advice posted on Microsoft’s page Recover from a ransomware attack in Microsoft 365 stating that it is best practice to “regularly back up your Microsoft 365 content and data using third-party apps and services” is flawed advice. The guidance is acceptable for Exchange Online and SharePoint Online, but fails miserably for apps like Teams, Planner, and Whiteboard. There’s still work to be done before organizations can back up the data for an entire tenant.
Update (Oct 6): Microsoft updated their online guidance after we pointed out the issue with their best practice recommendation.
Great write up, Tony. There is certainly more work to be done by Microsoft. Interestingly enough, the “Recover from Ransomware” documented was updated to remove the recommendation.
Yeah, I pointed out the inconsistencies of their position WRT best practice for backups using GitHub https://github.com/MicrosoftDocs/microsoft-365-docs/issues/6496. Anyone can provide feedback for Microsoft documentation errors using the options at the bottom of each page. It’s a good way to let the writers know about conditions in the real world.