Blog

Nooit meer servers vervangen met AWS

Auteur Ben

In 2014 moest ik geregeld op de fiets naar een datacenter om schijven en servers te vervangen. Het mooie was dat we controle hadden van A tot Z en ik zowel hardware en applicaties beheerde, maar ook softwarecomponenten bouwde. Wanneer iets kapot ging dan konden we dat zelf herstellen, maar het nam ook best wat tijd in beslag. Tijd die ik liever wilde besteden aan het bouwen van tools om te interacteren met API’s en processen weg te automatiseren. Gelukkig geloven we bij Trivento in het samenwerken met partners. Aangezien Amazon Web Services (AWS) gespecialiseerd is in het beheren van datacenters en servers gaan wij als Trivento zelf geen servers beheren. Dat is een van de redenen waarom we AWS partner zijn. Verder biedt AWS alle cloud vormen aan tegen een lage prijs en kunnen we dankzij AWS voor onze opdrachtgevers razendsnel applicaties veilig live brengen. In deze blog vertel ik je meer over AWS en hoe het zich positioneert in de cloud.

Oprichting AWS

AWS is een dochteronderneming van Amazon opgericht in 2002. In de jaren daarvoor had Amazon al ervaring opgedaan in het omgaan met piekbelastingen tijdens de periodes voorafgaand aan feestdagen, waarin significant meer producten werden besteld op Amazon. Amazon had al een team dat in staat was de Amazon website in de lucht en werkbaar te houden door extra systemen bij te schakelen en open source software te gebruiken. Aangezien buiten deze drukke perioden deze hardware systemen en software niks stonden te doen is het vermoeden dat Amazon naar manieren ging kijken om wat met deze systemen te gaan doen. 

Zo kwam men op het idee om diensten te gaan bouwen en deze voor partijen beschikbaar te stellen. Men begon toentertijd met EC2 (Elastic Cloud Computing, een IaaS dat klanten de mogelijkheid biedt Virtuele Machines (VMs) te maken), S3 (Simple Storage Service, een SaaS dat klanten de mogelijkheid biedt bestanden in virtuele-emmers (buckets) op te slaan) en RDS (Relational Database Service, een SaaS dat de mogelijkheid biedt een database zoals PostgreSQL as a service af te nemen). Inmiddels zijn er meer dan 200AWS diensten.

AWS Wereldwijd

AWS is een publieke cloud provider die in alle continenten op de wereld aanwezig is (zie figuur 1). 

Figuur 1: de huidige en aanstaande locaties van AWS datacenters

Eén van de voordelen van AWS is dat zij de hardware beheren en de klant niet meer te maken heeft met de on-premise cloud vorm. Er kan onderscheid gemaakt worden tussen CapEx en OpEx die respectievelijk staan voor Capital en Operational Expenditure. De eerste betreft investeringen en de tweede de kosten die men besteedt aan het onderhoud van systemen. Indien men van meet af aan zou kiezen voor een publieke cloud leverancier, zoals AWS dan is sprake van OpEx aangezien men alleen betaalt voor het gebruik. Kortom, AWS is verantwoordelijk voor de datacenters en biedt de klant de mogelijkheid om van IaaS tot SaaS verschillende services te laten afnemen. Echter zal de klant ook zelf bepaalde zaken moet regelen. 

AWS Shared Responsibility Model

Welke zaken dit zijn heeft AWS vastgelegd in het Shared Responsibility Model (zie figuur 2).

Figuur 2: het shared responsibility model

In dit model geeft AWS weer wat de verantwoordelijkheden zijn van AWS zelf en van de klant. AWS is verantwoordelijk voor de wereldwijde infrastructuur die bestaat uit regio’s, Availability Zones (AZ) en edge locaties. Daarnaast is AWS ook verantwoordelijk voor bepaalde software, zoals compute en networking. De klant is zelf verantwoordelijk voor de veiligheid IN de cloud, terwijl AWS zorg moet dragen voor de veiligheid VAN de cloud.

AWS Regio’s

AWS bevindt zich op het moment van schrijven in 25 regio’s met meerdere AZ’s, hetgeen twee keer meer is dan de op twee na grootste publieke cloud speler. In 2021 is AWS nog steeds de grootste speler, op afstand gevolgd door Microsoft Azure die op minder grote afstand wordt gevolgd door Google Cloud Platform (GCP). AWS heeft datacenters in de volgende Europese steden: Frankfurt, Ierland, Londen, Milaan, Parijs en Stockholm. Daarnaast is men bezig om datacenters te bouwen in Spanje en Zwitserland.

Op dit moment heeft AWS geen datacenters in Nederland, maar wel een Edge locatie. De media geven echter aan dat in 2021 meerdere datacenters gebouwd zullen worden in Zeewolde. Het is onbekend welk van de grote drie cloud providers het betreft. Kijkend naar het beleid van AWS, bestaat een regio uit meerdere AZ’s die elk uit meerdere datacenters bestaan. Tussen deze AZ’s moeten meerdere kilometers zitten om te voorkomen dat in geval van een lokale overstroming de software van klanten onbereikbaar wordt. AWS vermeldt alleen dat de maximale afstand tussen AZ’s 100 kilometer is. Over de minimale afstand wordt niets aangegeven alleen dat de AZ’s zelfstandig kunnen draaien indien een andere AZ onbereikbaar wordt. Het lijkt onwaarschijnlijk dat het een AZ van AWS betreft aangezien geen andere berichten zijn gevonden over de bouw van andere grote datacenters in Nederland die zich op meerdere kilometers van Zeewolde bevinden. Even leek het er in 2018 op dat AWS mogelijk datacenters ging bouwen in Middenmeer naast Microsoft Azure, maar dit bleek later om datacenters te gaan van GCP, die overigens ook datacenters heeft in Groningen. Kortom, het blijft koffiedik kijken of er Nederlands AWS datacenters zullen komen. Wat wel vaststaat is dat AWS verder blijft uitbreiden.

AWS Availability Zone

Een Availability Zone (AZ) bestaat uit één of meerdere datacenters. Op het moment van schrijven beschikt AWS over 81 AZ’s. Iedere regio in Europa bestaat uit drie AZ’s. Aangezien deze AZ’s volledig op zichzelf draaien blijven de applicaties beschikbaar indien er een AZ uitvalt vanwege stroomuitval of overstromingen. AWS geeft aan dat alle AZ’s zich binnen 100 km bevinden. Zo nu en dan lezen we dat een bepaalde AZ in Frankfurt even niet beschikbaar was. Aangezien Ons Trivento Cloud platform is neergezet op alle drie de AZ’s merken onze klanten niets wanneer een datacenter of gehele AZ of twee AZ’s uitvalt.

AWS Edge locatie

Op dit moment beschikt AWS over meer dan 218 edge locaties.

Om uit te leggen wat dit is maak ik gebruik van een voorbeeld. Want stel dat je initieel een applicaties had neergezet in bijvoorbeeld Frankfurt. En  op een gegeven moment gaat een klant in Australië gebruik maken van jouw software. Dan kan je Edge met CloudFront (CloudFront is een Content Delivery Network (CDN) )configureren om de mate van vertraging op de lijn (latency) te verkleinen. Op deze manier lijkt het voor klanten alsof ze van servers gebruik maken die bij hen in de buurt staan. . 

AWS Services

AWS biedt services in verschillende cloud vormen aan, zoals EC2 hetgeen een IaaS is, EKS (CaaS), BeanStalk (PaaS) en Lambda (Faas). Tegenwoordig beschikt AWS al over meer dan 200 verschillende services. Sommige klanten geven in een gesprek aan dat zij graag een “cloud-agnostische” oplossing willen. Als reden hiervoor wordt vaak het vermijden van een “Vendor lock-in” genoemd. Een “Vendor lock-in” houdt in dat men services bij een publieke cloud provider afneemt zoals AWS, die niet bij andere publieke cloud providers zoals Azure en GCP aanwezig zijn. Hierdoor is  men afhankelijk van AWS, aangezien het veel geld gaat kosten om naar een andere publieke cloud provider te migreren. 

Dit is echter een illusie aangezien het “cloud-agnostisch” maken van een architectuur meer tijd en geld kost en betekent dat bepaalde services die veel goedkoper zijn bij een bepaalde publieke cloud provider worden overgeslagen aangezien deze niet aanwezig zijn in een andere publieke cloud provider. Vergelijk maar eens de kosten van AWS RDS met die van AWS Aurora (figuur 3). 

Figuur 3: kostenvergelijking PostgreSQL RDS (Multi-AZ) met Aurora op basis van db.r4.16xlarge op 19-aug-2021

Door een kostenvergelijking te doen kan je een overweging maken of het gebruik van een op het oog lijkende “Vendor lock-in” variant, zoals Aurora aangezien deze alleen in AWS voorkomt ook echt een “Vendor lock-in” is. Misschien kan de PostgreSQL data vrij eenvoudig geëxporteerd worden en vervolgens ingeladen worden in een RDS of PostgreSQL die je “cloud-agnostisch” in een EC2 draait of ergens anders. Nadeel van het zelf draaien is dat je zelf de security updates moet doen en downtime zal hebben als de EC2 herstart. Je kan het natuurlijk ook zelf high-available maken door meerdere lees replica's te gaan toevoegen, maar dit zal allemaal tijd gaan kosten die je beter kan besteden aan het bouwen van features. Kortom, staar je niet blind op het voorkomen van een  “Vendor lock-in” aangezien het “cloud-agnostisch” inrichten van een landschap veel tijd en geld kan kosten.

Technieken om een Vendor lock-in te verkleinen

Wat al enorm helpt om een “Vendor lock-in” te af te wenden is om technieken te gebruiken die in de grootste drie publieke cloud providers toegepast kunnen worden, zoals Docker images, Kubernetes (k8s) en/of OpenShift. Wanneer je een type CaaS gebruikt dat overal verkrijgbaar is dan kan je veel makkelijker migreren. Dit geldt ook voor wanneer je de stap naar de publieke cloud gaat maken. Door te zorgen dat de applicaties on-premise eerst worden gecontaineriseerd en draaien op k8s, dan is de drempel veel lager om van de ene naar de andere cloud te migreren. Wat afwegingen zijn om voor een bepaalde AWS service te kiezen, zullen in een andere blog worden behandeld.

Klant

De klant kan indien deze in AWS Management Console inlogt gebruik maken van verschillende services. Het begint met Identity en Access Management (IAM) waarin de gebruikers worden aangemaakt. In eerste instantie heeft men een root account dat men gelijk van Multi Factor Authentication (MFA) moet voorzien. Met MFA koppelt men een extra apparaat, zoals een mobiele telefoon, waardoor naast het wachtwoord een token dat door de telefoon wordt gegenereerd, ingetoetst moet worden. Het root account is het belangrijkste account en is nodig voor de betalingen. Dit account moet te allen tijde goed beveiligd zijn. Men dient na de eerste keer inloggen gelijk individuele accounts aan te gaan maken voor individuele users en deze ook van MFA voorzien. Verder dient men een password policy aan te zetten en te zorgen dat alleen access keys door de gebruikers worden gebruikt die minimaal een keer per drie maanden vervangen moeten worden. Programmatic users zijn alleen voor bepaalde servers en moeten geen login hebben maar op basis van policies alleen bepaalde zaken kunnen. Zoals gezegd is de klant verantwoordelijk om het veilig in te richten. Om gebruikers te helpen heeft AWS de vijf pilaren van de Well-Architected framework opgesteld. Hier ga ik in mijn volgende blog dieper op in.

Kortom, AWS is ontstaan uit Amazon en is een publieke cloud provider die klanten de mogelijkheid biedt om ontzorgd te worden qua services en hardware. Een klant hoeft geen on-premise cloud vorm te beheren, maar neemt een service af zoals EC2 waardoor men in de cloud VMs kan maken zonder zich zorgen te maken om de onderliggende hardware. Dit houdt niet in dat de klant zelf geen aandacht moet besteden aan security. In het shared responsibility model staat keurig uitgelegd wat de verantwoordelijkheden van AWS en de klant zijn. AWS biedt alle vormen van cloud aan, er zijn inmiddels meer dan 200 diensten en zelf hoef ik nooit meer naar het datacenter om servers te vervangen.

Ben je opzoek naar meer?

Bekijk hier een selectie van onze ebooks.

Businesscase DICTU: 5x sneller releasen in de cloud

Lees hier

Businesscase FWG: migratie naar een Amazon Cloud Platform

Lees hier

Ebook: de bouwstenen van een schaalbaar businessmodel

Download nu