Volledige cloudkostenbesparingen met tools? Denk nog eens na

Cloud Migratie

De eerste blog in deze tweedelige serie beschreef hoe tools een kans kunnen bieden om kosten van cloud economics te besparen. Maar hoewel veel organisaties zich ervan bewust zijn dat ze hun uitgavenpatroon voor de cloud moeten verbeteren, lijkt het proces dat nodig is om daar te komen vaak exorbitant, waardoor ze de veranderingen die nodig zijn om hun clouduitgaven om te buigen, links laten liggen. Deze blog wil laten zien dat de tijd en middelen die met de uitvoering gemoeid zijn, bedrijven er niet van moeten weerhouden de nodige veranderingen door te voeren.

Van inzicht tot proces, deze twee bedrijven ontdekten dat het inhuren van een partner om hen te begeleiden bij het werk dat nodig was om hun cloudkosten te transformeren, op een manier die was aangepast aan hun behoeften, het verschil maakte om ervoor te zorgen dat ze niet alleen doorgingen met het uitvoeren van een actieplan, maar hen ook een succesvol resultaat te geven.

Een internationaal telecommunicatiebedrijf heeft zijn volledige infrastructuur gemigreerd naar de publieke cloud (AWS en Azure) en maakt gebruik van een broker richting AWS en Microsoft, die contractbeheer en basisbeveiligingsdiensten uitvoert. Voor beide providers is een System Integrator (SI) gecontracteerd om managed services (IM en TAM) bovenop de cloudproviders te leveren.

Tijdens de migratie stegen de cloudkosten boven de beschikbare budgetten die op basis van het advies van de SI’s waren vastgesteld. Tijdens de migratie richtten de SI’s zich op de projectdeadlines in plaats van te optimaliseren en te besparen op wat er al in de cloud draaide. Het telecommunicatiebedrijf wendde zich tot IDC Metri voor onafhankelijk advies over kostenbesparingen in de cloud, zogenaamde cloud economics.

IDC Metri heeft geholpen bij het verbeteren van tooling, en bij het definiëren van processen en werkwijzen, zodat dit telecommunicatiebedrijf zelf cloudkosten kan analyseren en beheren en beter kan inspelen op de veranderingen in cloud economics. IT-leiders kunnen uit hun ervaring leren dat aanbevelingen van tools, waaronder die van cloudaanbieders, niet altijd realistisch zijn. Ze zijn vaak opportunistisch, zoals suggereren dat alle instanties voor drie jaar moeten worden gereserveerd, en dat dit meer dan 50% van de kosten voor die instanties zal besparen. Dat is hetzelfde als verwachten dat uw IT-landschap hetzelfde blijft binnen die tijd – dit is gewoon niet waar.

PostNL was een van de eerste beursgenoteerde bedrijven in Nederland die ‘all in’ ging naar de publieke cloud, te beginnen in 2012. Tegenwoordig bevindt PostNL zich in de tweede fase van de transformatie van al zijn maatwerkapplicaties van IaaS naar PaaS-oplossingen, zoals BI/Analytics-platforms, containerplatforms en serverless computing. In vergelijking met IaaS zijn de prijsmodellen voor PaaS meer gebaseerd op gebruik dan op capaciteit. Kosten besparen op op gebruik gebaseerde geprijsde diensten betekent het optimaliseren van de software, in plaats van de onderliggende infrastructuur.

In tegenstelling tot het anonieme internationale telecommunicatiebedrijf in ons voorbeeld, heeft PostNL geen SI’s tussen hen en de cloudproviders die managed services aanbieden. De applicatieteams, voornamelijk gebaseerd op DevOps, beheren de cloudinfrastructuur zelf. Ook hier hadden de cloudkosten een stijgende lijn, waarvan PostNL IDC Metri heeft gevraagd deze om te buigen.

IDC Metri heeft aanbevelingen gedaan, die veel minder ondersteund werden door tools, omdat deze zich richten op IaaS, in plaats van PaaS. Met de top 10 teams wat betreft kosten is afstemming gedaan over besparingen, wat heeft geleid tot ongeveer 8% besparing. Een weetje hierbij is dat grootschalige optimalisaties, zoals het toepassen van besparingsplannen, al door PostNL zelf waren gedaan. De besparingen die IDC Metri heeft helpen realiseren waren meer op architectuur en licenties.

Concluderend kan gesteld worden dat het gebruik van tools die aanbevelingen genereren slechts het startpunt is voor het realiseren van besparingen. Allereerst moeten de aanbevelingen met een korreltje zout worden genomen, omdat ze vaak nogal opportunistisch zijn. Bovendien is een lijst van aanbevelingen één ding, het daadwerkelijk realiseren van besparingen, het overwinnen van onverschilligheid of zelfs weerstand om kosten te besparen, is een ander ding. IDC Metri ondersteunt het volledige proces, van het analyseren van de kosten via het opzetten van processen tot het daadwerkelijk realiseren van besparingen.

Wil je meer weten?

Vul onderstaand formulier in om zelf een afspraak in te plannen voor een vrijblijvend gesprek. Kom je er niet uit? Bel ons dan op 020 655 1777.

Cijfers zeggen alles… of niet?

Het is alweer even geleden dat het Nederland mannenelftal onderuit ging op het EK Voetbal. Een nederlaag die gevolgen had voor de bondscoach Frank de Boer.

In één van de vele artikelen die aan dit onderwerp gewijd zijn, stond een interessant zinnetje: Frank de Boer heeft in 15 wedstrijden 28 punten gehaald, en Ronald Koeman in 20 wedstrijden 38 punten. Ofwel een gemiddelde van 1,87 punten per wedstrijd tegen 1,9. Puur cijfermatig is er nauwelijks verschil tussen beide coaches, maar de beeldvorming over Frank de Boer is totaal anders dan die over Ronald Koeman. Is dat terecht of niet?

Als je een oordeel velt op basis van cijfers, dan moet je ook de juiste cijfers erbij betrekken. In dit geval ga je dus niet alleen af op het aantal punten per wedstrijd, maar ook op de tegenstanders waartegen werd gespeeld. Nu is dat laatste lastig in cijfers te vangen, maar de FIFA doet een poging met een wereldranglijst waarin punten worden toegekend o.b.v. prestaties. Laten we die er eens bij pakken. Dan zien we dat Noord Macedonië op het moment van de wedstrijd 1374 punten had (nr. 62 op de wereldranglijst) en Duitsland op 6 september 2019 (4-2 winst in Hamburg, weet u het nog?) 1582 punten (nr. 16).

Als we die cijfers erbij trekken, dan zien we dat de tegenstanders van Nederland onder Frank de Boer gemiddeld 1420 punten hadden, en onder Ronald Koeman 1532 punten. Als je kijkt naar de huidige FIFA wereldranglijst (27-5-2021), dan is dat het verschil tussen de plaatsen 50 en 23, ofwel de categorie Noord Ierland, Griekenland en IJsland (allen niet op het EK) versus Polen, Oostenrijk en Oekraïne (allen wel op het EK). Vanuit die optiek moet de prestatie van Ronald Koeman dus wel degelijk hoger worden aangeslagen dan die van Frank de Boer. En daarmee zou de beeldvorming (in ieder geval deels) terecht zijn.

Nu is voetbal natuurlijk veel meer dan cijfertjes alleen. Gelukkig maar, anders was er, letterlijk, geen bal aan. En het doel van dit blog is niet om een oordeel te vellen over bondscoaches of voetbal in het algemeen. Daar zijn tientallen tijdschriften, kranten, tv-programma’s, blogs en ik weet niet wat voor. Het doel is wel om het belang aan te geven dat de juiste cijfers worden gebruikt, en de juiste duiding wordt gegeven aan deze cijfers.

Als bijvoorbeeld een kostenvergelijking wordt gemaakt tussen de huidige manier van werken (Current Mode of Operations, ofwel CMO) en de toekomstige manier van werken (Future Mode of Operations, ofwel FMO), dan is het van belang dat alle cijfers aan beide zijden worden meegenomen. Het is maar al te vaak dat vanuit politieke motieven cijfers die onwelgevallig zijn worden weggelaten.

Bijvoorbeeld: transitiekosten. Tegenstanders van een transitie halen deze kosten aan om aan te tonen dat de FMO duurder is dan de CMO. Maar ze vergeten dat sowieso de CMO niet eeuwig kan blijven voortbestaan. Apparatuur in een datacenter heeft niet het eeuwige leven en zul je ook moeten vervangen, en die kosten zul je ook moeten meenemen. Hetzelfde geldt voor software. Er is bij software dan weliswaar geen sprake van fysieke slijtage, maar functionaliteit, eisen aan de onderliggende infrastructuur, veiligheid, support door de leverancier enzovoort verouderen wel. Ooit zul je de software moeten vervangen.

Ander voorbeeld: baten. Voorstanders van een transitie halen graag de baten erbij om aan te tonen dat de FMO echt het Walhalla is. Met een beetje mazzel dekken de baten zelfs de transitiekosten. Ben je gelijk van het gezeur uit het vorige voorbeeld af. Maar als je dan naar de cijfermatige onderbouwing gaat kijken, dan is die niet altijd even sterk. Soms worden er percentages of bedragen als uitgangspunt genomen op basis van toezeggingen van leveranciers of andere vormen van wensdenken.

Of worden er besparingen ingeboekt, waarvan niet duidelijk is wie er nu verantwoordelijk voor is. Bijvoorbeeld: een applicatie wordt uitgefaseerd onder verantwoordelijkheid van de eigenaar zelf, dus buiten het transitieprogramma. Als die eigenaar blijkt geen budget te hebben, of zijn gebruikers willen niet, of wat dan ook, dan kan dat zomaar op losse schroeven komen te staan. Best vervelend als je hele business case erop is gebaseerd dat je het datacenter per datum X had willen sluiten, en dat dat dus niet gaat.

Zo zijn er nog legio voorbeelden te bedenken. Waar het om gaat is, dat als je beslissingen gaat nemen op basis van cijfers, dit doet op basis van de juiste cijfers. Metri is als geen ander in staat om de juiste cijfers te achterhalen, en die af te zetten tegen dat wat gebruikelijk is in de markt. Zo zie je waar de sterke en zwakke punten zitten in de onderbouwing, en neem je de juiste beslissingen. En daar is uiteindelijk iedereen bij gebaat.

Wil je meer weten?

Vul onderstaand formulier in om zelf een afspraak in te plannen voor een vrijblijvend gesprek. Kom je er niet uit? Bel ons dan op 020 655 1777.

Inzicht is goed, besparen is beter

Cloud Econimics

Je ziet het regelmatig op de televisie: programma’s over mensen die het financieel lastig hebben. Ze komen aan het einde van de maand geldtekort, ze krijgen hun huis niet verkocht, ze hebben een problematische schuldenlast: er komt van alles voorbij. Een gemene deler is dat vaak het inzicht ontbreekt in de eigen situatie, en dat het bedenken van besparingen niet heel ingewikkeld is, maar het doorvoeren en vooral volhouden ervan lastiger is. Ik bedoel: je kunt als buitenstaander makkelijk vinden dat iemands hond de deur uit moet, maar als deze zijn of haar enige afleiding is, dan kost het op z’n minst moeite.

Hetzelfde geldt voor cloudkosten: besparen is gemakkelijker gezegd dan gedaan. Om de kosten in beeld te krijgen, zijn er allerlei prachtige tools beschikbaar, van cloudproviders zelf en van derde partijen. Deze tools geven allerlei rapportages en dashboards, en zelfs aanbevelingen over welke instances je kunt weghalen of verkleinen/vergroten (rightsizing). Met de juiste kennis kun je ook bepalen hoe je kortingsmogelijkheden (reserved instances, savings plans, reserved capacity etc.) kunt inzetten, hoe je slim omgaat met licenties en wat je in je applicatie-architectuur kunt doen om kosten te besparen. En je kunt natuurlijk instances uitschakelen op momenten dat je ze niet gebruikt.

Al dat inzicht is natuurlijk mooi. Maar dan komt deel twee. Net als mensen die moeite hebben om afscheid te nemen van hun viervoeter, hebben ook gebruikers en beheerders moeite om hun oude gewoonten en denkwijzen af te schudden. En daar hoor je de cloudproviders nooit over.

Neem bijvoorbeeld het buiten werktijden uitschakelen van instances. In theorie is dat een uitstekende besparing, maar instances zijn onderdeel van applicaties, die op hun beurt weer onderdeel zijn van ketens. En dan kan het zomaar zo zijn dat er buiten werktijden data-uitwisseling plaatsvindt in een keten. Maar ook testteams die tegen een deadline aan zitten kunnen hun omgeving nog wel eens nodig hebben buiten de vooraf bedachte werktijden. En als omgevingen worden gebruikt in de beheerketen moeten ze in geval van nood ook na werktijd beschikbaar zijn. Zo zijn besparingen in theorie eenvoudig, maar is de praktijk weerbarstiger. Het kan, maar je moet er heel wat voor doen.

Ook rightsizing is minder eenvoudig dan het lijkt. Vaak zijn gebruikers en beheerders huiverig voor het wegnemen van capaciteit: gebruikers zien hun performance dalen, en beheerders zien het risico dat er meer storingen komen omdat er minder overcapaciteit is om issues op te vangen. In dat laatste geval moet je goed analyseren waar deze issues vandaan komen: een matige applicatie kan profiteren van meer capaciteit, maar dat is geen langetermijnoplossing. Als het dak lekt, kun je de emmer om het water op te vangen vervangen door een speciekuip, maar ook die raakt op een gegeven moment vol. Uiteindelijk zul je toch het dak moeten repareren.

Zo zijn voor alle soorten besparingen bezwaren aan te voeren. Uiteindelijk zul je toe moeten naar een werkwijze waarbij je niet alleen de kosten inzichtelijk maakt, maar ook gebruikers en beheerders betrekt, en zo komt tot de juiste afwegingen om op sommige plaatsen wel, en op andere plaatsen juist niet te besparen op je cloudkosten.

Heb je geen idee waar je moet beginnen? Kom je er zo snel niet uit? Metri heeft al verschillende organisaties op weg geholpen. Onze specialisten kunnen je helpen de besparing op cloudkosten een kickstart te geven. Want inzicht in de kosten is één ding, je hebt er pas iets aan als deze daadwerkelijk afnemen.

Wil je meer weten?

Vul onderstaand formulier in om zelf een afspraak in te plannen voor een vrijblijvend gesprek. Kom je er niet uit? Bel ons dan op 020 655 1777.

Wat hebben laadpalen en de public cloud met elkaar gemeen?

Sinds een aantal maanden ben ik de berijder van een elektrische auto. Omdat de zomervakantie in deze periode viel zijn we ook voor het eerst met een elektrische auto op vakantie geweest, naar het buitenland nog wel.

Het rijden ging prima, maar het laden ervoer ik toch wel als een nadeel. Niet zozeer de aanwezigheid van voldoende laadpalen, de laadtijden (leve 350kW snelladers) of het bereik van de auto (350km snelweg met dakkoffer), maar het gedoe met laadpassen.

Als voormalig dieselrijder was ik gewend om een tankstation binnen te rijden, bij de ingang te zien staan wat een liter diesel me zou gaan kosten, vervolgens te tanken en af te rekenen met de pinpas of creditcard. Gewoon getankte liters maal de literprijs.

Met een elektrische auto werkt dat helaas anders. Niet alleen moet je meerdere laadpassen hebben om overal te kunnen laden, je moet ook kijken welke laadpas welke prijs geeft bij welk laadpunt, aangezien dit per laadpas verschilt. Een bord met kWh-prijzen zul je vergeefs zoeken, en in de praktijk zit je in allerlei apps te zoeken wat je betaalt met welke pas. Lang niet alle laadpalen hebben een scherm waarop staat hoeveel kWh je hebt afgenomen. Feitelijk weet je pas echt waar je aan toe bent als je de rekening krijgt.

Dat deed mij denken aan waar veel van onze klanten tegenaan lopen bij het gebruik van public cloud. Prijzen voor dezelfde typen resources (bijvoorbeeld virtual machines) verschillen per regio: meestal zijn ze in Dublin goedkoper dan in Amsterdam of Frankfurt. Verder zijn er allerlei kortingen mogelijk met enterprise discounts, savings plans, reserved instances enzovoort, waarbij per type resource en licentie verschillende voorwaarden gelden. In het ene geval kun je van regio en grootte wisselen, in het andere geval juist niet. Bovendien zijn de prijzen en voorwaarden niet vast, maar worden ze regelmatig aangepast. Typen resources worden opgevolgd door nieuwere typen met een betere prijs-prestatieverhouding, soms wel 40%. Ook hier zien veel van onze klanten pas waar ze aan toe zijn als de rekening van de cloudprovider komt.

Op vakantie heb ik uiteindelijk maar één laadpas gebruikt, die lang niet altijd de goedkoopste was, maar wel op vrijwel alle laadpunten werkte. Dat heeft me ongetwijfeld extra geld gekost, maar meer dan een paar tientjes is dat niet geweest. In relatie tot de kosten van de totale vakantie viel het reuze mee en bovendien was het eenmalig.

Voor gebruikers van public cloud is het echter minder luchtig. Het gaat niet om eenmalig een paar tientjes, maar om tien- of honderdduizenden euro’s, iedere maand weer. Het is niet voor niets dat we bij Metri vragen krijgen om te helpen met het in de hand houden van de cloudkosten.

En dat kunnen we. We helpen u niet alleen bij het omlaag brengen van de kosten, maar ook met het zelf onder controle krijgen en houden daarvan. We doen dat in twee stappen. In de eerste stap brengen we de kosten in beeld met eigen tooling, of de tooling die u zelf inbrengt. We analyseren waar de meeste kosten zitten en definiëren mogelijke maatregelen die tot besparingen leiden.

We zien namelijk dat bij migraties klassieke oplossingen één op één worden omgezet naar de public cloud, waar er met relatief weinig inspanning een efficiëntere oplossing is. Verder hebben we kennis van de kostenmodellen van Microsoft Azure en AWS, waardoor we kunnen adviseren over het optimaal gebruik van de kortingsmogelijkheden met behoud van flexibiliteit. Hiermee brengen we de kosten binnen afzienbare tijd op een acceptabel niveau.

In de tweede stap helpen we u de organisatie in te richten zodat u voortaan zelf in staat bent om de cloudkosten te beheersen, waarbij u uiteindelijk de cloudkosten als gevolg van grote wijzigingen en projecten vooraf kunt inschatten en proactief kunt acteren door de juiste maatregelen te nemen voordat de factuur weer voor een onaangename verrassing zorgt.

Wilt u grip houden op je cloudkosten?

Metri heeft een aanpak ontwikkeld die zijn waarde in de praktijk heeft bewezen. Met deze methode worden kosten weer inzichtelijk gemaakt en kun je eenvoudig zien waar de kansen op besparingen liggen. Het gaat dan niet alleen om de (te hoge) kosten op de cloud providers zelf, maar ook licenties en architectuurkeuzes worden in het heldere verhaal meegenomen. En al die besparingen kun je alleen realiseren als je echte veranderingen bereikt met leveranciers én gebruikers. In deze kennis-sessie krijg je haarfijn uitgelegd hoe je deze cloud economics inricht en bestuurt.

In onderstaande webinar replay vertelt Paul Groen je graag hoe je controle krijgt over de zo complexe cloud consumptiekosten.

Webinar: Help! Mijn cloudkosten lopen uit de hand!

Cloud Consumptie

Het rijke landschap van de applicaties is sterk veranderd en nu zien we door de bomen het bos niet meer. Hoe kan het nu dat de facturen van de public cloud providers zo hoog uitvallen? Met cloud zou alles toch goedkoper worden? Metri vertelt u tijdens een onderstaande webinar replay graag hoe je wél inzicht krijgt in deze kosten en waar je het beste op kunt besparen.

Dat veel bedrijven geen notie hebben van de applicatie-uitgaven is niet eens zo vreemd. Er heeft nogal een aardverschuiving plaatsgevonden; de data-centers zijn leeg, slechts een paar applicaties draaien nog ergens in een rack. Het overgrote deel heeft zijn plek gevonden in de public cloud, bij Azure of AWS. Alles goed en wel, maar dan komt de rekening. En die valt zomaar enkele tienduizenden of zelfs tonnen euro’s hoger uit dan vooraf was ingeschat. Wat nu gedaan?

Ook bedrijven die al hun rekeningen uitpluizen, komen vaak niet tot de juiste inzichten. Het controleren van de facturen is al een heidens karwei aangezien het iedere maand weer om honderdduizenden tot miljoenen regels gaat. Zoals gezegd, u ziet door de bomen het bos niet meer. En intussen zucht het bedrijf onder de veel te hoge kosten.

Metri heeft een aanpak ontwikkeld die zijn waarde in de praktijk heeft bewezen. Met deze methode worden kosten weer inzichtelijk gemaakt en kun je eenvoudig zien waar de kansen op besparingen liggen. Het gaat dan niet alleen om de (te hoge) kosten op de cloud providers zelf, maar ook licenties en architectuurkeuzes worden in het heldere verhaal meegenomen. En al die besparingen kun je alleen realiseren als je echte veranderingen bereikt met leveranciers én gebruikers. In deze kennis-sessie krijg je haarfijn uitgelegd hoe je deze cloud economics inricht en bestuurt.

In onderstaande webinar replay vertelt Paul Groen je graag hoe je controle krijgt over de zo complexe cloud consumptiekosten.

Zicht op applicaties versnelt cloudmigratie

METRI Cloud Migratie

Het besluit is genomen: na een aantal experimenten en voorzichtige stappen heeft het hogere management besloten dat de organisatie naar de cloud gaat. Dan begint het echte werk pas. Een cloudmigratie die gebaseerd is op strategisch inzicht in het applicatieportfolio voegt de meeste waarde toe en kan zo’n verhuizing in een versnelling brengen.

Een migratie naar de cloud is voor de meeste organisaties een ingrijpende gebeurtenis. Processen, legacy-apparatuur en applicaties moeten tegen het licht gehouden worden. Passen ze nog in de cloud-strategie? Kunnen we ze vervangen door cloud-varianten of kunnen ze ‘lift and shift’ verplaatst worden? Het hele proces blijkt vaak een kwestie van experimenteren, migreren en transformeren.

De eerste stap is om de rest van de organisatie ook mee te nemen. Voor de meeste gebruikers is IT een basisvoorziening die het vooral moet doen. Een migratietraject dat voor hen geen meerwaarde oplevert, maar wel ongemak en risico’s, zitten ze niet op te wachten. Zonder degelijke uitleg vooraf, over het hoe en waarom, zal de bereidheid tot medewerking niet groot zijn.

Vervolgens worden applicaties die naar de cloud moeten in beeld gebracht. Dat is ingewikkelder dan het lijkt. Vaak is er binnen IT al geen eenduidig overzicht van de applicaties die er zijn, laat staan van alles wat er buiten IT om is gekocht of gebouwd.

Als het applicatieoverzicht er eenmaal is, is het van belang om vast te stellen hoe de applicaties gemigreerd zouden moeten worden naar de cloud. Het bekendste model hiervoor is dat van AWS: het ‘6R model’ (6 Strategies for migrating applications to the cloud) om het overzetten van applicaties naar cloud infrastructuur te versnellen. Applicaties worden in dit model langs de meetlat gelegd, om uiteindelijk in één van de zes ‘R’ bakjes te vallen:

  • Retire:
    De applicatie is niet meer nodig of levert te weinig waarde, ten opzichte van de kosten, en wordt daarom uit gefaseerd.
  • Retain:
    De status quo rond een applicatie blijft voorlopig gelijk. Deze keuze is relevant als een applicatie een beperkte levensverwachting heeft of ongeschikt is om naar de cloud over te zetten, bijvoorbeeld vanwege bijzondere eisen of eigenschappen van de applicatie, of technologisch zwaar verouderd. Retain moet altijd worden gezien als een tijdelijke oplossing; je zit er immers niet op te wachten om voor een beperkte verzameling applicaties een dure uitzonderingspositie te handhaven.
  • Rehost:
    De applicatie gaat één op één naar de cloud (‘lift and shift’). Dit is doorgaans een snelle, goedkope en relatief risico vrije manier om te migreren, maar levert ook geen meerwaarde op. Immers, bestaande problemen zullen ook één op één meegaan naar de cloud. In de praktijk brengt deze keuze vaak hogere infrastructuurkosten met zich mee voor de applicatie. Organisaties betalen de flexibiliteit van de cloud met een hogere uurprijs dan in een marktconform geprijsd datacenter.
  • Replatform:
    Voor de applicatie wordt een nieuwe infrastructuur gebouwd in de cloud, de software zelf blijft onaangeroerd. Deze aanpak is vooral geschikt voor de migratie van applicaties waarvoor de organisatie alleen een gebruikslicentie heeft en geen eigendom van de broncode. Dit is bijvoorbeeld bij standaardpakketten het geval. Ten opzichte van een rehost is dit een complexere en dus duurdere en minder snelle manier van migreren. Het levert wel meerwaarde op doordat er optimalisaties gedaan kunnen worden en bestaande problemen opgelost kunnen worden. Zonder de software aan te passen zijn de mogelijkheden beperkt en zal ook de meerwaarde beperkt zijn.
  • Refactor:
    Voor de applicatie wordt een nieuwe, zo optimaal mogelijke, infrastructuur gebouwd in de cloud en wordt de software aangepast, zodat deze optimaal op de cloud infrastructuur draait. De functionaliteit verandert in principe niet. Vaak is er overigens geen sprake van een infrastructuur in de klassieke opvatting, maar van een PaaS platform waar de software op landt. Deze aanpak is vooral geschikt voor de migratie van applicaties waarvan de organisatie eigenaar is; bijvoorbeeld maatwerk. Ten opzichte van replatform is hier opnieuw sprake van een hogere meerwaarde. Dit loopt echter tegen zijn grenzen aan door de eigenschappen van de software.
  • Repurchase:
    De applicatie wordt in zijn geheel opnieuw aangeschaft of gerealiseerd. Hierbij kan maximaal gebruik worden gemaakt van de diensten van cloud serviceproviders, maar de weg is lang en kostbaar. Je praat immers over een totale vervanging, waarbij ook de functionaliteit zal veranderen en je dus ook de organisatie zal moeten aanpassen en trainen om van de nieuwe oplossing gebruik te maken.

Bovenstaand overzicht lijkt helder. Als je gedetailleerd naar de materie kijkt, is het veel minder eenduidig dan het in eerste instantie lijkt. Er is bijvoorbeeld niet één meetlat langs welke je de applicaties legt. Bijvoorbeeld: als ik een applicatie één op één verplaats, maar een instelling wijzig omdat de nieuwe omgeving dat eenmaal vereist (bijvoorbeeld een andere locatie voor de database), is het dan al een replatform? En als het er twee zijn? Of tien? Of als ik het meer recente versie van het besturingssysteem neem? Bovendien zijn de kosten meer dan één aspect: organisaties die al gebruik maken van de cloud ontdekken dat kostenbesparingen maar een beperkt deel zijn van de waarde die cloud biedt. De cloud biedt vooral ook mogelijkheden voor innovatie.

Strategisch inzicht in het applicatieportfolio kan een cloudmigratie in een versnelling brengen, omdat zo’n analyse business waarde en de kwaliteit van software in de beoordeling meeneemt. Veel organisaties hebben hier geen inzicht in. Zij managen het portfolio alsof alle applicaties gelijk zijn en/of gelijkwaardige problemen hebben. Daarnaast wordt er niet goed op waarde geschat wat het bedrijfsbelang van een specifieke applicatie is. Hierdoor is het lastig om de juiste prioriteiten te stellen. Met de Metri Applicatie Portfolio Strategizer wordt er per applicatie een passend migratieplan vastgesteld, die in een bredere cloudmigratie in te passen is.

Cloud: het gemak van de creditcard heeft zijn prijs

Organisaties standaardiseren op cloud en lopen daarbij tegen barrières aan. Een belangrijk obstakel zijn onverwacht hoge kosten. Wie dacht met cloud als leveringsmodel goedkoper uit te zijn, komt vaak bedrogen uit. Is er wat aan te doen of moeten we ermee leren leven?

De bekende cloudplatformen van AWS, Google en Microsoft zijn helemaal ingericht op gebruiksgemak. Je logt in, zet een paar vinkjes en klaar. Wil je meer? Geen enkel probleem. Als een provider aan een specifieke behoefte kan voldoen, heb je daar zó de beschikking over – nadat je de creditcard hebt getrokken. In dat gemak schuilt tegelijkertijd het gevaar. Want mensen zijn lui, en nadenken over wellicht goedkopere alternatieven komt ons op het moment van bestellen niet uit. Cloudadoptie is vaak een bottom-up-proces gebleken: individuele teams migreren toepassingen naar de cloud, zonder veel onderlinge coördinatie. Per team lijken de kosten misschien beperkt en overzichtelijk, maar al die teams zorgen voor overlap in afgenomen toepassingen en licenties – en dus ook voor onnodig hoge kosten.

Transparantie bedrieglijk

Op het eerste gezicht lijken kostenoverschrijdingen niet aan cloud-providers te liggen. De kosten van hun dienstverlening zijn tenslotte overzichtelijk gepubliceerd op de portal of zijn via een API ontsloten. Die transparantie is alleen bedrieglijk want grote providers zoals de hierboven genoemde werken met tienduizenden prijspunten, en facturen kunnen miljoenen regels lang zijn. De uiteindelijke link met de afgenomen oplossingen en diensten is vaak moeilijk te leggen. En zijn met IaaS-diensten de prijspunten nog grotendeels vergelijkbaar met traditionele infrastructuur, met PaaS en FaaS diensten zijn die overeenkomsten verdwenen.

Wat de complexiteit ook verhoogt, zijn de voortdurende prijswijzigingen. Zowel individuele prijzen als complete prijsmodellen zijn voortdurend aan veranderingen onderhevig. Wat vandaag een goede deal is, is dat morgen wellicht niet meer. Daarnaast zijn er nog de vaak onderschatte netwerkkosten: data downloaden vanuit de cloud kost geld. Vaak zijn die kosten juist bij goedkope archiefopslag aanzienlijk. Als een archief dan toch regelmatig geraadpleegd wordt, dan dat duur uitvallen.

Eigen verantwoordelijkheid

Laat een ding duidelijk zijn. Het is de verantwoordelijkheid van afnemers zelf om de uitgaven aan cloud onder controle te houden. Uit het meest recente jaarlijkse rapport van RightScale, leverancier van oplossingen voor multi-cloud management en kostenoptimalisatie, blijkt dat de uitgaven aan de publieke cloud bij grote organisaties aanzienlijk zijn en nog steeds flink groeien. De groei is zelfs drie keer zo groot als die van de private cloud. De meeste organisaties proberen wel de stijgende kosten van hun bestaande cloud-oplossingen terug te dringen, maar vooralsnog zonder blijvend succes: voor het derde achtereenvolgende jaar in dit terugkerende onderzoek staat dit bovenaan de prioriteitenlijst. Dat veel bedrijven meerdere oplossingen bij meerdere cloud-providers afnemen en in meerderheid ook in hybride vorm, maakt het er ook niet overzichtelijker op.

Waarom vallen migraties naar de cloud op termijn vaak duurder uit dan IT on premise? In een aantal gevallen komt het door het ontbreken van specialistische kennis. Het managen van alle licenties die in een publieke cloudomgeving gebruikt worden, is daar een goed voorbeeld van. Cloud-licenties doen qua complexiteit zeker niet onder voor die van on-premise software. En dat terwijl providers vaak opties bieden om te besparen. Bij AWS en Azure zetten gebruikers respectievelijk slechts ongeveer de helft en een kwart van de tijd zogenaamde Reserved Instances in. Waarom zou je diensten die continu nodig zijn niet voor langere tijd inkopen als je dit kortingen tussen de 50 tot 70 procent oplevert.

Slecht in opruimen

Het is niet alleen ontbrekende kennis. Mensen zijn nu eenmaal slecht in opruimen. Veel services die tijdelijk nodig zijn, worden na gebruik niet meer afgesloten. We hevelen dus in toenemende mate workloads over naar de public cloud, maar kijken er daarna nog maar nauwelijks naar om. Met clouddiensten moet je echter veel vaker dan voorheen – bij on-premise oplossingen – een assessment doen of een systeem nog doet wat het moet doen, en of er geen nieuwe clouddiensten zijn ontstaan die beter of goedkoper zijn dan de huidige. Neem hergebruik, wat je kunt ondervangen door alle afgenomen clouddiensten op te nemen in een configuratie database met alle gebruikte IT-componenten, en periodiek de CMDB te vergelijken met de portal. Diensten die niet in de CMDB staan, kun je dan in principe uitschakelen.

Maar we zijn niet alleen slechte opruimers. Ook plannen staat op gespannen voet met de praktijk van alledag. Soms is het echter zo moeilijk niet. Je kunt dit zelf monitoren, maar het kan ook automatisch. Slechts een minderheid van cloud-gebruikers zet geautomatiseerde processen in, zoals het uitschakelen van workloads als deze niet worden gebruikt na een x-moment of het optimaliseren van instances zodat precies de juiste capaciteit beschikbaar is (rightsizing in combinatie met autoscaling). Een belangrijke verbetering is een centraal cloud team ingericht dat toezicht houdt op kosten, functionaliteit en de keuze van applicaties. Twee derde van de bedrijven heeft deze maatregel genomen. Maar bedrijven kunnen veel meer doen om de kosten terug te dringen, terwijl ze steeds meer workloads naar de cloud overhevelen. Het rapport van Rightscale wijst uit dat IT-beslissers verspilling onderschatten: het werkelijke percentage is 35, terwijl de respondenten gemiddeld schatten dat het 27 procent is.

Markt consolideert

Ligt het alleen aan de afnemers of nemen cloudplatformen ook de ruimte in die ze willen krijgen? Op alle genoemde verbeterpunten heb je als organisatie zelf in zekere zin invloed. Maar er is meer aan de hand. Lange tijd drukte marktleider AWS de prijs, daarbij geholpen door Microsoft en Google. Maar de vraag naar clouddiensten zal stijgen, en er zijn hordes bedrijven die de stap naar de cloud nog moeten maken. Dus als straks de markt consolideert, zullen de prijzen ongetwijfeld de hoogte in gaan. Als dat geen reden is om je cloud-services eens goed tegen het licht te houden…

Welke kant zeilt Netflix op met de multicloud?

Streamingdienst Netflix, grootgebruiker van cloudgebaseerde applicatie omgevingen, laat een goed voorbeeld zien hoe je softwareontwikkeling in de wereld van de megaplatformen kunt adresseren. Dat zie je aan hun nieuwe Spinnaker-product voor multi cloud regie dat kortgeleden met de open source community gedeeld is.

Door cloud native applicaties te ontwikkelen zijn de beperkingen van eigen datacenters, legacy hardware en traditionele dienstenaanbieders omzeild. Volledige ontzorging op infrastructuurgebied toch? Dat is niet het hele verhaal. Organisaties van enige omvang hebben over het algemeen een te breed landschap om applicaties vanuit een cloudvormplatform te bedienen. Van IaaS, PaaS, tot containers en serverless. In zo’n multicloud landschap is het moeilijker grip houden. Qua planning van resources, kosten, development en deployment.

Implicaties

De inzet van meerdere, parallelle cloudplatformen heeft nogal wat implicaties voor de IT-afdeling. Het gebrek aan uniforme standaarden en portabiliteit kost tijd en geld en is problematisch voor ontwikkelaars. Software moet aansluiten op verschillende omgevingen. En in een tijd waarin continuous delivery de nieuwe norm is, moet ook de deployment zo gepland zijn dat de user experience nooit lijdt onder het uitbrengen van een nieuwe release.

Bedrijven willen hoe dan ook flexibiliteit. Vanuit een organisatorische invalshoek – denk aan fusies, overnames en samenwerkingen – maar ook voor redundante omgevingen, voor testdoeleinden, of omdat apps en services elders beter blijken te draaien. We gaan dus langzaamaan naar een situatie toe waarin je vandaag niet weet waar je morgen je apps en services host.

Servicelaag

Ontwikkelen voor verschillende cloudplatformen vraagt om een orkestratielaag: een toepassing waarmee je de resources in de verschillende clouds kunt beheren en je de software deployment zó kunt inrichten dat je gebruikers en klanten de beste UX blijft bieden door constant aan de knoppen te kunnen draaien. In de markt is dat geen vanzelfsprekendheid. De grote cloudplatformen hebben er geen belang bij om applicatie portabiliteit breed te ondersteunen. Maar ook bij kleinere cloud services providers laat de portabiliteit nogal eens te wensen over. Er zijn er die klanten terug willen duwen naar waar ze vandaan kwamen. Door standaardisatie niet te omarmen en door kunstmatige beperkingen, waardoor organisaties beperkt worden in hun softwareontwikkeling, innovatie en flexibiliteit.

Duizenden deployments

Nu multicloud de norm wordt, ontstaat er langzamerhand een kritische massa van startups en grotere aanbieders die de ontwikkeling van standaarden en nieuwe services actief ondersteunt. Een startup is het natuurlijk niet meer te noemen, maar het is precies die cloud regie, die Netflix met het uitbrengen van Spinnaker in het open source domein heeft gebracht. Met deze toepassing organiseer je continuous delivery die compatibel is met AWS EC2, Kubernetes, Google Compute Engine, Google App Engine, Microsoft Azure en Openstack. Ontwikkelaars hoeven vanuit hun continuous integration project alleen maar een deployable unit te maken en Spinnaker test de integratie, het systeem, beheert servergroepen en monitort de geautomatiseerde uitrol. Netflix zet dagelijks zo duizenden deployments weg en beheert een heel landschap van honderden microservices, virtual memory, containers en content delivery networks.

Hoe complex het aan de achterkant misschien ook lijkt, heel veel werk is al gedaan en het is ook nog eens open source. Ondernemingen die bij dit soort ontwikkelingen aanhaken zullen de eerste rijpe vruchten van de multicloud plukken. En misschien komt er nog wel meer. De geschiedenis lijkt zich te herhalen. Net zoals AWS een succesvolle spin off van de Amazon webshop werd, zo zou Spinnaker als nieuwe activiteit en aanvulling op video streaming een eigen leven kunnen gaan leiden.

De cloud is niet goedkoper

METRI Cloud Migratie

Als je middenin een verhuizing zit, heb je – als je het goed hebt gepland tenminste –  voldoende tijd ingeruimd om je aan het verplaatsen van je spullen te wijden. Maar als de geplande tijd erop zit en je de buitenwacht kunt melden dat je ‘over’ bent, zul je zien dat er vóór de verhuizing allerlei klussen zijn blijven liggen. Terwijl je nog aan het wennen bent aan je nieuwe woonsituatie, word je al snel in de dagelijkse sleur gedwongen en kom je er achter dat deze verhuizing meer vergt en meer kost dan de vorige.

Dit soort wetmatigheden zie je ook optreden bij grote transities in het IT-domein. Neem een verhuizing naar de cloud. Sommige CIO’s of programmamanagers denken daarbij en handelen in termen van inpakken, transporteren en weer uitpakken, oftewel unfreeze, change, freeze. Maar dat is vandaag de dag onzinnig: bij een overstap op clouddiensten moet je IT-operatie namelijk in een voortdurende staat van verandering zijn.

De cloud is echt radicaal anders dan on-premise. Indien je vooraf je opties niet goed doordacht hebt, kom je bedrogen uit. Als je traditionele dagelijkse operatie om te beginnen niet efficiënt in elkaar zit, kunnen je kosten in de cloud zelfs significant stijgen. Het laatste State of the Cloud Report van de Amerikaanse consultancy firma Rightscale noemt zelfs een percentage van 25.

In traditionele omgevingen wordt vaak alleen nog gereageerd op incidenten. Er is zó geknepen in de kosten dat er geen ruimte meer is voor anticiperend gedrag. Maar in de cloud is flexibiliteit troef en kun je betalen naar gebruik. Je kunt rekencapaciteit verlagen of helemaal uitschakelen wanneer je deze niet nodig hebt. Bijvoorbeeld van 168 naar 60 uur beschikbaarheid omdat de nacht en het weekeinde wegvallen. Als de kosten lineair zijn, bespaar je daar wel 65 procent.

Dit veronderstelt echter dat je je huiswerk hebt gedaan, terwijl maar weinig cloud providers dit afdwingen. Sterker nog, door hard te roepen dat je goedkoper uit bent in de cloud blijft de boodschap weliswaar simpel, terwijl veel gebruikers onder de streep duurder uit zijn – zie het genoemde rapport.

De waarheid is dat je alleen in combinatie met een goede governance op gebruik kosten bespaart. En dat is zeker in het begin wel even wat werk: je moet gaan monitoren wanneer productiesystemen nu echt worden gebruikt en wanneer test- en ontwikkelomgevingen in de lucht moeten zijn. Het brengt nieuwe verantwoordelijkheden met zich mee. En ofschoon veel grote cloud service providers tools beschikbaar stellen waarmee je dit soort taken deels kunt automatiseren, moet je de zaak wel inregelen en blijvend je gehele IT-landschap monitoren.

Het is dus zaak om de sales pitch van providers met een korrel zout te nemen. De technologie tilt je organisatie echt naar een nieuw tijdperk, dus het is wijs om deze als hefboom te gebruiken in de digitale transitie en zo een lang uitgesteld afscheid te forceren van twintig jaar oude technologie in je datacenter. Maar het is niet per se goedkoper, en het wordt nooit meer zoals het was: volop change, maar geen freeze meer.