De transitie naar de cloud en IDaaS

Wanneer migreer je je Identity & Access Management (IAM) naar de cloud en welke strategie hanteer je hiervoor? En hoe verloopt zo’n migratietraject naar de cloud? Dit soort vragen krijgt Tools4ever regelmatig. Relevante vragen. Zeker omdat er naar verwachting vanaf 2025 meer geïnvesteerd wordt in cloud-technologie dan in traditionele IT-oplossingen.

Veel organisaties zijn momenteel bezig met de transitie naar de cloud. Om dit in goede banen te leiden passen zij verschillende migratiestrategieën toe. Gartner beschrijft een aantal van deze migratiestrategieën, de zogenaamde 5R’s. Wat zijn de voor- en nadelen van deze migratiemethodes en hoe werkt het migratietraject in de praktijk? En dan met name in combinatie met een Identity Management oplossing? Het antwoord daarop lees je in deze blog.

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.

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.

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.

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.

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.

Een gefaseerde overgang naar de cloud

De afgelopen 10 jaar heeft de opkomst van cloud computing de IT wereld volledig op zijn kop gezet. Waar elke organisatie voorheen nog hun eigen on premise datacenter had – zelfs vaak dubbel om te zorgen voor high availability en redundantie om uitval en verlies van gegevens te voorkomen – is er tegenwoordig in steeds meer organisaties geen fysieke server meer te vinden. Vanaf het moment dat Gartner in 2008 voor het eerst verklaarde dat cloud computing voor een revolutie zou zorgen was echter niet iedereen zo zeker van dit uiteindelijke succes. Veel organisaties waren sceptisch over de overstap naar de cloud. Vooral op het gebied van security en beschikbaarheid waren er tal van tegenstanders. Zo zou het onveilig zijn om al je data elders op te slaan en waren er zorgen dat er niet meer gewerkt zou kunnen worden wanneer de cloud service of de eigen internetverbinding zou uit vallen. Sommigen waren er zelfs van overtuigd dat het een bubbel was die zou gaan barsten.

Inmiddels mogen we wel stellen dat de overstap naar de cloud voor de meeste organisaties niet meer tegen te houden is. Weinig ICT’ers hebben nog de illusie dat zij hun servers en data beter kunnen beveiligen tegen kwaadwillenden dan dat een grote gespecialiseerde partij als Microsoft, Google of Amazon dat kan. Dit geldt zowel voor toegang tot in de cloud opgeslagen data – probeer bijvoorbeeld maar eens op te boksen tegen een budget van 1 miljard dollar voor beveiligingsonderzoek en 3500 specialisten op het gebied van cyber security – als bijvoorbeeld de zekerheid van werkende backups – hoe vaak controleer jij je backup tapes? Cloudaanbieders zelf zijn inmiddels zo ver dat ze over het algemeen een beschikbaarheid van minimaal 99,95% bieden. Daarnaast zijn de internetverbindingen van ons Nederlanders inmiddels zo betrouwbaar dat de beschikbaarheid überhaupt geen discussiepunt meer 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 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. 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. 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.

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.

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.

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