Blunder 1: Data on-prem, rekenkracht in de cloud
Ik hoor vaak klanten begrijpelijk zeggen: "Mijn data is heilig, dus dat mag niet in de cloud. Maar we betalen wel te veel voor rekenkracht en ruimte in het datacenter, dus laten we dat stuk naar de publieke cloud schuiven." Dat is een slecht idee om meerdere redenen. Ten eerste ga je te maken krijgen met een hoop latency. Sterker nog, ik heb een dergelijke hybride-architectuur nog nooit zien werken vanwege de lags waar ze tegenaan lopen. Ten tweede wordt beveiliging een stuk lastiger. In de praktijk krijg je zelfs te maken met meer issues dan daarvoor.
Blunder 2: Personeel dat met legacy werkt te snel ontslaan
Organisaties budgetteren in de regel rondom publieke clouds en beursgenoteerde bedrijven willen in de regel, zelfs gedurende de cloudtransitie, geen hogere kosten maken. Ze maken een budget als een nulsom-spel en om die situatie te bereiken, bezuinigen ze personeel weg dat met de legacysystemen werkt, zelfs nog voordat de workloads daadwerkelijk naar de cloud zijn verplaatst.
Dat is een enorme misstap. Gemiddeld genomen duurt een migratie al snel een jaar. Je hebt op z'n minst gedurende die periode de legacysystemen nodig voor de bedrijfsvoering. Belangrijker: je zult niet al je applicaties in de cloud kunnen draaien. Sommige kunnen dat niet vanwege het kostenplaatje en andere vanwege technologische beperkingen. Daar blijf je legacy-personeel voor nodig hebben. Je zult bezuinigen, maar pas op de langere termijn.
Blunder 3: Te veel beloven
Hoe de tijden zijn veranderd! IT'ers die een paar jaar geleden zich nog agressief verzetten tegen de cloud, hebben het nu omarmd. Ze zien hoe de wind waait. Maar meewaaiend met de hype neigen ze nog wel eens de ROI te overschatten en te verkopen aan het bestuur als enorme kostenbesparing.
Als die enorme besparing vervolgens uitblijft, ziet het bestuur dat als falen. De waarheid is dat de winst die je kunt behalen heel erg verschilt per bedrijf en implementatie. Daarom besteed ik zelf veel tijd aan het opstellen van de businesscase, zodat ik uiteen kan zetten wat realistische verwachtingen zijn. Jij moet hetzelfde doen.
Latency is een heuse "sluip-moordenaar". Zelfs al heb je een grote "pijp" naar het internet en/of cloud-provider. Bij normaal gebruik merk je in principe vrij weinig van mogelijke latency problemen, maar dat betekent dus niet dat jouw verbinding geen latency probleem heeft.
Maar daar kom je bij toepassing van blunder 1 snel genoeg achter. Dit was een probleem 20 jaar geleden en dat is het nog steeds.
Nu zijn er wel oplossingen bedacht die latency problemen enigzins op kunnen lossen, maar dat vereist extra hardware, zeer specifieke software (Wanos is zo'n aanbieder) en de expertise van dure netwerk engineers om die software optimaal te configureren.
Zulk soort software werkt op OSI level 2/3/4 en ik verwacht dat het aantal gecertificeerde/gelicenseerde netwerk engineers vrij laag is.
Simpel gezegd, je moet aan de slag met de netwerk stack van je operating systeem om redelijke file I/O tussen on-premise en cloud voor elkaar te krijgen.
Maar dit is niet het enige probleem. Het TCP protocol negotieert de optimale packet-grootte. In windows die waarde staat standaard op 1500. In een LAN hoeft dit geen probleem te zijn als je kabels en netwerkapparatuur daar ook op is afgesteld.
Het TCP protocol hoeft de packet-grootte in principe maar 1 keer in te stellen in een LAN. Zodra je TCP pakktjes verder moeten reizen dan je LAN dan kan het wel eens voorkomen dat je ISP/Cloud-provider jouw traffic door een netwerk-kaart heen leid.
Dit kan als slim en handig overkomen, maar is het niet. Deze kaart staat vaak ook op 1500 afgesteld. Nu is het zo dat het TCP protocol extra data toevoegd aan elk data pakketje vanwege de routering. En dan gaan de volledige pakketjes dus over de grens van 1500 en moet het TCP protocol steeds opnieuw de optimale pakketgrootte van je actuele datapakket vast te stellen. En dit gaat proef-ondervindelijk.
Dat dit kostbare tijd en dus heel veel performance tussen on-premise en cloud kost, mag hopelijk wel duidelijk zijn.
Is het scenario van blunder 1 jouw ideale vorm van bedrijfvoering? En is je salaris afhankelijk van de tevredenheid van je gebruikers? Vergeet de cloud dan maar gauw, het is namelijk niet goedkoper, bezorgt iedereen op je netwerk veel meer hoofdpijn dan je jezelf kan voorstellen en hun gezeik komt allemaal op jouw bureau terecht.
Reageer
Preview