Ontwikkelaars snakken er al jaren naar, maar sinds vorig jaar is het realiteit: serverloze architectuur. Het is een wat verwarrende term, omdat er wel degelijk sprake is van servers. Ontwikkelaars kunnen ontwikkelen zonder zich druk te maken over beheer van servers. Daarmee hebben ze de handen vrij voor belangrijkere zaken. Serverloze architectuur is dan ook de toekomst voor ontwikkelaars.
De meeste bedrijven ontwikkelen eerst applicaties en zetten ze vervolgens pas op servers. Dat betekent dat ze van tevoren moeten bepalen hoeveel opslagruimte en rekenkracht ze nodig gaan hebben en dat ze alle hardware en software moeten gaan optuigen en implementeren die nodig is om de applicatie te draaien. Een tijdrovende en vaak kostbare aangelegenheid.
Maar wat als je als ontwikkelaar gebruik zou kunnen maken van een dienst die de onderliggende infrastructuur al voor je klaar heeft staan, precies op maat en zonder dat je er omkijken naar hebt? Technisch gezien kan geen enkele applicatie natuurlijk serverloos draaien, maar met bijvoorbeeld de Lamba Service van AWS wordt de complexiteit van de implementatie van servers, opslag en databases, volledig geautomatiseerd. De server wordt zo als het ware onzichtbaar.
Schaalbaarheid zorgt voor flexibiliteit
Voor ontwikkelaars kan een serverloze architectuur echt een uitkomst zijn. Infrastructurele randzaken leiden immers alleen maar af van de kern van hun bezigheden: het ‘kloppen’ van de best mogelijke code. Tijd is geld, en met serverloze architectuur kunnen ontwikkelaars zich richten op datgene wat ze van de concurrentie gaat onderscheiden, zoals het ontwikkelen van die ene baanbrekende applicatie. Maar er zijn meer voordelen.
Het grootste voordeel van serverloze architectuur is de schaalbaarheid. Applicaties zijn eenvoudig op grote schaal te testen. Dat kun je als ontwikkelaar wel in eigen beheer doen, maar dat kan heel tijdrovend zijn en dat kunnen veel ontwikkelaars zich niet veroorloven. De winst die je op dat gebied met serverloze architectuur kunt behalen, is enorm.
Microservices
De flexibiliteit wordt nog verder vergroot door de mogelijkheid microservices te gebruiken. Microservices zijn kleine, onafhankelijke processen die samen een applicatie draaiende houden. Ik verwacht dat deze in 2016 in toenemende mate belangrijk zullen gaan worden.
Met microservices kun je grote projecten beheersbaar maken. Door je applicaties op te splitsen in meer componenten, houd je ze overzichtelijk en zijn ze ook beter toegerust op groei in de komende jaren. Bovendien zorgt ook dit weer voor meer flexibiliteit en lagere kosten: in plaats van dat je één enorme applicatie uitzet, kun je nu een applicatie met een single-action trigger uitzetten en alleen betalen voor de rekenkracht die je gebruikt, waarbij we tot op honderd milliseconden nauwkeurig het gebruik kunnen meten. Je schrijft de code, definieert de event triggers en de service zal automatisch draaien op het moment dat de voorwaarden zijn vervuld. Zo eenvoudig is het.
Nooit teveel betalen
Dankzij de eenvoudige schaalbaarheid is ook de financiële kant van serverloze architectuur erg interessant voor ontwikkelaars. Ze betalen immers naar gebruik. De ene maand is dat misschien wel meer of minder dan de andere maand. De kosten stijgen of dalen mee. Er zijn bovendien geen hoge instaptarieven. Een website kan zo al voor een paar dollar draaiende worden gehouden, dankzij serverloze architectuur.
Toekomst
Serverloze architectuur is in mijn ogen absoluut de toekomst. Ik ben erg enthousiast over de voordelen die ontwikkelaars dankzij serverloze architectuur in de praktijk weten te behalen. Ik sta elke keer weer versteld van wat ontwikkelaars voor elkaar weten te krijgen. Men heeft de sprong van DevOps, naar NoOps inmiddels gemaakt. Ik ben er trots op dat serverloze architectuur daar een belangrijke bijdrage aan levert.
“serverloze architectuur. Het is een wat verwarrende term, omdat er wel degelijk sprake is van servers.”
eeeeeeeeeh, ja.
Wie bedenkt zo’n term eigenlijk ?
Lezen we binnenkort over ‘het Internet without things’ ?
Helemaal eens met dit artikel.
Grappig, in 2011 schreef ik al samen met Peter van Eijk een ebookje “Run your business in the cloud- Kick-start your new company with server-less IT” (voor de liefhebber : https://goo.gl/p5KHSs )
Dit ging dan over de afnemers kant, en uiteraard met bijv. AWS RDS kun je een database runnen zonder zelf de server te hoeven beheren.
Dino : Voor de mensen voor wie het verwarrend is; zij zijn ook niet de doelgroep.
Eind jaren 60 schreef E.W. Dijkstra het bekende artikel “Go To Statement Considered Harmful”.
In hoeverre wijken events eigenlijk af van het beruchte goto-statement?
Waar je met GoTo nog naar één plaats in de code springt, daar kun je met een event tegelijk (!) naar alle plaatsen in de architectuur springen waar dat event wordt geconsumeerd.
Kortom: met goto-statements maak je spaghetti-code en met events (of event triggers) maak je spaghetti-architecturen.
Terwijl we al sinds jaar en dag weten dat we juist naar lasagne-architecturen toe moeten.
ik denk dat de consument triggert. Een service is een routine, die naar een consument luistert, die bedient, of daarmee klaar is. Heel overzichtelijk en gestructureerd dus.
Volgens mij kun je met microservices geen spaghetti maken, alleen ravioli. Ravioli als modulaire stukjes lasagna. Belangrijkste is wel dat de chef kan koken zodat het uiteindelijk te vreten is. Het kan allemaal nog verpest worden als de bediening te lang op zich laat wachten
Vind serverloze architectuur ook een misleidende term. Dat is misschien geen eigen server hoeft te onderhouden is waar en dat je serverside inrichte met de AWS diensten dat kan natuurlijk, maar het doet niets af aan je architectuur (client-server). En maar hopen dat die AWS diensten precies voor jou voldoen, en ook dat zal weer een wereld zijn die je eigen moet maken.
Jack, in de basis is een computer al eventdriven en bij GUI’s is dat ook het model voor de toepassing, eventdriven met een event loop. Hoe zou je het anders willen en wat moet ik me dan voorstellen bij lasagne architectuur?
Louis, Jack,
Hoe dichter je bij de processor komt hoe meer je zult merken dat “compute” één groot GOTO feestje is. Het zijn de wat hogere programmeertalen die de goto uit het zicht haalt.
Louis, wellicht dat voor sommige mensen “serverloze architectuur” verwarrend is, niettemin denk ik dat het principe erachter extreem krachtig is.
Stel je hebt een datawarehouse (deze kan ook serverloos, neem bijv. Amazon Redshift) en er wordt ruwe data aangeleverd. Afhankelijk hoeveel en hoe vaak moet je dan servers kopen (of virtualiseren) inrichten, klaar zetten en batchverwerkingen starten. Dat kost geld.
Met serverloze verwerking zijn de kosten nagenoeg 0. Je betaald een microscopisch laag bedrag om de data tijdelijk op te slaan in een s3 bucket en als je Amazon Lambda gebruikt een paar seconden processortijd om het bestandje te bewerken en je datawarehouse in te knallen. Dag geen bestanden aangeleverd? Een dag geen kosten. Heb je ineens extreem veel verwerkingkracht nodig? No problem.
Maar in geen geval heb je daar iets van hoofdpijn aan of moet de capaciteit worden uitgebreid. Gewoon; rekenkracht als een service.
“En maar hopen dat die AWS diensten precies voor jou voldoen,” tja. Als de treinen niet rijden en de bussen staken kun je ook niet met het openbaar vervoer reizen. Nu kan ik je verklappen dat AWS het een stuk beter doet dan de NS….
Serverloze architectuur kent nagenoeg geen nadelen en heeft zeer veel aansprekende voordelen.
– veilig
– goedkoop
– schaalbaar
– eenvoudig te bedienen
– etc.
Dat het een wat verwarrende term is, dat schrijft de auteur zelf in zijn tweede regel. Natuurlijk halen de hogere programmeertalen de goto uit het zicht. Daarom zijn ze hoger. Voor lagere talen is efficientie belangrijker dan structuur, so just straight jump/go to the fastest sotion.
Soort goto-less programming in die hogere programmeertalen 😉
voorlopig oeverloze zwets architectuur alom.