owered by TCPDF (www.tcpdf.org) Academiejaar 2013 2014 Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg 1 9000 Gent Opzetten van een cloud based business intelligence solution Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica Gylian VERSTRAETE Tim VAN GOETHEM Promotoren: ing. Pieter-Jan MAENHAUT ing. Peter SEYNAEVE (Deloitte Accountancy BC & IT) Jeroen BLANCKAERT (Deloitte Accountancy BC & IT) Begeleider: Johan VLAMINCKX (Deloitte Accountancy BC & IT)
ii
De auteurs geven de toelating deze scriptie voor consultatie beschikbaar te stellen en delen ervan te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting uitdrukkelijk de bron te vermelden bij het aanhalen van resultaten uit deze scriptie. The authors give the permission to use this thesis for consultation and to copy parts of it for personal use. Every other use is subject to the copyright laws, more specifically the source must be extensively specified when using from this thesis. Gent, juni 2014 Gylian Verstraete Tim Van Goethem
iv
Woord vooraf Een thesis vormt het sluitstuk van een opleiding. Een masterproef laat toe om een eigen toets te geven aan de studie door een onderwerp te kiezen in een domein dat je interesseert. Deze thesis heeft ons veel kennis bijgebracht in de domeinen van cloud computing en business intelligence. Een thesis maak je niet alleen en daarom dient er een dankwoord geschreven te worden. Vooreerst willen wij onze dank betuigen aan onze interne promotor ing. Pieter-Jan Maenhaut. Wij bedanken hem voor zijn begeleiding tijdens deze masterproef en zijn technische hulp en kennis die hij meermaals aan ons ten dienste heeft gesteld. Vervolgens richten wij onze oprechte dank aan onze externe promotoren Jeroen Blanckaert en ing. Peter Seynaeve. Ze stonden ons bij tijdens onze masterproef met zowel functionele als technische hulp. Zij maakten het ook mogelijk dat wij dit boeiend project konden aanvatten. Verder willen we ook Johan Vlaminckx bedanken. Als partner van Deloitte BC&IT is hij diegene die dit project mogelijk maakte voor ons. Ten slotte nog een speciaal woord van dank aan onze families. Ze stonden ons niet alleen in dit project bij, maar ook in de rest van ons leven. Wij richten hierbij een woord van dank aan Flo Vandenbussche voor het meehelpen aan de poster voor dit project. In het bijzonder bedanken we de moeder en de zus van Tim en de moeder van Gylian voor het nalezen van deze thesis. Gylian Verstraete Tim Van Goethem Gent, juni 2014 v
vi
Inleiding Wat is de cloud? Wat houdt multitenancy in? Wat wordt er bedoeld met business intelligence? Hoe kan een bestaande toepassing omgebouwd worden naar een cloud applicatie? Wat zijn de veiligheidsrisico s bij cloud toepassingen? Hoe kan een cloud applicatie toch goed beveiligd worden? Hoe gebeurt dit performant? Hoe zit het met de schaalbaarheid van dergelijke applicaties? Deze thesis zal met behulp van een concrete applicatie trachten een antwoord te bieden op al deze vragen. Een begrip dat enigszins losstaat van de cloud, is business intelligence 1. Business intelligence, afgekort BI, is een collectie van applicaties en technologieën om gegevens te verzamelen, te bewaren, te analyseren en beschikbaar te stellen aan het management. Zij kunnen dan op die manier meer gegronde beslissingen nemen. Tijdens de masterproef werd in samenwerking met Deloitte 2 een proof of concept uitgewerkt, waarbij een bestaande applicatie, de Deloitte Controlling Template (DCT) genaamd, werd omgevormd naar een cloud variant. Wat de DCT is en waarvoor men het gebruikt, wordt uitlegd in het eerste hoofdstuk. In het tweede hoofdstuk worden een aantal functionele vereisten opgelijst die aangepast zijn aan een multi-tenant omgeving. Zo wordt besproken hoe tenants beheerd worden en hoe de applicatie dynamisch kan worden aangepast aan de noden van de klant. In het derde hoofdstuk wordt de cloud vanuit verschillende perspectieven bekeken. Als eerste komt multitenancy aan bod waarbij een historische schets wordt gemaakt. Een tweede aspect bestaat uit de verschillende implementatiemodellen zoals een publieke en een private cloud en een beknopte inleiding in gedistribueerde clouds en inter-cloud architecturen. Vervolgens worden de verschillende servicemodellen toegelicht. De belangrijkste hierbij zijn Infrastructure as a Service, Platform as a Service en Software as a Service. Als vierde topic worden de verschillende kostenmodellen uit de doeken gedaan, gevolgd door Service Level Agreements 1 Zie ook: http://www.techopedia.com/definition/345/business-intelligence-bi 2 http://www2.deloitte.com/be/en.html vii
viii (SLAs) en de problematiek rond privacy en wetgeving. Tot slot wordt er een keuze gemaakt over hoe de cloud er voor de DCT moet uitzien. In het vierde hoofdstuk wordt eerst een overzicht gegeven van de gebruikte technologieën om vervolgens de logische opbouw van de applicatie te bekijken. De verschillende lagen worden uitgelegd en er wordt bekeken hoe de logging met behulp van Aspect-Oriented Programming (AOP) 3 kan verweven worden in de code. Ten slotte wordt Microsoft Azure kort toegelicht, waarbij onder andere gekeken wordt naar de beperkingen die hierbij worden opgelegd aan de applicatie. In het vijfde hoofdstuk worden enkele datamodellen van bestaande business intelligence solutions geanalyseerd en wordt een eigen datamodel uitgewerkt voor zowel de relationele databank als het datawarehouse 4. In het zesde hoofdstuk worden allerhande technieken bekeken die de performantie van de applicatie verhogen. Zo zal er aan server-side paginering, filtering en sortering worden gedaan. Verder wordt asynchroon programmeren in C#.NET en ASP.NET MVC uitgediept. Hierbij wordt eerst uitgelegd wanneer asynchroon programmeren voordelen biedt ten opzichte van het klassieke synchroon programmeren. Vervolgens worden enkele programmeerpatronen besproken en om dit topic af te sluiten, wordt een codevoorbeeld uitgewerkt waarbij een asynchrone file upload geïmplementeerd wordt. Het vervolg van hoofdstuk zes handelt over de verschillende partitioneringscriteria en -modellen en de voordelen van partitioneren. Het hoofdstuk wordt afgesloten met een woordje uitleg over state servers en load balancers. In het zevende en laatste hoofdstuk wordt gekeken naar de verschillende veiligheidsmaatregelen die genomen zijn. Deze maatregelen gaan van het scheiden van de tenants tot het toekennen van rollen binnen een tenant en zelfs tot het weren van kwaadaardige acties. 3 Aspect-Oriented Programming is een manier van programmeren waarbij men de modulariteit wil verhogen door de zogehete cross-cutting concerns zo veel mogelijk te scheiden. 4 Een datawarehouse is een databank, gebruikt voor het analyseren en rapporteren van data.
Abstract (Nederlands) Het doel van deze masterproef is om een bestaand financieel rapporteringsplatform om te vormen naar een multi-tenant applicatie in de cloud. Hierbij stelt elke tenant een bedrijf voor en elk bedrijf kan een aantal entiteiten bevatten. Bij het rapporteren kunnen bepaalde entiteiten gegroepeerd worden tot consolidaties. Het is vereist dat de bestaande functionaliteiten uit de Deloitte Controlling Template (DCT) beschikbaar zijn in deze online oplossing. De gebruiker moet via een performante en gebruikersvriendelijke user interface toegang krijgen tot zijn gegevens en deze verder kunnen gebruiken/manipuleren om tot de gewenste rapportering te komen. Hierbij is het uiteraard de bedoeling dat een gebruiker geen impact ondervindt van andere gebruikers. Samen met performantie behoren beveiliging en schaalbaarheid tot de drie grootste aandachtspunten binnen deze thesis. ix
x
Abstract (English) The goal of this master dissertation is to convert an existing financial reporting platform to a multitenant cloud based application. In this application each tenant represents a company and each company can consist of multiple entities. During the reporting phase several entities can be grouped into a consolidation. The existing functionality from the Deloitte Controlling Template needs to be transformed to the cloud based solution. An efficient and user-friendly user interface should give the user access to his data and enable him to use/manipulate this data to achieve his desired reporting state. During these actions the user should not experience delays due to actions of other users. The main points of interest for this dissertation are performance, security and scalability. xi
xii
Inhoudsopgave Woord vooraf Introductie Abstract (Nederlands) Abstract (English) Inhoudsopgave v vii ix xi xvii 1 Huidige applicatie 1 2 Functionele vereisten 5 2.1 Inleiding....................................... 5 2.2 Het beheer van tenants............................... 5 2.2.1 Een nieuwe tenant aanmaken....................... 5 2.2.2 Een tenant desactiveren.......................... 5 2.2.3 Het activeren en desactiveren van formulieren.............. 6 2.3 Het beheer van gebruikers en gebruikersprofielen binnen een tenant...... 6 2.3.1 Een gebruiker aanmaken.......................... 6 2.3.2 Een gebruiker verwijderen......................... 6 2.3.3 Het wachtwoord van een gebruiker wijzigen............... 6 2.3.4 Profielen beheren.............................. 6 2.4 Het beheer van structures binnen een tenant................... 7 2.4.1 De types structures............................. 7 2.4.2 Hiërarchie van structures in de tijd.................... 7 2.5 De applicatie dynamisch aanpassen........................ 7 2.5.1 Hooks in de SQL-code........................... 7 2.5.2 De dimensiekolommen........................... 7 2.6 Het uploadproces.................................. 8 2.6.1 Een upload mapping vastleggen, wijzigen of verwijderen........ 8 2.6.2 Het opladen van de data.......................... 8 2.7 Werken met verschillende versies van de data.................. 8 2.7.1 Het opladen van een nieuwe versie.................... 8 2.7.2 De activatie van een versie......................... 8 xiii
Inhoudsopgave xiv 2.8 De data corrigeren................................. 9 2.9 Het exporteren naar het datawarehouse..................... 9 2.10 Van datawarehouse naar rapporteringstool.................... 9 2.11 Logging: het ideale hulpmiddel.......................... 10 2.11.1 Systeemlogs................................. 10 2.11.2 Applicatielogs................................ 10 3 De Cloud 11 3.1 Inleiding....................................... 11 3.2 Multitenancy.................................... 12 3.2.1 Historiek.................................. 12 3.2.2 Economisch aspect............................. 13 3.2.3 Uitdagingen................................. 13 3.3 Implementatiemodellen............................... 14 3.3.1 Publieke cloud............................... 15 3.3.2 Private cloud................................ 16 3.3.3 Community cloud............................. 18 3.3.4 Hybride cloud................................ 18 3.3.5 Samenvatting................................ 18 3.4 Gedistribueerde clouds en inter-cloud architecturen............... 19 3.4.1 Gedistribueerde clouds........................... 19 3.4.2 Inter-cloud architecturen.......................... 19 3.5 Servicemodellen................................... 21 3.5.1 Infrastructure as a Service......................... 22 3.5.2 Platform as a Service........................... 22 3.5.3 Software as a Service............................ 22 3.5.4 Afgeleide architecturen........................... 23 3.6 Kostenmodellen................................... 24 3.6.1 Pay-as-you-go model............................ 24 3.6.2 Maandelijks vast bedrag.......................... 24 3.6.3 Pay-for-resources model.......................... 25 3.6.4 Waardegebaseerde prijszetting...................... 25 3.6.5 Kostengebaseerde prijszetting....................... 25 3.6.6 Competitiegebaseerde prijszetting.................... 25 3.6.7 Spot-pricing model............................. 25 3.6.8 Klantgebaseerde prijszetting........................ 25 3.6.9 Hybride prijszetting............................ 25 3.7 Service Level Agreements............................. 26 3.7.1 Mogelijke criteria QoS........................... 26 3.7.2 Soorten SLAs................................ 27 3.7.3 Voorbeeld.................................. 28 3.8 Privacy en wetgeving................................ 28 3.8.1 Privacy................................... 28
Inhoudsopgave xv 3.8.2 Wetgeving.................................. 29 3.9 Keuze........................................ 31 4 Cloud applicatie 33 4.1 Inleiding....................................... 33 4.2 Gebruikte technologieën.............................. 33 4.2.1 C#.NET.................................. 33 4.2.2 ASP.NET MVC 4.0............................ 35 4.2.3 Entity Framework............................. 38 4.2.4 Language-Integrated Query (Linq).................... 40 4.2.5 SQL Server................................. 41 4.2.6 HTML5, CSS3, JQuery.......................... 41 4.3 Applicatiemodel.................................. 42 4.3.1 Het meerlagenmodel............................ 42 4.3.2 Logging................................... 44 4.3.3 Exception handling............................. 45 4.4 Microsoft Azure................................... 47 5 Datamodel 49 5.1 Inleiding....................................... 49 5.2 Multi-tenant datamodellen............................. 49 5.3 Voor- en nadelen.................................. 50 5.3.1 Economisch................................. 50 5.3.2 Beveiliging................................. 51 5.3.3 Doelgroep.................................. 51 5.4 Keuze........................................ 52 5.4.1 Relationele databank............................ 52 5.4.2 Datawarehouse............................... 53 5.5 Salesforce.com................................... 54 5.5.1 Situering.................................. 54 5.5.2 Datamodel................................. 54 5.6 Jaspersoft...................................... 54 5.6.1 Situering.................................. 54 5.6.2 Datamodel................................. 54 5.7 Eigen datamodel.................................. 55 5.7.1 Tabellen van het framework........................ 55 5.7.2 Mogelijke implementaties......................... 59 6 Performantie 61 6.1 Inleiding....................................... 61 6.2 Server-side pagineren, filteren en sorteren.................... 61 6.3 Bulk copy...................................... 63 6.4 Asynchroon programmeren in C#.NET en ASP.NET MVC.......... 67 6.4.1 De thread pool op een webserver..................... 67
Inhoudsopgave xvi 6.4.2 Wanneer is asynchroon programmeren de juist keuze.......... 68 6.4.3 Asynchronous Programming Patterns.................. 68 6.4.4 Asynchrone lambda-uitdrukkingen.................... 70 6.4.5 Parallellisme................................ 70 6.4.6 Synchrone en asynchrone controllers................... 72 6.4.7 Toepassing: asynchrone file upload.................... 74 6.5 Partitionering.................................... 74 6.5.1 Voordelen.................................. 74 6.5.2 Partitioneringscriteria........................... 75 6.5.3 Partitioneringsmethodes.......................... 77 6.5.4 Partitionering in de DCT Online..................... 77 6.6 State server en load balancers........................... 78 6.6.1 Inleiding................................... 78 6.6.2 IIS implementatie............................. 80 7 Beveiliging 81 7.1 Inleiding....................................... 81 7.2 Rollen binnen de applicatie............................ 81 7.3 Isolatie van de tenant data............................ 83 7.3.1 Mogelijkheden............................... 83 7.3.2 Query interceptor in het Entity Framework............... 84 7.3.3 Iedere tenant een eigen connectiestring in combinatie met views.... 84 7.3.4 De ideale mix: een query interceptor samen met views......... 85 7.4 Rollen binnen een tenant............................. 88 7.5 Beschikbaar stellen van de data aan een rapporteringstool........... 89 7.5.1 Webservice................................. 89 7.5.2 Tijdelijke tokens.............................. 90 7.6 Weren van kwaadaardige acties.......................... 90 7.6.1 Url aanpassen................................ 90 7.6.2 SQL injection................................ 91 7.6.3 Code injection............................... 91 7.6.4 Packet sniffing............................... 92 7.7 Beveiliging in ASP.NET MVC........................... 93 7.7.1 Authenticatie en autorisatie........................ 93 7.7.2 AntiForgeryToken............................. 94 7.7.3 Encryptie van connectiestrings...................... 94 7.8 Encryptie van data................................. 96 7.8.1 Hashing van gebruikerswachtwoorden.................. 97 7.8.2 Encryptie van tenantwachtwoorden.................... 99 7.8.3 Encryptie van de eigenlijke data..................... 100 Conclusie 101 Lijst van figuren 105
Inhoudsopgave xvii Lijst van tabellen 107 Lijst van codevoorbeelden 108 Bijlage A Handleiding 111 A.1 Een handleiding voor de ontwikkelaar...................... 111 A.1.1 De eerste keer builden........................... 111 A.1.2 Nieuwe databanktabellen toevoegen................... 112 A.1.3 Een nieuwe module creëren........................ 112 A.1.4 Een nieuw formulier aanmaken...................... 112 A.2 Een handleiding voor de application admin................... 113 A.2.1 Tenants beheren.............................. 113 A.2.2 Logs bekijken................................ 119 A.3 Een handleiding voor de tenant admin...................... 120 A.3.1 Beheerpagina openen............................ 120 A.3.2 Structures beheren............................. 122 A.3.3 Profielen beheren.............................. 125 A.3.4 Gebruikers beheren............................. 127 A.4 Een handleiding voor de gebruiker........................ 128 A.4.1 Wachtwoord wijzigen............................ 128 A.4.2 De menustructuur............................. 130 A.4.3 Een uploadmapping vastleggen...................... 133 A.4.4 Een bestand uploaden........................... 135 Bijlage B Microsoft Azure: Service Level Agreement 139 Bijlage C Datamodel van Salesforce.com 147 Bijlage D Datamodel van Jaspersoft 149 Bijlage E Eigen datamodel 151 Bijlage F Asynchrone file upload 155 Bijlage G Form-autorisatie 161 Bijlage H Encryptie van tenantwachtwoorden 167 Referentielijst 171
Inhoudsopgave xviii
Hoofdstuk 1 Huidige applicatie De Deloitte Controlling Template (DCT) werd ontwikkeld om het rapporteringsproces binnen kleine en middelgrote ondernemingen (KMO s) te ondersteunen. Het resultaat van de rapportering moet het management een duidelijk beeld geven over de stand van zaken binnen de onderneming. Ten gevolge van enkele trends binnen de KMO-wereld voldeden de bestaande methodes niet meer. Zo vormden ondernemingen steeds meer groepen of bestonden ze vaker uit verschillende activiteiten. Een ander aspect was de expansieve groei en de overnames. Het gevolg hiervan binnen een ondernemingsgroep was dat business units 1 en legale entiteiten niet meer éénop-één afgestemd waren. Een goed en snel inzicht krijgen in de rentabiliteitscomponenten van de groep werd hierdoor lastiger. Ten slotte dwong de steeds toenemende druk op marge ondernemingen om de toegevoegde waarde van elke overhead-activiteit te maximaliseren en tegen een minimale kost uit te voeren. De DCT is een template die het rapporteringsproces ondersteunt door gebruik te maken van gangbare software die reeds beschikbaar is in de meeste KMO s. Deze template vormt een basisversie van de software en datastructuur die dan verder wordt aangepast aan de noden van de klant. De Deloitte Controlling Template bestaat uit een aantal kernfunctionaliteiten. Zo kan periodiek een consolidatie worden opgemaakt. De balans- en resultatenrekeningen van de verschillende entiteiten worden opgeladen en de eventuele einde-periode-boekingen toegevoegd. Het omrekenen van wisselkoersverschillen, de automatische eliminatie van intercompanytransacties en het invoeren van consolidatieboekingen zijn enkele van de standaard mogelijkheden in de template om een geconsolideerd resultaat van een groep op te maken. 1 Een business unit, kortweg BU, is een logische eenheid binnen een bedrijf dat een specifieke business functie vertegenwoordigt (bv. productie, marketing, human resources... ). 1
Hoofdstuk 1. Huidige applicatie 2 Kosten en opbrengsten worden aan business units toegewezen. Hiervoor kan analytische informatie uit de boekhouding worden ingelezen of kan een kostenallocatiemodel worden opgemaakt in de DCT. De integratie van operationele data maakt het mogelijk om deze verdeelsleutels op een geautomatiseerde manier up-to-date te houden. Er wordt in de DCT gebruikgemaakt van een datawarehouse om op een gecontroleerde manier de brede waaier aan gegevens te beheren: financiële gegevens, analytische informatie, kostenverdeelsleutels, versies, correctieboekingen... Zo is men steeds zeker dat de correcte gegevens gebruikt worden in het rapporteringsproces. De uiteindelijke rapportering (het consolidatierapport, het business unit rapport... ) wordt berekend in de DCT, maar weergegeven in de business intelligence software waarover de onderneming reeds beschikt. Microsoft Power Pivot en QlikView zijn enkele voorbeelden hiervan. In figuur 1.1 wordt de data flow van de Deloitte Controlling Template visueel weergegeven. Bovenaan is te zien dat er verschillende data geïnjecteerd worden in de DCT. Deze data kunnen een data-export uit bijvoorbeeld SAP 2 zijn; ook een Excel-bestand of een CSVbestand 3 behoren tot de mogelijkheden. Na het verwerken van deze data, levert de DCT de rapporteringsdata af aan bijvoorbeeld QlikView. Figuur 1.1: De data flow binnen de Deloitte Controlling Template 2 www.sap.com 3 CSV is de afkorting voor Comma Separated Values. Waarden worden gescheiden door een bepaald karakter, bijvoorbeeld het kommapunt.
Hoofdstuk 1. Huidige applicatie 3 Momenteel wordt de DCT als rich client 4 opgezet. Dit heeft echter als nadeel dat het de nodige infrastructuur en opzet bij de klant vereist, wat kosten met zich meebrengt (licenties, installatie- en configuratietijd... ). Een rich client (Figuur 1.2) verwijst naar een client computer die bepaalde taken kan uitvoeren zonder de tussenkomst van een server. Zijn tegenhanger is de thin client (Figuur 1.3) die wel sterk afhankelijk is van een server. Een thin client komt typisch voor bij cloud toepassingen. Figuur 1.2: De opstelling voor thick clients Figuur 1.3: De opstelling voor thin clients In de volgende hoofdstukken van deze thesis wordt dan ook beschreven hoe deze tool omgezet kan worden naar een multi-tenant cloud applicatie. Deze cloud-versie heeft de naam Deloitte Controlling Template Online (DCT Online) gekregen. 4 Een rich client wordt ook wel een fat, heavy of thick client genoemd.
Hoofdstuk 1. Huidige applicatie 4
Hoofdstuk 2 Functionele vereisten 2.1 Inleiding In dit hoofdstuk zullen de voornaamste functionele vereisten behandeld worden. Eerst wordt het beheer van tenants, gebruikers en gebruikersprofielen beschreven. Daarna wordt er gekeken hoe men de applicatie dynamisch kan aanpassen om aan de noden van iedere tenant te voldoen. Vervolgens worden de verschillende fasen die de data doorlopen, nader bekeken. Ten slotte zal het nut van logging in diverse situaties toegelicht worden. Indien de lezer wenst te weten hoe deze verschillende vereisten effectief uitgewerkt zijn, kan hij in de handleiding (Bijlage A) kijken. Merk hierbij op dat niet alle functionele vereisten reeds geïmplementeerd zijn. 2.2 Het beheer van tenants 2.2.1 Een nieuwe tenant aanmaken Als de application admin een nieuwe tenant aanmaakt, zal er een stored procedure uitgevoerd worden. Deze stored procedure zal naast het aanmaken van een nieuwe databankgebruiker en het toevoegen van een record in de Tenants-tabel, ook een extra partitie voorzien. Hierna worden dan twee tenant admins aangemaakt: één voor Deloitte en één voor de klant. 2.2.2 Een tenant desactiveren Tenants kunnen niet verwijderd worden, enkel gedesactiveerd. Een gebruiker die tot een gedesactiveerde tenant behoort, staat automatisch ook op non-actief. Doordat tenants niet volledig verwijderd worden, blijven hun data bestaan. Op die manier kan Deloitte slecht betalende klanten tijdelijk de toegang tot de applicatie ontzeggen. 5
Hoofdstuk 2. Functionele vereisten 6 2.2.3 Het activeren en desactiveren van formulieren Een ander taak van de application admin is het activeren en desactiveren van formulieren. Iedere tenant beschikt over een aantal formulieren die hij kan gebruiken. Formulieren worden gedeeld door alle tenants, maar zijn slecht beschikbaar indien ze voor de tenant in kwestie geactiveerd zijn. Op die manier is het mogelijk om klanten extra te laten betalen indien ze wensen gebruik te maken van een specifiek formulier. Verder bevordert dit ook de flexibiliteit, want zo kunnen extra formulieren gecreëerd worden om de eisen van een specifieke klant in te willigen zonder dat de andere tenants hiervan iets afweten. 2.3 Het beheer van gebruikers en gebruikersprofielen binnen een tenant Naast de tenant admins die beheerd worden door de application admin, zijn er ook gewone gebruikers binnen een tenant. Deze gewone gebruikers kunnen door een tenant admin gemanaged worden. 2.3.1 Een gebruiker aanmaken Gewone gebruikers worden aangemaakt door een tenant admin. moeten er profielen aan toegekend worden. Nadat ze gecreëerd zijn, 2.3.2 Een gebruiker verwijderen Een gebruiker zal niet echt verwijderd worden. Er wordt van lazy deletion gebruikgemaakt, want er kunnen gegevens gekoppeld zijn aan die gebruiker. Lazy deletion houdt in dat het veld IsActive van de Users-tabel op false gezet wordt. 2.3.3 Het wachtwoord van een gebruiker wijzigen Het wijzigen van een wachtwoord wordt overgelaten aan de gebruiker in kwestie. Om te vermijden dat data echter verloren gaan wanneer de gebruiker zijn wachtwoord vergeten is, kan een admin dit ook resetten. Een tenant admin kan dit doen voor een gebruiker binnen dezelfde tenant, de application admin voor tenant admins. 2.3.4 Profielen beheren Profielen worden op tenantniveau beheerd en leggen de lees- en schrijfrechten vast per formulier. Deze profielen kunnen voor elke gebruiker apart per structure toegekend worden. Met andere woorden het is mogelijk om een gebruiker of gebruikersgroep voor een specifieke entiteit lees- en/of schrijfrechten te geven op een bepaald formulier en dit te ontzeggen voor elke andere entiteit.
Hoofdstuk 2. Functionele vereisten 7 Bij het maken van profielen, kan men van scratch alle rechten toekennen. Eens één profiel gemaakt is, heeft men de mogelijkheid om een kopie te nemen van dit profiel en hierop enkele wijzigingen aan te brengen. Op die manier is men niet genoodzaakt verschillende keren hetzelfde in te stellen, wat de kans op fouten behoorlijk vermindert. Het spreekt voor zich dat men te allen tijde de mogelijkheid heeft om de eigenschappen (ook de naam) van profielen te wijzigen. 2.4 Het beheer van structures binnen een tenant 2.4.1 De types structures Momenteel bestaan er twee types structures: de entiteit en de consolidatie. Consolidaties vormen een groep van entiteiten en/of andere consolidaties. Een tenant admin kan de structures binnen zijn tenant beheren. Structures kunnen net zoals gebruikers niet echt verwijderd worden. Ook hier is er een veld IsActive voorzien. 2.4.2 Hiërarchie van structures in de tijd Zoals eerder gezegd, kunnen structures een ouder toegewezen krijgen. Deze ouder kan echter wijzigen: in periode A kan een entiteit bijvoorbeeld deel uitmaken van een consolidatie X terwijl het in periode B tot consolidatie Y behoort. 2.5 De applicatie dynamisch aanpassen 2.5.1 Hooks in de SQL-code Bij het uitvoeren van controles zullen een reeks stored procedures gebruikt worden. Deze stored procedures verschillen van klant tot klant. Ze zullen dan ook moeten bewaard worden in een tabel zodat dynamisch de juiste stored procedure kan opgehaald en uitgevoerd worden. Stored procedures van enkele duizenden lijnen zijn hierbij geen uitzondering. Een klein percentage van deze lijnen zal echter klantspecifiek zijn. Daarom ligt het voor de hand om op diverse plaatsen in de stored procedure, hooks te voorzien. Een hook maakt het mogelijk om dynamisch extra code in de basiscode te haken. Een extra vereiste hierbij is dat er eventueel meerdere stukken code op dezelfde plaats ingevoegd moeten worden, weliswaar in een zekere volgorde. 2.5.2 De dimensiekolommen Bij de transactionele data horen ook metadata bewaard te worden. Deze metadata kunnen sterk variëren naargelang de tenant. Om deze te kunnen bewaren, moeten er extra dimen-
Hoofdstuk 2. Functionele vereisten 8 siekolommen voorzien zijn. Indien er dimensiekolommen tekort zouden zijn voor een bepaalde tenant, moet het mogelijk zijn om die kolommen eenvoudig toe te voegen. Het spreekt voor zich dat dit moet gebeuren met een minimum aan aanpassingen en vooral zonder repercussies voor de andere tenants. 2.6 Het uploadproces 2.6.1 Een upload mapping vastleggen, wijzigen of verwijderen Tenant admins beheren de upload mappings. De admins in kwestie moeten in staat gesteld worden zulke mappings vast te leggen, te wijzigen en te verwijderen. Deze mappings gelden binnen de volledige tenant en definiëren hoe bestanden die opgeladen worden, moeten gemapt worden naar een tabel in de databank. Bij deze mappings kan men kolommen uit het bestand in een andere volgorde in de databank stoppen; zelfs niet alle kolommen hoeven gebruikt te worden. Verder leggen ze ook vast of een bepaald veld verplicht is of niet en welk datatype er verwacht wordt. Bovendien houdt een mapping bij hoeveel lijnen er mogen genegeerd worden in het begin van het te uploaden bestand. Op die manier kunnen hoofdingen overgeslagen worden. 2.6.2 Het opladen van de data Gebruikers die de gepaste rechten hebben, kunnen hun data opladen. Eerst moet men kiezen voor welke structure de data geldig zijn. Vervolgens zal men een reeks bestanden kiezen. Deze bestanden mogen gerust elk een ander bestandsformaat hebben. Daarna kiest men voor ieder bestand een upload mapping die is vastgelegd door een tenant admin. Ten slotte worden alle bestanden tegelijkertijd geüpload en verwerkt. Merk hierbij op dat er zal gecontroleerd moeten worden of deze bestanden voldoen aan het desbetreffende formaat. Hoe dit verwezenlijkt wordt, staat beschreven in paragraaf 2.11.2. 2.7 Werken met verschillende versies van de data 2.7.1 Het opladen van een nieuwe versie Een versie bestaat uit verschillende bestanden. Wanneer men een versie oplaadt, kan het gebeuren dat er nog fouten inzitten. Indien dit zo is, zal een nieuwe versie of een aantal bestanden van zulke versie moeten worden opgeladen. 2.7.2 De activatie van een versie Eens een versie geüpload is, zal men ze trachten te activeren. Bij deze activatie ondergaat de versie in kwestie een reeks testen. Zulke testen controleren of de versie wel geldig is. Als dat
Hoofdstuk 2. Functionele vereisten 9 niet zo is, zal men voor een nieuwe versie moeten zorgen. 2.8 De data corrigeren Vanaf het moment dat een versie geactiveerd is, kan men de data corrigeren. Zo zal men onder andere de transacties tussen de entiteiten van eenzelfde consolidatie elemineren. 2.9 Het exporteren naar het datawarehouse Wanneer alle correcties zijn doorgevoerd, is de data klaar om geëxporteerd te worden naar een datawarehouse. Van daaruit worden de data dan in een rapporteringstool geladen. Vooraleer de data effectief geëxporteerd worden, zullen dezelfde controles als bij activatie doorlopen worden. 2.10 Van datawarehouse naar rapporteringstool Bij het beschikbaar stellen van de data aan rapporteringstools, mag de veiligheid van de applicatie niet in het gedrang komen. Vanuit veiligheidsoverwegingen zal de databank achter firewalls ver buiten het bereik van het internet geplaatst worden. Dit impliceert dat die rapporteringstools niet rechtstreeks kunnen inloggen op de databankserver. Dit kan eenvoudig opgelost worden door een webservice te voorzien. Die kan dan de data bijvoorbeeld aanleveren in JSON- of XML-formaat. Er kan echter niet vertrouwd worden op de veiligheid van de gebruikte rapporteringstools (bijvoorbeeld wachtwoorden die onveilig bewaard worden). Het is dan ook beter om de gebruiker zijn gebruikersnaam en wachtwoord daar niet te laten invullen. Wel kan er gebruikgemaakt worden van een soort tijdelijk token, eigen aan de gebruiker. Dit token kan dan in de query string van de URL geplaatst worden. Een mogelijkheid om zulk token te voorzien, is de gebruiker dit te laten genereren als hij ingelogd is in de applicatie. Een andere optie is het gebruik van de session id. Als een gebruiker inlogt, zal de server zulke identificatie terugsturen. Bij elke nieuwe aanvraag stuurt de client deze identificatie mee zodat de server weet over welke sessie het gaat. Wanneer de rapporteringstool de gepaste URL gebruikt die deze identificatie bevat, zal de webservice automatisch weten met welke credentials er data opgevraagd worden. Als de gebruiker uitlogt op de applicatie, is meteen ook de identificatie niet meer geldig en kunnen er dus geen data meer opgevraagd worden.
Hoofdstuk 2. Functionele vereisten 10 2.11 Logging: het ideale hulpmiddel Logging is het ideale hulpmiddel om bij te houden wat er allemaal gebeurt in de applicatie (bv. acties door een bepaalde gebruiker, excepties die opgeworpen worden... ). De logs kunnen worden opgedeeld in de systeemlogs en de applicatielogs. 2.11.1 Systeemlogs Systeemlogs zijn logs van algemene gebeurtenissen. Zo zal er gelogd worden als een bepaalde resource niet beschikbaar is. Ook fouten ten gevolge van code die niet goed werkt, worden gelogd. Er kunnen natuurlijk ook louter informatief logs gegenereerd worden. 2.11.2 Applicatielogs De applicatielogs omvatten alle logs die gegeneerd zijn tijdens een gebeurtenis ten gevolge van een gebruikersactie. Bijvoorbeeld als men een bestand uploadt dat niet aan de opgegeven mapping voldoet, wordt er gelogd op welke lijnen welke data niet voldoen en waarom. De gebruiker kan dan eenvoudig deze log opvragen en weet zo onmiddellijk waarom de upload mislukte.
Hoofdstuk 3 De Cloud 3.1 Inleiding Cloud computing verwijst zowel naar de applicaties die als diensten via het internet beschikbaar worden gesteld als naar de hard- en software in het datacenter die deze diensten mogelijk maken. De specifieke hard- en software binnen een dergelijk datacenter worden gedefinieerd als de Cloud. Meer en meer ondernemingen kiezen ervoor om hun IT-infrastructuur (deels) te migreren naar de cloud. Vooral kleine en grote ondernemingen nemen hier het voortouw. Kleine ondernemingen hebben typisch een beperkte in-house infrastructuur waardoor er een lage overstapdrempel is. Grote bedrijven daarentegen zullen niet-bedrijfskritische delen overhevelen naar de cloud omwille van het kostenbesparende aspect. In tegenstelling tot de kleine en de grote ondernemingen houden de middelgrote ondernemingen langer vast aan een traditionele IT-infrastructuur. In het begin van dit hoofdstuk wordt het begrip multitenancy verklaard en kort de ontstaansgeschiedenis geschetst. Verder zal ook ingezoomd worden op het economisch aspect. Er bestaan verschillende soorten cloud implementatiemodellen: de belangrijkste zijn de publieke, de private en de hybride. Naast deze drie hoofdmodellen wordt in dit hoofdstuk ook de community cloud aangehaald. Een samenvatting van de voor- en nadelen van de verschillende implementatiemodellen sluit dit topic af. Vervolgens wordt een beknopte inleiding gegeven in gedistribueerde clouds en inter-cloud architecturen. Er worden verschillende redenen aangehaald waarom inter-cloud architecturen zo interessant zijn. Later in het hoofdstuk worden de verschillende servicemodellen toegelicht. Bij elk model zal gekeken worden naar wat de verantwoordelijkheid is van de vendor en naar wat de klant voor 11
Hoofdstuk 3. De Cloud 12 zijn rekening moet nemen. Daarna zullen enkele kostenmodellen besproken worden, gevolgd door een beschrijving van Service Level Agreements (SLAs). Privacy en wetgeving vormen het thema van de voorlaatste sectie. Zo zal men zich afvragen wie toegang heeft tot welke data en hoe ongeauthoriseerde toegang wordt vermeden. Dikwijls is het ook zo dat men verplicht is een private cloud te kiezen om aan de wetgeving te kunnen voldoen. Ten slotte wordt een keuze gemaakt over hoe de cloud er voor de DCT moet uitzien. Voor een meer gedetailleerde inleiding rond de cloud wordt de lezer doorverwezen naar het artikel van Armbrust et al. (2009). 3.2 Multitenancy In een multi-tenant omgeving maken meerdere klanten tegelijkertijd gebruik van één applicatie die gedeeld wordt door de verschillende tenants. Iedere tenant heeft zijn eigen geïsoleerd deel met data. Hoe deze scheiding verwezenlijkt wordt, hangt af van het gekozen datamodel (Hoofdstuk 5). Desondanks dat in een multi-tenant omgeving de applicatie voor iedereen dezelfde is, heeft elke tenant het gevoel dat hij als enige de applicatie gebruikt. 3.2.1 Historiek Het concept van multitenancy kwam op in de jaren zestig. Bedrijven huurden opslagruimte en rekenkracht van een mainframe 1, wat een enorme kostreductie teweeg bracht. In die tijd waren computercomponenten namelijk zeer groot en kostelijk. In de jaren negentig, toen het internet populair werd onder het grote publiek, stelden application service providers (ASPs) applicaties beschikbaar voor hun klanten. Organisaties konden zo het hosten van applicaties die veel rekenkracht vergden, uitbesteden. Twee voorbeelden van dergelijke applicaties zijn websites en webgebaseerde e-mail. Naargelang de beperkingen van de applicatie in kwestie, waren de ASPs al dan niet genoodzaakt om een applicatie voor elke tenant op een aparte machine te laten draaien. Sinds midden de jaren negentig zijn talrijke consumentgerichte webapplicaties zoals Hotmail 2, Gmail, Facebook, Wolfram Alpha... ontstaan. Deze applicaties bedienen alle gebruikers met slechts één instantie. Multi-tenant applicaties zijn een uitbreiding op deze applicaties; gebruikers die tot eenzelfde organistatie behoren, worden gegroepeerd tot een tenant. Per organisatie wordt een zekere graad van customization beschikbaar gesteld. 1 Zie ook: http://en.wikipedia.org/wiki/mainframe computer 2 Hernoemd naar Outlook.com
Hoofdstuk 3. De Cloud 13 3.2.2 Economisch aspect Vanuit een economische invalshoek gezien, biedt multitenancy in combinatie met de cloud veel voordelen. Hieronder zullen enkele van deze voordelen besproken worden. Centraal beheer en onderhoud Vermits de applicatie op een beperkt aantal centraal beheerde instanties draait, zal bij het uitkomen van een nieuwe versie slechts op beperkte schaal een update moeten worden uitgevoerd. Bij iedere update bestaat trouwens de kans dat bepaalde hardwarecomponenten en/of softwarepaketten vernieuwd moeten worden. Indien de applicatie niet multi-tenant zou zijn, zou er dus getest moeten worden voor alle mogelijke omgevingen. Met andere woorden een multi-tenant applicatie is eenvoudig centraal te onderhouden, wat de kosten sterk drukt. Specialisatie Aangezien de applicatie centraal beheerd wordt en een vast team instaat voor het onderhoud, kunnen de mensen in zulk team zich specialiseren. Bij een applicatie die ontplooid wordt binnen elk bedrijf, zullen gemiddeld meer mensen moeten instaan om de continuïteit te garanderen. Bovendien zullen deze mensen trager werken en hoogstwaarschijnlijk mindere kwaliteit afleveren. Minder onbenuttigde resources Doordat de tenants gebruikmaken van dezelfde resources, kunnen deze resources beter verdeeld worden. De ene tenant zal bijvoorbeeld op een bepaald tijdstip veel resources opeisen, terwijl een andere er amper nodig heeft. Beide extremen heffen elkaar op, waardoor de fluctuatie in de benodigde resources sterk afgezwakt wordt. Op die manier kan men het percentage benuttigde resources flink opdrijven zonder het risico te lopen dat er op bepaalde momenten te weinig zullen zijn. Verder wordt er in dit verband ook dikwijls gekozen voor het pay-asyou-use 3 kostenmodel. Zo zal men enkel moeten betalen voor de effectief gebruikte resources. 3.2.3 Uitdagingen Naast de vele voordelen die multitenancy biedt, zijn er ook enkele uitdagingen bij de implementatie ervan. Performance isolation Een eerste grote uitdaging is performance isolation. Dit houdt in dat de resources zo eerlijk mogelijk verdeeld worden onder de verschillende tenants. De performantie moet dus voor 3 Zie ook paragraaf 3.6.1
Hoofdstuk 3. De Cloud 14 iedere tenant gegarandeerd kunnen worden. Zo kan een bepaalde tenant een query uitvoeren die zeer veel van de databank eist. Het is dan natuurlijk niet aanvaardbaar dat een andere tenant moet wachten tot die query van de eerstgenoemde tenant beëindigd is. Beveiliging De tweede uitdaging bestaat uit het beveiliging van zulke multi-tenant applicaties. Deze applicaties zijn publiekelijk toegankelijk. Er zullen dus extra beveilingsmaatregelen moeten worden genomen op applicatieniveau. Enkele voorbeelden van zulke maatregelen zijn: het gebruik van beveiligde verbindingen; het kiezen van de gepaste encryptie-algoritmen; het opstellen van een aangepast wachtwoordbeleid. Data isolation De laatste grote uitdaging hangt nauw samen met het beveiligingsaspect, namelijk de isolatie van de tenantdata. Een tenant zijn data mag absoluut niet beschikbaar worden gesteld aan een andere tenant. Er bestaan hiervoor verschillende manieren om dit aan te pakken; deze worden in het vijfde hoofdstuk besproken. 3.3 Implementatiemodellen Het verband tussen de voornaamste implementatiemodellen die hier zullen worden besproken, is te zien in figuur 3.1. Figuur 3.1: Het verband tussen de voornaamste implementatiemodellen
Hoofdstuk 3. De Cloud 15 3.3.1 Publieke cloud De belangrijkste redenen om te kiezen voor een publieke cloud zijn: Schaalbaarheid Groot scala aan kostenmodellen Elasticiteit Geen systeemonderhoud Hoge graad van beschikbaarheid Een eerste voordeel van de publieke cloud is het gemakkelijk schalen van de applicatie. Zo kan men bij piekmomenten met slechts enkele muisklikken een extra core toevoegen. Dit eenvoudig schalen hangt nauw samen met enkele kostenmodellen (sectie 3.6) waarbij men slechts betaalt wat men nodig heeft. Dit kan onder de vorm van een abonnement zijn, maar het kan ook even goed een overeenkomst zijn waarbij men betaalt wat er effectief verbruikt is. Een ander voordeel is de elasticiteit. Dit is de mate waarin het systeem automatisch kan schalen naargelang de vereiste resources op dat moment. Op die manieren worden de kosten gedrukt en de kwaliteit van de dienst verhoogd. Een voorbeeld zal duidelijk maken hoe deze elasticiteit verwezenlijkt wordt. Voorbeeld Beschouw een website die op tijdstip t 0 niet populair is. Eén machine volstaat om alle gebruikers te bedienen. Op tijdstip t 1 is er plots meer belangstelling en één machine is niet meer genoeg. Op basis van het aantal gebruikers die gelijktijdig verbinding maken met de website en de vereiste resources op de webserver wordt bepaald dat er tien machines noodzakelijk zijn om dezelfde kwaliteit af te leveren. Een elastisch systeem zou dit onmiddellijk moeten waarnemen en negen extra machines voorzien. Op tijdstip t 2 is het piekmoment voorbij. De tien machines zijn nauwelijks in gebruik en één machine zou weer voldoende zijn om de website beschikbaar te stellen. Een elastisch systeem zou dit onmiddellijk moeten vaststellen en de negen overtollige machines vrijgeven. (bron: http://en.wikipedia.org/wiki/elasticity (cloud computing)) Verder beschikt de onderneming niet zelf over de infrastructuur die onderhouden moet worden. Een laatste voordeel is de hoge graad van beschikbaarheid, vastgelegd in een Service Level Agreement (SLA) 4. Typische percentages hierbij liggen tussen de 99.90% en 99.99%. 4 Zie paragraaf 3.7
Hoofdstuk 3. De Cloud 16 De voornaamste nadelen van een publieke cloud zijn: Verlies aan controle Minder veilig dan private cloud (data staan niet fysisch geïsoleerd) Minder investeren, minder afschrijven, minder kosten, meer belastingen Legale aspecten Doordat de infrastructuur beheerd wordt door de provider, verliest men in grote mate de controle hierover. Soms kan dit een reden zijn om voor een ander type cloud te kiezen. Het verlies aan controle kan ook impliceren dat er niet voldaan wordt aan de beveiligingseisen vastgelegd in het IT-beleid binnen het bedrijf. Het beheer van bedrijfsgeheime data toevertrouwen aan een third party is dikwijls onaanvaardbaar. Een minder voor de hand liggend nadeel is een kleinere investering. Zo moet er geen dure infrastructuur aangekocht worden. Minder investeren betekent minder afschrijven en minder afschrijven leidt tot lagere kosten. Een bedrijf drukt graag zijn winst om zo belastingen te vermijden. 3.3.2 Private cloud Het tegenovergestelde van een publieke cloud is een private cloud. Dit is een cloud eigen aan een bepaalde organisatie waarbij de data achter hun firewall staan. Ook een private cloud heeft zijn voordelen: Meer controle Veiliger dan publieke cloud (data staat fysisch geïsoleerd) Hogere performantie binnen het bedrijfsnetwerk Een private cloud biedt meer controle over de infrastructuur dan een publieke cloud. Dit kan belangrijk zijn als de diensten van de onderneming geoptimaliseerd zijn voor specifieke apparatuur (bv. Intel-processor). Een ander en zeker niet het minste voordeel is de veiligheid. De complete cloud bevindt zich achter de bedrijfsfirewall, dus niet rechtstreeks bereikbaar vanuit het internet. Merk hierbij wel op dat grote publieke cloud providers zeer strikt toezien op de beveiliging van hun systeem, wat niet altijd het geval is bij een private cloud. Een ander voordeel dat gepaard gaat met het feit dat cloud zich binnen het bedrijfsnetwerk bevindt, is de performantie. Zo kan men aan LAN-snelheden 5 communiceren met de applicatie i.p.v. aan de snelheden van het internet. Soms is het echter ook zo dat men genoodzaakt is om voor een private cloud te kiezen. Dit kan omwille van de wetgeving zijn, maar het kan even goed gebeuren dat de service enkel overweg kan met specifieke hardware. 5 Local Area Network
Hoofdstuk 3. De Cloud 17 Enkele nadelen van een private cloud zijn: Meestal duurder On-site onderhoud Moeilijk te schalen Slechte elasticiteit In het algemeen is een private cloud duurder dan een publieke cloud. Zo moet men de volledige infrastructuur aankopen en vernieuwen en eventueel het personeel extra opleidingen laten genieten. Indien er bestaande infrastructuur kan herbruikt worden, kan het zijn dat een private cloud toch goedkoper uitkomt. On-site onderhoud leidt niet enkel tot de gebruikelijke kosten zoals materiaal en personeel, maar ook tot kosten ten gevolge van de down-time die opmerkelijker hoger zal zijn dan bij een publieke cloud. Frustraties van de gebruikers en imagoverlies zijn slechts enkele voorbeelden hiervan. Nog een belangrijk nadeel is het gebrek aan schaalbaarheid. Bij een private cloud moet men zelf voor de infrastructuur zorgen; dit is iets statisch. De infrastructuur moet zodanig geschaald worden dat bij piekmomenten de diensten gegarandeerd blijven. Gedurende de andere periodes zal er m.a.w. een overschot aan resources zijn. Een publieke cloud daarentegen laat de gebruiker toe on-the-fly te beslissen hoeveel resources vereist zijn. In de figuur 3.2 van Bulens (2012) wordt deze vergelijking grafisch geschetst. Figuur 3.2: Schalen bij resp. private en publieke cloud (Bulens, 2012)
Hoofdstuk 3. De Cloud 18 3.3.3 Community cloud Een variant is de community cloud. Hierbij delen een groep ondernemingen die gemeenschappelijke toepassingen gebruiken een cloud. Zo kan men zowel van de voordelen van een publieke als die van een private cloud genieten. Het is goedkoper dan wanneer elke onderneming zijn eigen private cloud heeft. Het belangrijkste nadeel van dit model is dat de verschillende ondernemingen de beschikbare bandbreedte moeten delen. Een community cloud kan zowel on-premises als off-premises ontplooid worden. Bij onpremises wordt gebruikgemaakt van de eigen datacenters, terwijl men bij off-premises een beroep zal doen op een extern datacenter. Het beheren gebeurt door de organisaties in kwestie of door een third-party managed service provider (MSP) 6. 3.3.4 Hybride cloud Naast de publieke, private en community cloud bestaat er ook een combinatie, namelijk een hybride cloud. Een hybride cloud zal trachten de voordelen van verschillende modellen te bundelen en de nadelen weg te werken. Omwille hiervan en de mogelijkheid om de bestaande infrastructuur te hergebruiken, is het hybride cloud model het populairst. Een van de voornaamste mogelijkheden is cloud bursting. Bij cloud bursting draait de applicatie standaard in een private cloud en zal indien te weinig resources beschikbaar zijn, extra resources gebruiken uit de publieke cloud. Een belangrijk voordeel hierbij is dat de onderneming die extra resources slechts moeten betalen indien ze daadwerkelijk vereist zijn. Een andere mogelijkheid is dat men bijvoorbeeld de applicatie zelf in een publieke cloud plaatst waardoor het schalen ervan slechts enkele muisklikken inhoudt. De data daarentegen kunnen dan op een private cloud bewaard worden, waar men de veiligheid ervan kan garanderen. Een laatste combinatie is die van een private en een community cloud. Bedrijven met gemeenschappelijke belangen kunnen bepaalde taken uitvoeren in dezelfde community cloud. Hun bedrijfskritische gegevens zullen ze echter liever binnen een private cloud houden. Op die manier hebben ze perfect controle over hun kritische data, maar tegelijkertijd ervaren ze een kostenreductie ten opzichte van een complete private cloud. 3.3.5 Samenvatting In tabel 3.1 kan de lezer een overzicht vinden van de voor- en nadelen van de verschillende implementatiemodellen. 6 Een managed service provider is een organisatie die netwerkgebaseerde infrastructuur, diensten en applicaties levert aan onder andere bedrijven.
Hoofdstuk 3. De Cloud 19 Tabel 3.1: Overzicht van de voor- en nadelen van de verschillende implementatiemodellen publiek privaat community hybride Kostprijs 7 + +/ +/ Vrijheid in kostenspreiding + +/ Onderhoud infrastructuur + +/ +/ Controle infrastructuur + +/ +/ Beschikbaarheid + Wetgeving + + +/ Performantie + + + Schaalbaarheid + +/ Veiligheid + +/ Elasticiteit + +/ 3.4 Gedistribueerde clouds en inter-cloud architecturen 3.4.1 Gedistribueerde clouds Dikwijls volstaat één machine niet om een volledige cloud op te laten draaien. De beschikbaarheid kan immers niet voldoende gegarandeerd worden. Een hardwarecomponent die faalt, een update die moet worden uitgevoerd, een brand die uitbreekt en een natuurramp zijn enkele situaties die ervoor kunnen zorgen dat de service niet meer beschikbaar is. Verder kan het ook gebeuren dat er plots te veel aanvragen binnenkomen, waardoor de machine overbelast wordt en bijgevolg niet meer in staat is om een aanvaardbare responstijd te leveren. Om de kans op deze problemen te minimaliseren, moet er toevlucht gezocht worden bij meerdere machines. Vaak zullen deze machines geografisch verspreid worden. Om de belasting te verdelen over de verschillende machines, wordt gebruikgemaakt van load balancers 8. Clouds waarbij meerdere machines instaan voor het leveren van de services, worden gedistribueerde clouds genoemd. 3.4.2 Inter-cloud architecturen Het is niet altijd mogelijk om de geografische verdeling van gebruikers van de aangeboden diensten op voorhand te kennen. Dit maakt het verdelen van resources zeer moeilijk en 7 Hierbij wordt uitgegaan van het standpunt hoe minder kosten, hoe beter. 8 Zie paragraaf 6.6
Hoofdstuk 3. De Cloud 20 gewone gedistribueerde clouds zullen dan ook niet meer volstaan. Een meer geavanceerde vorm van gedistribueerde clouds zijn inter-cloud architecturen waarbij verschillende clouds geclusterd worden. Deze verschillende clouds kunnen elk een ander implementatiemodel volgen. Inter-cloud architecturen maken het mogelijk dat voor iedere locatie de gewenste resources beschikbaar worden gesteld volgens het Just-in-Time-principe. Met andere woorden, ze worden gekenmerkt door een zeer grote elasticiteit, ongeacht de geografische spreiding. In figuur 3.3 wordt een voorbeeldarchitectuur (testopstelling van IEEE 9 ) van zulke inter-cloud weergegeven. Figuur 3.3: Een voorbeeld van een inter-cloud architectuur (http://cloudcomputing.ieee.org/intercloud/technology) De intercloud exchanges doen dienst als broker. Dit wil zeggen dat zij het aanspreekpunt zijn voor een cloud die een service van een andere cloud wil gebruiken. Ze zijn in feite een soort façade die de achterliggende clouds abstraheert. De intercloud root zorgt voor algemene services zoals naming en trust authority. Hij wordt gerepliceerd om single point of failures te vermijden. Een ander probleem dat inter-cloud architecturen trachten te minimaliseren is dat van vendor lock-ins. Bij een vendor lock-in is men afhankelijk van een bepaalde leverancier. 9 Institute of Electrical and Electronics Engineers
Hoofdstuk 3. De Cloud 21 3.5 Servicemodellen Wanneer men gebruikmaakt van services in de cloud, kan men kiezen uit drie hoofdmodellen. Deze verschillende servicemodellen kunnen worden opgedeeld volgens lagen zoals te zien is in figuur 3.4. Infrastructure as a Service (IaaS) is het meest rudimentaire model dat aangeboden wordt. Als er iets meer verwacht wordt van de service, kan toevlucht gezocht worden bij Platform as a Service (PaaS). Software as a Service (SaaS) biedt het totaalpakket aan; de eindgebruiker moet zelf niks beheren. Figuur 3.5 geeft per servicemodel in detail weer wat de vendor beheert en wat de verantwoordelijkheid is van de eindgebruiker. Figuur 3.4: De verschillende servicemodellen weergegeven als lagen (http://en.wikipedia.org/wiki/cloud computing)
Hoofdstuk 3. De Cloud 22 Figuur 3.5: Detailweergave per servicemodel van wie wat beheert (http://cloudappassessment.cloudapp.net/) 3.5.1 Infrastructure as a Service Infrastructure as a Service, kortweg IaaS, is de basislaag voor alle cloud services. De cloud provider zorgt hier voor de basisinfrastructuur. Dit houdt in dat hij de virtuele machines, de servers, de opslag, de netwerkinfrastructuur, de load balancers... onderhoudt. De eindgebruiker installeert zijn applicaties, databanken en besturingssystemen op deze infrastructuur, maar heeft geen controle over of toegang tot de onderliggende machines. De EC2-services van Amazon en Oracle Cloud infrastructure as a service zijn hiervan een voorbeeld. 3.5.2 Platform as a Service De tweede laag, de PaaS-laag, levert bovenop de IaaS-laag nog het besturingssysteem, de middleware 10 en de runtime-omgeving. De runtime-omgeving is hetgeen de tenant zal zien en waar hij zijn applicaties op kan laten draaien. Twee welbekende voorbeelden van dit servicemodel zijn Microsoft Azure en Google App Engine. 3.5.3 Software as a Service De derde en laatste servicelaag is de SaaS-laag, waarbij de provider een eindproduct aanbiedt. Hij exploiteert een applicatie met onderliggend de volledige infrastructuur om dit op een 10 Middleware is stuk software dat services (die het besturingssysteem niet voorziet) aanbiedt aan applicaties. Het doet als het ware dienst als een soort lijm die stukken software aan elkaar kleeft.
Hoofdstuk 3. De Cloud 23 performante, veilige en gebruikersvriendelijke manier mogelijk te maken. Salesforce1 Sales Cloud en Microsoft Office 365 zijn voorbeelden van zulke applicaties. 3.5.4 Afgeleide architecturen Naast deze drie hoofdmodellen bestaan er ook diverse afgeleide architecturen. Merk hierbij op dat de meeste afgeleid zijn van het SaaS-model. Hieronder worden enkele daarvan besproken. Storage as a Service Storage as a Service (STaaS) is een architecturaal model waarbij serviceproviders opslagruimte aanbieden. Voor bedrijven is dit interessant voor back-ups. Het voornaamste nadeel van dit model is de vereiste bandbreedte. Grote hoeveelheden data transporteren over het internet is niet altijd vanzelfsprekend. Security as a Service Security as a Service (SECaaS) is een model waarbij security management wordt geoutsourcet. Deze services kunnen zorgen voor authenticatie, een anti-virus, anti-malware/spyware, intrusion detection, logging en security event management. Data as a Service Bij Data as a Service (DaaS) worden data zoals stadsplannen aangeboden. Dit model kent twee belangrijke manieren van kostenbepaling. Enerzijds kan er op basis van volume kosten berekend worden, waarbij men nog de keuze heeft tussen per byte en per request. Anderzijds kan de kost bepaald worden aan de hand van datatypes of attributen. Naast bijvoorbeeld het beschikbaar stellen van die stadsplannen, kunnen er ook bezienswaardigheden getoond worden. Volgens de laatstgenoemde kostenbepaling zal men hiervoor extra moeten betalen. Database as a Service Database as a Service (DBaaS) biedt een databank aan, beheerd en onderhouden door de cloud provider. Elastisch schalen, upgraden, back-ups maken... wordt allemaal achter de schermen gedaan, zonder dat de eindgebruiker daar iets van hoeft te merken. Compute as a Service Compute as a Service (CaaS) kan analoog aan het elektriciteitsnet gezien worden. Zoals stroom opwekt wordt en daarna geleverd volgens hetgeen men nodig heeft, worden bij dit model resources beschikbaar gesteld en men gebruikt wat men nodig heeft. Op die manier kan een eindgebruiker op flexibele wijze resources gebruiken, zonder dat hij infrastructuur moet aankopen of zich iets moet aantrekken van de configuratie en het onderhoud.
Hoofdstuk 3. De Cloud 24 3.6 Kostenmodellen Naar de cloud stappen omwille van technische redenen, is absoluut niet te rechtvaardigen vanuit businessperspectief. Er moet naar de bigger picture gekeken worden. De ITinfrastructuur heeft als doel de business te ondersteunen; een overstap kan dan ook alleen maar overwogen worden als de business er wel bij vaart. Om te bepalen of zulke investering een meerwaarde biedt, zal men kijken naar de return on investment (ROI) en de vooropgestelde key performance indicators (KPIs) evalueren. De ROI is een meeteenheid die het mogelijk maakt de efficiëntie van verschillende investeringen te vergelijken. Het wordt gedefinieerd als het verschil van de opbrengst en de kost van de investering, gedeeld door de kost van de investering. KPIs zijn maatstaven die ervoor zorgen dat de performantie kan vergeleken worden met de vooropgestelde strategische en operationele doelstellingen. Cloud services worden aangeboden met verschillende kostenmodellen. Om de meerwaarde voor de business te kunnen optimaliseren, spreekt het voor zich dat het meest geschikte kostenmodel bepalen van cruciaal belang is. In het artikel van Al-Roomi et al. (2013) worden de verschillende kostenmodellen (ook de theoretische) besproken. De modellen die men in de praktijk implementeert, worden in de volgende paragrafen kort toegelicht. 3.6.1 Pay-as-you-go model Het populairste kostenmodel is het pay-as-you-go of pay-as-you-use model. Voor velen is de mogelijkheid om enkel de resources te betalen die men daadwerkelijk nodig heeft, één van de belangrijkste redenen om van cloud diensten gebruik te maken. Bij een traditionele ITinfrastructuur zal men extra resources moeten voorzien opdat het in de toekomst nog zou volstaan. Het pay-as-you-go model laat toe om op het moment dat die extra resources nodig zijn, er meer te reserveren. De prijs wordt gezet door de cloud provider en is een statisch gegeven. Dit wil dus zeggen dat de provider de prijs niet kan aanpassen aan de vraag. Op drukke momenten kan hij de prijs niet doen stijgen en bij rustige periodes, zal de klant meer betalen dan marktprijs. 3.6.2 Maandelijks vast bedrag Een tweede veelgebruikt model is dat van een abonnement. Hierbij betaalt de klant maandelijks een vast bedrag. Klanten die zeer veel gebruikmaken van de diensten zullen in verhouding zeer weinig betalen ten opzichte van klanten die de resources onderbenutten.
Hoofdstuk 3. De Cloud 25 3.6.3 Pay-for-resources model Het laatste model dat zeer veel geïmplementeerd wordt, is het pay-for-resources model. Hierbij betaalt de klant slechts de resouces die hij effectief gebruikt. Dit model mag niet verward worden met het pay-as-you-go model waar men resources reserveert naargelang de huidige businesssituatie. 3.6.4 Waardegebaseerde prijszetting Bij waardegebaseerde prijszetting wordt de prijs bepaald volgens hetgeen de klant ervaart als de waarde van de aangeboden service. Dit zorgt voor hoge inkomsten voor de provider per verkochte dienst, maar het is niet eenvoudig om te bepalen hoe de klant nu effectief de service waardeert. 3.6.5 Kostengebaseerde prijszetting Er bestaat ook een model waarbij men de kost bepaalt die hoort bij het aanbieden van de services. De prijs wordt dan gezet op deze kost, vermeerderd met een zekere winstmarge. 3.6.6 Competitiegebaseerde prijszetting Een andere mogelijkheid is dat men de markt zijn werk laat doen. Providers verkopen hun services aan marktconforme prijzen, waarbij men met elkaar concurreert. Op die manier worden de prijzen sterk gedrukt, wat natuurlijk ten gunste is van de klant. 3.6.7 Spot-pricing model Het spot-pricing model laat geïnteresseerden bieden op resources, waarbij geldt: hoe hoger het bod, hoe hoger de prioriteit. Amazon gebruikt bijvoorbeeld dit model voor de ongebruikte capaciteit van zijn EC2-services. 3.6.8 Klantgebaseerde prijszetting Bij een klantgebaseerde prijszetting zal de provider een inschatting trachten te maken van wat de klant bereid is om te betalen en dit dan gebruiken om de prijs te bepalen. Zulke inschattingen maken is niet altijd vanzelfsprekend omdat klanten zelden zullen vertellen wat ze bereid zijn te betalen. 3.6.9 Hybride prijszetting De laatste benadering rond prijszetting is een hybride vorm. Statische en dynamische modellen worden gecombineerd. De provider en de klant spreken hierbij een aantal vaste prijzen af.
Hoofdstuk 3. De Cloud 26 Naargelang de geleverde Quality of Service (QoS) (bijvoorbeeld gebaseerd op de wachttijden) zal dynamisch één van die vaste prijzen toegekend worden. 3.7 Service Level Agreements Een Service Level Agreement (SLA) behoort tot het contract tussen een provider en een eindgebruiker. Het geeft aan welke Quality of Service (QoS) de provider garandeert en wat de schadevergoeding is indien hij dit niet doet. Het spreekt voor zich dat de provider de nodige statistische modellen heeft opgesteld om na te gaan met welke waarden van de parameters hij het meeste winst kan boeken. 3.7.1 Mogelijke criteria QoS In deze paragraaf zullen enkele voorbeelden (uit de white paper van GICTF) gegeven worden waarmee men de QoS kan definiëren. Deze voorbeelden zijn opgedeeld volgens drie mogelijke criteria. Merk op dat het niet noodzakelijk is dat alle criteria vermeld worden in een SLA. Beschikbaarheid Een aantal mogelijkheden om de beschikbaarheid te definiëren zijn: de beschikbaarheid van de service zelf, uitgedrukt in percentages; de gemiddelde tijd om een fout te herstellen; de vereiste tijd om weer operationeel te zijn na een ramp; de momenten waarop back-ups worden genomen. Performantie De performantie kan uitgedrukt worden in termen van: de online responstijd; het percentage van de transacties die worden voltooid binnen de vooropgestelde tijd; de responstijd voor de verwerking van een batch; het percentage van de batches die worden voltooid binnen de vooropgestelde tijd; het maximum aantal taken die kunnen worden uitgevoerd in één tijdseenheid; het percentage van de gevallen waar het aantal verwerkte taken per tijdseenheid minstens het vooropgestelde aantal is.
Hoofdstuk 3. De Cloud 27 Veiligheid De veiligheid kan beschreven worden aan de hand van: de behaalde certificaten; het al dan niet voorzien van maatregelen om datalekken te vermijden; het al dan niet confidentieel houden van data die verzonden worden tussen clouds; de datalocatie; het al dan niet aanwezig zijn van een detectiemechanisme om ongerechtigde toegang op te sporen; de tijdsduur voor het bewaren van bewijsmateriaal inzake onrechtmatige acties; de eventuele maatregelen genomen om Denial of Service (DoS) aanvallen te weren; de genomen maatregelen om een malware-infectie te voorkomen. 3.7.2 Soorten SLAs Service Level Agreements kunnen worden gecatalogeerd volgens verschillende criteria. Een eerste opdeling voorziet aparte SLAs voor afdelingen binnen dezelfde onderneming en andere ondernemingen. Een andere mogelijke opdeling gebeurt via de scope. In de subparagrafen hieronder worden de verschillende SLAs per scope besproken. Klantspecifieke SLA Een eerste scope is per klant. Hierbij wordt voor iedere klant een aparte SLA opgesteld, meestal vertrekkende vanuit een soort template. Servicespecifieke SLA Een andere mogelijkheid is dat men per service die men aanbiedt, een aparte SLA voorziet. Deze SLA wordt gebruikt voor elke klant. Multi-level SLA Een meer geavanceerde manier splitst de SLA in verschillende niveaus: per onderneming: elke afdeling binnen een onderneming eenzelfde SLA per klantengroep: elke groep van klanten (bv. bepaalde sector) een aparte SLA per soort service: ieder servicetype een andere SLA
Hoofdstuk 3. De Cloud 28 3.7.3 Voorbeeld In bijlage B kan de lezer ter illustratie de SLA vinden die Microsoft hanteert voor cloudservices, virtuele machines en virtuele netwerken van Microsoft Azure. 3.8 Privacy en wetgeving 3.8.1 Privacy Data worden meer en meer in de cloud geplaatst, maar hoe goed wordt de privacy beschermd? Uit het onderstaand artikel kan geconcludeerd worden dat de integriteit van data in de cloud niet altijd gegarandeerd kan worden. Dit kan dan ook een belangrijke reden zijn om te opteren voor een private cloud waar men zeker is van de locatie waar de gegevens zich bevinden. Artikel The National Security Agency has obtained direct access to the systems of Google, Facebook, Apple and other US internet giants, according to a top secret document obtained by the Guardian. The NSA access is part of a previously undisclosed program called Prism, which allows officials to collect material including search history, the content of emails, file transfers and live chats, the document says. The Guardian has verified the authenticity of the document, a 41-slide PowerPoint presentation classified as top secret with no distribution to foreign allies which was apparently used to train intelligence operatives on the capabilities of the program. The document claims collection directly from the servers of major US service providers. Although the presentation claims the program is run with the assistance of the companies, all those who responded to a Guardian request for comment on Thursday denied knowledge of any such program. In a statement, Google said: Google cares deeply about the security of our users data. We disclose user data to government in accordance with the law, and we review all such requests carefully. From time to time, people allege that we have created a government back door into our systems, but Google does not have a back door for the government to access private user data. Several senior tech executives insisted that they had no knowledge of Prism or of any similar scheme. They said they would never have been involved in such a program. If they are doing this, they are doing it without our knowledge, one said. An Apple spokesman said it had never heard of Prism. The NSA access was enabled by changes to US surveillance law introduced under President Bush and renewed under Obama in
Hoofdstuk 3. De Cloud 29 December 2012. The program facilitates extensive, in-depth surveillance on live communications and stored information. The law allows for the targeting of any customers of participating firms who live outside the US, or those Americans whose communications include people outside the US. It also opens the possibility of communications made entirely within the US being collected without warrants.... (bron: http://www.theguardian.com/world/2013/jun/06/us-tech-giants-nsa-data) 3.8.2 Wetgeving Er zijn geen specifieke wetten voor cloud computing, maar het is wel onderhevig aan een reeks verschillende wetgevingen. Deze wetgevingen kunnen worden onderverdeeld volgens: het verbintenissenrecht 11 het fiscaal recht het arbeidsrecht 12 de e -wetten: de e-commerce wet en de privacywet de sectorgebonden regelgevingen (bv. in de fincanciële of medische wereld) Om dit thema af te sluiten, wordt een case behandeld. Artikel L association Union pour un mouvement populaire (l UMP) a signé le 30 décembre 2010 avec la société Oracle France un contrat dénommé Software as a service permettant la mise à disposition d un logiciel de gestion d une base de données nominatives Oracle CRM On Demand partagé entre plusieurs utilisateurs selon la technique du Cloud computing. Ce contrat, qui a pour objet la gestion et l hébergement des données nominatives de l UMP au sein d une base dénommée Base Pop, a été conclu pour une durée de deux ans et arrive à expiration le 29 décembre 2012. Ayant souhaité reprendre ses données pour les confier à un autre prestataire à l expiration de ce contrat, l UMP s est heurtée 11 Koop- en huurovereenkomsten vallen bijvoorbeeld onder het verbintenissenrecht. 12 Het arbeidsrecht wordt onder andere vastgelegd in collectieve arbeidsovereekomsten of CAO s.
Hoofdstuk 3. De Cloud 30 à diverses difficultés techniques qu elle a signalées le 7 octobre 2012 à la société Oracle France. Le 18 octobre 2012, cette dernière lui a indiqué que l impossibilité rencontrée pour récupérer les données était la conséquence d un bug de la 20ème version de l application Oracle CRM On Demand opérationnelle depuis le 21 septembre 2012 et qu en attendant la mise en œuvre de la 21eme version, un correctif spécifique à l environnement de l UMP était en cours de réalisation et une solution de contournement en préparation. C est dans ces conditions que l UMP, après lui avoir adressé une mise en demeure le 2 novembre 2012, a, par acte du 12 novembre 2012, assigné en référé la société Oracle pour obtenir, sur le fondement des articles 808 et 809 du code de procédure civile, sa condamnation sous astreinte à lui fournir tous moyens techniques de nature à lui permettre l exportation de l ensemble de ses données nominatives hébergées et à lui payer la somme de 3500 en application des dispositions de l article 700 du code de procédure civile. La société Oracle fait valoir que la procédure est sans objet dans la mesure où les opérations de correction de l anomalie sont en cours de finalisation. Elle précise à cet égard que les stipulations contractuelles ne prévoient pas de délai de correction des anomalies de fonctionnement, de sorte qu il ne peut lui être fait grief d avoir manqué à ses obligations contractuelles. Elle ajoute que la demande de l UMP se heurte à une contestation sérieuse et que celle-ci ne justifie ni d un dommage imminent, ni d un trouble manifestement illicite, de sorte que ce qui est sollicité excède les pouvoirs du juge des référés. Elle demande qu il soit pris acte de ce qu elle s engage à maintenir l accès de l UMP à la solution Oracle CRM On Demand jusqu à ce que l UMP ait pu exporter la totalité de ses données.... (bron: https://www.legalis.net/spip.php?page=jurisprudence-decision&id article=3794) Kort samengevat komt het erop neer dat een Franse politieke partij na twee jaar gebruik te maken van de diensten van een SaaS-provider, wou migreren naar een andere provider. Door een bug was het echter niet mogelijk om een export van de gegevens te doen. De politieke partij dreigde in tijdsnood te geraken om haar data op tijd te migreren. De rechtbank stelde de provider voor de keuze: Ofwel moesten alle middelen beschikbaar gesteld worden zodat de partij haar data kon migreren; Ofwel zou het kosteloos zijn diensten moeten blijven leveren totdat de partij minstens twee maanden de tijd had gekregen om de volledige migratie uit te voeren. Verder legde de rechtbank een dwangsom op per dag vertraging.
Hoofdstuk 3. De Cloud 31 3.9 Keuze Deloitte wil de mogelijkheid hebben om later te beslissen welk type cloud er gebruikt wordt. Dit wil zeggen dat de applicatie zo gebouwd moet zijn dat ze compatibel is met de verschillende types. Verder moet ook vermeden worden dat de applicatie onderhevig is aan een vendor lockin 13. Er worden voornamelijk twee opties overwogen, namelijk een private cloud en Microsoft Azure. Enkele redenen kunnen worden bedacht waarom de voordelen van een publieke cloud niet opwegen tegen de nadelen van een private cloud. Ten eerste beschikt Deloitte reeds over een private cloud. De infrastructuurkosten moeten dus niet meer gemaakt worden en de onderhoudskosten kunnen zelfs over een post meer verdeeld worden. Met andere woorden zolang er geen bijkomende infrastructuur nodig is, vervallen de financiële voordelen van een publieke cloud ten opzichte van een private cloud. Een tweede reden is het feit dat de applicatie met vertrouwelijke data werkt. Jaarrekeningen moeten worden gepubliceerd via bijvoorbeeld de Nationale Bank van Belgïe (NBB). De data bestaan echter niet alleen uit jaarrekeningen. Elke onderneming heeft naast zijn boekhouding die het moet publiceren nog een boekhouding die uitsluitend dient voor interne doeleinden. Onder deze interne doeleinden verstaan we dan het rapporteren. Hierbij worden allerlei extra gegevens (bv. uit een ERP-systeem 14 ) samengenomen met de boekhouding om een zo volledig mogelijk beeld te geven aan het management. Het management kent dan op die manier de complete financiële situatie van de onderneming en kan op basis van die cijfers beslissingen nemen. De laatste reden heeft te maken met de technologische beperkingen die opgelegd worden door een publieke cloud. Zo biedt onder andere SQL Azure slechts een beperkte verzameling van de standaard SQL-mogelijkheden aan. Bij het kiezen van de technologieën tijdens deze masterproef, is er dan ook steeds belang gehecht aan de compatibiliteit. Kortom, Deloitte zal later de voor- en nadelen van de publieke cloud en hun eigen private cloud afwegen en op basis daarvan beslissen waar de applicatie moet ontplooid worden. 13 Een vendor lock-in betekent dat men afhankelijk is van een bepaalde leverancier. 14 Enterprise Resource Planning
Hoofdstuk 3. De Cloud 32
Hoofdstuk 4 Cloud applicatie 4.1 Inleiding In dit hoofdstuk komen eerst de voornaamste technologieën aan bod die in deze masterproef gebruikt zijn. Hierbij wordt beargumenteerd waarom voor deze technologieën gekozen is door telkens de voor- en nadelen ervan naast elkaar te plaatsen. In het tweede deel wordt uitgelegd hoe de applicatie is opgebouwd. Er wordt dieper ingegaan op hoe de foutafhandeling en de logging geïmplementeerd zijn. Ten slotte wordt kort Microsoft Azure besproken. 4.2 Gebruikte technologieën 4.2.1 C#.NET C#.NET is een programmeertaal die ontwikkeld is door Microsoft. C#.NET is gegroeid uit Java en C++ 1, waarvan men de sterkste punten heeft proberen over te nemen. Het is uitermate goed geïntegreerd in de Visual Studio IDE 2. Bij Deloitte BC&IT is dit de voorkeurstaal. In de Deloitte Controlling Template Online is het MVVM (Model View ViewModel) ontwerppatroon gebruikt. Dit houdt in dat er tussen de view laag en de modellen een extra laag komt, namelijk het viewmodel. In de views worden de viewmodellen gebruikt, en niet de reguliere modellen, die door het entity framework uit de databank zijn gegenereerd. Zo wordt de validatie van gegevens die de gebruiker ingeeft gescheiden van de business logica (databank) vereisten. Deze validatie gebeurt aan de hand van attributen, zoals in codevoorbeeld 4.1. 1 De naam van C#.NET tijdens de ontwikkeling was COOL, of C-like Object Oriented Language 2 Integrated Development Environment 33
Hoofdstuk 4. Cloud applicatie 34 Figuur 4.1: Het Model-View-ViewModel designpatroon (http://msdn.microsoft.com/en-us/library/hh821028.aspx) 1 2 p u b l i c c l a s s Product 3 { 4 // De d i s p l a y a t t r i b u t e n s t e l t voor welke naam er moet 5 // getoond worden i n de view. 6 [ Display (Name= Product Number ) ] 7 // De input u i t de view moet een g e t a l z i j n 8 // t u s s e n nul en 5000 9 [ Range ( 0, 5000) ] 10 p u b l i c i n t ProductID { get ; set ; } 11 12 [ Display (Name= Name ) ] 13 // Dit veld moet i n g e v u l d z i j n 14 [ Required ] 15 p u b l i c s t r i n g ProductName { get ; set ; } 16 17 [ Display (Name= P r i c e ) ] 18 // Dit veld moet een v a l uta eenheid z i j n 19 [ DataType ( DataType. Currency ) ] 20 p u b l i c double L i s t P r i c e { get ; set ; } 21 } Codevoorbeeld 4.1: Het gebruik van attributen in C#.NET Een andere mogelijkheid van C#.NET is het overschrijven of uitbreiden van klassen via partiële klassen. Dit kan handig zijn als men iets aan gegenereerde code wil wijzigen. Men wil hierbij niet de code zelf wijzigen, vermits de wijzigingen telkens overschreven zullen worden. Dit kan gebeuren aan de hand van het MetadataType-attribuut. Codevoorbeelden 4.2 en