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
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 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!
Citaat: Cloud-transitie betekent dan misschien afscheid nemen van servers, maar zeker niet van nadenken en regie voeren!
Een goede titel van dit artikel zou zeker ook zijn: Afscheid van Servers, maar zeker niet van Service!
IT-er 2.0 mag gerust hierin gerust mee veranderen richting Klant; in die zin is het opvallend dat het woord Cloud nog steeds vaker valt dan het woord Klant. http://www.waardoenwehetvoor.nl
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.