Je zou denken dat anno 2021 de meeste organisaties hun cloudtransitie wel voltooid hebben. Toch is dat niet het geval. Cloud is weliswaar een belangrijk onderdeel van de hedendaagse technologiemix, maar echte cloud-native it-infrastructuren zijn schaars. Terwijl je daarmee pas echt de optimale resultaten uit cloud behaalt.
Alles op zakelijk it-gebied draait om business-optimalisatie. De cloud is al vele jaren het go-to-platform om organisaties te voorzien van een betaalbare en schaalbare infrastructuur zonder de hoge kosten voor aanschaf en beheer. Maar ook binnen de cloud valt er nog genoeg te optimaliseren.
Veel bedrijven die hun bestaande it-infrastructuur naar de cloud migreren, beginnen namelijk met hun virtuele machines. Die vm’s zijn echter nog steeds gebaseerd op specifieke hardware en software, ook als ze in een cloud-omgeving gebruikt worden. Ze profiteren niet van de voordelen van abstractie, ofwel serverless computing, waarbij applicaties niet meer afhankelijk zijn van specifieke hardware- of softwareplatformen. Dit is de basis voor een cloud-native architectuur.
Standaardcloud versus cloud-native
Veel gevestigde it-infrastructuren zijn in de loop der jaren complex geworden. Ze bestaan uit een veelvoud aan gekoppelde applicaties, databases, front-ends, enterprise service buses en loadbalancers, waaronder vaak de nodige legacy-applicaties. Diezelfde architecturen worden door veel organisaties ook in de cloud in stand gehouden, waardoor ze niet optimaal gebruikmaken van de voordelen van cloud. Denk bijvoorbeeld aan automatische schaalvergroting of verlaging en onderhoudsvriendelijk beheer.
Maar als je deze structuren logisch beschouwt, blijven er slechts drie kernelementen over: de database, front-end en applicatie. En dat is ook precies zoals moderne bedrijfssoftware is opgebouwd in een cloud-native architectuur. Daarmee profiteer je veel directer van de voordelen van cloud.
Minder onderhoud en resources
Het businessmodel van cloud-native infrastructuur is daarom ook gunstiger dan dat van een infrastructuur die niet cloud-native is. Het onderhoud van een dergelijke infrastructuur vereist namelijk veel meer onderhoudsinspanning en technische resources dan een omgeving die volledig is opgebouwd en geoptimaliseerd voor de cloud.
De financiële verschillen zijn eens berekend op basis van een aantal praktijkcases, en daaruit bleek dat de kosten voor een transactie in een cloud-native omgeving een eurocent kostte, terwijl diezelfde transactie in een niet-geoptimaliseerde cloud-omgeving het dubbele bedroeg. Het spreekt voor zich dat een dergelijke halvering van de transactiekosten een enorme efficiëntieverbetering is voor organisatie.
Met vertrouwen naar de cloud
Wat is nu de meest directe route naar een cloud-native infrastructuur? Wellicht heb je al een ‘lift & shift’ naar de cloud afgerond, en misschien zijn er gaandeweg zelfs al wat legacy-componenten vervangen door cloud-native applicaties.
De sleutel is de bestaande toepassingen binnen de infrastructuur stapsgewijs te moderniseren, specifiek voor gebruik in een cloud-native omgeving. Gaandeweg zijn dan alle bestaande infrastructuurelementen zoals netwerken, servers, databases en besturingssystemen te vervangen door cloudgebaseerde diensten, om uiteindelijk een volledige cloud-native architectuur over te houden, met alle voordelen van dien.
Blueprinting
Een nieuwe benadering bij het migreren van niet-geoptimaliseerde (cloud-)applicaties naar cloud-native varianten is het gebruikmaken van blueprinting. Bij dit proces treden in de praktijk opgestelde blauwdrukken op voor het converteren van bekende applicaties en processtructuren naar een cloud-native omgeving.
Die blueprints bevatten alle noodzakelijke kennis om een migratie zo efficiënt mogelijk te laten verkopen, inclusief ci/cd-pipelines, referentieontwerpen, code library’s en methodes voor het genereren en testen van code.
Verder is het belangrijk om altijd vier kernprincipes in acht te nemen:
- Eerst automatiseren
Niets zou handmatig geconfigureerd of gecreëerd moeten worden;
- Gebruiksgemak voor alles
Maar dit mag niet ten koste gaan van security en compliance;
- Bewezen in de praktijk
Gebruikte code en oplossingen moeten in de praktijk getest zijn;
- Herzie de huidige situatie
Houd geen legacy in stand, gebruik nieuwe en bewezen technologieën en best practices.
Met deze ontwerpprincipes en blueprinting verloopt een cloudmigratie veel efficiënter. De basis wordt immers gelegd met een helder proces dat is gebaseerd op de kennis en ervaring uit eerdere projecten. Zo kunnen applicaties veel sneller cloud-native gemaakt worden, zonder dat een partij daarbij elke keer opnieuw het wiel moet uitvinden.
Naar mijn mening worden er nogal wat dingen door elkaar heen gegooid voor de buzzword bingo want een architectuur is meer dan een infrastructuur. En zelfs Gartner geeft toe dat een infrastructuur uit meerdere horizontale lagen bestaat die op verschillende snelheden draaien waardoor er altijd een soort van legacy zal zijn want business services zijn uiteindelijk vertikaal geörienteerd. De auteur vergeet nog de middleware te noemen welke niet onbelangrijk is als je schaalbaarheid in je infrastructuur wilt terwijl die vaak ook belangrijk is in het kostenmodel. Ik ben dan ook heel benieuwd naar de transactie kosten waarover Jan het heeft, een simpele e-commerce oplossing is tenslotte nog iets anders dan een complex ERP systeem. Maar vooral interessant is de KPI service want de transactie kosten verlagen en daarmee de response verhogen is geen efficiëntieverbetering, het knelpunt van I/O blijft dan ook een lastige en dit geldt zeker als je kiest voor een schaalbaarheid middels uitschalen. Maar het is zeker goed dat Jan wijst op de nul-meting, begin eerst met je kosten inzichtelijk te maken voordat je over een verhuizing na gaat denken want zoals ik altijd zeg biedt de cloud wel mogelijkheden maar geen wonderen.
Groter gaan wonen door te verhuizen is een optie maar verbouwen ook want tenslotte is ook een niet-cloud infrastructuur te optimaliseren door een voortschrijdende technologische voortgang zodat knelpunten weggenomen worden door het wisselen van componenten. Er zijn namelijk een paar dominante factoren waarmee rekening gehouden moet worden als het gaat om het afstemmen van eigen of gedeelde infrastructuur op de behoeften van de applicaties. Zo heb je bijvoorbeeld geheugen intensieve applicaties maar dus ook de I/O intensieve applicaties omdat je daarmee nog altijd makkelijker data deelt en deze ook makkelijker beschermd tegen bijvoorbeeld verlies door een stroomonderbreking. En oplossingen zijn niet altijd gericht op de data integriteit omdat met het SOA paradigman alle ogen gericht zijn op het herstel van de service waardoor de robuustheid van legacy nog weleens onvolprezen blijft. Maar zoals gezegd, bezint eer ge begint want in de ICT doen we niks anders dan telkens het wiel opnieuw uitvinden met de cyclische verhuizingen van centraal naar decentraal en vice versa.