Category Archives: AWS

Cloud is het grote “Standaardisatie feestje”

Ik schreef eerder in deze reeks over versnelling en complexiteit. In een tweede schrijven ben ik ingegaan op de rol die kwaliteit van processen (en standaardisatie) spelen om verder te kunnen versnellen. In deze derde blog wil ik graag “Onze gang naar de cloud” vanuit dit perspectief belichten.

Kapotte airco

Ik kan me nog herinneren dat het bedrijf waar ik werkte alle server systemen naar een datacenter wilde verplaatsen. In eerste instantie vond ik dat jammer, het beheer van onze eigen serverruimte was best wel cool, totdat de airco het begaf. Een datacenter is toch een veel professionelere oplossing dat werd mij wel duidelijk.

De migratie naar de cloud heb ik net zo ervaren. Datacenter werkzaamheden zijn best lastig als het je core business niet is. Daarnaast heb je liever de volledige aandacht voor hetgeen wel je core business is.

Goedkoper of duurder?

Er waren veel goede redenen om naar de cloud te willen migreren. Eerste dachten we dat het goedkoper zou zijn. Dat kan ook wel, maar niet als je een-op-een de spullenboel naar de cloud verhuist. Het minimaliseren van de resources die je wilt gebruiken is toch wel handig. Voorheen kochten brokken resources vooraf in waarover we vervolgens vrijelijk konden beschikken. Inmiddels kopen we die resources fijnmazig in en het is daarom zinvol de hoeveelheid te beperken. Dat kan ook, want we kunnen de infrastructuur middels code beschrijven (Infrastructure as Code) en we kunnen middels autoscaling performance matchen met wat er echt nodig is.

Innovatie as a Service

Toen we wat meer bedreven raakten met cloud ontdekten we dat er een voortdurende stroom van nieuwe services beschikbaar kwam. Daar konden we zo gebruik van maken. Kortom, ook hier neemt de cloud leverancier een deel van de “Heavy lifting” van ons over en kunnen wij ons op onze core business richten.

Het staat ons natuurlijk vrij om wel of geen gebruik van deze nieuwe services te gaan maken. Het uitproberen is echter eenvoudig, kan snel en kost weinig. Experimenteren zou dan eigenlijk wel een deel van ons werk moeten zijn. Hierbij geldt, laat het snel mislukken (Fail Fast) want dat kost alleen maar geld. Is het niet zinvol of succesvol, dan stoppen we ermee.

Secure, dus cloud?

Daarna bleek dat de cloud ons heel veel mogelijkheden biedt om workloads secure te kunnen draaien. Daar waar we eerder dachten, “Moet het secure, dan in een eigen datacenter”, denken we nu veel eerder, “Moet het secure, dan in de cloud”. En dat klopt. De mogelijkheden en tools die cloud ons biedt om een workload secure en compliant te houden is enorm. Het is eigenlijk niet praktisch dat zelf te bouwen en dus is de stap naar de cloud zinvol. Je moet het nog steeds zelf goed inrichten, maar dat kan dan ook.

Cloud engineers willen serverless

Wanneer je met engineers over cloud spreekt, blijkt dat zij nog een ander perspectief belangrijk vinden. Ze hebben het dan over “Serverless” of over “Cloud native Development”. Los van mogelijkheden als autoscaling, ze hebben liever geen systemen in de cloud. Een deel van de functionaliteit kan je namelijk regelen middels services waarvoor de cloud leverancier verantwoordelijk is. De rest doe je dan bij voorkeur met containers of zelfs functions (FaaS – Functions as a Service) waarbij je helemaal geen verantwoordelijkheid hebt voor infrastructuur.

Er zijn dan ook referentie architecturen voor applicaties in de cloud. “Best practices” waarvan het zinvol is die te volgen. Waarom zou je het wiel gaan uitvinden als het er al is? Natuurlijk zijn deze referentie architecturen er voor verschillende typen applicaties. Gebruik je daarnaast het Well Architected Framework en Well Architected Reviews, dan ben je goed (professioneel) op weg.

Standaard is sneller

Met al deze “Best Practices” in de cloud zijn we aardig op weg gebruik te maken van standaard services, standaard design en een standaard manier om zaken aan te pakken. Is dat erg dan? Nee helemaal niet, ik ben er groot voorstander van. Ga maar na, je pakt het optimaal aan, gebruikt optimale design (patterns) en het ontwerp is door iedereen te begrijpen, want de referentie architectuur is leidend. Daar waar IT graag telkens het wiel wil uitvinden, gaat het zich nu langzaam conformeren aan een standaard manier van oplossingen bouwen en beheren. Dit is toch veel professioneler, is het daarmee het “Grote standaardisatie feestje”?

Want wat was ook weer het voordeel van kwaliteitssystemen en standaardisatie? Oh ja versnelling en het verlagen van complexiteit. Naar mijn stellige overtuiging is dit dan ook de grootste toegevoegde waarde van cloud, het versnelt ons en laat het daar nu net om gaan.

AWSome for the enterprise

Inmiddels is iedereen er wel van overtuigd. Public Cloud is de toekomst in het IT landschap. Aanvankelijk verzonnen we redenen om niet naar de cloud te moeten. We vonden de cloud bijvoorbeeld niet secure. De data stond niet in Nederland en het was alleen geschikt voor websites. Ook was het voornamelijk bedoeld voor start ups, en ehh, oh ja, de cloud was te duur. Toch zijn er door de jaren heen steeds meer bedrijven die kozen voor de Public Cloud. Blijkbaar waren onze redenen drogredenen. Of misschien hadden we de feiten onjuist, een soort alternatieve waarheden? Nu we deze vooroordelen achter ons hebben gelaten, kunnen we naar de Cloud. Of gelooft u nog steeds dat de mens niet op de maan is geweest en dat Elvis nog steeds leeft?

Natuurlijk verloopt de adoptie niet bij alle bedrijven even snel. Het is alleen niet meer de vraag “Of we naar de Cloud gaan”, maar “Wanneer”. Een interessante observatie daarbij is dat Amazon’s AWS verreweg de grootste aanbieder is van Public Cloud diensten. Interessant omdat Amazon geen speler was in het IT landschap. Ze begon ooit als webshop voor boeken, maar bouwde al snel een infrastructuur waar haar klanten ook graag gebruik van maakten. Inmiddels is ze de grootste aanbieder van Public Cloud diensten. AWS (Amazon Web Services) is vele malen groter dan alle overige Cloud aanbieders bij elkaar. Maar hoe maken we AWS geschikt voor grote bedrijven?

Multi account structuur

Wanneer je snel aan de slag wilt met Public Cloud, dan is een Amazon AWS account zo aangelegd. Voor zo’n account is slechts een credit card nodig en je bent “In business”. Alle AWS diensten staan je vervolgens ter beschikking. Ook echte enterprise features zoals Content Delivery Networks en uitgebreide security tools. Dat klinkt allemaal prima, maar gaan grote bedrijven er zo ook mee om? Is het echt een kwestie van account aanleggen credit-card-klaar? Misschien dat bedrijven op deze wijze starten, maar na verloop van tijd kiezen zij voor een structuur die past bij een enterprise.

Grote bedrijven hebben bijvoorbeeld behoefte om applicaties van elkaar gescheiden te houden. Ook willen ze uitgebreid gebruikersbeheer (met gedelegeerde rechten) te kunnen uitvoeren of IT architectuur uitgangspunten te kunnen afdwingen (zoals off site backups). Daarnaast willen ze security maatregelen kunnen treffen (zoals off site audit trails) en overzicht te houden over de kosten (consolidated billing). In AWS is dit mogelijk door meerdere accounts aan elkaar te koppelen, waarbij sommige account generieke voorzieningen verzorgen, de multi account structuur.

Root account

Nu is het belangrijk om te weten dat de eerste user die je aanlegt de root user is. Dit is de enige user binnen het AWS account waarmee alles gedaan kan worden. Het is ook de enige die het gehele account kan opgeheffen. Het dagelijks gebruik van deze root user is daarom ook af te raden. Deze root user credentials kunnen beter in een kluis worden opgeslagen. Voor het dagelijkse gebruik van de AWS console (de web toegang tot alle AWS diensten) worden gewone user accounts gemaakt.

Operationele- versus non-operationele accounts

Bij het gebruik van meerder AWS accounts wordt een onderscheid gemaakt tussen operationele accounts (zoals bijvoorbeeld een account waarin de productieomgeving van een specifieke applicatie draait) en non-operationele accounts (zoals bijvoorbeeld een account waarin alleen gebruikersbeheer wordt gedaan). AWS biedt daarom de mogelijkheid de accounts op een zinvolle manier te integreren zoals bijvoorbeeld de kosten in een billing account te verzamelen. Hiermee kunnen zaken effectief van elkaar gescheiden worden. Door de verschillende operationele accounts van elkaar te isoleren kunnen bijvoorbeeld fijnmazig rechten worden gegeven aan beheerders. Ook kunnen de omgevingen elkaar niet beïnvloeden, praktisch, want dit zorgt voor een hoger security niveau.

Welke non-operationele account zijn er nodig?

Multi Account structuur

Multi account structuur in de Amazon AWS Public Cloud

Billing

Het is praktisch om alle kosten centraal te verzamelen, ook wel consolidated billing genoemd. Dit gebeurd in een “Billing account”. De billing account wordt niet gebruikt voor productietaken, maar alleen voor de financiële afhandeling van de kosten. Zo “Hangen” alle accounts aan dezelfde credit card, of worden alle kosten middels een enkele factuur afgerekend. De voordelen hiervan zijn dat de volumekorting van AWS over het gehele bedrag wordt verkregen en dat gebruikers met een financiële verantwoordelijkheid alleen toegang krijgen tot deze billing account. Zij hebben geen toegang nodig tot een operationele account en houden toch overzicht over de kosten. Deze kosten worden overigens in groot detail inzichtelijk gemaakt, ze zijn per account en per resource type of tag te bekijken. Zo is te zien wat de kosten van storage zijn, of wat de kosten zijn van een ontwikkel account.

IAM

Naast de billing account is er een “Identity and Access Management (IAM) Account”. Dit is het account waar het gebruikersbeheer uitvoert wordt. Het enige dat in deze account gemaakt wordt zijn users, groepen en rollen. De overige accounts (zoals operationele accounts) hebben geen gebruikers. Vanuit de IAM account krijgen users rechten binnen andere accounts. De voordelen hiervan zijn evident, centraal gebruikersbeheer, een centrale account waarop users inloggen en geen users in de andere accounts. Deze manier van werken leidt ook tot een hogere mate van security en een beter controleerbaarheid daarvan. Voor de duidelijkheid, de users waarover we hier spreken zijn users die werken binnen de webconsole van AWS en niet de eindgebruikers van applicaties.

Audit

Vanuit security standpunt bezien is het wenselijk dat een audit trail veiliggesteld wordt voor het geval een applicatie of account gecompromitteerd raakt. In zo’n geval moet het audit trail aantoonbaar onveranderd zijn en op een andere plaats opgeslagen zijn. Speciaal hiervoor is de “Audit Account”. Dit account bestaat uit S3 buckets (object store – opslag van files) waarin de audit informatie wordt weggeschreven. Ieder operationeel account heeft een eigen S3 bucket waarin alleen dat account mag schrijven, ze mag er niet lezen en niet verwijderen. Uiteraard worden de kosten verhaald op de account die de betreffende S3 bucket gebruikt en netjes verzameld in de billing account.

Backup

De bovenstaande constructie wordt ook gebruikt voor backups. Bedrijven willen graag dat backups aantoonbaar veilig worden opgeslagen, liefst met aparte credentials. Dus waarom zou niet dezelfde constructie gebruikt kunnen worden als bij de audit account? En dat is precies waarom er een “Backup Account” gemaakt wordt. Deze account heeft alleen S3 buckets voor de verschillende operationele accounts waarin zij een backup mogen schrijven. Ook hier kunnen zij de backups niet lezen of verwijderen. De kosten van iedere bucket wordt verhaald op de betreffende operationele account en verzameld in de billing account.

Shared

Soms zijn er generieke diensten die beschikbaar gesteld moeten worden aan de operationele accounts, zoals bijvoorbeeld een GIT repository (een versiebeheersysteem voor software en configuratie files), een Puppetmaster (state config software) of centrale opslag van gedeelde informatie. Het gebruik van een zogenaamde “Shared Account” dan erg handig.

My Organization

Inmiddels heeft Amazon een nieuwe dienst gelanceerd die het opzetten en beheren van een multi account structuur vereenvoudigen, “My Organization”. Organizations geeft overzicht over de gekoppelde accounts (de billing account is leidend). Centraal kunnen bijvoorbeeld beperkingen op andere accounts aangelegd worden.

Tot slot

Er is inmiddels een goed beeld geschetst over een enterprise structuur in AWS. De non-operationele accounts zorgen voor overzicht, inzicht en betere isolatie van enterprise functies. Middels uitgebreide autorisatie kunnen users rechten krijgen op de verschillende functionele gebieden die zo gecreëerd zijn. De hier beschreven non-operationele accounts zijn wel de belangrijkste, maar er is geen beletsel er nog meer te maken als dat opportuun mocht zijn.

Met het ondersteunen van een dergelijke enterprise structuur toont Amazon aan dat Public Cloud klaar is for the enterprise, maar dan wel met de juiste inrichting.