“Als er één ding is dat we weten van IT, is dat het op een bepaald moment zal foutlopen”

Naar de cloud gaan kan eenvoudig, maar ze ten volle benutten vraagt een andere aanpak. Zoals er voor zorgen dat een applicatie ook blijft werken als het ergens misgaat, zegt Sebastien Stormacq van AWS.

Data News spreekt met Sebastien Stormacq, Senior Technical Evangelist bij cloudaanbieder Amazon Web Services (AWS). Hij is daarbij de schakel tussen gebruikers en het productteam. “Enerzijds is mijn rol het ‘onderwijzen’ van klanten over onze technologie. Anderzijds praat ik met hen over hun uitdagingen en die feedback breng ik naar ons productteam. Dat maakt spreken op conferenties zoals Devoxx in België heel interessant voor ons.”

U wou het graag hebben over het omarmen van falen bij het bouwen van infrastructuur. Moeten we er dan niet meer voor zorgen dat iets gewoon goed werkt?

STORMACQ: Het gaat om de mogelijkheid om te blijven werken als iets faalt. Als er één ding is dat we weten van IT, is dat het op een bepaald moment zal foutlopen. Dat kan voorvallen in je netwerk, in de stroom… overal. Maar in de plaats dat je webapp crasht en onbeschikbaar wordt, ga je naar een systeem dat werkt in beperkte modus en zichzelf uiteindelijk herstelt dankzij verschillende technieken op codeniveau. Zoiets maakt apps steviger en veerkrachtig.

De meeste legacy apps zijn niet voor de cloud of voor distributed systems gebouwd, maar eerder voor eentje waar de database er altijd is en in de cloud en on premises is dat niet altijd waar. Daarom moeten we inzetten op beter failure management.

Hoe leer je zoiets aan klanten?

STORMACQ: Veel hiervan hebben we intern geleerd, vaak op de lastige manier. Maar we documenteren best practices als onze teams ze ontdekken en die delen we zo veel mogelijk. In de loop der jaren hebben we best practices verzameld om systemen op zeer grote schaal te laten werken en deze delen we met ontwikkelaars via de Amazon Builder’s Library.

Vermoedelijk doen jullie dat ook omdat AWS infrastructuur aanbiedt die zich flexibel opstelt?

STORMACQ: Er is natuurlijk de veerkrachtigheid van je infrastructuur en met AWS willen we onze klanten een betrouwbaar platform geven. Maar veel ligt ook aan de applicatie. Daar moeten specifieke codes kunnen blijven functioneren.

Op een lager niveau wil dat zeggen dat klanten onze infrastructuur gebruiken voor een highly available architectuur, bijvoorbeeld twee in plaats van één server in de cloud, verspreid over meerdere datacenters. Dan is je infrastructuur gemaakt om te blijven doorgaan in het geval dat een server niet beschikbaar zou zijn. Je legt je eieren in twee mandjes.

Kan u dat iets concreter beschrijven?

STORMACQ: Op applicatieniveau kan je bepaalde dingen vandaag anders doen dan vroeger. Toen ik nog ontwikkelde schreef ik code voor een database. Zodra er iets faalde, werkte ze niet. Vandaag ontwikkel je zodanig dat een app dan pauzeert, opnieuw probeert en vaak zichzelf herstelt. Als dat niet kan, moet er een soort default content of cached content komen, iets om op terug te vallen.

Een mooi voorbeeld daarvan is de homepage van Netflix. Idealiter krijg je daar aanbevelingen op basis van je kijkgedrag en wat er op dat moment trending is. Dat zijn verschillende services in één box. Als één daarvan niet werkt kan het zijn dat je een wit vakje met een foutmelding ziet, of je krijgt cached content. Die zal voor elke gebruiker hetzelfde zijn, maar je krijgt nog altijd iets te zien als gebruiker.

Ik ga hier vloeken in de kerk, maar is het voor veel toepassingen dan niet nuttiger om een public cloud als AWS te combineren met een private cloud on-premise?

STORMACQ: Je kan evenzeer problemen krijgen op je lokaal netwerk hoor. Bij ons loopt de data via verschillende availability zones en je kan je infrastructuur zo ontwerpen dat het atlijd overeind blijft.

Geeft dat geen problemen met latency voor sommige toepassingen? Een andere zone ligt toch al snel een paar honderden of duizenden kilometers verder?

STORMACQ: Dat zijn de regio’s, daar hebben we er 22 van, onder meer in Ierland, Frankfurt, Londen, Parijs en binnenkort Milaan. Maar binnen elke regio hebben we lokale datacenters op een paar kilometer van elkaar.De latency tussen deze lokale data centra is meestal minder dan 10 ms.

U promoot ook graag het gebruik van diensten om te ontwikkelen voor de cloud. Gaat dat heel specifiek, of is het one size fits all?

STORMACQ: Vandaag zijn er zo’n 185 services voor AWS-klanten beschikbaar. Het is zeker geen one size fits all. We bieden trainingsmaterialen aan om klanten te helpen van start te gaan, sommigen ook gratis en per video. En uiteraard hebben we een breed netwerk van partners die klanten kunnen helpen bij het ontwikkelen van oplossingen.

Hoe loopt dat in België? Zijn patronen of de omarming van public cloud al gangbare praktijk hier?

STORMACQ: Belgische klanten gaan naar de cloud zoals anderen. Maar je ziet wel verschillen. In finance zien we bijvoorbeeld sneller de startups voor ons kiezen omwille van de agility en elasticiteit waardoor het makkelijk schalen is. Eén grote Belgische bank, waarvan ik de naam helaas niet kan noemen, werkt wel met ons.

De VDAB gebruikt AWS om met machine learning de beste kandidaten voor bepaalde vacatures te matchen. Ook het Vlaams Agentschap Wegen en Verkeer heeft op AWS een app die alle wegen in kaart heeft en daarop al het materiaal en de defecten aan de weg bijhoudt. Op momenten dat die app niet beschikbaar was, moesten ze terugvallen op pen en papier. Met AWS is er altijd beschikbaarheid.

Naar de cloud gaan is uiteraard makkelijk voor nieuwe projecten. Krijgen jullie ook de oudere toepassingen mee?

STORMACQ: Ja, we zien drie soorten migraties: lift & shift, je neemt je toepassing en brengt ze naar de cloud. Dat is relatief eenvoudig en het voordeel van de cloud is beperkt.

De tweede is refactoring: in plaats van iets zelf te beheren gebruiken ze Amazon RDS, wij beheren de database en de klant moet zelf niet kijken naar back)ups, upgrades en dergelijke.

Het derde type, waar ook nieuwe toepassingen onder vallen, is een herarchitecturering waarbij je cloudtechnologie gaat gebruiken. Bijvoorbeeld je code serverloos laat draaien. Hierbij kom je van een migratie on premise naar een applicatie die gebouwd is voor de cloud.

Voor Aurora, onze relationele database die native cloudtechnologie gebruikt, kent de database de verschillende datacenters en repliceert het de data naar hen zodat er niets verloren raakt. Het is compatibel met mySQL en postgreSQL dus je moet zelf geen code veranderen. We hebben ook een migratie service om ontwikkelaars te helpen over te stappen naar Aurora vanaf je traditionele Oracle database. Vanaf daar kan je schalen, je moet ook geen extra opslag voorzien waar je dat in een traditionele omgeving wel moet doen.

Recent zijn we trouwens met Amazon.com (waaronder de webwinkel, de streamingdienst enz… vallen, nvdr.) volledig afgestapt van Oracle. Daarbij hebben we 1.600 instances naar een nieuw platform gebracht. Soms naar Aurora, soms mySQL of noSQL, afhankelijk van de app.

Oracle-oprichter Larry Elisson benadrukte maar al te graag dat Amazon niet zonder Oracle-technologie kon. Ik veronderstel dat jullie dit gaan gebruiken om klanten te overtuigen dat het even goed kan op AWS-technologie?

STORMACQ: Dat is inderdaad de boodschap. Als een grote en complexe organisatie als Amazon zonder Oracle kan, dan kan een andere organisatie het ook. Het vraagt veel werk en het is niet altijd makkelijk. Maar het kan wel degelijk.

En omgekeerd, hoe makkelijk is het om van AWS Services weer af te stappen? Als een bedrijf hun specifieke workload naar Azure of Google Cloud wil? Of ze weer on premise wil brengen?

STORMACQ: Die vraag krijgen we van veel klanten en ze moeten dat ook vragen. Klanten van AWS blijven hun data bezitten. Het is hun eigendom en ze moeten die kunnen verplaatsen.

We gebruiken daarvoor veel technologie die standaard is op de markt. Zo werkt een tool om data in en uit mySQL te verplaatsen ook met Aurora. Voor applicaties werkt het hetzelfde als met Linux of Windows in je eigen datacenter. Er is geen lock-in, klanten kunnen hun data naar en van ons verplaatsen. Ze betalen enkel voor wat ze gebruiken, stop je met gebruiken, dan stop je ook met betalen.