De transitie naar de cloud en IDaaS

Wanneer en hoe migreer je je Identity & Access Management (IAM) naar de cloud? Dit zijn vragen die veel organisaties zich stellen, vooral omdat er vanaf 2025 naar verwachting meer in cloud-technologie wordt geïnvesteerd dan in traditionele IT-oplossingen.

Dit artikel bespreekt de verschillende strategieën voor de migratie van IAM naar de cloud, de zogenaamde 5R’s, en de voor- en nadelen van deze methoden. Ook wordt er ingegaan op de praktische aspecten van een migratietraject naar de cloud, met name in combinatie met een Identity Management oplossing.

Wat is IDaaS in het kort

IDaaS, of Identity-as-a-Service, is een cloudgebaseerde service die identiteits- en toegangsbeheerfuncties biedt aan organisaties. Met IDaaS kunnen bedrijven gebruikersauthenticatie, autorisatie, single sign-on (SSO), identiteitsbeheer en andere gerelateerde functies uitvoeren zonder dat ze de infrastructuur zelf hoeven te onderhouden.

Het is een flexibele en schaalbare oplossing die het mogelijk maakt om snel te reageren op veranderende zakelijke behoeften en technologische trends.

De 5 migratiestrategieën

Er zijn dus verschillende manieren om on-premise applicaties naar de cloud te migreren. De verschillende migratiestrategieën die organisaties kunnen hanteren worden door Gartner beschreven als de 5R’s:

Welke strategie je kiest is in grote mate afhankelijk van de situatie waarin je organisatie zich bevindt en het soort toepassing dat gemigreerd wordt.

Rehost

Rehosting wordt ook wel ‘lift and shift’ genoemd en heeft alles te maken met Infrastructure-as-a-Service (IaaS). Dit is de meest laagdrempelige manier om je applicaties naar de cloud te migreren. Je bestaande data en applicaties pak je simpelweg op (lift) en verplaats je as-is van je eigen datacenter naar de cloud (shift). Dit is een goede optie als je applicaties intact en zonder wijzigingen aan de codebase wilt migreren óf wanneer je een applicatie enkel as-is kan migreren.

Het is een relatief voordelige cloudmigratiemethode met minimale risico’s tot productieverstoring. Tegelijkertijd ben je echter iets ouds aan het verplaatsen zonder stappen vooruit te zetten.

Het nadeel is dan ook dat de voordelen van de cloud op het gebied van schaalbaarheid en performance helemaal niet (volledig) worden benut. Met mogelijke prestatieproblemen en verminderde gebruiksvriendelijkheid tot gevolg. Kenmerkend voor deze methode zijn bijvoorbeeld cloudapplicaties waar je op inlogt via een RDP sessie.

• Voordelen:
  • Snel
  • Goedkoop
  • Minimale verstoring
• Nadelen:
  • Beperkte optimalisatie
  • Mogelijk hogere operationele kosten op de lange termijn

Refactor

Refactoring, ook wel bekend als ‘lift, tinker en shift’ betekent dat je je applicaties aanpast om ze te optimaliseren voor gebruik in de cloud. In dit geval wordt er gebruikgemaakt van een Platform-as-a-Service (PaaS)-oplossing.

De architectuur van de applicaties blijft in de basis hetzelfde, maar er worden aanpassingen gedaan aan de code om beter gebruik te kunnen maken van cloud-based tools.

Refactoring is vaak een duurdere oplossing omdat het aanpassen van de applicaties om te kunnen werken met cloud tools een complex proces is. Het uiteindelijke voordeel van deze methode is dat het een cloud-native en schaalbare oplossing oplevert.

• Voordelen:
  • Betere integratie met cloudservices
  • Mogelijk lagere operationele kosten
  • Cloud-native en schaalbare oplossing
• Nadelen:
  • Hogere kosten en inspanning dan rehosting
  • Complex proces
  • Mogelijk risico op verstoring

Revise

Revise combineert de vorige twee strategieën. Hierbij worden enkele veranderingen gedaan aan de architectuur en code van de applicaties die naar de cloud worden gemigreerd.

De applicaties worden gemoderniseerd zodat ze diensten die beschikbaar zijn in de cloud kunnen benutten. Het voordeel hiervan is dat je een oplossing kan creëren die schaalbaar is en die bijvoorbeeld cloudopslag en databases kan benutten.

Het nadeel is dat de kosten voor het aanpassen van de architectuur en de code van applicaties snel op kunnen lopen, en dat dergelijke projecten langer kunnen duren dan oorspronkelijk verwacht. Waar transparantie vaak een bekend voordeel van cloudapplicaties is, zorgt de revise methodiek hierdoor juist vaak voor veel onzekerheid.

• Voordelen:
  • Betere prestaties
  • Meer flexibiliteit
  • Betere integratie met cloudservices
• Nadelen:
  • Hogere kosten en inspanning
  • Mogelijk risico op verstoring

Rebuild

Kies je voor deze strategie dan ga je niet verder met de bestaande toepassing, maar kies je voor een nieuwe architectuur die volledig is toegespitst op werking in de cloud.

Het voordeel hiervan is dat de software naadloos integreert met de cloud en je gebruikmaakt van de meest innovatieve technologie. Daarbij zijn cloudapplicaties vaak sneller te ontwikkelen doordat je gebruik kunt maken van standaard cloud-componenten, denk bijvoorbeeld aan authenticatiemechanismen.

Het nadeel is logischerwijs dat het volledig nieuw bouwen van een applicatie hoge kosten met zich meebrengt en specialistische kennis vereist. Het heeft onszelf bijvoorbeeld alsnog ruim vijf jaar gekost voordat onze cloudoplossing functioneel onze on-premise oplossingen kon vervangen, mede doordat er gedurende die tijd ook niet stilgezeten kan worden met de bestaande software.

• Voordelen:
  • Optimale prestaties en flexibiliteit
  • Lagere operationele kosten
• Nadelen:
  • Hoogste kosten en inspanning
  • Risico op verstoring

Replace

Een laatste mogelijkheid is het vervangen van de applicatie. On-premise applicaties worden uitgefaseerd en je stapt over naar een Software-as-a-Service (SaaS) oplossing die in functionaliteit vergelijkbaar is.

Hiermee is het niet nodig om zelf de ontwikkeling voor je rekening te nemen, maar neem je deze als SaaS-dienst af van een cloudaanbieder. Enkel de data vanuit de on premise applicatie wordt hierbij gemigreerd.

Mogelijke nadelen van deze methode zijn bijvoorbeeld niet aansluitende datamodellen en het risico op een vendor lock-in.

• Voordelen:
  • Snelle implementatie
  • Lage onderhoudskosten
• Nadelen:
  • Beperkte aanpassingsmogelijkheden
  • Afhankelijkheid van serviceprovider

Een gefaseerde overgang naar de cloud

De afgelopen 10 jaar heeft cloud computing de IT-wereld volledig veranderd. Waar organisaties voorheen hun eigen on-premise datacenters hadden, vaak zelfs dubbel uitgevoerd voor hoge beschikbaarheid en redundantie, is er tegenwoordig in veel organisaties geen fysieke server meer te vinden.

Toen Gartner in 2008 voor het eerst verklaarde dat cloud computing een revolutie zou veroorzaken, was niet iedereen overtuigd van dit uiteindelijke succes. Veel organisaties waren sceptisch over de overstap naar de cloud, vooral vanwege zorgen over beveiliging en beschikbaarheid. Er waren bedenkingen zoals:

• Het risico van het opslaan van alle data op een externe locatie.
• De angst dat werkzaamheden zouden stagneren als de cloudservice of de eigen internetverbinding zou uitvallen.
• De vrees dat de cloud een ‘bubbel’ was die zou barsten.

Echter, de overstap naar de cloud is nu voor de meeste organisaties onvermijdelijk. Weinig ICT’ers hebben nog de illusie dat zij hun servers en data beter kunnen beveiligen dan grote gespecialiseerde partijen zoals Microsoft, Google en Amazon. Dit geldt zowel voor toegang tot in de cloud opgeslagen data als voor de zekerheid van werkende backups.

Enkele voordelen van de overstap naar de cloud zijn:

• De mogelijkheid om te profiteren van de expertise van grote cloudaanbieders, die aanzienlijke middelen investeren in beveiligingsonderzoek en cyberbeveiliging.
• De betrouwbaarheid van cloudaanbieders, die over het algemeen een beschikbaarheid van minimaal 99,95% bieden.
• De betrouwbaarheid van internetverbindingen, die in Nederland over het algemeen zeer goed zijn, waardoor de beschikbaarheid van cloudservices zelden een probleem is.

Overgang van business-apps

De overgang naar de cloud gaat bij de meeste bedrijven niet zonder slag of stoot. Vaak gaan er jaren overheen voordat de overstap helemaal is gemaakt. Als we teruggrijpen naar de 5R’s zien we bij onze klanten vaak combinaties van rehost– en replace-strategieën. Aan het begin van de cloudtransitie in Nederland – rond 2010 – zagen we vooral dat kleinere business-apps van een lokaal datacenter naar de cloud verhuisden.

Hierbij ging het dan vooral om applicaties die niet interfereerden met de core IT-systemen. Deze applicaties werden vaak door afdelingen zelf aangekocht, ter vervanging van bestaande on-premise applicaties, zonder IT hierbij te betrekken.

Vandaag de dag kennen we dit ook wel als shadow IT, een term die niet geheel ontoevallig ongeveer gelijktijdig is opgedoken – in het jaar 2018 – als dat de term cloud computing wereldkundig gemaakt werd.

Overgang van bedrijfskritische apps

Veel organisaties passen inmiddels een cloud-only strategie toe, wat betekent dat iedere on-premise applicatie die wordt uitgefaseerd vervangen wordt door een cloudoplossing – de typische replace-strategie.

De meeste softwareleveranciers hebben de afgelopen jaren dan ook hun ontwikkeling richting de cloud verplaatst. De afgelopen tien jaar zien we daarom dat veel van de grotere en meer bedrijfskritische systemen, zoals HR, ERP en financiële systemen, worden vervangen door software in de cloud. De laatste vijf jaar wordt dit gevolgd door on-premise file-share systemen die worden vervangen voor systemen in de cloud, zoals Sharepoint Online. Zo zijn stapje voor stapje de applicatielandschappen van organisaties verSaaSt. Tegelijkertijd zijn er zelfs 14 jaar na dato echter toch nog regelmatig enkele applicaties, met een hoge impact, waar geen direct cloud alternatief voor beschikbaar is.

De logische stap voor organisaties die tegen dergelijke obstakels aanlopen, maar zich niet willen laten vertragen in hun migratie naar de cloud, is dan rehosting. De on-premise systemen worden opnieuw uitgerold in een IaaS-omgeving waarbij alleen de infrastructuur-configuratie wordt veranderd. De applicaties draaien niet meer op een eigen server omgeving, maar op

Van IAM naar IDaaS

Veel van onze klanten vragen ons wat het beste moment is om ook het Identity & Access Management naar de cloud te verplaatsen. Wij raden aan om naar SaaS IAM – of in ons vakgebied ook wel IDaaS (Identity-as-a-Service) genoemd – over te stappen wanneer de IAM-oplossing sowieso al vervangen wordt of de organisatie een cloud-beleid voert en de meeste applicaties niet meer on-premise, maar in de cloud draaien. Urgenter wordt het wanneer de primaire IDP naar de cloud verplaatst.

In dit laatste geval zou een VPN of agent nog een connectie mogelijk kunnen maken, maar deze opties zijn verre van ideaal. Een van de voordelen van een IDaaS-oplossing als HelloID is dat het relatief eenvoudig een brug kan slaan tussen on-premise en cloud. HelloID bijvoorbeeld ondersteunt zowel hybride als full cloud omgevingen.

Op het moment dat het HR-systeem als SaaS-oplossing wordt afgenomen, maar er nog gebruik wordt gemaakt van een lokale Microsoft Active Directory, kan HelloID beide systemen met elkaar koppelen. Op deze manier profiteer je in alle fasen van het migratietraject naar de cloud van de voordelen die een moderne IDaaS-oplossing biedt.

Aandachtspunten bij het kiezen voor een IDaaS-oplossing

Kies een IDaaS-leverancier met een rebuild-strategie

Kies je voor een IDaaS-leverancier, dan is het belangrijk dat die een rebuild-strategie voert en niet simpelweg de ‘oude’ software vanuit een cloudinfrastructuur (lees: IaaS) aanbiedt. Het rehosten, refactoren of revisen van IAM is vaak geen goede lange termijn oplossing. IAM is complex en de spil binnen je organisatie die tal van verschillende systemen met een grote diversiteit aan koppelvlakken met elkaar verbindt.

Hanteer een lange termijn visie en strategie voor IAM

De keuze van een IAM oplossing is strategisch en organisaties maken in onze ervaring gemiddeld een keuze voor een termijn van 5 tot 8 jaar. De IAM oplossing moet daarom toekomstvast zijn in een applicatielandschap dat steeds sneller verandert, momenteel vanuit de cloud, maar potentieel ook op gebieden die we vandaag nog nauwelijks kunnen voorzien. Daarnaast geldt simpelweg: voer je een cloud beleid dan wil je ook dat je IAM-oplossing echt ontwikkeld is voor de cloud. Legacy en rehosted IAM-oplossingen vereisen daarbij veel custom code op een oude code base waar de originele ontwikkelaars niet altijd meer voor beschikbaar zijn. Net als elke legacy applicatie zijn ze lastig te implementeren, te beheren en te upgraden.

Wees bewust van de beperkingen van legacy IAM-software

De software heeft vaak een relatief laag release schema van bijvoorbeeld tweemaal per jaar in plaats van iedere maand. Ze worden gekenmerkt door hoge hosting infrastructuurkosten die achteraf vaak tegenvallen en zich vertalen in hoge maandvergoeding terwijl er al een vendor lock-in is ontstaan. Tot slot hebben legacy-oplossingen veelal te maken met een afnemende installed base en een daarmee samenhangende afname in beschikbare consultants met kennis van het product.

Selecteer een standaard IDaaS-oplossing ontworpen voor de cloud

Alléén met een volledig nieuwe voor de cloud ontworpen standaard IDaaS-oplossing kun je er zeker van zijn dat deze aan de meest recente beveiligingsstandaarden voldoet, en alle voordelen van de cloud biedt en benut. Zaken als event logging, reporting en moderne beveiligingsmechanismen als multi-factor authentication zijn vaak standaard aanwezig in een IDaaS-oplossing en helpen je als organisatie te voldoen aan de strikte wetgeving. Een moderne en gestandaardiseerde IDaaS-oplossing als HelloID is bovendien snel in te zetten en te implementeren en heeft een interface die eenvoudig in gebruik is – waarmee je verlost bent van de spaghetti aan maatwerk code. Een rebuild Identity & Access Management as-a-Service oplossing biedt ook alle overige voordelen van de cloud zoals schaalbaarheid, performance en geautomatiseerde updates. En doordat het als dienst wordt aangeboden heeft het een flexibel licentiemodel op basis van daadwerkelijk gebruik en vereist het geen technisch beheer.

Minimaliseer risico op vendor lock-in

De potentiële nadelen van een replace-strategie, waaronder niet aansluitende datamodellen en risico’s op een vendor lock-in zijn voor een ervaren softwareontwikkelaar veelal gemakkelijk te voorkomen. Bij Tools4ever hebben we bijvoorbeeld gekozen voor het gebruik van niet-relationele databases zodat het datamodel van HelloID naar wens uit te breiden is. Om data binnen andere applicaties te kunnen lezen en schrijven zijn geen andere eisen dan dat de te koppelen applicatie een koppelvlak moet bieden. Het zijn de connectoren die zorgen voor de juiste translatie van gegevens waardoor bij ons geldt: is er een koppelvlak dan kan HelloID ermee koppelen. De risico’s van een vendor lock-in hebben we geminimaliseerd door niet alleen de softwareoplossing opnieuw te ontwerpen, maar ook de gehele organisatie daaromheen opnieuw op te bouwen. Zo kun je inmiddels terecht bij meer dan 25 gecertificeerde HelloID-partners en delen we zowel kennis als connectoren publiekelijk en kosteloos. Daarover lees je meer in de blog over het ecosysteem dat we rondom HelloID hebben ontwikkeld.

Herkennen van cloudwashing

Wanneer je als organisatie hebt besloten om over te stappen naar een IDaaS-oplossing moet je echter op je hoede zijn voor cloudwashing. Naarmate organisaties zich meer en meer bewust worden van de voordelen van SaaS-oplossingen proberen softwareleveranciers zich ook zo te positioneren terwijl ze niet de kostbare en tijdrovende stappen van een rebuild-proces hebben doorlopen. Ze bieden “SaaS” zonder de hierboven beschreven bijkomende voordelen. Om te voorkomen dat je toch te maken krijgt met kostbare en tijdrovende aanpassingen en updates is het daarom belangrijk om de verschillen tussen een echte SaaS-leverancier en een leverancier die aan cloudwashing doet te kunnen herkennen. Het meest kenmerkende van echte SaaS-applicaties is dat deze single instance en multi-tenant zijn. Dit betekent dat elke klant op exact dezelfde codebase draait en (eventueel per regio) één enkele instantie van de software wordt gehanteerd. Maken klanten gebruik van verschillende versies van de software, of is de instantie uniek per klant, dan heb je te maken met een leverancier die enkel vanuit marketingoverwegingen het label SaaS op zijn software plakt.

Conclusie

Afhankelijk van het soort applicatie en de omgevingsfactoren heb je voor het migreren van applicaties naar de cloud keuze uit verschillende strategieën. In de praktijk betekent dit voor organisaties meestal een combinatie van een rehost- en een replace-strategie. In specifieke gevallen, bijvoorbeeld bij Identity & Access Management kan het daarnaast belangrijk zijn om ook de strategie van de leverancier onder de loep te nemen. Kiezen voor een rebuild IDaaS-applicatie is dan de beste oplossing.

Echte cloudapplicaties, namelijk SaaS-applicaties, worden als dienst aangeboden waarbij de cloudaanbieder de onderliggende infrastructuur, inclusief hardware en software, beheert. Deze cloud diensten zijn niet alleen betrouwbaarder en veiliger, doordat het – zoals eerder in deze blog ook al vermeld – de core business van de aanbieder is, maar verlagen potentieel ook de operationele IT-kosten. Er hoeft immers niet meer geïnvesteerd te worden in hardware en allerlei software, nog niet eens te spreken over alle uren beheer die hierbij komen kijken. Andere voordelen zijn dat om cloudtoepassingen schaalbaar, interoperabel en veiliger te maken, ze vergaand zijn gestandaardiseerd, elke klant op dezelfde code base draait, en doordat ze als dienst worden aangeboden meestal een flexibel maandelijks licentiemodel kennen. Dit laatste betekent weer dat hoge investeringen vooraf en langdurige en complexe implementaties en updates tot het verleden behoren. Oftewel: sneller resultaat, gemakkelijker in gebruik, minder risico en minder kosten.

• HelloID
• Identity Management
• cloud
• IDaaS
• Voordelen IAM