29/11/2013
Auto Deploy met VMware en Chef – Development omgevingen
Dit artikel beschrijft hoe we automated deploym hebben toegepast om de development machines binnen Cyso te stroomlijnen, zodat elke developer in controle is over zijn omgeving.
Blog
Steeds meer cloud infrastructuur providers blijven hun platform uitbreiden met nieuwe services. Hierdoor zijn de mogelijke opties om applicaties te bouwen explosief gegroeid. Organisaties die geen richtlijnen hebben voor het gebruik van cloud computing riskeren een ‘cloud sprawl’: een wildgroei aan cloudapplicaties en -oplossingen. De referentiearchitectuur verschilt afhankelijk van bedrijf, gekozen services en eisen. Wat zijn best practices van een cloud referentiearchitectuur?
Dat organisaties naar de cloud gaan is inmiddels gemeengoed. De volgende stap voor organisaties is het antwoord vinden op de vraag hoe ze hun cloud omgeving moeten inrichten. Er zijn genoeg organisaties die beperkt worden door budgetten, beschikbare kennis en wet- en regelgeving of andere compliance standaarden. Het kiezen van de juiste service voor jouw applicatie moet overwegingen bevatten over de prijs, schaalbaarheid, beschikbaarheid, beheersbaarheid, security en compliance.
En willekeurige cloudprovider heeft vaak honderden services beschikbaar en in sneltreinvaart worden er nieuwe toegevoegd. Developers hebben architectuur richtlijnen nodig over de beste services die ze kunnen gebruiken voor hun oplossingen om de kosten te beheersen, sneller te leveren en naleving te garanderen.
Referentiearchitectuur helpt project managers, software developers, enterprise architects en IT managers samenwerken en effectiever te communiceren over een implementatie project. Een reference architectuur houdt rekening mee en beantwoord de meest voorkomende vragen die ontstaan tijdens het project. Als gevolg hiervan helpt dit teams fouten en vertragingen te voorkomen die gebeuren zonder een set van best practices te volgen.
Het definiëren van een cloud referentiearchitectuur is een essentiële stap om cloud volwassenheid te bereiken. Een referentiearchitectuur adresseert de zorgen van stakeholders door het definiëren van de mogelijkheden van de betreffende architectuur en roadmap die in lijn ligt met de business goals.
Er is niet één perfecte cloud referentiearchitectuur voor iedere organisatie. Afhankelijk van het soort bedrijf, de gekozen services en andere eisen of restricties verschilt de referentiearchitectuur. Het is dus maatwerk. Wel zijn er enkele gedeelde noemers die je steeds terugvindt in referentiearchitecturen. We lichten een aantal factoren toe van een goede referentiearchitectuur:
Door de load te verdelen over het netwerk is de applicatie response sneller. Daarnaast kan het de beschikbaarheid van applicaties en websites verhogen voor gebruikers. Voor deze high availability omgevingen zorgt een load balancer ervoor dat requests alleen naar servers gaan die online zijn. Verder is het mogelijk om servers toe te voegen of te verwijderen naar behoefte van de load.
Load balancing leidt niet alleen tot hoge beschikbaarheid, het bevordert ook de incrementele schaalbaarheid.
In tegenstelling tot wat je misschien zou verwachten is het toevoegen van meer onderdelen aan het platform niet de oplossing om het stabieler en beschikbaarder te maken. Sterker nog, je maakt het alleen maar erger omdat meerdere onderdelen de kansen op failures verhogen. Een moderne omgeving verdeelt de workloads over meerdere instances (bv. netwerk, clusters), wat helpt bij het optimaliseren van het gebruik van resources, beste performance, kortere responstijden en het vermijden van overbelasting door gebruik van load balancing. Hieronder valt ook het overschakelen naar een standby server/netwerk in geval van een storing, bekend als failover systemen.
Hoe realiseer je een high availability omgeving?
Door redundantie voorkom je dat door het falen van een component het hele systeem faalt. Een voor de hand liggende oplossing is om je applicatie over meerdere servers te implementeren. Hierbij kun je de belasting verdelen, zodat bij uitval of overbelasting van één server een andere server deze functies kan overnemen.
In systemen die redundant zijn uitgevoerd kan het voorkomen dat het failover mechanisme zelf een single point of failure wordt. Een betrouwbare, automatische, failover staat of valt bij een goede health check.
Als jouw applicaties en databases op servers leven die op dezelfde fysieke locatie staan en er gaat iets mis met die locatie, dan kan dit alsnog tot flinke downtime leiden. Zorg er dus voor dat jouw servers op verschillende locaties staan. Dit kan door gebruik van meerdere datacenters of availability zones.
Verder lezen over high availability omgevingen? Lees High availability omgevingen voor E-commerce
Het is een slechte zaak als lekken in software niet snel gedicht worden. Hoe langer je wacht met het installeren van de vereiste patch, hoe groter de kans op misbruik. Als je het niet meeneemt in je procedures, dan gebeurt het niet en wordt het vergeten of ligt het ergens onderaan de stapel.
Het creëren van een vast updateproces voorkomt dat systemen te lang niet worden bijgewerkt. Richt vaste, maandelijkse onderhoudsvensters in waarin je zoveel mogelijk alle besturingssystemen voorziet van de laatste updates. Zorg daarnaast voor een goede risico-inventarisatie als er kwetsbaarheden aan het licht komen.
Welk back-up systeem het beste past bij jouw organisatie hangt vooral samen met het type business en welke eisen jij stelt aan de recovery time objective (RTO, de maximale restore tijd) en de recovery point objective (RPO, de hoeveelheid van dataverlies bij een restore).
Een betrouwbare en consistente back-up maken – en zeker weten dat je alle benodigde data terugkrijgt op het moment dat je moet restoren – klinkt als iets vanzelfsprekends, maar is vaak niet het geval. Een goed doordachte back-up-methode bespaart een hoop ellende in het geval dat er iets misgaat.
Er zijn verschillende methodes om data veilig te stellen: file-based back-ups, snapshots en image-based back-ups. Los van welke cloud je gebruikt, denk goed na over welke garanties er gegeven moeten worden op de RTO en RPO. Bepaal daarna hoe disaster recovery geregeld moet worden. Wij bevelen aan om regelmatig een restore test uit te voeren.
Kies vervolgens de back-up-methode die het beste aansluit bij jouw business. Ben je gebonden aan specifieke eisen rond de RTO/RPO, dan is de kans groot dat deze het best te realiseren zijn binnen een private of multi-cloud omgeving.
Steeds meer (persoonsgevoelige) gegevens worden online verwerkt en uitgewisseld. Een veilig transport van deze data en het borgen van de privacy moet een hoge prioriteit hebben. Specifieke beveiligingseisen en/of certificering standaarden, zoals PCI-DSS of NEN 7510, zijn makkelijker af te vangen binnen een private of multi-cloud omgeving dan binnen de public cloud. Bijvoorbeeld door data gegarandeerd op te slaan op Nederlandse bodem in een Nederlandse cloud.
Public cloud-providers besteden vanzelfsprekend veel aandacht aan de beveiliging van hun platformen en bieden de gebruiker talloze opties op dit vlak. Tot op zekere hoogte is de beveiliging naar eigen wens in te regelen, maar dat vereist veel kennis en tijd van degene die het moet uitvoeren.
Een streng toegangsbeleid hoort bij de lijst van preventieve security maatregelen. Hoe minder mensen toegang hebben tot applicaties en systemen, hoe kleiner de kans dat via één van die gebruikers beveiligingsincidenten ontstaan. Dat kan zowel door een menselijke fout als door misbruik door derden via bijvoorbeeld phishing. Denk ook na over logins en het gebruik daarvan. Heb je een generieke login of moeten gebruikers elk een persoonlijke login hebben?
Het wordt ook aangeraden om diensten en (beheer)interfaces die geen publieke toegang vereisen achter een (SSL) VPN te zetten of in een niet-publiek VLAN te plaatsen. Gebruik hierbij ook een access list om alleen de noodzakelijke gebruikers toegang te verlenen, het liefst ook met two-factor authentication. Beperk daarnaast de rechten in de vorm van het ‘least privilege’ concept: de basisrechten zijn nul en op verzoek worden er specifieke rechten verleend. Dit is van toepassing voor zowel de protocollen en applicaties die gebruikt worden voor de toegang als voor de specifieke functionaliteit die beschikbaar gemaakt wordt.
Je IdP (Identity Provider) is bepalend voor de architectuur. Systemen en applicaties waarvoor gebruikersidentificatie plaatsvindt (met keys, 2FA/MFA en andere oplossingen), zijn vaak gelaagd bovenop de kern-IdP. Ze dienen om de kerngegevens (gebruikersnaam en rollen) van de gebruikers (via bijvoorbeeld SAML of OIDC/OpenID) te bundelen naar verschillende eindpunten (applicaties) en ze vervolgens de juiste rechten te geven. Daarom heeft de keuze voor een specifieke IdP een diepgaande invloed op de algehele IAM-architectuur.
Zoals je merkt, dé oplossing is er niet. De juiste cloud referentiearchitectuur moet de blueprint zijn van jouw organisatie: het is dus maatwerk. Afhankelijk van de gewenste technische en zakelijke eisen en gebruikte applicaties verandert de architectuur. Bovenstaande is een selectie van best practices waarop wij kijken naar IT omgevingen. Zeker naarmate platformen en applicaties groter worden, komt er meer bij kijken. Wil je weten wat een geschikte cloud referentiearchitectuur voor jouw organisatie is? Laten we een (virtueel) kopje koffie pakken. Neem contact met ons op!
