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!
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.