Als developer advocate van ontwikkelaars spreek ik vaak met leidinggevenden in het bedrijfsleven en de publieke sector over hun strategie om naar de cloud over te stappen. Deze gesprekken zijn altijd interessant, maar wanneer ze overgaan op het kiezen van cloudproviders, heb ik opgemerkt dat ze de ‘veilige’ weg kiezen en de werklast gelijkmatig verdelen over twee of drie providers. Maar wanneer het gesprek gaat verder in detail gaat over hoe dit in de praktijk zal werken, komen er veel vragen over het kiezen van deze aanpak. Waarom dit niet praktisch is en wat een betere manier is om workloads te beheren, leg ik graag verder uit.
Laten we eerst bespreken waarom het niet ideaal is om jouw workload ‘gelijkmatig’ te verdelen over verschillende cloudproviders. In theorie klinkt het als een veilige en risicomijdende aanpak om naar de cloud te migreren – kies twee of drie cloudproviders en verdeel je workload over deze allemaal. De fundamentele veronderstelling hierbij is dat alle cloudproviders op hetzelfde niveau zitten als het gaat om serviceproviders, softwareontwikkelaars, oplossingen, systeemintegrators en meer. Dit dwingt je om workloads te standaardiseren op de kleinste gemene deler in plaats van te optimaliseren voor een enkele provider van jouw keuze. Stel je jezelf eens voor dat je alle tijd besteedt aan het configureren van servers, monitoringsystemen, logboekregistratie en beveiligingsmechanismen bij verschillende cloudproviders en vervolgens orkestreert hoe ze allemaal samenwerken. Dit kost veel tijd die je liever gebruikt om je te kunnen focussen op het bouwen van jouw kernproduct, om nog maar te zwijgen van de mate van complexiteit die het met zich meebrengt.
Iets dat ik heb geleerd uit mijn jaren ervaring van werken in dit vakgebied: het is erg moeilijk om technici te vinden die experts zijn in meerdere cloudplatforms. Functiebeschrijvingen die expertise in 20 verschillende technologieën vragen, blijven het langst open staan. Dit betekent het inhuren van specialisten voor elke cloudprovider die je van plan bent te gebruiken. Het engineeringteam neemt in omvang en complexiteit toe naarmate je de workload naadloos probeert te laten werken bij meerdere cloudproviders. Ontwikkelteams hebben een hekel aan deze aanpak en het leidt uiteindelijk tot een verspilling van middelen om nog maar te zwijgen van het verhogen van de stressniveaus van de CIO. Over resources gesproken, elke cloudprovider heeft kortingen op volume. Hoe meer middelen je gebruikt, hoe minder je uiteindelijk per eenheid betaalt. Door de workload te spreiden, verlies je de mogelijkheid om koopkracht te krijgen in termen van deze volumekortingen.
Het denkproces achter het gelijkmatig verdelen van de workload is om risico’s te beperken, maar dit is uiteindelijk een verkeerde aanpak. In de jaren 90, toen je de client-serverstrategie aan het implementeren was, selecteerde je toen twee tot drie databaseproviders en gebruikte je ze allemaal om het risico te verkleinen? Mijn gok is dat je hebt gekozen voor een enkele databaseprovider na zorgvuldige evaluatie van je opties. Dit is analoog aan het kiezen van een cloudprovider. Soms hebben klanten het gevoel dat er daarnaast ook andere risico’s zijn:
- Wat als mijn cloudprovider failliet gaat? Gezien de wereldwijde toename van cloudadoptie, is dit scenario hoogst onwaarschijnlijk. Kies jouw cloudprovider door verstandig te kijken naar de operationele ervaring, de breedte en diepte van services, de wereldwijde infrastructuur ‘footprint’ en het ecosysteem eromheen.
- Hoe zit het met het risico dat mijn cloudprovider de kosten verhoogt? Kijkende naar Amazon Web Services (AWS), hebben we de kosten juist 107 keer verlaagd sinds de lancering in 2006.
- Hoe zit het dan met de kosten van migratie? Ja, er zijn kosten verbonden aan migratie en het is prima om een noodplan te hebben om uit jouw cloudprovider te migreren. Maar deze migratie heeft alleen zin als de voordelen veel groter zijn dan de gemaakte kosten.
Dus, hoe besluiten ondernemingen hun werklast te spreiden? Doen ze gewoon hun due diligence en gaan ze dan all-in voor één enkele cloudprovider? Nou, ja en nee. Van wat ik heb gezien, kiezen alle klanten voornamelijk voor één enkele cloudprovider voor hun workloads. Sommige klanten gaan all-in en sommige kiezen een secundaire provider om een klein deel van hun workloads uit te voeren. Dit kan om verschillende redenen zijn: om ervaring op te doen, om prijs- en prestatievergelijkingen te zien, en ook gewoon zodat ze weten dat ze het kunnen. Met de flexibiliteit en het gemak waarmee de cloud kan beginnen, wordt dit een steeds vaker voorkomende benadering van migratie vanuit on-premise datacenters.
Cloudproviders hebben deze voorkeur voor meerdere cloudproviders opgemerkt en maken het nu gemakkelijker om workloads op verschillende plaatsen te creëren en te laten werken. AWS heeft bijvoorbeeld services om containerclusters te creëren en te exploiteren, zowel on-premises als bij andere cloudproviders. Dit betekent dat je containers nu op verschillende cloudplatforms en on-premise kunt uitvoeren, met één beheerpaneel. Hierdoor is het voor het engineering- en DevOps-team niet nodig om meerdere domeinen en vaardigheden te leren en om complexe software zelfstandig te kunnen beheren.
Persoonlijk vind ik deze gesprekken met CIO’s over hun strategie om naar de cloud te verhuizen erg leuk. Een rode draad die ik terugzie in deze bijeenkomsten is het hebben van keuzevrijheid als het gaat om cloudaanbieders. Dit is begrijpelijk, aangezien de geschiedenis van IT vol staat met voorbeelden van leveranciers die misbruik maken van hun klanten met beperkende licenties en prijsverhogingen. Ik zeg vaak: “geen twee workloads zijn hetzelfde” en de cloud heeft een nieuw tijdperk ingeluid waarin je de vrijheid hebt om te kiezen hoe je je workload precies wilt uitvoeren.
Sohan Maheshwar is Senior Developer Advocate bij AWS
