Een kijkje onder de dekmantel van Datto SaaS Protection

We weten allemaal dat de overstap naar cloudinfrastructuur en in de cloud gehoste diensten al geruime tijd in hoog tempo toeneemt – en de pandemie heeft die groei alleen maar versneld. De SaaS Protection-service van Datto beschermt SaaS-oplossingen zoals Microsoft 365 en Google Workspace (voorheen G Suite). Snelle groei gaat vaak gepaard met ingrijpende veranderingen en soms ook met instabiliteit. Zelfs voor bedrijven als Microsoft en Google, die op hyperschaal opereren, kan deze versnelde groei problemen veroorzaken.

Datto is gespecialiseerd in databescherming, wat betekent dat kwaliteit, betrouwbaarheid en veerkracht voorop staan bij onze technische prioriteiten. Het afgelopen jaar heeft ons allemaal op de proef gesteld op deze belangrijke gebieden. We zijn een flexibele organisatie die zich voortdurend aanpast en incrementele verbeteringen aanbrengt. In deze blogpost belicht ik een aantal van de recente uitdagingen die we zijn tegengekomen, de acties die we hebben ondernomen en onze plannen voor de toekomst om de beste service in zijn klasse te bieden om SaaS-workloads te beschermen.

Hoewel we zowel Microsoft 365 als Google Workspace ondersteunen, ga ik me specifiek richten op M365 omdat dit een steeds groter deel van ons klantenbestand vertegenwoordigt. Hoewel veel van deze onderwerpen ook van toepassing zijn op Google Workspace.

API's van Microsoft

De Microsoft-API’s maken momenteel een overgang door van dienstspecifieke (bijv. Exchange Online, SharePoint, OneDrive) verouderde API’s naar de Graph API. We zijn in hoog tempo overgestapt op Graph en al onze nieuwe ontwikkelingen vinden plaats in Graph. Dit is al een tijdje zo. We zijn op de hoogte van alle uitloopdata voor dienstspecifieke API’s en lopen ruim voor op elk van deze data. We versnellen de overgang waar nodig, aangezien sommige dienstspecifieke verouderde API’s vaste einddatums (EOL) hebben. Er zijn twee API-situaties die ik graag wil benadrukken:

• API’s veranderen wat ze teruggeven: we merken dat het gedrag van Microsoft-API’s vrij regelmatig verandert. De signatuur van de API’s verandert niet, aangezien dat een standaardbeleid voor ontwikkelaars is. De resultaten die door de API-aanroepen worden teruggegeven, kunnen echter zonder voorafgaande kennisgeving veranderen (en dat gebeurt ook). Zo kunnen we bijvoorbeeld regelmatig een specifieke tekenreekswaarde ontvangen die verandert, of ontvangen we verschillende foutcodes bij exact dezelfde aanroepen. Ik heb gezien dat onze concurrenten publiekelijk naar dit soort veranderingen verwijzen. Om een tegenwoordig veelgebruikte uitdrukking te gebruiken: we zitten allemaal in hetzelfde schuitje. De API’s die wij gebruiken, zijn dezelfde API’s die onze concurrenten gebruiken (met één uitzondering, die in het volgende punt wordt beschreven). Dit betekent dat als wij fouten of uitzonderingen zien als gevolg van een probleem bij Microsoft, de kans groot is dat andere oplossingen hier ook mee te maken hebben.
• Het gebruik van een bèta-API brengt risico’s met zich mee: Microsoft stelt bepaalde functionaliteit beschikbaar via bèta-API’s om realtime feedback te krijgen van zijn naaste partners en klanten. Als strategische partner van Microsoft maakt Datto regelmatig gebruik van bèta-API’s om zo snel mogelijk nieuwe functies voor onze partners en eindklanten te ontwerpen en te ontwikkelen. Zo waren we er bijvoorbeeld trots op dat we vorig jaar als eerste ondersteuning voor native Microsoft Teams-back-ups op de markt brachten. We zullen stabiliteit en betrouwbaarheid echter niet opofferen ten gunste van snelheid. De bèta-API’s van Microsoft brengen, net als alle pre-release code en functionaliteit, inherente risico’s met zich mee. In tegenstelling tot wat ik hierboven heb gezegd, kunnen bèta-API’s afwijken van het standaardbeleid (bijvoorbeeld door een wijziging in de handtekening) of mogelijk zelfs volledig verdwijnen zonder of met slechts zeer korte voorafgaande kennisgeving. Vanwege dat risico gebruiken wij simpelweg geen bèta-API’s in de productieomgeving. Wees op uw hoede voor leveranciers die mogelijk geen soortgelijk beleid hanteren, aangezien dit een inherent risico vormt voor de mogelijkheid om uw gegevens te beschermen en te herstellen.

Net als veel andere aanbieders van clouddiensten past Microsoft een beperking toe op API-aanroepen om een hoge kwaliteit van de dienstverlening te waarborgen. Tijdens piekuren geeft Microsoft voorrang aan bepaalde API-aanroepen boven andere. Zo krijgt een verzoek van een gebruiker (bijvoorbeeld het ophalen van een bericht via een eindgebruikersclient) voorrang boven een verzoek van een applicatie van een derde partij, zoals een verzoek van Datto SaaS Protection. Wanneer onze API-aanroepen worden afgeremd, ontvangen we een specifieke foutcode, doorgaans „429 Too Many Requests“. Een voordeel dat wij hebben als zowel ontwikkelaar als exploitant van de dienst, in tegenstelling tot een onafhankelijke softwareleverancier (ISV) die zijn software in licentie geeft aan een externe aanbieder, is dat wij toegang hebben tot een enorme hoeveelheid telemetriegegevens. We hebben aanzienlijk geïnvesteerd in het analyseren van deze gegevens, met als uitdrukkelijk doel onze dienst beter te laten presteren en betrouwbaarder te maken. Een concreet voorbeeld hiervan is een aanpassing die we eerder dit jaar hebben doorgevoerd om back-ups strategisch in te plannen op momenten van de dag waarop we de minste beperkingsfouten waarnemen. Dit heeft ons algehele succespercentage bij back-ups meetbaar verhoogd.

Microsoft-evenementen

Veel cloudservices die een hypergroei doormaken zoals M365 heeft doorgemaakt, vooral in de afgelopen 18 maanden, moeten veranderingen doorvoeren om de vraag bij te houden. Dat houdt niet alleen het toevoegen van nieuwe functies in, maar ook het toevoegen van infrastructuur om de vraag te ondersteunen. Er zijn het afgelopen jaar twee gebeurtenissen geweest die een grote impact hebben gehad op onze service.

Het eerste van dergelijke voorvallen vond plaats op 15 maart, toen er wereldwijd een storing in het authenticatiesysteem was. Dit was een zeer opvallend voorval dat zowel eindgebruikers als dienstverleners trof. Voor ons leidde dit tot een enorme toestroom van supportverzoeken voor Datto SaaS Protection, waardoor ons verwachte supportvolume voor de maand maart meer dan verdubbelde. Het afhandelen van al deze supportverzoeken kostte veel tijd en zorgde voor een aanzienlijke achterstand. We hebben sindsdien wijzigingen doorgevoerd in onze processen en personeelsbezetting om een dergelijke situatie aan te kunnen, mocht deze zich in de toekomst opnieuw voordoen.

Vrijwel op hetzelfde moment dat het authenticatieprobleem zich voordeed, constateerden we ook storingen op een van onze peering-verbindingen in de VS. Microsoft biedt een peering-dienst aan die zorgt voor een lagere latentie en hogere betrouwbaarheid voor verkeer van en naar Microsoft-diensten zoals M365 en Azure. We investeren in deze verbindingen wanneer we in een bepaalde regio een bepaalde schaalgrootte bereiken. Het gebruik van peering-verbindingen levert zowel Datto als onze partners voordelen op. In de VS hebben we meerdere peering-verbindingen met onze datacenters, waarvan er slechts één fouten vertoonde, wat het moeilijker maakte om het exacte probleem te diagnosticeren. De grootste uitdaging bij het achterhalen van de oorzaak van de peering-fouten was dat we simpelweg Microsoft API-foutmeldingen terugkregen die er precies zo uitzagen als de fouten die we tijdens de authenticatiestoring hadden ontvangen. Door de timing versmolten deze problemen tot een ‘perfect storm’ en leidden ze tot een enorme toename van het aantal supporttickets.

Het laatste opmerkelijke Microsoft-evenement vond plaats op opeenvolgende dagen in mei. Onze monitoring- en waarschuwingssystemen signaleerden al snel een probleem, omdat onze KPI’s plotseling sterk begonnen te dalen. Na onderzoek stelden we vast dat de hoofdoorzaak een mislukte TLS-onderhandeling was. Microsoft paste namelijk stapsgewijze updates toe op de TLS-versies en versleutelingsalgoritmen die het accepteerde. Wij maakten al gebruik van TLS v1.2. Microsoft had echter binnen TLS v1.2 een specifieke set versleutelingsalgoritmen uitgekozen die zij uitsluitend zouden accepteren. Omdat deze wijziging niet goed was gecommuniceerd, hebben we bij Microsoft een ticket ingediend voor een productiestoring. Ik kan alleen maar aannemen dat andere leveranciers hetzelfde hebben gedaan, want zeer kort daarna stopte Microsoft de stapsgewijze updates en maakte het de wijzigingen ongedaan (wat inderdaad zeer zeldzaam is). Helaas begon Microsoft slechts 24 uur later opnieuw met het doorvoeren van deze updates. We waren bezig met het testen van de wijzigingen in de versleutelingsalgoritmen, maar moesten snel overschakelen naar het implementeren van de TLS-wijzigingen in ons hele systeem. Dit bood de gelegenheid om samen met Microsoft een passend communicatieplan op te stellen, zodat we in de toekomst goed gewaarschuwd zouden worden voor dergelijke wijzigingen. Geloof het of niet, maar zelfs onze contactpersonen voor premiumondersteuning waren niet op de hoogte van dit onderhoud.

Onze samenwerking met Microsoft

Gezien het belang van Microsoft voor ons en onze klanten, investeren we aanzienlijk in die relatie. Er zijn een paar dingen die we in het bijzonder willen benadrukken:

• De afgelopen twee jaar hebben we een Microsoft premium developer support contract gehad. Dit zorgt voor een toegewijde supportmanager om onze supporttickets te helpen escaleren en biedt ook toegang tot extra technische bronnen.
• Naast het premiumcontract voor ondersteuning van ontwikkelaars, kopen we blokken met consultancy-uren voor ontwikkelaars in op basis van behoefte. We hebben deze op verschillende manieren gebruikt:
  • Wanneer we nieuwe functionaliteit bouwen, kunnen we een beroep doen op een expert op een bepaald gebied die ons ontwerp en onze logica kan beoordelen om er zeker van te zijn dat we de juiste API's gebruiken en de gegevens op de juiste manier interpreteren. Het is een handige manier om een expert van Microsoft te vragen om te helpen bij het ontwerpen en beoordelen van onze oplossing.
  • Voor specifieke ondersteuningsgevallen waarvan we vinden dat ze niet de juiste aandacht krijgen, kunnen we deze consultancy-uren gebruiken om een speciale resource toegewezen te krijgen. Op die manier betalen we om sneller aandacht te krijgen voor sommige van onze belangrijkste Microsoft-problemen. Soms leidt dit ertoe dat Microsoft een codewijziging moet doorvoeren, wat langere tijd kan duren. Andere keren kunnen ze een workaround of een alternatieve oplossing voorstellen om het probleem volledig te vermijden.
• Tot slot, vanuit het perspectief van Microsoft-ondersteuning, voegen we een optie toe aan onze premiumondersteuning waarmee onze partners en klanten samen met ons aan een Microsoft-ticket kunnen werken. Dit zorgt niet alleen voor transparantie over de status, maar verkort ook de doorlooptijd van bepaalde tickets. We worden vaak de persoon in het midden (Microsoft vraagt ons om iets aan de partner of eindklant te vragen en omgekeerd). We denken dat dit een groot verschil zal maken in specifieke situaties en het is gewoon nog een toegevoegde waarde die we kunnen bieden.
• Nu Datto Backup for Microsoft Azure in de Early Access-fase is, zijn we niet alleen een partner van Microsoft, maar ook een belangrijke opkomende klant. We hebben er gezamenlijk alle belang bij om onze samenwerking tot een groot succes te maken. Het is echt een win-win-win-situatie (voor Datto, Microsoft en onze partners).

We hebben nog maar een tipje van de sluier opgelicht van de verhalen en technische uitdagingen die we zijn tegengekomen. Kom terug voor toekomstige blogs die zich richten op verschillende aspecten van Datto SaaS Protection.