EFFECTIEF IN DE CLOUD

EFFECTIEF IN DE CLOUD Praktische guidelines voor optimaal gebruik van cloud technologie binnen online omgevingen.

Mirabeau B.V. Opiniestuk cloud Hayo Rubingh (Director Application Management) en Marco ter Horst (technisch architect) Pagina’s 8

H.J.E. Wenckebachweg 108 | 1096 AR Amsterdam | tel :+31(0)20-5950550 | [email protected]

Opiniestuk cloud Versie 1.6 Cloud technologie speelt een steeds grotere rol binnen de exploitatie van web omgevingen. De voordelen van cloud zijn inmiddels breeduit bekend en de technologie is grotendeels geaccepteerd. Maar welke ontwerpcriteria zijn belangrijk en waarom is een sterke focus op automation essentieel voor een optimaal rendement van cloud omgevingen? Wie begint met cloud krijgt in eerste instantie te maken met de selectie van een aanbieder. Het aantal aanbieders op de markt is de laatste jaren explosief gegroeid. Het maken van de juiste keuze, met alle risico’s van bijvoorbeeld een vendor lock-in, kan daarom lastig zijn. Als advies, evalueer grondig de verschillen tussen de aanbieders. Niet alleen op prijs maar focus vooral op de technisch inhoudelijk en functionele verschillen. Om inhoudelijk meer inzichten te verkrijgen valt het aan te bevelen zelf capaciteitstesten, performancetesten en structurele vergelijkingen van aangeboden functionaliteiten uit te voeren. Dit stelt ICT afdelingen in staat een gedegen inhoudelijk beeld te vormen. In onderstaande alinea's belichten we een aantal belangrijke verschillen en aandachtspunten bij de keuze van een aanbieder. Waarom is locatie belangrijk? De exacte geografische locatie van een cloud platform kan consequenties hebben voor de diensten die gebouwd worden op het platform. Zo zijn er potentieel juridische consequenties voor de opslag van data buiten de Nederlandse landsgrenzen, ongeacht of deze nu versleuteld is of niet. Dit kunnen bedrijfspolicies zijn, maar ook EU regelementen. Daarbij komt dat veel grote spelers van origine Amerikaanse bedrijven zijn (Amazon, Microsoft etc.) waardoor er spanning kan ontstaan tussen enerzijds de Safe Harbor regeling en anderzijds de Patriot Act wetgeving. Net als met andere security en privacy gevoelige zaken valt het aan te raden dit helder te krijgen. De locatie kan ook invloed hebben op de snelheid van een online omgeving. Hoe verder de bron van de bezoeker afligt, hoe trager de initiële response is in een webbrowser. Er zijn tal van oplossingen om dit ongewenste gedrag tegen te gaan, maar het hosten van een applicatie in de VS als de verwachte gebruikersgroep vooral in de EU zit is zeker niet optimaal. Is een cloudaanbieder een one-stop-shop? De meeste cloudaanbieders streven naar een sterke integratie tussen al hun diensten. Dit uit zich in gedeelde faciliteiten zoals facturatie, toegangs beheer, gebruikers management, monitoring etc. Bij het kiezen van de juiste cloudaanbieder loont het daarom om de juiste mix van functionaliteiten en benodigde infrastructurele componenten te bepalen. De voordelen zijn onder andere: -

Minder administratieve overhead; Geen versnippering van kennis over meerdere platformen; Eén management console; Eén periodieke rekening.

Onderstaande tabel biedt een handvat om cloudaanbieders te vergelijken en daarmee een juiste match te kunnen maken tussen het vraagstuk en de juiste aanbieder. Basis diensten Servers (VPU, MEM, OS) DNS Load balancing Firewall Database Network Storage Messaging / Queuing Mirabeau bv | 23 augustus 2013

Additionele diensten Dynamic Scaling CDN API Provisioning Dedicated Hardware PaaS services

Support en Beheer Admin Tooling Access Control Logging Monitoring VPN Facturatie (billing) Support / Knowledgebase Email 1

Opiniestuk cloud Versie 1.6

Server / Stack Templates

Hoe kan je de performance vergelijken tussen cloudaanbieders? Gevirtualiseerde platformen hebben jammer genoeg niet één standaard om performancevergelijkingen te doen; er is geen échte universele benchmark. Het blijkt in de praktijk daarom lastig om één uniform antwoord te formuleren welk platform bijvoorbeeld de meeste ruwe kracht levert; helemaal ongeacht de prijs. Ook dit is een argument om eigen testen uit te voeren en te valideren of de cloudaanbieder levert conform de vereisten. Een voorbeeld hiervan is een test die bepaalt hoeveel Database Read IOPS elk van de cloudplatformen kan leveren onder vrijwel gelijke specificaties en condities. Afhankelijk van de test samenstelling, configuratie en technische keuzes kan een uitkomst er bijvoorbeeld als volgt uit zien:

Figuur 1) DB Read IPS per cloudaanbieder. Hoger is beter.

Dergelijke uitkomsten - overigens zeer situatie specifiek - onderbouwen een goed advies over het meest geschikte platform, waarbij overigens niet alleen de absolute performance, maar ook de kosten per eenheid een belangrijke factor spelen.

Mirabeau bv | 23 augustus 2013

2


Architectuur en ontwerp Cloudplatformen hebben niet alleen invloed op de uiteindelijke technische implementatie en de locatie hiervan; ook het ontwerpproces verandert. Architecten en engineers merken snel dat de balans tussen beperkingen en vrijheden van het cloudplatform leiden tot een andere manier van ontwerpen. De infrastructurele componenten (firewalls, webservers, loadbalancers, storage) verschillen per cloudaanbieder op vele punten, zowel qua technische oplossing als de kosten. De juiste keuze ligt daarom niet altijd voor de hand en kan variëren tussen een snelle en simpele oplossing zoals het hosten van een statische website (in bijvoorbeeld een Amazon S3 bucket) tot het realiseren van een complete private cloud backend met 50+ servers, VPN connecties, backupstrategie en een uitwijk voorziening. Los van de scope en omvang van de infrastructuur is het raadzaam onderstaande principes te hanteren bij het ontwerpen van een cloud architectuur: Van beperkingen word je creatief Het gebruik van clouddiensten (en dan vooral de PaaS en SaaS varianten) brengt inherent beperkingen met zich mee. De cloudaanbieder maakt bepaalde keuzes die gelden voor alle afnemers en in maar weinig gevallen kan hier van worden afgeweken. Veel van de grotere cloudaanbieders bieden uitgebreide API’s aan waarmee toegang tot de resources in de cloud kan worden verschaft. Echter, buiten deze API’s en de beschikbare gestelde configuratiemogelijkheden is er weinig ruimte voor zogenaamde “specials” of maatwerk oplossingen; typisch iets wat wel mogelijk is bij een dedicated hostingpartij of in een eigen datacentrum. Echter, een afgedwongen kader werkt productief. Het komen tot een oplossing binnen de beperkingen van een platform zorgt vaak voor simpelere oplossingen. Waar eerst elk probleem een eigen oplossing kende (de weg van de minste weerstand) en vervolgens de infrastructuur zo opgezet werd om die oplossing te faciliteren, moet nu juist gekeken worden of de oplossing past binnen het kader. Zo niet, dan moet een andere oplossing gezocht worden die wél past. Deze beperkingen dwingen engineers en architecten om creatief te zijn en te denken in nieuwe patronen en hergebruik. Accepteer een bepaalde mate van trial & error Het opzetten van een infrastructuur in de cloud is soms slechts minutenwerk. Dit betekent niet dat er geen degelijk ontwerp ten grondslag moet liggen aan een architectuur in de cloud. Alle fouten en onvolkomenheden van een slecht ontworpen architectuur komen in de cloud net zo hard aan het licht als in een fysiek of alleen gevirtualiseerde architectuur; slechte on-premises oplossingen zijn slechte oplossingen in de cloud. De manier waarop een ontwerp tot stand komt kan echter wel anders worden aangevlogen. Doordat de fysieke en financiële drempel weg is, is het makkelijker en minder kostbaar om op basis van prototyping (en een bepaalde mate van trial & error) tot een ontwerp te komen. Het uitproberen van oplossingen zonder deze eerst in een gedetailleerd technisch ontwerp te zetten biedt sneller zekerheid of iets werkt of niet. Op deze manier kan continu de praktische invulling van een oplossing getoetst worden aan het “papieren ontwerp.” Je ziet dat het ontwerpen van een architectuur zo steeds meer een agile proces wordt. Hybride oplossingen ontlasten de on-premises infrastructuur Een oplossing gebaseerd op 100% cloudcomponenten is niet altijd wenselijk of mogelijk, bijvoorbeeld vanwege licentie beperkingen of data locatie vereisten. Ook met beperkte inzet van de cloud kan echter geprofiteerd worden van de voordelen. Veel aanbieders bieden daarom diensten Mirabeau bv | 23 augustus 2013

3

Opiniestuk cloud Versie 1.6 die ook te integreren zijn in een traditionele on-premises oplossing. Een goed voorbeeld hier van zijn diverse storage diensten zoals content delivery networks (CDN’s). Contentrijke E-commerce sites met een groot aantal digital assets (denk aan productcatalogi, of user generated content) hebben veel voordeel bij het opslaan en serveren van deze assets uit de cloud, zoals: -

De core infrastructuur wordt zo ontlast om de dynamische content uit te serveren; De storagekosten zijn substantieel lager; Standaard operating systems zijn niet geschikt voor het opslaan en doorzoeken van miljoenen bestanden.

De implementaties zijn divers: Funda.nl serveert 8,5 terabyte (verspreid over 130 miljoen objecten) vanuit de Amazon S3 laag aan haar voornamelijk Nederlandse bezoekers; klanten in de reisindustrie gebruiken CDN’s om ook de performance in bijvoorbeeld China op peil te houden.

Automation en de Cloud zijn gemaakt voor elkaar Het grootste operationele voordeel van Cloud is wellicht dat het automatiseren van een omgeving naar een nieuw niveau kan worden gebracht. De exacte opbouw, de blueprint, van alle infrastructurele componenten worden vastgelegd in eenduidige source code, ook wel “infrastructure as code” genoemd. Alhoewel automation ook bij niet-cloud oplossingen sterk valt aan te raden, heeft de cloud een aantal kenmerken die automation nog aantrekkelijker maken: -

Vrijwel alle cloudplatformen zijn aan te spreken via een API. Diverse services en tools maken het mogelijk direct de infrastructuur te beïnvloeden. Dit biedt uitgelezen kansen voor de integratie van acties op de infrastructuur in geautomatiseerde scripts. Kies daarom altijd een cloudplatform met een goede API ontsluiting.

-

De lifecycle van servers in de cloud kan zeer dynamisch zijn. Het verwijderen en later weer opnieuw uitrollen van een typische server moet niet leiden tot een hoop handmatige installatiewerkzaamheden nadat de server up is. Dus ook de installatie van middleware en overige software moet automatisch gaan.

Hou er rekening mee dat een volledig geautomatiseerde stack uitrollen- van server tot werkende webshop – niet altijd haalbaar of nuttig is. Als er geen zicht is op heftig fluctuerende vraag naar resources of groei dan kunnen bepaalde zaken via meer traditioneel beheer ingevuld worden. Om deze reden is het verstandig om automation vraagstukken op te delen in vier aandachtsgebieden en hier afzonderlijk een strategie voor te definiëren. Deze verdeling is hieronder schematisch weergegeven.


4


1. Cloud Provisioning (via API scripting of vendor native tools)

2. OS Configuratie

3. Middleware Configuratie

4. Applicatie Deployment

Operating System Baseline

Webservers

Deployment Management

Maintenance & Security

Applicatieservers

Deployment Tracking OTAP

Technische Monitoring

Databases

Deployment Execution

Basic Access Control

CMS/E-Commerce software

Content en Assets

Puppet Configuration Management

Nolio Continuous Delivery en Deployment

Figuur 2) Vier verschillende automation processen en mogelijke tooling

1) Cloud provisioning gaat om het creëren, configureren en ook weer verwijderen van de basisresources op het cloudplatform (servers, disks, loadbalancers, firewalls etc.). Aansturing hiervan kan via eigen scripts of door gebruik te maken van tools van de specifieke cloudaanbieder; Amazon AWS biedt hiervoor bijvoorbeeld CloudFormation. 2) OS configuratie biedt een stabiele onderlaag waardoor bijvoorbeeld security eisen - op het gebied van systeem user en auditing - en technische monitoring consequent en uniform kunnen worden uitgerold. Hiervoor kunnen configuration management tools als Puppet worden ingezet om zo op basis van baselines één configuratie af te dwingen op een omgeving. 3) Middleware configuratie is de stap waar de diverse onderliggende applicatieve componenten worden geïnstalleerd en geconfigureerd. Het meest in het oog springende voorbeeld is een webserver met een bepaalde virtual host configuratie. Het automatiseren van deze laag dient ervoor de uiteindelijke gebruikersapplicatie (een CMS of een Ecommerce pakket) betrouwbaar door een OTAP-straat te kunnen uitrollen. Tot op zekere hoogte kunnen hiervoor tools als Puppet gebruikt worden. 4) Applicatie deployment is het eindstation waar een werkende instantie van een applicatie geleverd wordt middels automation. Hierbij gaat het om veelal implementaties van CMS of E-commerce pakketten of volledige maatwerk software op basis van Java of .Net. In een typisch scenario bestaan er meerdere versies van deze software op meerdere lokaties in de OTAP-straat en op meerdere servers binnen de productieomgeving. Nolio is high end software wat het mogelijk maakt om zo’n proces te automatiseren. Het automatiseren van de cloudinfrastructuur en de applicaties die daarop moeten landen kan een complexe aangelegenheid zijn. Door onderstaande uitgangspunten te hanteren komt succesvol automation in de cloud een stap dichterbij.:


5


Maak het leven makkelijk; ontkoppel zo veel mogelijk Een hoge mate van koppeling en integratie tussen frontend, middleware en backend kan zorgen voor veel kopzorgen. Bij een zo’n monolithische architectuur neemt de complexiteit van releases toe, ontstaan schaalbaarheidsproblemen en zijn hoge kosten gemoeid met wijzigingen. In een traditionele omgeving springen dit soort “embarrassing dependencies” minder in het oog omdat de fysieke architectuur vaak statischer is. Het opschakelen van extra servers, disks en netwerkinfra zit zo ingekaderd in procedures, contracten en soms bureaucratie dat de technische uitdagingen minder opvallen. Bij geautomatiseerde cloud architecturen vallen de meeste van deze procedurele obstakels weg. Dat is natuurlijk winst, maar helaas komen nu alle onhandig gekozen koppelvlakken tussen de verschillende lagen sneller aan het licht. Wil je dus werkelijk de lifecycle van een applicatie in de cloud compleet automatiseren, dan moet je applicatiestack daarvoor geschikt zijn. Ontkoppel en definieer (RESTful) diensten tussen applicatielagen. Het risico is anders dat je eindigt met een éénop-één kopie van een traditionele architectuur in de cloud die nog steeds onderhouden wordt door een lange reeks handmatige procedures. Configuratiemanagement wordt (nog) belangrijker Van nature zijn resources in de cloud vluchtig. Naast het “on the fly” aanmaken van servers, storage en netwerk is het verwijderen van deze componenten net zo belangrijk. Parallel aan het groeien en slinken van het IT-landschap veranderen natuurlijk ook nog de versies van software, services, patches, fixes etc. etc. Zonder configuratie- en versiebeheer is het daarom zeer moeilijk te bepalen welke servers, met welke applicaties (en welke configuratie voor welke omgeving) nu in een bepaalde situatie aangemaakt moeten worden. Automation leunt sterk op een eenduidige en exacte vorm van configuratiemanagement; er is in een geautomatiseerd proces weinig ruimte voor twijfels en toevalligheden. Maar dit mes snijdt aan twee kanten: automation zorgt tegelijkertijd ook voor een voorspelbare en eenduidige infrastructuur! Dit is ook de boodschap van het infrastructure-as-code principe: door configuratie te vangen in echte code is er meteen een gestructureerd document van de infrastructuur. Deze kan in bekende code versiebeheersystemen zoals SVN of GIT worden opgeslagen; auditing, controle en logging op wijzigingen in de infrastructuur worden zo veel makkelijker. Exacte sizing is moeilijk; monitor en automatiseer je omgeving daarom. Bij nieuwe online initiatieven is het vaak nog onduidelijk hoeveel bezoekers een site uiteindelijk gaan bezoeken of hoe goed een bepaald stuk code zich houdt onder belasting. Dit leidt op zijn beurt weer tot storingen of een slechte performance. Het exact inschatten van wat er nodig is aan vermogen om de pieken van het bezoek op te vangen is een lastig en tijdrovend vraagstuk waarin vele variabelen en aannames een rol spelen. Dit kan leiden tot oversizing, waarbij grote investeringen in resources uiteindelijk ongebruikt blijven. In andere gevallen leidt het tot undersizing waarbij vooral tijdens lanceringen en speciale acties de capaciteit niet voldoende blijkt, met economische- en/of imagoschade tot gevolg. Het motto in de cloud moet dan ook zijn dat de correcte sizing niet op voorhand bekend is: maar dat dat niet erg is. Hier moet wel tegenover staan dat een applicatie op de juiste plekken gemonitord wordt zodat dalingen in performance direct aan het ligt komen en dat door automation, resources vlot bijgeschakeld kunnen worden. Een dergelijke strategie biedt ook kostenvoordelen, koop niet meer in dan noodzakelijk!

Tot slot, een goede cloud implementatie biedt veel voordelen zoals het automatisch opschalen op Mirabeau bv | 23 augustus 2013

6

Opiniestuk cloud Versie 1.6 basis van bepaalde performance criteria; en zonder menselijke interactie! Op deze wijze worden kostenvoordelen bereikt en de operatie maximaal ontzorgt. Om dit te bereiken zijn wel andere uitgangspunten benodigd dan klassieke on-premises omgevingen. Het programmeren van infrastructuren - Infrastructure-as-code - is hierbij een belangrijk principe. Online applicaties die zelfvoorzienend zijn in het toewijzen en schalen van infrastructuur zijn wat dat betreft ook het toekomstbeeld.

Over de auteurs Hayo Rubingh is Director Application Management bij Mirabeau en houdt zich bezig met strategische ontwikkelingen zoals cloud computing. Marco ter Horst is technisch architect bij Mirabeau en verantwoordelijk voor het ontwerp van online architecturen.

Een aantal voorbeelden van verschillende cloud oplossingen: Amazon Web Services: Amazon Web Services (AWS) is de public cloud-marktleider, maar biedt daarnaast ook hybride vormen waarbij infrastructuren gekoppeld kunnen worden aan een bestaande on-premises infrastructuur. AWS biedt een rijke functionaliteit en een lage instapdrempel. Data kan worden opgeslagen binnen de Europese unie. Microsoft Azure: De Azure IaaS oplossing van Microsoft is een nieuwkomer in de public cloudmarkt. Microsoft begeeft zich daarmee direct op het terrein van AWS De combinatie van bekende Microsoft producten in PaaS-vorm en de recent gelanceerde IaaS-functionaliteit is vaak voordelig binnen Microsoft georiënteerde omgevingen. Azure kan fysiek in Nederland (Amsterdam) gehost worden. Interoute: Interoute biedt private clouddiensten die gebruik maken van een uitgebreid, sterk Europees georiënteerd, netwerk van datacenters en co-locaties. Naast het on-demand aanvragen van resources via het Virtual Data Center (VDC) kunnen dus ook co-locatie of andere, niet virtuele, oplossingen gefaciliteerd worden. Interoute is aanwezig in Nederland en acht andere Europese locaties. Interoute is Brits eigendom en valt daarom niet direct onder de Amerikaanse wetgeving.


7

EFFECTIEF IN DE CLOUD

Recommend Documents