Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Ontwerpprincipes voor de cloud

 

Computable Expert

Henri Koppen
Directeur, THINGKS. Expert van Computable voor de topics Digital Transformation, Cloud Computing en Start-ups.

Ieder bedrijf is tegenwoordig in meer of mindere mate een it-bedrijf. Neem het it-component weg van een bedrijf en praktisch niet één organisatie functioneert meer. Maar we worden ook steeds meer een leverancier van een it-product of -dienst: Contact zoeken via de website, digitaal kunnen factureren of bestellingen doen op basis van zelfbediening.

Maar denk ook aan het delen van bestanden en samenwerken, of het openstellen van interne gebruikte software middels webservices, zodat derde-partijen bijvoorbeeld zonder tussenkomst van een medewerker een order kunnen plaatsen.

Dit soort initiatieven beginnen klein, maar groeien langzaam uit, waardoor het een belangrijk onderdeel wordt van het onderscheidende vermogen van de organisatie. Omdat er vaak aan het begin van zo’n traject niet nagedacht is over de langere termijn zijn hier een aantal ontwerpprincipes die de levensduur van je diensten kunnen vergroten en het opbouwen van een technische schuld kunnen vermijden.

Wereldwijd

Globaal als uitgangspunt is een opwarmertje. Steeds vaker staan de (virtuele) servers niet in het land waar de organisatie zijn diensten aanbied. Of draait de website ergens anders dan waar de gebruiker de dienst gebruikt. Dit heeft gevolgen als er bijvoorbeeld vastgelegd wordt wanneer welke gebruiker wat doet. Hou altijd rekening met gebruikers en tijdzones. Neem meertaligheid altijd mee in het ontwerp, aangezien later toevoegen vaak lastig is. Dit geldt al bij de website van de organisatie. Naast Nederlands wil je dan ook Engels aan kunnen  bieden en een taal achteraf toevoegen leidt tot allemaal uitdagingen.

Multitenant

In het verlengde van meertaligheid: Cloud computing is fundamenteel gericht op het bedienen van meerdere klanten, zonder dat deze bij elkaars data kunnen. Zorg ook dat meerdere klanten naast elkaar kunnen leven in een dienst. Maak iedere versie al vanaf dag één klaar voor multitenancy. Zo maken ontwikkelaars vaak de keuze of iedere klant een eigen database krijgt, of dat er meerdere klanten in één database kunnen bestaan. Zorg juist dat beide scenario’s mogelijk zijn.

Zelfbediening is de basis

De kracht van zelfbediening kan moeilijk overschat worden. Verregaande zelfbediening zorgt voor schaalbaarheid: Meer klanten kunnen bedienen met minder eigen arbeid op tijdstippen die de klant het beste uit komt. Zelfbediening betekent ook dat de organisatie de automatisering onder controle heeft en een mate van volwassenheid bereikt heeft. Zelfbediening is vaak complexer dan het lijkt. Meerdere disciplines van software defined tot en met 'user experience' en interactief ontwerp komen eraan te pas en ook de infrastructuur moet het aankunnen.

Alle communicatie over webservices

Webservices zijn interfaces tussen apparaten/applicaties over het netwerk en worden ook wel eens aangeduid als application programming interface (api). Webservices praten in de regel over http- of https-verbindingen en dat heeft als voordeel dat ze niet gebonden zijn aan specifieke besturingssystemen, programmeertalen of protocollen. Het voordeel is dat een webservice in zichzelf kan bestaan en functioneren, maar ook met alles en iedereen kan communiceren. Ik ben er groot voorstander van dat alle applicaties alleen maar communiceren door middel van webservices, zelfs in een client/server scenario. Met andere woorden: Een applicatie heeft geen directe verbinding meer met de database, maar haalt zijn data en business-logica uit de webservice laag. De voordelen zijn immens, maar er zijn ook nadelen. Als extra tussenlaag kost dit performance en latency en het is makkelijk om een spaghetti aan koppelingen te maken, waardoor een oerwoud ontstaat.

Identity and access management

Gelukkig is hiervoor het ontwerpprincipe 'Eén identity and access management (iam)'. Alle toegang tot data wordt geauthenticeerd over één kanaal. De autorisatie zelf vindt binnen de applicatie of service zelf plaats. Voordelen is centraal beheer, maar ook toegang en inzicht in datastromen, wat leidt tot meer veiligheid, betere controle en eenvoudiger regie voeren. Iam is zelf in feite ook een webservice.

Iedere gebruiker die toegang wil tot iets moet dus geïdentificeerd worden door de iam en je kunt ook instellen tot wat een gebruiker toegang heeft. Uiteraard geldt wel: Als je software maakt voor anderen moet het aansluiten op zo veel mogelijk iam-systemen. Saml lijkt overigens in een rap tempo de winnende verbindende taal te worden die iam-systemen spreken.

Iam zit echt in de lift, steeds meer cloud aanbieders maken dit onderdeel van hun dienstverlening en de complexiteit om het toe te passen neemt snel af. Vooral grotere organisaties hebben veel baat bij IAM om te kunnen voldoen aan compliance en als onderdeel van governance.

Separation of concerns

Kun je het ene onderdeel los gebruiken van het andere onderdeel? Door verantwoordelijkheid en logica goed te scheiden worden de life-cycles van oplossingen langer. Afhankelijkheden zorgen voor allerlei problemen. Als data corrupt raakt in een bepaald deel en deze heeft ook afhankelijkheden in de keten, dan kan er niet zonder na te denken een backup teruggezet worden. Nu is het functioneel gescheiden van 'concerns' niet altijd makkelijk. Als er bijvoorbeeld een service is die scans in leest, dan wil je dit gescheiden houden van het workflow systeem wat iets met die scans doet. Het scannen kan dan ook voor meerdere doeleinden gebruikt worden.

De praktijk

Ik kom bij veel verschillende soorten bedrijven waaronder software-ontwikkelaars. Ik ben nog geen oplossing tegengekomen die al deze principes hanteert en ik heb wel vaak software gezien die aan geen enkel genoemd ontwerpprincipe voldeed. Wat ik mooi vind aan deze principes is dat ze heel goed te toetsen zijn. Er kan een checklist van gemaakt worden. Het zijn een soort standaard terugkerende requirements.

Deze principes leiden naar schaalbare oplossingen met een lange levensduur. Hiermee wordt een platform gerealiseerd waaraan ook andere partijen waarde kunnen toevoegen en dit zorgt weer voor een ander bij-effect: Kijk bijvoorbeeld eens naar de dominante positie van Apple en Android. Zij hebben een platform gebouwd en daarop is een heel ecosysteem ontstaan. Dit is de reden waarom Microsoft het moeilijk heeft een groot marktaandeel te veroveren. Je kunt de principes van een systeem kopiëren, maar niet het gehele ecosysteem, al sla je daar miljarden op stuk.

Uiteraard is dit slechts een algemene greep uit de ontwerpprincipes die ik hanteer. Welke principes hanteer jij? In de reacties kunnen we zo een opbouwende discussie voeren.

Dit artikel is afkomstig van Channelweb.nl (https://www.channelweb.nl/artikel/5187335). © Jaarbeurs IT Media.

8


Lees ook


 

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.