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

Serverless maar niet mindless

Computable Expert

Gijs in ‘t Veld
CTO, Motion10. Expert van Computable voor de topics Digital Transformation, Cloud Computing en Infrastructuur.

Het moderniseren van applicaties en daarmee klanten beter kunnen bedienen is de belangrijkste reden om aan cloud-transitie te doen. De goedkoopste vorm is applicaties uitzetten en de cruciale modules migreren naar SaaS. Daarnaast is het opnieuw naar de architectuur kijken en van api’s voorzien een belangrijke stap om digitale ecosystemen te kunnen realiseren. Maar waar in het landschap gehakt wordt vallen ook spaanders. Hoe gaan we daar mee om?

In traditionele it-organisaties is er een sterke onderverdeling in ontwikkeling en beheer. Ook zien we bij elke organisatie wel een toename in het aantal applicaties, maar wordt er zelden afscheid van een applicatie genomen. Het bestaansrecht van sommige medewerkers is direct afhankelijk van een applicatie. De boodschap dat de applicatie vervangen gaat worden door iets moderners of gewoon uitgezet gaat worden zal niet altijd even goed vallen bij de technisch- en functioneel applicatie-beheerders. De rol van de medewerkers in de it-organisatie zal mee moeten veranderen met het moderniseren van het applicatielandschap.

Serieus aanpakken

"Cloud-transitie moet serieus aangepakt worden."

Bij elke organisatie is tegenwoordig wel een beleid dat voorrang geeft aan SaaS en PaaS boven eigen gehoste applicaties of private cloud. Vaak wordt er begonnen met SaaS diensten. Eerst een kleintje (Dropbox) en later steeds grotere en meer strategische (Office 365). Wat eerst begint als shadow-it, gedreven vanuit de business, krijgt steeds serieuzere vormen. Vervolgens ontstaat er bij de it-afdeling de notie dat een hybride cloud architectuur noodzakelijk wordt. Omdat de huidige omgeving wildgroei kent en moeilijk te beheren is.

Cloud-transitie moet serieus aangepakt worden. Het ontwikkelen van de architectuur begint als iets wat alleen met techniek te maken heeft. Hierbij komen onderwerpen als infrastructuur, security, identity en te gebruiken cloud services aan bod. En aan welke principes en requirements er voldaan moet worden. Allemaal belangrijke onderwerpen.

Naadloze dienstverlening

Het huidige applicatielandschap is vaak ondergebracht bij een hosting provider. Deze provider beheert de infra en de servers en is verantwoordelijk voor het 'technisch' in de lucht houden van het landschap. De hosting provider staat vaak niet te springen om organisaties de cloud in te helpen. Hun verdienmodel is marge op hardware. Daar is ook het eufemisme 'private cloud' waarschijnlijk door ontstaan. Maar wanneer de procedure om een nieuwe virtual machine aan te vragen en op te spinnen twee weken duurt, kunnen we niet echt van cloud computing spreken.

Deze providers zullen dus mee moeten gaan bewegen met de keiharde eisen van hun klanten. Tegelijkertijd zal de eigen organisatie met de nieuwe realiteit van hybride cloud om moeten leren gaan. We hebben met twee omgevingen te maken die technisch én organisatorisch tot één geheel moeten worden gesmeed om naadloze dienstverlening te kunnen bieden. Daar zul je zelf voor aan de slag moeten.

Niet alleen een technisch feestje

"Cloud-transitie is zeker niet alleen een technisch feestje."

Cloud-transitie is dus zeker niet alleen een technisch feestje. Niet alleen de rol van medewerkers verandert, ook de manier waarop de it-organisatie is ingericht. En hoe met het verlenen van (interne) cloud services moet worden omgegaan. Waar sommige rollen zullen vervallen, ontstaan weer nieuwe rollen simpelweg omdat het ontwikkelen voor en het beheren van een hybride cloud omgeving complex is. En omdat het nieuwe skills en samenwerkingsvormen noodzakelijk maakt.

De cloud maakt het met name mogelijk om een sneller time-to-market te realiseren voor moderne oplossingen. Maar zonder bijbehorende, op DevOps gebaseerde en rond functionele domeinen georganiseerde teams zal de cloud op zich niets veranderen aan de snelheid van realiseren van oplossingen.

Het is juist de combinatie van techniek en organisatie die dit mogelijk maakt. De it-organisatie zal getraind moeten worden in deze nieuwe manier van (samen)werken. De functioneel applicatie-beheerder zal onderdeel moeten worden van deze teams. Hij of zij is niet verantwoordelijk voor het in de lucht houden van applicaties, maar voor (delen) van een bedrijfsproces. En met de juiste motivatie en begeleiding zal deze rol en verantwoordelijkheid al snel goed opgepakt en omarmd worden!

Nieuw rollen zoals cloud solution architect en cloud engineer zullen ontstaan. Er zal een cloud regie-team moeten zijn, dat de regie voert over de hybride cloud architectuur en de daarop landende oplossingen. Coaching van de it-organisatie vanuit dit team is ook een belangrijk aspect. En de meestal nog op oude principes werkende hostingprovider zal mee moeten bewegen, want alleen een goede regie is niet voldoende. Cloud-transitie betekent dan misschien afscheid nemen van servers, maar zeker niet van goed over zowel de technische- als de business architectuur nadenken en hier de regie over voeren!

Dit artikel delen:

Reacties

Gijs,
Weinig applicaties zijn platform (OS) agnostic en kennen dus nog altijd een logische server in de vorm van een onderliggend platform. De term serverless is dus misleidend en dat de hosting markt in Nederland door Microsoft met SPLA's onder druk wordt gezet komt omdat de meeste applicaties nog altijd een afhankelijkheid hebben met (een oudere versie van) Windows. Oja, de meeste Nederlandse hosting providers voldoen wel aan de nieuwe eisen betreffende landingsrechten van data. Want dat de niet-gecontracteerde (Shadow IT) cloud oplossingen zomaar geaccepteerd kunnen worden is lachwekkend en gaat voorbij aan de nieuwe regie rol van de functionaris gegevensbescherming.

Oja, ik meen me te herinneren dat de AIVD waarschuwde voor het gebruik van Dropbox en dat de overheid daarom iets soortgelijks gemaakt heeft met Localbox. Misschien dat het nu ook tijd wordt voor een Facebook alternatief?

@Ewout
GNUsocial is een bruikbaar alternatief voor Facebook als het door overheden gepushed zou worden, maar ja FB is makkelijk, net als dropbox. Net als water altijd naar het laagste punt stroomt zo zullen gebruikers altijd naar de weg van de minste weerstand zoeken dus blijven FB en dropbox nog lang bestaan tenzij er daadwerkelijk gestraft gaat worden.
Overigens "serverless is misleidend", blij dat je dat zegt, ik erger me al lang aan die marketingkreet.

Even buiten dat ik het artikel wat lastiger te lezen vind, wil ik -als schrijver over serverless- toch reageren op de kritiek op serverless. Uiteraard heb je nog steeds servers in een serverless scenario, alleen je hoeft te niet te beheren en zie je ze niet. Je gebruikt schaalbare rekenkracht zonder je zorgen te hoeven maken over servers, het beheer van servers of de capaciteit.

In feite heb je geen "ops" ofwel beheer meer nodig. En dat heeft heel veel voordelen. In veel scenario's betaal je extreem veel minder, je hebt praktisch ongelimiteerde rekenkracht en je hebt nul onderhoud. It just works. Betalen naar gebruik ik extrema.

Het is veel puurder omdat je leert denken in functies en declarative code.

Niet alles is gereed voor serverless, maar waar mogelijk passen we het toe. Zo hebben we serverless websites die snel, veilig, schaalbaar en extreem goedkoop zijn. Maar ook serverless databases, data storage en data processing.

OS? Welk OS? Heb niets met een OS te maken en programmeer taal? c#, javascript, python, zeg het maar.

Ik zeg: Geen marketingkreet maar kennisgebrek :-) Sorry jongens. Maar nu weten jullie het en als je vragen hebt, stel ze dan.

Dat is onzin Henri. Dat jij die Server niet ziet betekent niet dat die er niet is.
Jij maakt gebruik van een bepaalde funktie (dbserver) zonder dat je het ijzer ziet, dat wil niet iedereen en over goedkoop kunnen we nog een discussie opzetten. Bij veel SAAS oplossingen heb je toch weer wat extra (software/module) nodig en dat moet aan het einde wel op die server staan anders werkt 't niet. Je zegt het zelf al, "niet alles is gereed voor serverless" dus toch een marketingkreet.

Jan, ik probeer het nog een keer. Ja er zijn servers, alleen je ziet ze niet en ze zijn je zorg niet. Ze hebben geen vaste naam, geen IP adres, je ziet zelfs niet welk OS ze draaien. Een waanzinnig snelle serverless website met honderden bezoekers per dag kost nog geen 10 cent... per maand. Die extra Lambda functies die dingen voor mij regelen kosten vaak nog minder. Ik hoef niet te patchen, niet te updaten, geen downtime. Het probleem met serverless is dat het niet *alle* functies heeft. Niets is perfect, de beheersbaarheid van serverless zit in hele andere dingen waar Gijs eerder over geschreven heeft. Het is ook niet dat alles verdwijnt en alleen serverless overblijft. Maar voor wat het doet is het bijzonder krachtig en revolutionair. Net als dat containers niet de complete vervanger is voor VM's. Maar als iemand die hier dagelijks mee werkt heb ik een onderbouwde mening als het gaat om serverless. Kritiek komt vaak van mensen die het niet kennen of begrijpen. Probeer het eens en brand het dan onderbouwt af, hier is zeker ruimte voor. Maar het afschilderen als onbeduidend of misleidend om de verkeerde redenen vraagt om een reactie. Bij deze.

Hier zijn wat dingen waarmee je een case hebt tegen serverless:
- Er zit vaak een vendor lock-in omdat de aanroep van Serverless per provider anders is
- Het is moeilijk te debuggen
- je zit altijd vast aan een provider, deelt data met een andere partij
- als het stuk is ben je volledig afhankelijk wanneer je provider een oplossing biedt
- in gevallen van extreem gebruik is een andere aanpak efficiënter en goedkoper.

Dat ik daar weinig mee kan, heb je goed aangegeven, van die 5 punten zijn 4 voor mij belangrijk.
"Serverless" beschouw ik als verkeerd label, "gestripte funktionaliteit" beschrijft beter waar het om gaat, en dat dat soms zinnig is bestrijdt ik niet.

Henri, hoe heet die serverless dienst? Of diensten. Ik begrijp het wel, nee natuurlijk draaien die serverless diensten op servers alleen heb je als gebruiker/ontwikkelaar hier helemaal niets mee te maken met wat er op de achtergrond gebeurt en gebruik je een dienst (service) die je afschermt hiervan maar voldoende biedt om uit te voeren (website? ongetwijfeld meer) wat jij wil of nodig hebt. En het schaalt ook nog!

Dacht wel, bij een beetje organisatie heb je vast met meerdere applicaties te maken waarbij je niet ontkomt aan beheer op servernivo waarbij je wel sjoegen moet hebben van de systemen.

Private cloud vind ik helemaal niet zo gek, gebruik maken van technieken die de 'cloud' gaande houden alleen voor intern gebruik op eigen machines. Een combi van virtueel en software defined en de software om het te beheren. Keus te over!

Louis, google AWS Lambda, of Azure Cloud Functions voor inspiratie.

Als taalpurist snap ik wel waar Ewout en Jan op doelen. Als je al die hype en oneigenlijke termen weg stript hebben we het over "dienstloze diensten". Kortom, wat taalkundigen een "contradictio in terminis" noemen; oftewel het klinkt gewoon ontzettend dom.

Henri, heb even wat kort gekeken, klinkt wat als een Container++. Stukje code in diverse talen laten uitvoeren via de diensten van AWS of Microsoft, zonder iets te hoeven optuigen of je om capaciteit te hoeven bekommeren. Best mooi, maar natuurlijk ook nieuwe mogelijkheden in het al bijna ondoorzichtige bos van systemen, technieken, talen, tools en frameworks die ons ter beschikking staan. Veel wegen naar Rome. Het is overweldigend.

Gijs, deze nog. Je schrijft dat veranderingen niet altijd goed vallen bij mensen die hun bestaansrecht ontlenen aan systemen. Dat is inderdaad waar, maar dat is 1 kant van het verhaal en ook een karitkatuur. Wat ook mogelijk is dat onder het mom van innovatie, niet willen achterblijven en mee met de tijd er ook hele domme beslissingen genomen worden. Die vinden weer plaats op een ander niveau, dat is waar techneuten vaak tegenaan lopen. Oliedomme beslissingen op het C-niveau. Nu weet ik wel, iedereen heeft er verstand van maar soms is toch ook handig om naar de techneuten te luisteren. Dat hoeft niet altijd om eigenbelang te gaan.

Een dienst abstraheert altijd iets, daarom is het een dienst. De implementatie, daar zorgt de dienstverlener voor.
Je hoeft iets niet zelf te doen en verstand van te hebben t.b.v. die dienst, bijv een afhaaldienst serveert je eten zonder dat je hoeft te koken.
In dit geval hoef je geen server(s) of middleware te beheren om een schaalbare applicatie te programmeren.
Maar goed, ik lees nooit over stoveless dining als ik een pizza bestel, of carless single-tenant transportation als ik een taxi-ritje wil, terwijl wellicht toch wel ergens een oven of auto gebruikt wordt om het voor elkaar te krijgen.

@Dino Eens, maar een afhaal dienst zou ik het ook niet noemen waarbij je de pizza zo even naar binnen schuift. De serverless diensten klinken mij eerder in de oren als hele nieuwe en andere zorgen. Een iets andere wereld, zelfde programmeertalen. Zelfs las ik in het geval van Java dat het opstarten van de instantie wat langer duurde vanwege het opstarten van de JVM. Gelukkig sommige dingen veranderen niet, hoezo vooruitgang?

Ha allen, ik had deze hele thread even niet meegekregen. Leuke discussies :-) En dank Henri, voor de educatie.
Voor mij betekent echte PaaS overigens gewoon Serverless. Een PaaS dienst waar je een VM'tje voor moet opspinnen en voor de duur dat dat ding draait moet betalen is w.m.b. Nep PaaS. Net als een SaaS dienst waarmee je integreert d.m.v. database synchronisatie Nep SaaS is.
Overigens is alle Software ook niet altijd even Soft. Sommige oplossingen zijn hardcoded ;-)

Gijs, nog wel nieuwsgierig. Serverless is wel redelijk ongedefinieerd. Zelf maak ik nog wel wat onderscheid tussen puur serverless en praktisch serverless. Kun jij aangeven waar jij de scheidslijn ziet?

puur serverless voorbeelden:
AWS Lamda, AWS Step Functions, AWS SNS, AWS SQS
Azure Functions, Azure Storage accounts
Google Cloud Functions
Google Apps Scripts

praktisch serverless:
AWS Relational Database Services, AWS S3
Azure SQL databases

Praktisch serverless SaaS:
Office 365 (Online)
Google G-Suite
Dropbox, etc.

Grijs gebied maar in mijn ogen nog steeds serverless:
AWS Elastic Beanstalk, AWS Opswork
Azure App Services

Geen serverless:
AWS EC2, AWS Lightsail, AWS ECS
Azure Virtual Machines, Azure Container Services

Als je een vast IP adres hebt of op een individuele instance in kan loggen (al is het voor debug) of echt een server "ziet" al is ie virtueel, dan zie ik dat niet als serverless. Er mag zogezegd niets misgaan door verkeerd gebruik, je moet echt niets te maken hebben op iets wat naar server riekt. Containers zijn in mijn ogen dan ook niet echt serverless.

Discussie blijft mogelijk :-) Ik vind het een prachtige tijd in ieder geval. Laatst gewerkt aan een eerste serverless VR module :-) Als je bijvoorbeeld een Oculus Rift of een HTC Vive hebt kan ik je naar ons virtuele trainingscentrum sturen zonder dat je iets hoeft te installeren (aangenomen dat je een moderne browser hebt). Dat was overigens gedaan met AWS Sumarian...

Zodra Azure App Service niet meer in de Azure Calculator terug komt als VM'etjes komt het uit het grijze gebied. Dit is puur een transitie fase. Microsoft gaat erg snel, maar dit kost even tijd. Azure PaaS zal m.i. binnen een jaar puur serverless zijn. Logic Apps is al serverless. Net als functions.
Daarnaast zie je een trend om dingen in Azure PaaS te verSaaSen. Bijvoorbeeld IoT Central.
SaaS is eigenlijk altijd serverless.

Puur en praktisch. Naar server rieken. Eigenlijk serverless zijn .. Rutte kwam ook met zoiets : goed en verkeerd populisme. Het werd er niet duidelijker op. Zeker niet als server zoveel betekenissen heeft. Het OS daaiend op VM. De hardware alleen. Het OS alleen. De services die geleverd worden. Applicatie server, middleware. Services aan de eindgebruiker. Services aan een applicatie, een API...

Ok, onze meningen over serveless zijn niet veranderd maar wel bevestigd.
Tijd voor een nieuw onderwerp.

Wat ik me vooral afvraag: welk probleem lossen deze 'serverless' toepassingen op? Wat kan je ermee wat eerder niet mogelijk was? En als je dan een oplossing hebt kan je dan ook zomaar overstappen van de ene severless oplossing aanbieder naar de andere aanbieder?

Een van de kenmerken van computerland vind ik de veelheid. Er zijn zoveel systemen, tools en talen dat het amper nog te bevatten is. En als het even tegenzit, kijk naar Javascript, je ziet de bomen door het framework bos niet meer. Iedereen zijn eigen framework en iedere nieuwe techniek is het helemaal. Nu is het weer serverless, het is lastig om door alle hypes en trends heen te kijken en het op waarde te schatten. En vooral denk ik, wat is de techniek die past bij jouw probleem? Het zal wel alle kanten opkunnen.

Inderdaad, tjid voor een nieuw onderwerp.

wat ik me afvraag, waarom is mindless een probleem ?

@Dino synonyms: foolish, senseless, silly, thougthless.

Wat pas echt lachen wordt is dat de bedrijven en overheidsinstellingen 50% verhoging van de tarieven van de "Cloud" dienst voor hun kiezen krijgen, en dan niet zomaar weg kunnen, nul onderhandelingspositie/ruimte hebben en dus hun eigen producten/diensten duurder moeten maken om de IT te kunnen blijven bekostigen

Jouw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met je persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

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.