1 owered by TCPDF (www.tcpdf.org) Academiejaar Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg Gent Opzetten van een cloud base...
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¨eren 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¨en 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 Deloitte2 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 2
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¨en 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 datawarehouse4 . 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.
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 ´e´enop-´e´en 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¨ele 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 SAP2 zijn; ook een Excel-bestand of een CSVbestand3 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 CSV is de afkorting voor Comma Separated Values. Waarden worden gescheiden door een bepaald karakter, bijvoorbeeld het kommapunt. 3
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 2.2.1
Het beheer van tenants 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: ´e´en voor Deloitte en ´e´en 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
2.2.3
6
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¨eerd 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. Nadat ze gecre¨eerd zijn, moeten er profielen aan toegekend worden.
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 ´e´en 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 2.4.1
Het beheer van structures binnen een tenant 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¨ erarchie 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 2.5.1
De applicatie dynamisch aanpassen 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¨eren 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 2.6.1
Het uploadproces 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¨eren 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¨ upload 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 2.7.1
Werken met verschillende versies van de data 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¨ upload 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¨exporteerd te worden naar een datawarehouse. Van daaruit worden de data dan in een rapporteringstool geladen. Vooraleer de data effectief ge¨exporteerd 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
2.11
10
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 ´e´en 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 mainframe1 , 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 Hotmail2 , Gmail, Facebook, Wolfram Alpha. . . ontstaan. Deze applicaties bedienen alle gebruikers met slechts ´e´en 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 2
Zie ook: http://en.wikipedia.org/wiki/Mainframe computer Hernoemd naar Outlook.com
Hoofdstuk 3. De Cloud
3.2.2
13
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¨eindigd 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
3.3.1
15
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 t0 niet populair is. E´en machine volstaat om alle gebruikers te bedienen. Op tijdstip t1 is er plots meer belangstelling en ´e´en 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 t2 is het piekmoment voorbij. De tien machines zijn nauwelijks in gebruik en ´e´en 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-snelheden5 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
3.3.3
18
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
3.4 3.4.1
publiek
privaat
community
hybride
Kostprijs7
+
−
+/−
+/−
Vrijheid in kostenspreiding
+
−
−
+/−
Onderhoud infrastructuur
+
−
+/−
+/−
Controle infrastructuur
−
+
+/−
+/−
Beschikbaarheid
+
−
−
−
Wetgeving
−
+
+
+/−
Performantie
−
+
+
+
Schaalbaarheid
+
−
−
+/−
Veiligheid
−
+
−
+/−
Elasticiteit
+
−
−
+/−
Gedistribueerde clouds en inter-cloud architecturen Gedistribueerde clouds
Dikwijls volstaat ´e´en 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 8
Hierbij wordt uitgegaan van het standpunt hoe minder kosten, hoe beter. 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 IEEE9 ) van zulke inter-cloud weergegeven.
Figuur 3.3: Een voorbeeld van een inter-cloud architectuur
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¸cade 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
3.5
21
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
3.6
24
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¨entie 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, ´e´en 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
3.6.3
25
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 ´e´en 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¨eren. 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¨eren 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 ´e´en 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
3.7.3
28
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 3.8.1
Privacy en wetgeving 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 usersdata. 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 verbintenissenrecht11 • het fiscaal recht • het arbeidsrecht12 • de “e”-wetten: de e-commerce wet en de privacywet • de sectorgebonden regelgevingen (bv. in de fincanci¨ele 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´e le 30 d´ecembre 2010 avec la soci´et´e Oracle France un contrat d´enomm´e ”Software as a service”permettant la mise a ` disposition d’un logiciel de gestion d’une base de donn´ees nominatives ”Oracle CRM On Demand”partag´e entre plusieurs utilisateurs selon la technique du ”Cloud computing”. Ce contrat, qui a pour objet la gestion et l’h´ebergement des donn´ees nominatives de l’UMP au sein d’une base d´enomm´ee ”Base Pop”, a ´et´e conclu pour une dur´ee de deux ans et arrive a ` expiration le 29 d´ecembre 2012. Ayant souhait´e reprendre ses donn´ees pour les confier ` a un autre prestataire ` a l’expiration de ce contrat, l’UMP s’est heurt´ee 11 12
Koop- en huurovereenkomsten vallen bijvoorbeeld onder het verbintenissenrecht. Het arbeidsrecht wordt onder andere vastgelegd in collectieve arbeidsovereekomsten of CAO’s.
Hoofdstuk 3. De Cloud
30
` a diverses difficult´es techniques qu’elle a signal´ees le 7 octobre 2012 a ` la soci´et´e Oracle France. Le 18 octobre 2012, cette derni`ere lui a indiqu´e que l’impossibilit´e rencontr´ee pour r´ecup´erer les donn´ees ´etait la cons´equence d’un ”bug”de la 20`eme version de l’application Oracle CRM On Demand op´erationnelle depuis le 21 septembre 2012 et qu’en attendant la mise en œuvre de la 21eme version, un correctif sp´ecifique ` a l’environnement de l’UMP ´etait en cours de r´ealisation et une solution de contournement en pr´eparation. C’est dans ces conditions que l’UMP, apr`es lui avoir adress´e une mise en demeure le 2 novembre 2012, a, par acte du 12 novembre 2012, assign´e en r´ef´er´e la soci´et´e Oracle pour obtenir, sur le fondement des articles 808 et 809 du code de proc´edure civile, sa condamnation sous astreinte ` a lui fournir tous moyens techniques de nature ` a lui permettre l’exportation de l’ensemble de ses donn´ees nominatives h´eberg´ees et ` a lui payer la somme de 3500 € en application des dispositions de l’article 700 du code de proc´edure civile. La soci´et´e Oracle fait valoir que la proc´edure est sans objet dans la mesure o` u les op´erations de correction de l’anomalie sont en cours de finalisation. Elle pr´ecise ` a cet ´egard que les stipulations contractuelles ne pr´evoient pas de d´elai de correction des anomalies de fonctionnement, de sorte qu’il ne peut lui ˆetre fait grief d’avoir manqu´e ` a ses obligations contractuelles. Elle ajoute que la demande de l’UMP se heurte ` a une contestation s´erieuse et que celle-ci ne justifie ni d’un dommage imminent, ni d’un trouble manifestement illicite, de sorte que ce qui est sollicit´e exc`ede les pouvoirs du juge des r´ef´er´es. Elle demande qu’il soit pris acte de ce qu’elle s’engage ` a maintenir l’acc`es de l’UMP a ` la solution Oracle CRM On Demand jusqu’` a ce que l’UMP ait pu exporter la totalit´e de ses donn´ees. ... (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
3.9
31
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¨ele 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-systeem14 ) 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¨ele 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¨en 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 14
Een vendor lock-in betekent dat men afhankelijk is van een bepaalde leverancier. Enterprise Resource Planning
Hoofdstuk 3. De Cloud
32
Hoofdstuk 4
Cloud applicatie 4.1
Inleiding
In dit hoofdstuk komen eerst de voornaamste technologie¨en aan bod die in deze masterproef gebruikt zijn. Hierbij wordt beargumenteerd waarom voor deze technologie¨en 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 4.2.1
Gebruikte technologie¨ en 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 IDE2 . 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 2
De naam van C#.NET tijdens de ontwikkeling was COOL, of C-like Object Oriented Language Integrated Development Environment
33
Hoofdstuk 4. Cloud applicatie
34
Figuur 4.1: Het Model-View-ViewModel designpatroon
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 e r moet 5 // getoond worden i n de view . 6 [ D i s p l a y (Name=” Product Number” ) ] 7 // De i n p u t u i t de view moet een g e t a l z i j n 8 // t u s s e n n u l en 5000 9 [ Range ( 0 , 5 0 0 0 ) ] 10 p u b l i c i n t ProductID { g e t ; set ; } 11 12 [ D i s p l a y (Name=”Name” ) ] 13 // Dit v e l d 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 { g e t ; set ; } 16 17 [ D i s p l a y (Name=” P r i c e ” ) ] 18 // Dit v e l d moet een v a l u t a e e n h e i d z i j n 19 [ DataType ( DataType . Currency ) ] 20 p u b l i c d o u b l e L i s t P r i c e { g e t ; 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¨ele 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
Hoofdstuk 4. Cloud applicatie
35
4.3 illustreren het uitbreiden van klassen via parti¨ele klassen en het MetadataType-attribuut. Het is ook mogelijk een property te hernoemen door gebruik te maken van dit principe. Dit wordt gedemonstreerd in codevoorbeeld 4.4. 1 2 3 4
[ MetadataType ( t y p e o f ( UploadTableMetaData ) ) ] p u b l i c p a r t i a l c l a s s UploadTable { }
Codevoorbeeld 4.2: De klasse UploadTable wordt uitgebreid door de klasse UploadTableMetaData.
1 p u b l i c c l a s s UploadTableMetaData 2 { 3 [ D i s p l a y (Name = ” UploadType ” , ResourceType = t y p e o f ( R e s o u r c e ) ) ] 4 p u b l i c s t r i n g DisplayName ; 5 }
Codevoorbeeld 4.3: De implementatie van de klasse UploadTableMetaData. 1 public p a r t i a l c l a s s FinTransaction 2 { 3 p u b l i c LedgerAccount Ledg erAc count Loca l 4 { 5 g e t { r e t u r n LedgerAccount1 ; } 6 set { LedgerAccount1 = v a l u e ; } 7 } 8 }
Codevoorbeeld 4.4: Het hernoemen van een property via parti¨ele klassen.
In codevoorbeeld 4.3 wordt de naam van het attribuut die op het scherm getoond zal worden, opgehaald uit een resource. Op die manier wordt internationalization in C#.NET automatisch toegepast.
4.2.2
ASP.NET MVC 4.0
ASP.NET MVC zorgt standaard voor een zeer goede separation of concerns; de applicatie wordt opgedeeld in models, views en controllers. Indien een gebruiker een webpagina opvraagt, wordt de gepaste controller geactiveerd. Deze controller zal gegevens opvragen (het model), waarna hij een view zal genereren en die als HTML-pagina terugsturen naar de gebruiker. Dit principe wordt verduidelijkt aan de hand van figuur 4.2.
Hoofdstuk 4. Cloud applicatie
36
Figuur 4.2: Het MVC principe toegepast in ASP.NET MVC.
De applicatie wordt functioneel verder opgedeeld in areas. Men zou hier ook telkens een nieuwe map binnen de controllermap kunnen aanmaken, maar dit zou voor benamingsconflicten kunnen zorgen. Het leidt ook tot een minder nette verdeling. Dit komt omdat areas zorgen voor een URL opdeling. De URL zal er uitzien zoals in codevoorbeeld 4.5. Zo is het mogelijk een groot project toch zeer net en flexibel te houden. 1 h t t p : / /www. a d d r e s s . com/ a r e a / c o n t r o l l e r / a c t i o n
Codevoorbeeld 4.5: De URL bij het gebruik van areas in ASP.NET MVC.
Verder wordt ASP.NET MVC gecompileerd3 , wat voor een aanzienlijke performantieverbetering zorgt ten opzichte van ge¨ınterpreteerde technologie¨en4 . In ASP.NET MVC kan men gebruikmaken van de Nuget-functionaliteit. Nuget is een tool die men gebruikt om extra softwarepakketten aan de applicatie toe te voegen. Als view engine is er voor Razor gekozen. Razor heeft als voordeel dat het voor een meer leesbare code zorgt dan de standaard ASPX-technologie. Razor is ook de nieuwste view engine technologie. Razor is veiliger dan ASPX omdat Razor automatisch html encodeert. Dit zorgt ervoor dat cross-site scripting aanvallen onmogelijk worden. ASPX heeft als voordeel dat het
3
Gecompileerde technologie¨en worden door een compiler verwerkt; de verwerkte code wordt at runtime aangeboden. 4 Ge¨ınterpreteerde technologie¨en verwerken de broncode at runtime.
Hoofdstuk 4. Cloud applicatie
37
sneller is dan Razor. Er is voor Razor gekozen omdat deze technologie veiliger is en omdat ze zorgt voor een beter leesbare code. Beide technologie¨en kunnen gemixt worden in een project. In ASP.NET MVC zijn filters ingevoerd. Deze bieden de mogelijkheid om extra code te injecteren bij het uitvoeren van een methode in een controller. Deze filter kan zowel op een methode (zodat het attribuut enkel betrekking heeft op de methode zelf), als op een controller (dan is het van toepassing op alle methodes van de controller) geplaatst worden. De prioriteit van de filters is op de eerste plaats afhankelijk van het type filter. Filters worden in de volgende volgorde uitgevoerd: • Authorization filters • Action filters • Result filters • Exception filters De Action filter bevat de methodes OnActionExecuting en OnActionExecuted van de interface IActionFilter . Ze wordt opgeroepen voor- en nadat een methode uit een controller wordt uitgevoerd. De Result filter is gelijkaardig aan de Action filter , maar bevat de methodes OnResultExecuted en OnResultExecuting, die worden uitgevoerd voor en na de return-actie van de methode. Hiervoor moet de interface IResultFilter ge¨ımplementeerd worden. De Authorization filter zorgt voor autorisatie via de OnAuthorization-methode van de IAuthorizationFilter -interface. De Exception filter die de interface IExceptionFilter implementeert (met methode OnException) wordt opgeroepen indien er een exceptie optreedt in de actiemethode. Vervolgens kijkt men naar de scope waarop deze filter is gedefinieerd. De verschillende niveaus worden in volgende volgorde uitgevoerd: • Global • Controller • Action Filters worden gewoonlijk als attribuut gedeclareerd. Bemerk dat men het achtervoegsel “Attribute ”weglaat als men een attribuut definieert als attribuut. Codevoorbeeld 4.6 illustreert het gebruik van filters in ASP.NET MVC.
Hoofdstuk 4. Cloud applicatie
1 2 3 4 5 6 7 8
38
[ A u t h o r i z e ] // naam van de f i l t e r i n h e t a t t r i b u u t p u b l i c A c t i o n R e s u l t Index ( ) { // H i e r wordt de f i l t e r boven de methode a l s a t t r i b u u t // g e d e c l a r e e r d . // Dit kan ook boven de c o n t r o l l e r b e s c h r e v e n worden . r e t u r n View ( ) ; }
Codevoorbeeld 4.6: Het gebruik van filters in ASP.NET MVC
Indien een filter voor alle methodes van alle controllers van toepassing is, kan men deze in de methode RegisterGlobalFilters van de klasse FilterConfig configureren. Zo vermijdt men dat men telkens dit attribuut dient te vermelden (en eventueel kan vergeten). Dit gebeurt zoals in codevoorbeeld 4.7. In de DCT Online is dit belangrijk voor de beveiliging. Er is een extra functionaliteit toegevoegd die controleert of er autorisatie ingesteld is. De implementatie van deze functionaliteit vindt men in hoofdstuk 7.2. 1 public class FilterConfig 2 { 3 public s t a t i c void R e g i s t e r G l o b a l F i l t e r s ( G l o b a l F i l t e r C o l l e c t i o n 4 filters ) 5 { 6 f i l t e r s . Add( new H a n d l e E r r o r A t t r i b u t e ( ) ) ; 7 } 8 }
Codevoorbeeld 4.7: Filters declareren op alle controllers in ASP.NET MVC
Als alternatief voor ASP.NET MVC is WPF overwogen. WPF staat voor Windows Presentation Foundation. WPF is performanter dan ASP.NET MVC, maar vereist het installeren van het .NET framework op de computers van klanten, wat een onaanvaardbare eis is.
4.2.3
Entity Framework
Voor het mappen van de objecten (object-relational mapping of ORM5 ) vanuit de databank naar de applicatie, is voor het Entity Framework gekozen. Dit zorgt voor meer flexibiliteit in de applicatie. Telkens er veranderingen zijn kan het datamodel worden ge¨ updatet. Er wordt gebruikgemaakt van de database first approach, behalve bij de SimpleMembershipProvider . In de SimpleMembershipProvider zijn de tabellen gegenereerd door de code van de SimpleMembershipProvider . Dit wil zeggen dat databankwijzigingen automatisch veranderingen 5
ORM is een programmeertechniek waarbij klassen code automatisch vertaald worden naar de databank of vice versa
Hoofdstuk 4. Cloud applicatie
39
teweegbrengen in de code, in plaats van andersom. Het voordeel hierbij is dat de nadruk wordt gelegd op het databankdesign. De overige mogelijkheden zijn model first en code first. Bij model first wordt de databankstructuur gecre¨eerd in de modeldesigner. De databanken worden pas gemaakt als dit nodig is. Dit is de aangewezen manier bij een nieuw project als er nog geen databankmodel is. De laatste mogelijkheid is de code first benadering. Hierbij worden de klassen geschreven in code, waarna de databank aangepast wordt aan de klassen. Voor een logische scheiding binnen de applicatie is het DataModel.tt (dit is de template die de klassen genereert) naar de BusinessLogicLayer verhuisd, waar de rest in de DataLayer staat. Er is gebruikgemaakt van de zesde versie van het Entity Framework. Deze versie heeft enkele nieuwe mogelijkheden, zoals het gebruik van een query interceptor . Er zijn echter enkele compatibiliteitsproblemen met Visual Studio 2012. Een eerste probleem is het toevoegen van een stored procedure. Doordat recentelijk een aantal klassen verhuisd zijn naar een andere namespace, moet er eenmalig een manuele aanpassing doorgevoerd worden. De lijn (codevoorbeeld 4.8) uit de DataModel.Context.tt moet vervangen worden door de lijn uit codevoorbeeld 4.9. 1 u s i n g System . Data . O b j e c t s ;
Codevoorbeeld 4.8: De lijn die moet vervangen worden. 1 u s i n g System . Data . E n t i t y . Core . O b j e c t s ;
Codevoorbeeld 4.9: De lijn die in de plaats komt.
Een ander probleem is het genereren van klassen. Omwille van een andere bug worden klassen niet aangemaakt bij het updaten van het edmx-bestand. De oplossing ligt echter meer voor de hand dan die voor de vorige bug. Men moet met de rechtermuisknop op het DataModel.ttbestand klikken en vervolgens run custom tool selecteren. De klassen worden nu gegenereerd. Hieronder volgen nog enkele technologie¨en die overwogen zijn; alsook de reden waarom er toch voor het Entity Framework gekozen is. Een eerste overweging is ADO.NET . Vermits in ADO.NET alle query’s zelf geschreven moeten worden, is deze optie niet interessant voor grote projecten, zoals de Deloitte Controlling Template Online. In de applicatie is enkele keren van ADO.NET gebruikgemaakt. Een eerste keer is het gebruikt voor de logging omdat men in elke applicatielaag wenst te kunnen loggen. Een tweede keer is van ADO.NET gebruikgemaakt om de mapping van de query interceptor van Entity Framework uit de databank te halen. Ten slotte is om performantieredenen bij het importeren van data gebruikgemaakt van ADO.NET. Hiervoor wordt doorverwezen naar hoofdstuk 6.3. Ten slotte is ook NHibernate overwogen. Met oog op de toekomst is geopteerd om geen NHibernate te gebruiken. Entity Framework is de nieuwere technologie, waarvan de func-
Hoofdstuk 4. Cloud applicatie
40
tionaliteit continu verder uitgebreid wordt. Verder heeft het entity framework async/awaitondersteuning waardoor asynchroon programmeren mogelijk wordt.
4.2.4
Language-Integrated Query (Linq)
Voor de data access layer wordt gebruikgemaakt van Linq-to-Entity6 . Linq staat — zoals de naam doet vermoeden — voor een taal die gegevenscollecties op een uniforme manier kan bevragen. Die collecties kunnen bijvoorbeeld databanken zijn, maar kunnen evengoed gegevensstructuren (bv. Linq-to-Excel, Linq-to-Object) of onderliggende lagen (bv. Entity Framework) zijn. Andere mogelijke Linq-providers zijn: • Linq-to-SQL: Linq vertaalt de Linq-query rechtstreeks naar een SQL-query. • Linq-to-DataSet: Een gewone SQL-query vult een DataSet. Vervolgens ondervraagt Linq deze DataSet. Voordelen van Linq (to Entity) zijn: • Beveiliging tegen SQL-injecties: Parameters worden automatisch geparametriseerd. Op die manier worden malafide SQL-statements die in de parameters worden opgegeven als reguliere tekst beschouwd en niet ge¨ınterpreteerd als statement. • Dynamische query-opbouw: Bevragingen worden automatisch zo effici¨ent mogelijk gemaakt. Query’s kunnen ook stapsgewijs worden opgebouwd. • Lazy loading: Linq voert de query’s pas uit indien de gegevens gebruikt worden. Dit kan een groot performantievoordeel opleveren. Andere ophaalstrategie¨en zijn eager loading (alle gevraagde objecten, tezamen met alle gerelateerde objecten worden uit de databank gehaald) en explicit loading (alle gevraagde objecten, maar niet de gerelateerde objecten worden opgehaald). • Lambda-uitdrukkingen: Het is mogelijk anonieme types te gebruiken in bevragingen. Codevoorbeeld 4.107 geeft een korte demonstratie over het gebruik van lambda-uitdrukkingen. 1 L i s t numbers = new L i s t { 1 1 , 3 7 , 5 2 } ; 2 L i s t oddNumbers = numbers . where ( n => n % 2 == 1 ) . T o L i s t ( ) ; 3 //Now oddNumbers i s e q u a l t o 11 and 37
Codevoorbeeld 4.10: Het gebruik van lambda-uitdrukkingen 6
Linq-to-Entity betekent Linq gecombineerd met het Entity Framework Codevoorbeeld van de website http://www.codeproject.com/Tips/298963/Understand-LambdaExpressions-in-minutes 7
Hoofdstuk 4. Cloud applicatie
41
De nadelen van het gebruik van Linq zijn: • Verlies van controle over de query: Linq cre¨eert de SQL-query automatisch. Men weet niet welke query Linq genereert. Dit gaf bijvoorbeeld problemen bij de query interceptor, waarbij Linq niet de standaard insert into maakte, maar een insert opdracht. • Overhead voor het maken van de query: Er is telkens een lichte overhead voor het vertalen van de query naar SQL. In de applicatie was deze overhead echter niet merkbaar. Gegevens worden teruggegeven in drie gegevensstructuren: • IEnumerable • IQueryable • IList Standaard wordt het best IEnumerable gebruikt. De IQueryable-interface is afgeleid van IEnumerable. Linq haalt de gegevens ad hoc op; de gegevens worden dus niet opgehaald bij het oproepen van de query, maar bij het gebruiken van de gegevens indien voor lazy loading is gekozen. Ook de IList-interface is afgeleid van de IEnumerable-interface. De gegevens worden in een standaard C#.NET-lijst teruggegeven. Dit is de beste keuze voor toevoegen, verwijderen en ge¨ındexeerd zoeken.
4.2.5
SQL Server
Dit is de databankomgeving van Microsoft. Een voordeel van deze databanktechnologie is dat deze standaard gebruikt wordt bij Deloitte BC&IT. In SQL Server wordt de Microsoft variant van SQL gebruikt. Deze variant heet T-SQL of Transact-SQL. Er zijn ook handige tools zoals bcp.exe8 voorzien in SQL Server. In de DCT Online is gebruikgemaakt van een SQL Server 2012 databank. Hiervoor is de developer of de enterprise versie vereist omdat er van partitionering gebruikgemaakt wordt.
4.2.6
HTML5, CSS3, JQuery
HTML5 is samen met CSS3 de nieuwste HTML-standaard. Deze is op het moment van schrijven nog niet afgewerkt. Doch zijn reeds veel features in de grote browsers (Internet Explorer, Chrome, Firefox en Safari) opgenomen.
8
Zie hoofdstuk 6.3
Hoofdstuk 4. Cloud applicatie
42
De voordelen van HTML5 zijn: • Verhoogde leesbaarheid: Door het gebruik van semantische tags worden veel div -elementen vervangen door duidelijkere elementen, zoals ,
