Azure Office Office 365 SharePoint

Dag 2 Ignite – van SharePoint On Premises naar Office 365 en SharePoint Online

7 mei 2015

In de sessie van Scott Jamison over informatie architectuur voor SharePoint werd door Scott gevraagd wie SharePoint in het eigen datacenter gebruikt (on premises) en wie Office 365 / SharePoint Online gebruikt. De verdeling was een mooie 50/50. Microsoft heeft het al een tijdje aangekondigd de innovaties komen sneller in de cloud dan in on-premises SharePoint. Voor SharePoint 2016 moeten we ook nog even geduld hebben. Waarschijnlijk pas tweede kwartaal 2016.
Nu werk ik voor de Nederlandsche Bank en je kan je wel voorstellen dat wij de nodige gevoelige documenten in het document management systeem hebben staan. Sterker nog als je de wet doorleest die het toezicht op de banken regelt staat daar dat gegevens die wij voor de toezichthoudende functie verkrijgen met niemand mogen delen. Of dat dan ook betekent dat we niet naar een ander datacenter kunnen, dat laat ik graag over aan de juristen. Voorlopig zitten wij wel even vast aan ons eigen datacenter. Hoe kan je er nu voor zorgen dat de investering die wij nu doen in SharePoint on-premises niet nog eens opnieuw gedaan moet worden wanneer we willen migreren naar de cloud?

Ten eerste hebben wij de richtlijnen van Microsoft overgenomen door de SharePoint farm onder Product Line Architecture van Microsoft te plaatsen. Dit betekent bijvoorbeeld dat wij net zoveel webapplicaties hebben als in de cloud, namelijk één. Farm solutions die code op de server draaien zijn niet langer toegestaan en in plaats daarvan gebruiken wij het app model. Ik mag het alleen geen app model meer noemen want officieel praten we nu over add-ins voor SharePoint.

Nu lopen wij bij de implementatie wel tegen een aantal grijze gebieden aan. Wat te doen met provisioning van zaken zoals branding, contenttypes, list definitions, webtemplates, custom masterpages. Daar had Vesa Juvonen (chief engineer SharePoint Online) toch wel een verrassing voor mij in petto. Eigenlijk zijn er maar twee manieren om dit soort artefacten in SharePoint Online te deployen: declaratief via xml files via het sandbox solution feature framework of imperatief via sharepoint client side object model (remote provisioning). Tot nu toe heb ik altijd gekozen voor het declaratieve model, dit doen teams waar ik mee werk al jaren en het is een heel productieve manier van werken. Je draait het zo in elkaar (als je weet wat je doet) en je rolt het zo uit. Dat kan ik tot nog toe van het remote provisioning pattern niet zeggen. Je zou dan je eigen provisioning engine moeten schrijven. Ik focus liever op de waarde voor de business, die sprints zijn immers maar 3-4 weken lang. De verrassing voor mij zat hem er vooral in dat Microsoft nu ook actief samenwerkt met de SharePoint community om remote provisioning ook kosteneffectief te maken.

Het Patterns and Practices for Office 365 (http://dev.office.com/patterns-and-practices) brengt mij er wel toe om die mening eens te herzien. In verschillende sessies werd een provisioning engine getoond waarbij je aan de hand van een xml file heel veel van de artefacten kunt provisionen. Dit heeft een groot voordeel; het haalt de dependency op de sandbox solution weg. Als iemand per ongeluk de solution verwijdert zijn ook zaken zoals list definition en dergelijke weg waardoor lelijke fouten kunnen ontstaan in SharePoint. Remote provisioning is alsof de gebruikers het in elkaar hebben geklikt en er is weinig kans op fouten achteraf. Nadeel bljft nog wel steeds dat je extra infrastructuur nodig hebt, de remote provisioning app moet immers ook ergens leven. Echter met de code voorbeelden in de github repository van Office 365 PnP (https://github.com/OfficeDev/PnP) moet het eenvoudig zijn om zaken om te schrijven naar Powershell of een console app als je dat zou willen. Indrukwekkend was een demo waarmee je een site ook revers kon engineren naar een xml file die geaccepteerd wordt door de genoemde remote provisioning engine.

Van dag 2 was voor mij dan ook de highlight: als je nog in je eigen datacenter zit dan is niet de vraag of je naar de cloud gaat maar wanneer je naar de cloud gaat. Maak voor jezelf de afweging, sandbox solutions en custom masterpages blijven gewoon ondersteund (vooralsnog) maar je moet je afvragen of je met de nieuwe tooling. Dat is de boodschap die Microsoft brengt over SharePoint on-premises. Nu de nieuwe tooling er is vanuit Office 365 PnP kan ik de oplossingen die ik nu heb nog eens goed tegen het licht houden; hoe dichter we tegen de cloud kunnen aankruipen hoe beter. De kosten voor het opzetten van een remote provisioning engine zijn in ieder geval een stuk lager geworden en als ik in de toekomst kan kijken denk dat die cloud er wel gaat komen want vanuit kosten perspectief is het een stuk goedkoper dan ons eigen datacenter.

(Disclaimer: my opinions are my own and not the views of my employer)

You Might Also Like

Geen reacties

Plaats een reactie