Verbruiksmodellen en potentiële kosten geïntroduceerd door de nieuwe Teams-API’s van Microsoft vereisen een zorgvuldige berekening

Ik heb vaak opmerkingen gemaakt over de moeilijkheid om een ​​back-up te maken van de talloze stukjes gegevens die zijn gegenereerd door Microsoft Teams en de bijbehorende apps. De gegevens zijn verdeeld over veel Microsoft 365-repository’s en er zijn geen geschikte API’s om bepaalde informatie op te halen, wat het maken van back-ups van Teams een uitdaging maakt en Teams herstellen nog meer, vooral als je wilt dat alles goed in elkaar past na een herstel.

Graph Export API voor Teams is algemeen beschikbaar

De recente aankondiging van de algemene beschikbaarheid van de Graph Export API voor Teams-berichten lijkt een stap vooruit. De API is beschikbaar om chats en kanaalberichten te verwerken, samen met “gehoste” inhoud zoals bestanden, afbeeldingen en stickers die aan berichten zijn gekoppeld. Reacties zoals thumbs-up zijn een opmerkelijke uitzondering. Omdat de Export-API toegang heeft tot persoonlijke gegevens, beschouwt Microsoft het als een: beveiligde API en vereist dat degenen die het willen gebruiken om goedkeuring te vragen door het beoogde gebruik te beschrijven. Zodra toegang is verleend, kunnen ISV’s de Export API for Teams in hun producten opnemen, en dat zou allemaal in orde moeten zijn.

Maar er zijn enkele complicaties die aandacht verdienen door zowel app-ontwikkelaars als hun klanten. Berichtencentrummelding MC287036 (23 september) introduceert concepten voor twee API’s (Teams DLP en Teams Export), zoals gezaaide capaciteits- en verbruiksmodellen om verschillende gebruiksscenario’s aan te kunnen.

Microsoft verdeelt het gebruik van de Teams-API’s in beveiliging en naleving (model A) en ander gebruik (model B). App-ontwikkelaars declareren hun gebruik door het model dat ze willen gebruiken door te geven in de Graph API-query’s om gegevens uit Teams op te halen.

Licentie is een groot verschil tussen de twee modellen. Als je een app wilt gebruiken op basis van model A, hebben gebruikers Microsoft 365-compliancelicenties nodig (zoals Office 365 E5 of Microsoft 365 Compliance E5). Gastgebruikers zijn vrijgesteld van licentievereisten, als federatieve gebruikers (Teams of Skype-gebruikers in een andere tenant), maar er zijn nog steeds verbruikslimieten van toepassing. Microsoft zal de licentievereisten niet onmiddellijk afdwingen, aangezien er vanaf 5 oktober een respijtperiode van 6 maanden geldt voor bestaande klanten (met oplossingen die zijn ontwikkeld met de bèta-API’s) Nieuwe gebruikers hebben echter een E5-licentie nodig om toegang te krijgen tot Teams-berichten via de Export API.

De Model B-scenario’s (geen beveiliging en naleving) hebben “geen specifieke licentievereisten” maar “de API wordt in rekening gebracht per geëxporteerd bericht.” Op dat punt komen we later terug.

Verschillende toegang voor modellen A en B

Een ander verschil tussen de twee modellen is de manier waarop gegevens worden verbruikt. Producten zoals preventie van gegevensverlies, beveiligingsscans of archiveringsoplossingen hebben snel toegang tot Teams-berichten nodig. Het heeft bijvoorbeeld geen zin om 15 minuten te wachten voordat een DLP-oplossing de inhoud van nieuwe kanaalberichten kan onderzoeken om te beslissen of ze een organisatiebeleid schenden. Dienovereenkomstig stelt de Teams DLP API een webhook beschikbaar voor applicaties om nieuwe inhoud te leren kennen, zodat ze die inhoud kunnen ophalen en verwerken.

Applicaties die zijn gebouwd met model B zijn meer gericht op bulkverwerking, zoals het exporteren van berichten die gedurende een bepaalde periode in een team zijn gemaakt. Bulkexport kan worden opgevat als ‘back-up’, maar ik weet het niet zeker. Ten eerste is er geen aanvullende herstelmogelijkheid die ik kan zien. Ten tweede heeft Microsoft een oplaadmechanisme in de API opgenomen. Dit is waar seeding om de hoek komt kijken. Houders van E5-licenties ontvangen een bepaalde “seeded” transactiecapaciteit om ervoor te zorgen dat ze de API kunnen gebruiken voor beveiligings- en nalevingsdoeleinden. De limieten dekken verschillende soorten transacties, zoals wijzigingsmeldingen voor chatberichten en zijn in de bereik van 800 tot 1600 transacties per gebruiker per maand per app (Figuur 1). Nadat een gebruiker of app de gezaaide capaciteit overschrijdt, beginnen de verbruiksmeters van de API te lopen en begint Microsoft $ 0,00075 per bericht in rekening te brengen.

Teams-beheerders kunnen de gezaaide capaciteit en het gebruik volgen via de Rapporten van het Teams-beheercentrum.

Verbruikskosten komen eraan

Microsoft is vrij duidelijk dat het “de verantwoordelijkheid van de tenant-eigenaar (niet de app-eigenaar) om ervoor te zorgen dat gebruikers de juiste licentie hebben.” Met andere woorden, huurders moeten zich ervan bewust zijn dat het gebruik van een app kosten met zich mee kan brengen. En het ding met back-upscenario’s is dat ze de neiging hebben om veel gegevens te verwerken, en als Microsoft $ 0,00075 voor een afzonderlijk bericht in rekening brengt, kunnen die onbeduidende individuele kosten oplopen tot een groot bedrag.

Om een ​​idee te krijgen van de ruwe kosten, kunt u de gebruiks-API’s van Graph gebruiken om te zien hoeveel chat- en kanaalberichten gebruikers vandaag genereren (hier is een script om de gebruiksgegevens te extraheren) en reken uit.

We weten natuurlijk niet hoe apps deze API’s in de praktijk zullen gebruiken en het is mogelijk dat Microsoft hun prijsmodel zal aanpassen op basis van hun discussie met ISV’s. Bovendien is het gebruik van model B momenteel gratis. Microsoft zegt echter dat “in de toekomst zullen apps betalen op basis van het aantal berichten dat ze consumeren.” De bedoeling is duidelijk. Als een app gegevens verwerkt met behulp van de Teams Export API, klikt de organisatie die de app gebruikt de kosten omhoog.

Microsoft zal een nieuwe berichtencentrummelding plaatsen wanneer verbruiksmeters beschikbaar komen. Behalve zeggen dat “app-eigenaren worden in rekening gebracht voor alle API-aanroepen die ze maandelijks doen”, zijn er momenteel geen andere details beschikbaar over hoe Microsoft van plan is kosten in rekening te brengen voor API-verbruik. Het kan zo simpel zijn als een toevoeging aan de maandelijkse licentiefactuur voor de tenant of u moet mogelijk wat Azure-tegoed kopen.

Er is geen informatie beschikbaar over het vooruitzicht dat andere Microsoft-API’s een soortgelijk prijsmechanisme voor consumptie omarmen om informatie te verwerken. Als de aanpak succesvol blijkt te zijn met de Teams Export API, zou het me niet verbazen als het elders wordt gebruikt.

Migratieproblemen

Zodra de verbruiksprijzen van kracht zijn, zullen ISV’s die actief zijn in de migratieruimte, zoals Teams-tenant-naar-tenant-migraties, enkele beslissingen moeten nemen over hoe ze projecten prijzen. Hoewel de verantwoordelijkheid voor het betalen van Microsoft voor berichten die met de Export-API worden verplaatst, bij de huurder ligt, is het onvermijdelijk dat klanten willen weten wat de migratiekosten zullen zijn. Het bedenken van die schattingen zal ‘interessant’ zijn als de huurder niet weet om hoeveel berichten het gaat.

Geen back-up wondermiddel

De algemene beschikbaarheid van de Teams Export API is welkom. Het zal nieuwe oplossingen en tools mogelijk maken om het Teams-ecosysteem te exploiteren, maar ik denk niet dat de mogelijkheden en kostenimplicaties van de API betekenen dat het een solide basis is voor back-upverwerking. Hoe dan ook, het herstelprobleem is er nog steeds.

Dit alles betekent het advies dat op de Microsoft-pagina is gepost Herstel van een ransomware-aanval in Microsoft 365 waarin staat dat het de beste praktijk is om “maak regelmatig een back-up van uw Microsoft 365-inhoud en -gegevens met apps en services van derden’ is een gebrekkig advies. De begeleiding is acceptabel voor Exchange Online en SharePoint Online, maar faalt jammerlijk voor apps zoals Teams, Planner en Whiteboard. Er is nog werk aan de winkel voordat organisaties een back-up kunnen maken van de gegevens voor een hele tenant.

Update (6 oktober): Microsoft heeft hun online begeleiding bijgewerkt nadat we wees op het probleeme met hun best practice-aanbeveling.