Leestijd: 9 minuten
Afhankelijk van wie je gelooft, bereikt de hype rond de cloud de "piek van opgeblazen verwachtingen" (waar vroege succesverhalen veel aandacht van de media en de sector trekken), of glijdt het snel af naar de "trog van desillusie" (waarbij vroege implementaties niet voldoen aan de verwachtingen en de sector een begin maakt in de evaluatie van hun aanpak). En om dat nog ingewikkelder te maken, plaatst Gartner momenteel geavanceerde Cloud-services zoals ‘serverless computing’ op de opwaartse helling van de hype-cyclus. En welke van opties ook waar is, organisaties vallen over zichzelf heen om te verklaren dat ze voorop lopen in hun ‘Cloud-first-strategie’.
Gartner voorspelt dat in de loop van het jaar “90 procent van de organisaties een postmoderne strategie voor de integratie van applicaties en uitvoeringscapaciteit zal missen, resulterend in problemen met integratie, grotere complexiteit en hogere kosten”. Ervaringen uit de praktijk lijken de conclusie van Gartner te bevestigen, vooral omdat er ernstige verwarring lijkt te bestaan over wat 'Cloud First' eigenlijk betekent op het gebied van strategie. En als ze voor het eerst Cloud computing gebruiken, gaan de meeste organisaties ervan uit dat het eenvoudigweg repliceren van hun bestaande infrastructuur in de AWS-omgeving, de praktische invulling van hun strategie is. Maar deze organisaties zijn nog ver verwijderd van het realiseren van de volledige operationele en financiële voordelen van de cloud.
Naar onze mening zijn er vier fasen in de typische reis naar het bouwen van een echt duurzame IT-infrastructuur in AWS. In welke fase zit jouw organisatie momenteel?
Fase één: het repliceren van IT in de cloud
Zoals eerder vermeld, richten initiële cloudimplementaties zich op het proberen te repliceren van hun On-Premise infrastructuur op het AWS-platform. Het is begrijpelijk dat velen denken dat dit ook het einde van het proces is; niet alleen zijn ze nu trotse 'eigenaren' van een enorm vertrouwd platform dat ze van binnen en van buiten begrijpen, maar ze lossen tegelijkertijd ook een van hun meest urgente problemen op; beperking van de capaciteit van het platform.
Organisaties kunnen jaren in deze eerste fase doorbrengen en simpelweg opschalen naarmate de vraag naar resources toeneemt. En omdat alles zo vertrouwd is, kunnen ze volgens het DevOps-model gewoon doorgaan, waarbij ze hetzelfde niveau van productiviteit en efficiëntie behouden waar ze altijd al van genoten hebben. Maar als een organisatie in dit vroege stadium van zijn Cloud-first-strategie blijft hangen, kan het zijn dat vroege successen niet worden overgedragen naar de toekomst.
Fase twee: herbouwen en automatiseren
Ook bekend als de "Wat is er gebeurd met de kostenbesparingen die zijn beloofd?" fase, wordt fase twee normaal gesproken alleen geïnitieerd wanneer de financieel directeur of CFO moeilijke vragen begint te stellen. Hoewel de organisatie mogelijk de kapitaaluitgaven aan hardware heeft teruggeschroefd, blijven Cloud-kosten oplopen, en niemand weet precies waarom.
Het probleem is dat de onbegrensde schaalbaarheid van AWS onvoorziene problemen kan veroorzaken voor onervaren Cloud-ontwikkelaars en systeemingenieurs. Ontwikkelaars kunnen zo veel AWS-services gebruiken als ze willen, maar ze worden gefactureerd op basis van pay-as-you-use. Dat betekent dat veel gebruikers een groot aantal AWS-bronnen inefficiënt of onnodig toewijzen.
Het is geen toeval dat Gartner's "trog van desillusie" samenvalt met organisaties die in fase 1 problemen tegenkomen, waardoor een herevaluatie wordt afgedwongen van de implementaties en strategie van de cloud. Zoals David Stanley, hoofd van platformdelivery bij Trainline, zei over de AWS-ervaringen van zijn bedrijf: "De grootste culturele verandering, nadat je al je DevOps-wijzigingen hebt doorgevoerd, is om je te gaan richten op kosten."
Onder de druk door een zware afkeuring van de financiële afdeling, begint de IT-afdeling met het herdesign van systemen om ze af te stemmen op de verschillende regels waarmee AWS-kosten worden bespaard. Door bijvoorbeeld gebruikers en groepen te creëren, kunnen ze bepalen wie toestemming heeft om AWS-resources aan te vragen. Systemen worden hierdoor onmiddellijk efficiënter in termen van doorloop en kosten.
Naarmate hun ervaring met cloud-technologieën groeit, verhogen ontwikkelaars ook het automatiseringsniveau dat wordt gebruikt. Als voorbeeld, in een terugkeer naar de batch-verwerkingsprincipes van het verleden, zullen virtuele machines geactiveerd worden tijdens de daluren om de operationele kosten te verlagen. Met de AWS Auto Scaling-functie kunnen ontwikkelaars het schalen van resources beperken op basis van een vooraf gedefinieerde planning, zodat resources beschikbaar zijn op basis van de voorspelbare vraag en buiten die uren worden afgeschaald om uitgaven te beperken.
Met platformen die opnieuw zijn ontworpen voor de cloud, en automatisering die wordt gebruikt om de activiteiten te stroomlijnen, zal de financiële afdeling veel gelukkiger zijn als de facturatie weer onder controle komen. De uitgaven kunnen nog steeds stijgen, maar dit rationalisatieproces zorgt ervoor dat de kosten beter worden ingeperkt en volledig kunnen worden gerechtvaardigd.
Fase drie: Containerisatie
Hoewel de AWS-kosten nu onder controle zijn, gebruikt de gehoste infrastructuur nog steeds relatief veel resources als het gaat om beheer. Aan het einde van fase twee bevinden applicaties zich nog steeds in virtuele machines die zijn geïnstalleerd in een hypervisor, die zelf boven op de AWS-laag staat. Veel van deze gevirtualiseerde systemen zullen worden ingesteld om nooit meer naar te kijken, maar dat is eigenlijk zonde van de tijd en moeite om ze te configureren op het moment van implementatie. Daarnaast zijn er soms ook grote configuratiewijzigingen nodig, en wordt van de IT-afdeling verwacht dat zij dat werk uitvoeren om ervoor te zorgen dat de systemen blijven werken zoals verwacht.
Met de installatie van applicaties, bestanden en library’s, gast-besturingssystemen en een hypervisor bovenop het host-besturingssysteem, zijn er meerdere niveaus die moeten worden beheerd. Hier begint fase drie, met als doel de applicatiearchitectuur te vereenvoudigen, beheer te versimpelen en het gebruik van cloud-resources te beperken.
Met behulp van een container-engine zoals Kubernetes of Docker die direct op een gastbesturingssysteem is geïnstalleerd, kunnen ontwikkelaars applicaties opnieuw opbouwen zonder de noodzaak van een hypervisor of virtuele machine. Code wordt gecompileerd en uitgevoerd in een "container", die niets meer bevat dan de ‘afhankelijkheden’ die voor de toepassing zijn vereist. Dit biedt verschillende voordelen:
- De gecontaineriseerde applicatie is minder zwaar, dit helpt in vermindering van benodigde resources en dus kosten.
- De applicatie wordt portable, zodat deze met minimale inspanning opnieuw kan worden opgezet op een ander Cloudplatform.
- Ontwikkelaars kunnen zich volledig richten op het bouwen van een applicatie of dienst, zonder zich zorgen te hoeven maken over het besturingssysteem of andere secundaire factoren die het proces bemoeilijken.
- Doordat er minder lagen te beheren zijn, zijn beheerders en ontwikkelaars vrij om zich te concentreren op andere strategische projecten.
En als bonus helpt dit in een verdere vermindering van de behoefte aan resources om ook de AWS-kosten verder te verlagen, wat nog minder gedoe met de financieel directeur of CFO betekent.
Fase Vier: Echte serverless computing
Tegen het einde van Fase drie zijn de AWS-computerresources drastisch gestroomlijnd, waardoor de footprint en de bedrijfskosten van de applicaties zijn verminderd en de portibiliteit van code is toegenomen. Ook nu is de verleiding groot om aan te nemen dat het migratieproces van de Cloud compleet is, maar zijn er nog meer verbeteringen aan te brengen.
Op dit moment worden applicaties ingebouwd in zelfstandige containers, maar het Docker-platform waarop ze zijn gebouwd, verbruikt nog steeds resources binnen het AWS-datacentrum. In veel gevallen draaien ontwikkelaars complete virtuele machines in hun containers. Dit is niet noodzakelijk een slechte zaak, maar applicaties kunnen nog verder worden gestroomlijnd, wat op zijn beurt de ontwikkelingsinspanningen en -kosten beperkt.
Een groter probleem is dat door het behoud van een OS in de container, de omgeving dezelfde administratieve en beveiligingsoverhead behoudt. Aanvankelijke inspanningen kunnen zorgen voor een grotere dichtheid van virtuele machines, maar behoud van het besturingssysteem in een container doet weinig om de complexiteit van het onderhoud te verminderen - en de algemene kosten te beheersen.
De laatste fase van de Cloud-first-migratie is het ontwikkelen en implementeren van "serverloze" applicaties. Zoals de naam al aangeeft, zijn deze applicaties ontworpen om de afhankelijkheid van Kubernetes-, Docker- en AWS-servers zo veel mogelijk te verminderen. In plaats van te putten uit volledig gecompileerde applicaties en virtuele machines, worden serverloze applicaties gebouwd met behulp van gecontaineriseerde bibliotheken en binaire bestanden die worden gehost op Amazon ECS en gekoppeld aan API’s op de public cloud.
Simpel gezegd nemen serverloze applicaties de bouwstenen van verschillende online diensten en "lijmen" ze samen in AWS Lambda. In feite profiteren fase 4-applicaties van "Function as a Service" om kosten en overheadkosten te verlagen.
Deze applicaties zijn nog steeds oneindig schaalbaar, maken gebruik van resources van derden indien nodig, maar hebben een minimale lokale footprint. Het op deze manier koppelen van diensten verhoogt de ontwikkelsnelheid en vermindert het beheersniveau dat nodig is om de updates van de gebruikte services te verwerken.
En omdat de nieuwe applicaties afhankelijk zijn van SaaS-diensten die door derden worden geleverd, is er geen noodzaak (of functie) om de configuratie van componenten zoals httpd of MongoDB aan te passen, want deze functies worden afgehandeld door de externe partij. Er zal altijd een operationele overhead voor cloud-gebaseerde applicaties zijn, maar door de infrastructuur en OS-verantwoordelijkheden uit te besteden aan externe serviceproviders, worden de interne bedrijfskosten nog verder verlaagd.
Tijd om je voortgang te beoordelen
Met de Cloud-first journey in kaart gebracht, wordt het veel makkelijker om te beoordelen wat jouw organisatie tot nu toe heeft bereikt. Veel late gebruikers zullen zich nog steeds in fase één bevinden, wat betekent dat ze nog behoorlijk wat stappen moeten zettten. De meerderheid van de organisaties heeft fase twee echter bereikt, waarbij wordt onderzocht hoe de cloudinfrastructuur het best kan worden gebruikt om hun eigen activiteiten te verbeteren.
Cloud computing is een dramatische verschuiving in het gebruik van de IT en velen zijn nog steeds op de zoektocht hoe ze optimaal kunnen profiteren van de voordelen die AWS biedt. Het tekort aan vaardigheden wordt nog verergerd door het snelle tempo van de ontwikkeling van het AWS-platform, dus het is niet echt verrassend dat bedrijven moeite hebben om hun doelstellingen op gebied van ‘Cloud-first’ te bereiken. Vooral als echte Cloud-first-strategie nog steeds slecht wordt begrepen.
Meer weten?
Claranet is een actief lid van het Amazon Partner Network en heeft zowel de status van Premier Consulting Partner als de Managed Service Provider verkregen. Op 31 mei was Claranet aanwezig als partner bij de AWS Summit Benelux in Den Haag. Mocht je het event gemist hebben, maak dan een afspraak met onze AWS specialisten via onderstaand contactformulier.