Een platform dat meerdere operators bedient, moet ze op overtuigende wijze uit elkaar houden en tegelijkertijd voldoende infrastructuur delen om economisch te zijn. Waar die lijn ligt, is de beslissende architecturale beslissing, en het is moeilijk om later te bewegen.
Als je het fout doet in de toegestane richting, ontstaat er een datablootstelling. Als het in de restrictieve richting fout gaat, ontstaat er een platform dat te duur is om te exploiteren.
Grenzen die absoluut moeten zijn
De test is niet of de interface toegang verhindert. Het gaat erom of een query met een ontbrekend filter de gegevens van een andere tenant kan retourneren, omdat er uiteindelijk één zal worden geschreven.
- Sessie- en transactiegegevens, die commercieel gevoelig zijn.
- Chauffeurs- en klantgegevens, die privacyverplichtingen met zich meebrengen.
- Tarieven en commerciële voorwaarden, die concurrenten niet mogen zien.
- Inventaris- en locatiegegevens van opladers waar deze niet openbaar zijn.
- Alles wat een tenant kan exporteren, wat nooit de rijen van een andere tenant mag bevatten.
Dwing isolatie af onder de applicatie
Isolatie die afhankelijk is van elke query, inclusief een tenantvoorwaarde, zal mislukken, omdat deze afhankelijk is van het feit dat elke ontwikkelaar het zich herinnert. Handhaving op de gegevenslaag, dus een query zonder tenantcontext retourneert niets in plaats van alles, dat is wat overleeft.
Dit is in eerste instantie meer werk en het is het verschil tussen een grens en een conventie.
Wat veilig gedeeld kan worden
Protocolafhandeling, verbindingsbeheer, firmware-artefacten, referentiegegevens en de operationele infrastructuur. Geen van deze bevat huurderspecifieke informatie, en het delen ervan is waar de economie van multi-tenancy vandaan komt.
Laderverbindingen zelf zijn een gedeelde infrastructuur met een huurderattribuut. Daarom moet de onboarding van laders een huurovereenkomst tot stand brengen voordat er gegevens worden vastgelegd.
Lawaaierige buren
Eén huurder met een groot wagenpark, een agressieve rapportagegewoonte of een zich misdragende integratie kan de service voor iedereen verslechteren. Tariefbeperking en resourceboekhouding per tenant zijn op geen enkele zinvolle schaal optioneel.
Het falen zonder hen is dat een kleine huurder een storing ervaart die volledig wordt veroorzaakt door iemand van wie hij nog nooit heeft gehoord, en uw ondersteuningsteam kan dit niet verklaren.
Configuratie-divergentie
Huurders zullen verschillende tariefstructuren, autorisatieregels, branding en workflows willen. Configuratie regelt dat; codevertakkingen per tenant doen dat niet, en een platform dat ze heeft verzameld is niet langer één platform.
De discipline is om verschillen als configuratie uit te drukken of ze af te wijzen, in plaats van ze in speciale gevallen te omschrijven. Dat is zowel een commerciële als een technische discipline.
Exit moet per huurder werken
Een vertrekkende huurder moet zijn gegevens kunnen meenemen en zijn opladers opnieuw kunnen aansluiten zonder dat iemand anders daar last van heeft, en zijn gegevens moeten verwijderbaar zijn zonder de gedeelde structuren te verstoren.
Het is eenvoudig om dit in het begin te ontwerpen. Het ombouwen ervan naar een platform waar data van huurders verstrikt zijn, is een project, en wordt doorgaans op het slechtste moment dringend.