Sandboxed Solutions i Office 365 – det kræver ninjaevner

Når det gælder om at lave custom solutions (også kendt som Sandboxed Solutions) til SharePoint Online, er der et par ting, man skal være opmærksom på. En af dem er den underliggende arkitektur, der driver hele SharePoint Online-miljøet. Når man skræller al salgssnakken væk, skal der stadig være en Big-Ass ServerFarm (BASF) og en måde at dele kunderne op på i det fysiske miljø.

BASF-opsætningen#

Lad mig lige gøre klart, at jeg virkelig gætter på den her del af SharePoint Online-BASF-opsætningen (ja, det er stadig Big-Ass ServerFarm og ikke den gode gamle leverandør af 8-sporsbånd). Jeg antager, at det her mere eller mindre er arkitekturen for SharePoint Online-miljøet.

• BASF
• Masser af SharePoint-farme betjener kunderne. Mit gæt er, at hver Enterprise-kunde (Plan E1 til E4) får en WebApplication med mulighed for at oprette op til 300 SiteCollections. Alt sammen i en enkelt Content Database
• P1-kunderne ligger på deres egen SharePoint-farm, hvor de får tildelt en enkelt SiteCollection med en grænse på 10 GB lagerplads.
• Alle eller et antal kunder deler CPU- og RAM-ressourcerne på den SharePoint-farm, der betjener dem.

For at en Cloud Service Provider kan tjene penge, skal den have mest muligt ud af sin investering. Det betyder at proppe så mange kunder sammen som muligt. På den måde får BASF mest performance for pengene. Problemet med det scenarie har altid været, at man ender med nogle bøllekunder, der rider BASF, til solen går ned. De kunder dræner BASF, og alle de andre kunder mærker den nedsatte performance.

Den traditionelle måde at håndtere det på har altid været at bygge nogle barrierer ind i miljøet og derved forhindre BASF i at eksplodere. Fælles for dem alle er, at kunderne deler CPU-kernerne, hvilket ender med at give en variation i performance i løbet af dagen. Det er uundgåeligt. Barriererne kan variere noget, men i de fleste tilfælde er der kun én. I Office 365 er der 2:

• Resource Points – Man har et vist antal Resource Points om dagen. Spørg mig ikke, hvordan de bliver beregnet, men hver gang ens custom solution af en eller anden art kører, bruger den Resource Points. Jo flere brugere man har på sit abonnement, jo flere Resource Points har man til rådighed.
• Tidsgrænse – Man har 30 sekunder til at få sin Sandboxed Solution i luften og ned igen. Og husk at regne med de 7-8 sekunder, det tager løsningen at starte, når den skal kompileres første gang efter en periode, hvor den ikke har været brugt. (Dvs. hver morgen)

Problemet med at bruge to barrierer#

Faktisk er Resource Points ikke noget problem. Det er tidsgrænsen, der er den rigtige joker. Hvorfor? Fordi når man sætter en tidsgrænse på udførelsen af noget custom code i en hvilken som helst BASF, skal man tænke over, hvad der kan påvirke performance, mens koden kører. Hvor meget RAM man har til rådighed er én ting, CPU-kraften er en anden. Jeg ser egentlig ikke lagerplads som noget, der påvirker performance, men hey, lad os bare smide den i bunken af variabler. Måske skriver ens custom code nogle tunge filer, der tager lang tid at skrive på harddisken. Måske er det myldretid ovre hos naboens tenant, og de lægger beslag på al CPU-kraften. RAM er lidt lettere at styre og reservere, når koden startes (tror jeg. Jeg ved det faktisk ikke, jeg antager bare. Jeg er en softwarefyr, ikke hardware). Og oven i alt det skal man huske cachingen. Altså at ens kode ikke bliver kompileret før første kørsel.

Tag alle de variabler, og læg så dem, jeg ikke kender til, oven i, og så er det stort set umuligt at beregne, hvor lang tid ens custom code bruger fra start til slut. Det gør tidsgrænsen til den største og mest uforudsigelige variabel, når man koder Sandboxed Solutions til Office 365.

Krav for at barriererne virker ordentligt hver gang#

• Tidsgrænsen kræver reserverede ressourcer for at virke som forventet hver gang
• Tærsklen for ResourcePoints kræver ingen tidsgrænser for at virke som forventet
• Reservation af en CPU-kerne kræver ingen RessourcePoint- eller tidsgrænser, men er dyr

Resultatet#

Læser man Andy Burns iagttagelser fra hans første projekt med Sandboxed Solutions i SharePoint Online, så har jeg følt de samme frustrationer som Andy. Når man planlægger sit SharePoint Online-projekt, skal man tænke meget grundigt over sin brug af Sandboxed Solutions i SharePoint Online. Efter min erfaring er det stadig ret ustabilt, når tidsgrænsen er sat så lavt.

Løsningen#

Der er 3 måder at komme uden om det på (som jeg ser det, men der kunne sagtens være flere):

1. Slå tidsgrænsen fra på custom solutions, men håndhæv Resource Points i realtid, eller sæt tidsgrænsen til 10 minutter. Det gør ikke noget, at den er langsom til at blive færdig, så længe den bliver 100 % færdig. (Den nemme løsning)
2. Reserver præcis den samme mængde CPU-kerne pr. kunde, så kunden kan regne med, at løsningerne tager lige lang tid at blive færdige hver gang. (Den alt for dyre løsning)
3. Giv kunden mulighed for at reservere en CPU-kerne, hvis de har kritiske custom solutions, der rækker ud over de 30 sekunder. (Den mest fleksible løsning. Lad de kunder, der har brug for mere kraft, betale for det.)

Logning#

Det kan være en rigtig pine at finde ud af, hvorfor ens Sandboxed Solution ikke virker, for der er ingen adgang til logs. Alt man får, er et “Correlation ID”, men man har ingen måde at slå det ID op på for at gå på fejljagt i sin kode. Man kunne prøve at bruge “Try-catch-finally”-metoden i sin kode, men jeg har ikke set SharePoint acceptere den endnu. Nogle gange kan man faktisk få sin kode til at køre uden at bruge try-catch. SharePoint Online ignorerer bare metoden fuldstændig.

Sidste tanker om Sandboxed Solutions i Office 365#

Jeg er fan af hele Office 365-platformen. Jeg sælger den, rådgiver om den og hjælper andre med at bruge den – dagligt. Jeg har bygget et meget lille sagssystem på den, og jeg betragter mig selv som godt bevandret i Office 365’s rige. I de fleste tilfælde med de små og mellemstore kunder, jeg møder, kunne man tage højde for begrænsningerne i SharePoint Online og designe sin løsning uden om dem. Med andre ord anbefaler jeg kraftigt IKKE at bruge Sandboxed Solutions ret meget. Prøv at se, om man ikke kan klare sig med SharePoint Designer Workflows og JavaScript. I de fleste tilfælde kan det faktisk sagtens lade sig gøre. Vær opmærksom på mulige problemer med at skalere løsningen, og har kunden en kritisk løsning, de skal have på SharePoint, så tænk to gange, før den lægges på SharePoint Online. Når man bruger SharePoint Online til at bygge løsninger, skal man virkelig huske sine ninjaevner.