De inzet van cloud computing

Versie door Dgreefhorst (overleg | bijdragen) op 28 okt 2013 om 13:58 (→‎Voorbeelden)
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)

Dit hoofdstuk geeft inzicht in de belangrijkste criteria om IT-diensten te plaatsen in de cloud en geeft aan wat de impact is van cloud computing op het hoger onderwijs. Het hoofdstuk start met een inleiding, waarna de criteria worden beschreven. Het hoofdstuk eindigt met een beschrijving van de voorziene impact en implementatie van cloud computing bij HO-instellingen.

Inleiding

Eén van de doelen van het project Regie in de Cloud is om meer zicht te krijgen op de impact van cloud computing op instellingen voor hoger onderwijs. In de HO-sector is draagvlak ontstaan om samen op te trekken in de ontwikkeling van cloud computing en in het ingrijpende transitieproces dat daarvoor moet worden doorlopen. Om de algemene ‘Cloud tenzij’ ambitie te realiseren, is het belangrijk dat deze wordt geconcretiseerd. Dit document heeft tot doel bij te dragen aan deze concretisering door heldere criteria te bieden die gebruikt kunnen worden bij het opstellen van een cloudstrategie of het uitvoeren van aanbestedingen. Dit hoofdstuk kan worden gezien als een samenvatting en aanscherping van zaken in andere publicaties over cloud van SURF [14, 15, 16], e-IRG [20], Nationaal Cyber Security Centrum [21] en NIST [22].

Voordelen van cloud computing zijn onder meer:

  • Direct beschikbaar – Clouddiensten zijn direct beschikbaar en vragen geen ontwikkeltraject waardoor snel kan worden ingesprongen op nieuwe behoeften.
  • Zelf geen technische kennis nodig - Clouddiensten worden door leveranciers onderhouden die verantwoordelijk zijn voor de techniek achter de dienst. Hierdoor kunnen organisaties zich richten op waar het echt om gaat: de toegevoegde waarde van ICT.
  • Geen investeringen, en mogelijk lagere totale kosten – Een organisatie hoeft geen hardware en software aan te schaffen en betaalt alleen gebruikt voor de capaciteit die daadwerkelijk wordt gebruikt. Een deel van de beheeractiviteiten (technisch beheer) zijn niet meer noodzakelijk. Hierdoor kunnen de totale kosten lager zijn. Of dit ook daadwerkelijk het geval is context-specifiek; zo leidt minder behoefte aan beheercapaciteit niet automatisch tot minder beheerders.
  • Schaalbaarheid – Clouddiensten zijn ‘elastisch’ en kunnen meeschalen met het gebruik. Als er op specifieke momenten (veel) meer capaciteit noodzakelijk is dan is dat ook beschikbaar. Als deze extra capaciteit niet meer nodig is dan wordt deze ook niet meer gebruikt.
  • Tijd- en plaatsonafhankelijk werken – Clouddiensten worden via het Internet aangeboden en door de leverancier ook ’s avonds en in het weekend beschikbaar gesteld. Hierdoor kunnen studenten en medewerkers leren en werken waar en wanneer ze willen.
  • Hoge beschikbaarheid – Leveranciers van clouddiensten zorgen er veelal voor dat er basismaatregelen zijn genomen voor het omgaan met beschikbaarheidsrisico’s zoals het redundant uitvoeren van infrastructuur.

Nadelen van cloud computing zijn onder meer:

  • Afhankelijkheid van leverancier – Clouddiensten worden beheerd door de leverancier en die bepaalt hoe de dienst precies wordt ingericht, geleverd en evolueert. Hiermee geven organisaties zaken uit handen die ze zelf dus niet meer direct onder controle hebben. Dit vraagt een hoge mate van vertrouwen in de cloudleverancier.
  • Afhankelijkheid van Internet – Clouddiensten worden typisch geleverd via Internet. Dat betekent dat er extra eisen worden gesteld aan de beschikbaarheid, capaciteit en vertrouwelijkheid van de Internetverbinding. Dit kan aanvullende maatregelen vragen.

Dit hoofdstuk gaat specifiek in op criteria om IT-diensten in een eigen rekencentrum, in een community cloud of in de public cloud te plaatsen. Dit worden ook wel “deploymentmodellen” genoemd [9]. Met IT-diensten bedoelen we: functionaliteiten die kunnen worden geleverd door IT oplossingen. Het plaatsen van IT-diensten in de cloud kan worden gezien als een specifieke vorm van outsourcing [3] en wordt ook wel “cloudsourcing” genoemd. Clouddiensten hebben als kerneigenschappen dat ze schalen naar gebruik (elasticiteit), dat je alleen betaalt voor wat je gebruikt en dat de gebruiker zelf diensten kan inkopen en afnemen zonder directe betrokkenheid van de leverancier (self-service). De public cloud biedt publiek beschikbare IT-diensten. Daarbij kun je nog een onderscheid maken tussen clouddiensten die primair gericht zijn op eindgebruikers zoals Dropbox en clouddiensten die primair gericht zijn op organisaties. Dit document gaat vooral over deze laatste categorie van clouddiensten omdat de instelling verantwoordelijk is voor de inkoop ervan. Voor een deel is het document ook van toepassing is op clouddiensten voor eindgebruikers, maar de rol van de instelling is daarbij vooral kaderstellend.

Een community cloud is een omgeving die specifiek voor de sector wordt beheerd, maar wel (grotendeels) de algemene kenmerken van cloud heeft. Deze kan zelf worden beheerd of door een externe partij en dat geldt ook voor de hosting. In het algemeen heeft public cloud de voorkeur omdat daarbij maximaal gebruik kan worden gemaakt van standaard oplossingen en schaalvoordeel. Tevens is tijd, geld en capaciteit noodzakelijk voor het inrichten van community cloud diensten, terwijl public cloud diensten direct beschikbaar zijn. In de praktijk zijn er allerlei redenen waarom het (nog) niet haalbaar is om gebruik te maken van de public cloud. Er wordt in de literatuur ook wel gesproken over private cloud (een organisatie-specifieke cloud) en hybrid cloud (een mengvorm van verschillende vormen van cloud). We hebben voor de eenvoud en toegankelijkheid van dit document ervoor gekozen deze varianten niet expliciet mee te nemen in overwegingen en criteria.

Er bestaan verschillende servicemodellen voor cloud: Software as a Service (SaaS), Platform as a Service (PaaS) en Infrastructure as a Service (IaaS) [22]. Bij SaaS neem je een complete applicatie af die direct voor gebruikers toegankelijk is via hun web-browser. Bij PaaS neem je een platform af waarop zich allerlei halffabrikaten bevinden (middleware) en waarop zelf applicaties kunnen worden ontwikkeld, geïnstalleerd en gehost. Bij IaaS worden infrastructurele diensten zoals reken- of opslagcapaciteit aangeboden en heeft de afnemer zelf maximaal invloed op alle softwarelagen, maar ook maximale verantwoordelijkheid om deze in te richten en beschikbaar te houden. Let op dat de geboden diensten zelf ook weer afhankelijk zijn van onderliggende diensten, die mogelijk door derden worden geleverd. In de volgende figuur is weergegeven hoe het beheer van IT in de verschillende servicemodellen is belegd.

Hoofdstuk6 figuur1.png
Figuur 1 Servicemodellen voor cloud

Overigens bestaat er ook Business Process as as Service (BPaaS), waarbij processen als dienst worden afgenomen (ook wel: Business Process Outsourcing). In dit document ligt echter de focus op IT-diensten en wordt BPaaS niet in de vergelijking meegenomen. Overigens zouden sourcingoverwegingen juist wel op dit niveau moeten starten. Inzicht in kerncompetenties geeft de belangrijkste indicatie voor welke processen het best zelf kunnen worden uitgevoerd en welke het best kunnen worden uitbesteed. Keuzes op dit niveau hebben typisch ook een grotere impact dan keuzes over sourcing van IT-diensten. Als een bepaald bedrijfsproces wordt uitbesteed dan gaat het om een combinatie van mensen en (IT) systemen en wordt daarmee dus (impliciet) ook een keuze gemaakt voor het uitbesteden van IT-diensten.

Soorten criteria

Er zijn drie soorten criteria waarmee rekening moet worden gehouden bij het kiezen van een deploymentmodel (public cloud, community cloud, eigen rekencentrum) voor IT-diensten:

  • Dienstcriteria: criteria die een eerste indicatie geven welk deploymentmodel het meest logisch is gebaseerd op de eigenschappen van een IT-dienst, los van een specifieke oplossing of leverancier.
  • Productcriteria: criteria die gebruikt kunnen worden om een specifiek product van een specifieke leverancier die invulling geeft aan een IT-dienst te selecteren.
  • Succesfactoren: eigenschappen van een instelling die de kans op succesvol uitbesteden van IT-diensten sterk vergroten.

Door het onderscheid in deze drie soorten criteria te maken wordt het duidelijker hoe kan worden omgegaan met het implementeren van IT-diensten in de cloud. De volgende tabel laat zien hoe de verschillende criteria kunnen worden gebruikt in tijd. Dienstcriteria kunnen worden gebruikt bij beleid en planvorming, zoals in een sourcingstrategie, om een eerste indicatie te geven welk deploymentmodel wenselijk is. Productcriteria worden typisch in een later stadium gebruikt, zoals bij het uitvoeren van een aanbesteding in een project. Bij het opstellen van business cases zouden zowel dienstcriteria als productcriteria moeten worden gebruikt. In een business case zou vooral ook goed moeten worden gekeken naar de mate waarin de voor- en nadelen van cloudcomputing een business case versterken of verzwakken. Succesfactoren vragen de aandacht van een organisatie voorafgaand aan een aanbesteding en zouden eerst in algemene zin moeten worden geborgd.

Beleid en planvorming Beleidsimplementatie Opstellen business case Projectuitvoering
Dienstcriteria X X
Productcriteria X X
Succesfactoren X

Tabel 1 Verschillende soorten criteria in tijd

Dienstcriteria

In deze paragraaf wordt ingegaan op de criteria die een indicatie geven voor het meest geschikte deploymentmodel op basis van eigenschappen van een IT-dienst. Deze criteria zijn zo algemeen geformuleerd dat ze op alle servicemodellen kunnen worden toegepast en dus voor zowel voor applicaties (SaaS), platformen (PaaS) als infrastructuur (IaaS) gelden. Wel is hun betekenis licht anders voor al deze servicemodellen. Aan het eind van deze paragraaf wordt een overzicht gegeven van alle criteria en hun relatie met de deploymentmodellen.

Commodity oplossing
In de public cloud zijn veel diensten aanwezig die gekenmerkt kunnen worden als “commodity”. Deze diensten zijn in hoge mate gestandaardiseerd; ze bieden generieke functionaliteit en gestandaardiseerde koppelvlakken. Doordat hun functionaliteit niet onderscheidend is en afnemers ze makkelijk kunnen vervangen (door hun standaard koppelvlakken) concurreren leveranciers vooral op prijs, die daardoor relatief laag is. Diensten met dit soort eigenschappen kunnen dus het best uit de public cloud gehaald worden omdat dit het meest efficiënt is. Dit geldt met name voor meer infrastructurele diensten omdat deze van nature meer generiek van aard zijn en een brede gebruikergroep kennen.

Hoge eenmalige investering
Diensten die een hoge eenmalige investering vragen die door meerdere afnemers gedeeld kan worden lenen zich erg goed voor de cloud. Investeringskosten worden in de cloud namelijk gedeeld door alle afnemers en afrekening vindt plaats op basis van gebruik (‘economies of scale’). Dit geldt extra sterk voor de public cloud omdat de gebruikersgroep hierbij in potentie veel groter is dan bij de community cloud.

Sterk variabele capaciteit
Doordat afnemers alleen betalen voor het daadwerkelijk gebruik zijn ook diensten die een sterk variabele capaciteit vragen door een schommeling in de business volumes erg geschikt voor de cloud. Tijdens piekperioden wordt gewoonweg tijdelijk meer capaciteit ingeschakeld omdat er meer transacties moeten worden uitgevoerd. Voor de public cloud geldt dit sterker dan voor een community cloud doordat de schaal daar groter is.

Hoge beschikbaarheid
Cloudleveranciers kunnen veelal hogere niveau's van beschikbaarheid garanderen en ook buiten kantooruren ondersteuning door een servicedesk bieden. Voor instellingen is het veelal niet economisch verantwoord om dergelijke hoge serviceniveau's te bieden. IT-diensten waaraan hogere beschikbaarheids- en ondersteuningseisen worden gesteld kunnen daarom beter in de community of public cloud worden geplaatst. Dit geldt met name voor meer infrastructurele diensten omdat deze een grote gebruikersgroep hebben en onbeschikbaarheid van deze diensten een grote impact heeft.

Ervaring met dienst in public cloud
Het verkrijgen en implementeren van IT-diensten levert risico’s op die in voldoende mate moeten worden afgedekt. Diensten in de public cloud leveren additionele risico’s op en vragen daarom extra aandacht. Ervaringen van andere organisaties met het uit de cloud afnemen van een specifieke IT-dienst dragen sterk bij aan het vertrouwen dat dit soort risico’s acceptabel zijn.

Sectorspecifiek
Er zijn relatief minder sector-specifieke diensten beschikbaar in de public cloud doordat daar ook minder schaalvoordeel in te halen valt door de leverancier. Het ontwikkelen van een dienst voor een beperktere doelgroep is economisch minder aantrekkelijk voor een leverancier. Voor dit soort diensten ligt het dan ook voor de hand om deze uit de community cloud af te nemen. Overigens is dit vooral een keuze op sectorniveau; een individuele instelling kan niet zelf besluiten een dienst in de community cloud te ontwikkelen. Dit criterium geldt dan ook alleen voor een instelling indien er reeds een dergelijke dienst beschikbaar is in de community cloud.

Instellingsspecifiek
IT-diensten op een eigen locatie plaatsen kan noodzakelijk zijn als er hele specifieke functionaliteit noodzakelijk is die niet kan worden gevonden in een community of public cloud. Instellingsspecifieke functionaliteit is vooral gerechtvaardigd als deze ondersteuning biedt aan een onderscheidende kerncompetentie van de organisatie. In andere gevallen is het vooral een indicatie dat het proces dat wordt ondersteund nog onvoldoende is geharmoniseerd. Instellingsspecifieke functionaliteit kan zowel op applicatie, platform als op infrastructuurniveau bestaan, alhoewel de kans erop veruit het grootst is op applicatieniveau.

Instellingsspecifieke applicatiefunctionaliteit kan wel gebruik maken van een platform of infrastructuur in de cloud (PaaS, IaaS). Dit blijkt op een dieper patroon te duiden; als specifieke functionaliteit gewenst is op een bepaalde laag (applicatie, applicatieplatform, infrastructuur) dan kunnen de lagen eronder wel in de cloud worden geplaatst zodat je deze niet zelf hoeft te beheren (zie ook Figuur 10). Zo kan sectorspecifieke applicatiefunctionaliteit in de community cloud ook ondersteund worden door een platform af te nemen uit de public cloud. Daarnaast kan sectorspecifieke platformfunctionaliteit ook ondersteund worden op infrastructuur die uit de public cloud wordt afgenomen.

Locatie-afhankelijkheid
Bepaalde zaken zijn sterk afhankelijk van locatie of de nabijheid van andere systemen op dezelfde locatie en zijn daardoor niet geschikt voor de community of public cloud. Denk bijvoorbeeld aan netwerken, werkstations (voor zover deze niet door de gebruiker zelf worden meegenomen) of hele specialistische apparatuur. Daarnaast zouden er specifieke performance-eisen kunnen zijn waaraan community- of public cloud diensten niet kunnen voldoen doordat zij op een andere locatie staan. De responsetijd zal snel hoger zijn als systemen niet fysiek bij elkaar geplaatst zijn en dat kan voor specifieke toepassingen onacceptabel zijn. Denk bijvoorbeeld aan wetenschappelijke berekeningen die een hoge mate van interactie met de gegevens hebben.

Tabel 1 geeft een overzicht van de voorgestelde criteria en een indicatie voor het meest passende deploymentmodel. Een plusteken geeft aan dat een bepaald deploymentmodel logisch is. Een dubbel plusteken geeft aan dat dit zelfs in sterke mate het geval is. De community cloud en de public cloud delen veel kenmerken, waardoor een aantal criteria voor beiden gelden. Een aantal van die criteria gelden wel sterker voor de public cloud, omdat hier meer schaalvoordeel in gehaald wordt. Hierdoor kan de public cloud bijvoorbeeld beter met sterk variabele capaciteit omgaan en kunnen investeringskosten met meer gebruikers worden gedeeld.

Public cloud Community cloud Eigen locatie
Commodity oplossing + - -
Hoge eenmalige investering ++ + -
Sterk variabele capaciteit ++ + -
Hoge beschikbaarheid + + -
Ervaring met dienst in public cloud + - -
Sectorspecifiek - + -
Instellingsspecifiek - - +
Locatie-afhankelijkheid - - +

Tabel 1 Dienstcriteria

Voorbeelden

Tabel 4 geeft een aantal voorbeelden van IT-diensten, hoe zij scoren op de dienstcriteria en het meest logische deploymentmodel gegeven deze scoring. De diensten zelf zijn op een functionele wijze beschreven; het gaat immers om de functionaliteit en niet om het systeem dat de functionaliteit levert. Merk op dat de dienstcriteria vooral bedoeld zijn om een eerste indicatie te geven van het meest geschikte deploymentmodel. Pas nadat ook de succesfactoren, business case criteria en productcriteria zijn beoordeeld is pas helder of cloudsourcing ook echt verstandig is. Hierdoor kan het zijn dat een belangrijk deel van de IT-diensten in de tabel uiteindelijk toch niet als clouddienst zal worden afgenomen. De reden hiervoor kan zijn dat de organisatie er nog niet klaar voor is, het voordeel van cloud in de business case onvoldoende tot uitdrukking komt of doordat leveranciers van clouddiensten niet kunnen voldoen aan de productcriteria.

IT-dienst Locatie-afhanke-lijkheid Instellings-specifiek Commodity oplossing Hoge eenmalige investering Sterk variabele capaciteit Hoge beschik-baarheid Ervaring met dienst in public cloud Sector-specifiek Public cloud Community cloud Eigen locatie
Deelnemerwerving + + + +
Inschrijving + + +
Roostering + + + +
Toetsing + + + +
Onderzoeks-registratie + +
Onderzoeksresultaat-archivering + + + +
Medewerker-administratie + + +
Grootboekbeheer + + +
Delen van documenten + + + +
E-mail en agenda + + + +
Web content management + + + + +
Opslag van documenten + + + +
Opslag van ruwe meetgegevens + + + + + +
Servercapaciteit + + + + +
High performance computing + + + + + +
Fysiek werkstation + + +
Lokaal netwerk + + +
Specialistische apparatuur + + +

Tabel 2 Voorbeelden van diensten en indicatie van gewenst deploymentmodel

Een aantal scores in de tabel vragen een korte toelichting:

  • Deelnemerwerving is aangemerkt als instellingsspecifiek. Dit is gebaseerd op het feit dat bestuurders tijdens een workshop van het project Regie in de Cloud hebben aangegeven dat profilering en werving onderscheidende kerncompetenties zijn.
  • Onderzoeksresultaatarchivering gaat om het langdurig bewaren van onderzoeksgegevens die horen bij een verrijkte publicatie. In de tabel is voor deze dienst zowel “community cloud” als “public cloud” aangemerkt. Dit komt omdat er allerlei public cloud diensten ontstaan hiervoor zoals Figshare en Datadryad die concurreren met gemeenschappelijke voorzieningen zoals geleverd door 3TU.Datacentrum en DANS.
  • Bij servercapaciteit wordt gedoeld op capaciteit die niet een hele hoge mate van interactie heeft met een gegevensverzameling op een andere locatie. In dat geval zou namelijk het criterium “locatie-afhankelijkheid” gelden.

Productcriteria

Deze paragraaf gaat in op criteria die gebruikt kunnen worden van een specifiek product die invulling geeft aan een IT-dienst. Het benoemt vooral criteria die relevant zijn vanuit het perspectief van cloud computing en is dus niet bedoeld als een algemene checklist om te komen tot een programma van eisen voor de aanschaf van IT-diensten.

Beveiligingsmaatregelen
Het is belangrijk dat de integriteit van gegevens wordt geborgd en dat vertrouwelijke gegevens niet voor onbevoegden inzichtelijk zijn. Dat betekent dat een leverancier minimaal functionaliteit biedt voor authenticatie en autorisatie. Voor gegevens met een hoge vertrouwelijkheid kunnen meer specifieke maatregelen noodzakelijk zijn zoals sterke authenticatie, encryptie of het plaatsen van gegevens in de Europese Economische Ruimte (EER). De afweging tussen risico’s en maatregelen moet goed worden gemaakt en is een instellingsverantwoordelijkheid. Voor extreem gevoelige gegevens (bijv. concurrentiegevoelige onderzoeksgegevens) kunnen instellingen ondanks mogelijke maatregelen de risico’s toch nog te groot vinden om ze in de cloud te plaatsen.

Voldoen aan juridisch normenkader
Het juridisch normenkader [17] stelt regels aan het toezicht op IT-diensten die persoonsgegevens beheren. Het is vooral een uitwerking van de eisen die het College Bescherming Persoonsgegevens stelt aan persoonsgegevens, onderverdeeld in vier risicoklassen. Dit betekent onder meer dat persoonsgegevens in de Europese Economische Ruimte (EER) dienen te worden verwerkt. Deze eisen moeten geborgd worden door afspraken te maken met leveranciers van producten. Dit zorgt ervoor dat aspecten als privacy, vertrouwelijkheid, eigendom en beschikbaarheid van data worden geborgd.

Koppeling met SURFconext
Bij het gebruik van cloud diensten is de identiteit van de gebruiker noodzakelijk voor authenticatie en autorisatie. Op sectorniveau is hiervoor SURFconext gepositioneerd welke een intermediair vormt tussen instellingen (identity providers) en leveranciers van diensten (service providers). Als diensten SURFconext ondersteunen dan hebben gebruikers geen extra identiteit (en wachtwoord) nodig.

Koppelvlakken op basis van open standaarden
In het algemeen is het belangrijk dat de informatievoorziening geïntegreerd is. Dit vraagt om koppelvlakken die bij voorkeur gebaseerd zijn op open standaarden, zowel op technisch niveau als op inhoudelijk niveau (semantiek). Gestandaardiseerde koppelvlakken zorgen er tevens voor dat leveranciersafhankelijkheid zoveel mogelijk wordt voorkomen.

Aanpasbaarheid
Het moet mogelijk zijn de clouddienst aan te passen aan de eigenschappen die inherent specifiek zijn voor een bepaalde instelling. Denk met name aan specifieke bedrijfsregels en bijbehorende (drempel)waarden die sterk afhankelijk zijn van eigen keuzes. Ook kan een mate van aanpasbaarheid van het proces dat wordt ondersteund wenselijk zijn. Daar moet wel genuanceerd naar worden gekeken want veel processen kunnen nu eenmaal vrij standaard worden ingericht. Dit geldt met name voor processen in de bedrijfsvoering.

Evolueerbaarheid
Organisaties willen niet te sterk afhankelijk zijn van een specifieke leverancier. Veranderingen in een specifieke dienst zouden niet direct impact moeten hebben op de gebruikersorganisatie en het applicatielandschap. Dit betekent dat een leverancier niet zomaar functionaliteit zou moeten verwijderen en het mogelijk moet maken dat afnemers van een specifieke dienst in hun eigen snelheid kunnen migreren naar een nieuwe versie van deze dienst. Koppelvlakken zouden terugwaarts compatibiliteit moeten zijn omdat ze een verwevenheid kennen met het applicatielandschap van de organisatie die de dienst afneemt. Leveranciers zouden ook tijdig belangrijke wijzigingen moeten melden aan hun klanten.

Exit mogelijkheid
Sourcingkeuzes zijn niet voor eeuwig en instellingen moeten ook eenvoudig andere producten kunnen kiezen. Ze moeten dan ook eisen aan leveranciers dat zij kunnen beschikken over de gegevens die worden beheerd door de dienst, zodat deze kunnen worden gemigreerd naar een nieuw product. Ook zijn er juridische afspraken noodzakelijk, bijvoorbeeld om het risico af te dekken als de leverancier failliet gaat. Denk bijvoorbeeld aan een escrow overeenkomst die ervoor zorgt dat afnemers kunnen beschikken over (intellectuele) eigendommen als een leverancier failliet gaat.

Rekenmodel
Cloudleveranciers hanteren verschillende rekenmodellen voor het berekenen van de prijs van een clouddienst. Zo wordt veelal op basis van aantal gebruikers gerekend, maar kan bijvoorbeeld ook worden gekeken naar de hoeveelheid gebruikte rekencapaciteit of de hoeveelheid gegevens die van/naar de clouddienst zijn verplaatst/gekopieerd. Het is daarom belangrijk om goed te kijken of de karakteristieken van het gebruik van de clouddienst wel tot een gunstige prijs leiden gegeven het door de leverancier gehanteerde rekenmodel. Dit is met name relevant voor diensten in de public cloud; in de community cloud is het rekenmodel veelal beter afgestemd op de specifieke behoeften van het hoger onderwijs of worden kosten op een andere wijze doorbelast.

Service level agreement
Het is belangrijk om goede afspraken te kunnen maken met een leverancier over de kwaliteit van de dienstverlening en de wijze waarop wordt omgegaan met afwijkingen hierin. Denk daarbij ook aan het kunnen omgaan met calamiteiten door het bieden van uitwijkmogelijkheden en het voldoen aan duurzaamheidseisen. Het is in veel gevallen lastig om specifieke serviceniveau's te vragen van grote leveranciers; die bieden meestal een standaard SLA. SURFmarket kan namens meerdere instellingen onderhandelen met leveranciers en heeft daardoor een krachtiger onderhandelingspositie.

Succesfactoren

Het is duidelijk dat het gebruik van de community en public cloud voor veel instellingen op dit moment nog erg nieuw is. Er zijn wellicht, bewust of onbewust, al wel een aantal IT-diensten buiten het eigen rekencentrum geplaatst. De algemene maatregelen om dit op een optimale wijze uit te voeren zijn echter in veel gevallen nog niet genomen. De volgende succescriteria zorgen ervoor dat de kans op succesvolle cloud-sourcing hoger is.

Sourcingstrategie
Elke instelling dient zijn eigen context, prioriteiten en keuzen in acht te nemen bij het bepalen of en in welke mate het gebruik van community en public cloud opportuun is. Strategische keuzes dienen helder te zijn voorafgaand aan specifieke aanbestedingstrajecten. De in dit document beschreven dienstcriteria bieden daarbij een concreet handvat.

Regie-organisatie
Het inkopen van diensten en aansturen van externe leveranciers vraagt andere kennis en competenties dan het zelf ontwikkelen en beheren van systemen. Het is dan ook belangrijk om de daarvoor noodzakelijke rollen, organisatie en processen structureel in te richten. Dit vraagt onder meer een splitsing in demand, demand management, supply management en supply verantwoordelijkheden [18]. In het kader van demand management zullen taken als informatiemanagement, architectuur en governance zullen nadrukkelijk moeten worden geborgd. In het kader van supply management gaat het vooral over inkoop, contractmanagement en service (level) management.

Informatiebeveiliging
Het plaatsen van gegevens en functionaliteit buiten het eigen rekencentrum levert allerlei extra risico's op die wel goed in beeld dienen te zijn. Dit vraagt een professionele manier van omgaan met informatiebeveiliging [19, 21]. Minimaal is er een informatiebeveiligingsbeleid, een wijze van gegevensclassificatie en een lijst van standaard beveiligingsmaatregelen.

Beschrijving huidige IT-omgeving
Het is ook onverstandig om een landschap van IT-systemen uit te besteden dat onbeschreven is. Hierdoor ontstaan mogelijk onduidelijkheden over verantwoordelijkheden waar de leverancier misbruik van kan maken. Dit leidt tot hogere kosten alsook een slechte dienstverlening. Minimaal is er een beschrijving van de huidige IT-architectuur. Daarnaast zouden de kosten van de huidige IT-omgeving helder moeten zijn, zodat objectief kan worden beoordeeld of een cloud-gebaseerde dienst economisch aantrekkelijk is.

Impact van cloud

De vraag is wat de impact is van cloud op de informatievoorziening van instellingen voor hoger onderwijs. Op basis van de beschreven criteria en de voorbeelduitwerking lijken de meeste IT-diensten prima geschikt zijn om als clouddienst af te nemen. Het belangrijkste obstakel om voor cloud te kiezen voor deze IT-diensten is de relatief beperkte beschikbaarheid van deze diensten in de public cloud en/of de ervaring met deze IT-diensten door Nederlandse HO-instellingen. Dit kan in de toekomst veranderen door de aandacht die cloud computing op dit moment krijgt, waardoor op termijn een groter deel van de informatievoorziening cloudgebaseerd kan zijn. De toekomst zal echter vooral ook hybride van aard zijn. Een aantal IT-diensten zijn locatie-gebonden en zullen nooit als clouddienst kunnen worden afgenomen. Daarnaast is het de vraag in hoeverre er voldoende kwalitatief hoogwaardige sectorspecifieke diensten in de public cloud beschikbaar zullen komen om de community cloud overbodig te maken. Ook de prijsstelling van deze public clouddiensten speelt daarbij een belangrijke rol en kan reden zijn om (tijdelijk) toch voor een community cloud te kiezen. Op dit moment worden er met name door SURFsara en SURFnet community clouddiensten aangeboden.

Het is belangrijk om de verschillende servicemodellen van cloud (SaaS, PaaS, IaaS) goed van elkaar te onderscheiden omdat deze verschillende karakteristieken hebben en keuzes daarover ook relatief los van elkaar zijn te maken. Er is ook niet automatisch een groeipad van IaaS naar PaaS of SaaS. Zoals beschreven bij Figuur 10 kunnen ze elkaar wel completeren; als SaaS niet haalbaar is omdat een instellingsspecifieke functionaliteit gewenst is, kan wel gebruik worden gemaakt van PaaS of IaaS, waardoor de applicatie uiteindelijk ook niet in het eigen rekencentrum hoeft te worden gehost. Naast IaaS zullen instellingen ook op zoek gaan naar mogelijkheden om hun rekencentra te consolideren en daarmee kosten te besparen. De verwachting is dat er in de toekomst meer diensten beschikbaar komen in de community cloud, mede door de initiatieven die SURF onderneemt. Het is de vraag in hoeverre de inzet van PaaS in het hoger onderwijs verstandig is aangezien de algemene ontwikkeling juist is om applicaties niet meer zelf te ontwikkelen. Om migratiekosten te besparen moeten sourcingkeuzes daarom vooral heel bewust en weloverwogen worden genomen.