SaaS-ontwikkelaars, let op: klanten willen dezelfde controle als ‘on-premises’

Meer cloudgebruik en meer ‘cloud-native’: heeft dat gevolgen voor SaaS-aanbieders? Na de tendens om alles naar publieke en private clouddiensten te verhuizen is nu de tegenbeweging gaande. Organisaties willen weer controle over hoe en waar applicaties draaien.

Of je nu gestaag de transitie naar de cloud aan het maken bent, al jaren in de cloud werkt, of alleen een Office 365-account hebt: je kunt anno 2024 niet meer om de cloud heen. Hoewel er natuurlijk verschillende manieren van cloudadoptie zijn, zien we momenteel een duidelijke trend richting cloud-first (applicaties worden in de cloud ondergebracht, tenzij). Applicaties worden meer en meer cloud-native ontwikkeld. Gartner verwacht dat in 2025 zo’n 85 procent van de bedrijven zal kiezen voor een cloud-first-strategie, eventueel in combinatie met cloud-native ontwikkelde applicaties. Bovendien is de verwachting dat tegen die tijd 95 procent van de workload zal draaien op cloud-native platformen.

Dat applicaties steeds vaker cloud-native ontwikkeld worden heeft gevolgen voor SaaS-aanbieders. Het vereist een andere visie op softwareontwikkelen. Want waarom zou een organisatie straks nog afhankelijk willen zijn van de cloud die in beheer is van de softwareontwikkelaar? En waarom zouden de verschillende SaaS-oplossingen die een bedrijf gebruikt niet onafhankelijk van de leverancier in hun eigen cloudinfrastructuur kunnen draaien?

Van ‘op locatie’ naar de cloud

On-premises (op eigen locatie) is voor de meesten onder ons een bekend en vertrouwd begrip. Het verwijst naar een IT-omgeving waarbij je als organisatie beschikt over eigen servers, storage, back-up, firewalls en hardware die op je bedrijfslocatie of in een datacenter ondergebracht zijn. Het beheer wordt verzorgd door je eigen vertrouwde systeembeheerders, of in het geval van outsourcing, een externe partij. Wil je een nieuwe applicatie installeren? Dan moet je hiervoor middelen vrijmaken in de bestaande IT-omgeving of de IT-omgeving uitbreiden met extra middelen (hardware). Dit geeft een grote mate van zelfredzaamheid: echter, bij afschalen wordt de TCO niet lager omdat de investeringen in de hardware dan immers al gedaan zijn.

Maar nu steeds meer bedrijven de overstap maken naar een publieke of private cloud en het gebruik van SaaS-applicaties exponentieel blijft groeien, is er beduidend minder behoefte aan eigen (gevirtualiseerde) IT-omgevingen. Applicaties worden nu veelal als SaaS-oplossing afgenomen (vaak ook gedwongen, omdat softwareontwikkelaas de lokale variant niet meer aanbieden), waardoor de eigen IT-omgeving volledig van het speelveld aan het verdwijnen is.

Dit heeft voornamelijk te maken met de laagdrempeligheid en aanzienlijk lagere startinvesteringen die gepaard gaan met cloudadoptie. Je hoeft per slot van rekening geen eigen IT-omgeving meer op te tuigen (of uit te breiden) wanneer je gebruik wilt maken van de nieuwste versie van een applicatie. En de meest recente ontwikkelingen op het gebied van zowel hard- als software hoeven niet meer gevolgd te worden om de applicatie volledig tot zijn recht te laten komen. Cloudadoptie leert ons daarom dat er veel zorgen uit handen genomen worden.

Van de cloud naar het nieuwe ‘op locatie’

Laat ik er gemakshalve vanuit gaan dat over vijf jaar vrijwel elke organisatie al haar IT-toepassingen exclusief in de cloud plaatst. Deze lijn volgend zullen organisaties zoeken naar uniformiteit en standaardisatie, waardoor ik voorspel dat ieder bedrijf een eigen cloudstrategie ontwikkelt en deze vertaalt naar zijn eigen cloudoplossing. Dit zal in de meeste gevallen niet één cloud zijn: organisaties zullen hun workloads veelal verdelen over een verzameling van clouds. Uiteraard veel hybride, maar ik verwacht met name een groei in hypercloudoplossingen (een combinatie van on-premises, private en publieke cloud). De cloudkeuze hangt per applicatie af van zaken als de gewenste veiligheid, beschikbaarheid en compliancy, waarbij kosten natuurlijk eveneens een behoorlijke invloed op de besluitvorming zullen hebben.

Stel dat de afdeling finance nieuwe software wil gebruiken en hiervoor een geschikte SaaS-applicatie vindt. Is het dan niet raar om als organisatie ineens afhankelijk te worden van de private of publieke cloud van die externe SaaS-aanbieder? Je komt in een afhankelijkheidssituatie terecht die je met on-premises juist vermijdt. Welke continuïteitsgaranties heb je bijvoorbeeld als je SaaS-aanbieder in de (financiële) problemen komt? Ga je per applicatie die de organisatie gebruikt een exitplan inrichten? Voor veel bedrijven is het ook vanuit compliance-oogpunt belangrijk om te weten waar de data worden opgeslagen, wie toegang tot die gegevens heeft en welke maatregelen er in het licht van beschikbaarheid en cyberveiligheid genomen zijn.

Ik voorspel dat bedrijven, vooral wegens de grote organisatorische inspanningen die IT-verandering vragen, behoefte hebben aan SaaS-applicaties die in hun eigen cloudomgeving opgenomen kunnen worden. Bedrijven profiteren dan van alle belangrijke cloudvoordelen, zoals lage startkosten, betalen-per-gebruik en schaalbaarheid, maar dan wel binnen de eigen raamwerken voor cyberveiligheid, compliancy en (bedrijfs)continuïteit. Ze zijn voor dergelijke zaken dus niet afhankelijk van de SaaS-aanbieder. Updates doen ze als het hun uitkomt, terwijl retransitieplannen per leverancier en de beruchte vendor lock-in eveneens geen issues meer zijn.

Daarnaast is het geheel, door het delen van middelen (zoals opslag en databases), efficiënter in te richten dan bij het gebruik van allemaal losse SaaS-applicaties, waardoor de totale cloudkosten dalen. Het belangrijkste voordeel is echter het voorkomen van continuïteitsrisico’s wanneer het gaat om de SaaS-leverancier zelf. De praktijk leert namelijk dat er tot op heden weinig – te weinig in mijn optiek – aandacht is voor de mitigatie van de risico’s die een faillissement van je SaaS-leverancier met zich meebrengt.

Een voorbeeld is natuurlijk het failissement van Powerdale. Stel je eens voor: je hebt de energie via je eigen zonnepanelen, je hebt de gebruiker in de vorm van een elektrische auto en je hebt de laadpaal. Maar het verbindende element mist door dit faillissement, waardoor het niet mogelijk is je eigen stroom via je eigen laadpaal in je eigen auto te krijgen. En verplaats een dergelijk scenario dan eens naar jouw bedrijfskritische applicatie.

Gevolgen voor SaaS-aanbieders

Maar hoe voorkomen we dat er veel regels en procesmatige rompslomp verschijnen als het hierboven geschetste scenario werkelijkheid wordt? SaaS-aanbieders, oftewel softwareontwikkelaars, moeten er in de toekomst terdege rekening mee houden dat ze hun applicatie cloudonafhankelijk schrijven, in gebruik laten nemen en onderhouden: multicloud en multi-tenancy dus.

Maar hoe ga je daar mee om? Praktisch gezien betekent dit voor de sotwareontwikkelaar dat er geen gebruik gemaakt kan worden van cloudspecifieke functionaliteiten, dat de software volledig geautomatiseerd uitgerold wordt én dat iedere wijziging middels automation tooling plaatvindt. Dit alles om klanten een voorspelbaar SaaS-product met een constante kwaliteit aan te bieden, waarbij snel vastgesteld kan worden of afwijkend gedrag het gevolg is van de applicatie(update) of de onderliggende cloudinfrastructuur. Het resultaat hiervan is dus ook dat de DevOps-specialisten van SaaS-leveranciers de handmatige installatie los moeten laten en zich volledig moeten focussen op geautomatiseerde deployments en Infrastructure as Code (IaC).

De uitdaging voor SaaS-leveranciers is niet alleen cloudonafhankelijk software ontwikkelen, er dringt zich ook de vraag op of je virtuele machines of microservices gaat gebruiken. Een VirtualMmachine (VM) leent zich in de regel voor een verhuizing naar een andere cloud, zoals van AWS naar Microsoft Azure. Maar om voor iedere applicatie een set aan VM’s in je cloud onder te brengen met in potentie verschillende besturingssystemen en databases én de bijbehorende uitdagingen voor het operationele beheer lijkt me niet wenselijk. Voor dergelijke strategieën is het van belang dat zowel door de gebruikers van de SaaS-oplossing als de softwareontwikkelaar ‘containerisatie’ omarmd wordt. Dat is geen garantie, maar wel een voorwaarde dat een applicatie cloudonafhankelijk ontwikkeld is.

En als de markt zover is, welke tools ga je dan als softwareontwikkelaar gebruiken om deze applicaties naadloos en zonder downtime te updaten wanneer er een nieuwe versie uitkomt? En hoe ga je om met zaken als:

• Het toegang verlenen tot het deel van je cloudomgeving zodat de sofwareontwikkelaar de applicatie kan inzetten.
• De demarcatie van verantwoordelijkheden als het gaat om beveiliging, beheer, monitoring, back-ups en natuurlijk de updates en upgrades?

Op dit moment heeft Kubernetes wat mij betreft de beste papieren om dergelijke uitdagingen het hoofd te bieden. Besef echter wel dat Kubernetes een kennisintensief platform is dat interne expertise of de hulp van een gespecialiseerde partner vereist bij het gebruik.

Zorg dat je je applicaties in de cloudomgeving van de klant kunt plaatsen

SaaS-aanbieders die met name bedrijfskritische softwareoplossingen leveren zullen vroeg of laat te maken krijgen met het hierboven beschreven scenario. De praktijk leert ons zelfs dat eindklanten die voorop lopen op het gebied van digitale transformatie deze eis nu al neerleggen bij hun softwareleveranciers en SaaS-aanbieders. Het is dus belangrijk om je zo snel mogelijk bewust te worden van de vragen, verwachtingen en eisen die toekomstige en huidige eindklanten hebben met betrekking tot het in de eigen cloudomgeving onderbrengen van SaaS-applicaties.

Over de auteur: Paul Bijleveld is Managing Director en Senior Partner bij ACC ICT.