Doar 5 ani le-a luat sa-si dea seama ca ceva gandit doar pentru utilizare rara nu e ideal pentru utilizare frecventa? 
Unii musca mai tare din hype decat altii.
Din pacate noi ca devi ne lasam mult prea repede dusi de hype. Este o lipsa clara de educatie in zona asta, as putea spune.
La fel cum exista o lipsa grava de educatie financiara la populatia adulta din romania( cam stretched comparatia dar in fine), la fel cred ca ne-ar trebui si un fel de “hype restrain” crash course.
Vizavi de de serverless….e o tehnologie misto, dar prea ajunsese sa fie bagata pe gat peste tot. Si e clar ca nu are ce cauta peste tot.
PS. Un proiect serios de la Epic Games, este 90% serverless. Am fost la un interviu la ei pe la inceputul anului. Au mai multi SRE/devops decat devi in momentul asta. O fi bine? O fi rau?
Nu e invers? Adica technologiile sunt alese de manageri dupa hype, nu de dezvoltatori.
Nu prea stiu multi manageri ce-i o tehnologie sau alta.
Imi amintesc cat entuziasm aveau unii colegi dezvoltatori sa mute tot proiectul pe serverless in urma cu cativa ani.
Mie intotdeauna mi s-a spus cu ce sa lucrez de clientii mei: PHP, Java, chiar C.
Si intr-un fel mi se pare corect. Ei platesc asa ca ei trebuie sa decida ce tehnologii sa foloseasca in functie de cat costa un dezvoltator.
Chiar daca nu e ca la medici, cu jurăminte, e bine totuși sa le explicăm clienților care sunt riscurile la care se supun. Dacă nu ii interesează, ne vedem de treabă. In cazul serverless mie riscurile cele mai mari mi se par vendor lockin-ul, lipsa unor structuri clare a proiectelor care pot sa explodeze in copy paste-uri si lipeli atunci când cerințele de business evoluează si nu in ultimul rând plafonarea staffului tehnic, care in loc sa învețe sa inoveze o sa învețe sa configureze.
Hype-urile sunt create si artificial. Firmele mari investesc in marketing si articole pe medium, oamenii se entuziasmează se alătură la bulgăre, aud si managerii de hype, vad oportunitatea să se faca remarcați cu soluții cutting edge (perceived), si asa am ajuns toți să programam sisteme care trebuie sa scaleze de parcă suntem toti Netflix.
Lucram undeva, sistemul putea sa proceseze un batch de date in cateva ore. Dupa ce l-au inovat dura zile.
Cloud providerii au tot interesul sa convingă sa folosim serverless, sau serviciile lor si asa am ajuns sa avem mai mult ansible sau terraform sau you name it, decât logică de business in cod.
/rant over
I have some bad news for you:
Frontend-ul se îndreaptă pe edge rendering/pre-rendering. Totuși mi se pare un use-case foarte bun, în special combinat cu caching.
Eu cu serverless am avut deaface cu lambda si prima problemă era că suportau versiuni antice de node. Trebuia să încarci node cu node.
După am lucrat la o extensie de Google Sheets cu quota-uri destul de stricte. Dacă cumva ai scris un infinite loop contul tău de dev era gata pe ziua aia și trebuia alt cont. Nici nu aveai un mod de a opri ceva request.
Nu cred că știți că toata platforma de Google Docs, Sheets… e o platformă serverless cu un script rulat in V8 per document/organizatie la fiecare request. (Poti inclusiv crea un web script - un endpoint in care să faci cam orice)
Dar e super enervant fiindcă nu poți opri ceva pornit deja (sau nu puteai), e nebunie curată cu quota-urile, niciodată nu știi când treci de ele și îți moare extensia/aplicația cu erori criptice.
Nu prea sunt de acord cu voi cum ca serverless ar fi un hype. As zice ca-i mai degraba o necesitate, de la un nivel incolo.
Pai hai sa vedem care ar fi alternativa la serverless. E clar ca aici vorbim de proiecte foarte mari, foarte scalabile.
Alternative ar fi sa ai doar niste instante de EC2, adica niste servere bare-metal , pe care sa-ti instalezi tu toate serviciile si sa le faci manage. Sa faci tu manage la Kubernetes, la Kafka, la RabbitMQ, la baza de date si asa mai departe. Stiti cat efort, cata experienta/expertiza ar presupune asta? Care ar fi riscurile?
Daca nu ar fi mers pe serverless, probabil ar fi avut nevoie de si mai multi SRE/DevOps. Serverless-ul din contra, reduce necesitatea de DevOps.
Realist vorbind, cam ce procent din proiecte la care lucrezi tu, cunoscuții tăi sau cunoscuții acestora crezi că vor ajunge vreodată la punctul la care vor avea nevoie de tot hype-ul cu care suntem intoxicați?
Și în continuarea întrebării de mai sus: cam câte sisteme crezi că-s over-engineered la modul grosolan? [1]
Eu personal am nimerit în diverse organizații cu WordPress pus ori pe AWS ori pe Google ori pe Azure. Cu load balancer, cu RDS, cu etc. Că deh, trebuie infrastructură serioasă pentru a ține 5k vizitatori/zi.
↩︎
Confunzi serverless cu Software-as-a-Service (SaaS). Gazduiri managed de Kubernetes, baze de date, etc ofera mai orice cloud provider si ajuta mult.
Serverless/lambda e cand iti impachetezi site-ul intr-un anumit mod, iar sistemul ii face deploy cand vine o cerere, proceseaza cererea, apoi il da jos. Ideal cand ai 10 cereri/zi pentru a plati doar timpul folosit de ele (nu lasi un VM pornit non-stop – n-ai nevoie de un “server”), sau cand ai ceva batch job ce ruleaza periodic. Mai putin ideal cand ai un site ce e folosit non-stop.
Ma surprinde cat de repede ai ajuns la concluzia asta. Practic nu mai exista teren de mijloc intre serverless si “u run everything on your own infra”?
Sa zicem ca vrei sa folosesti AWS(eu nu prea le am cu AWS ca de ceva vreme lucrez numai in GCP, dar fac un exercitiu de memorie). In exemplul dat de tine poti folosi Amazon Kubernetes service cu SQS, S3 si o Aurora/Dynamo. Si ai un proiect mult mai modular, cu risc de vendor lock-in minim. Dar nu se numeste ca faci serverless.
Sau intelegem lucruri diferite prin serverless? Ca poate fi si asta.
Frontend-ul poate face ce doreste el. La urma urmei, frontend-ul modern poate fi vazut ca o alta aplicatie de sine statatoare care doar comunica cu restul stack-ului printr-un API.
Problema pentru multi oameni care canta prohodul backendului de dinainte de era noastra, este ca nu vei depasi nivelul de aplicatie simpla folosindu-te de tool-urile date de tine ca exemplu mai sus.
Sunt perfect de acord ca si tool-urile alea isi au rolul lor, la fel toolurile no-code/low-code, dar in faza initiala nimic nu este complicat(sau atat de complicat incat sa nu se poata face).
Complexitatea vine ulterior, cand produsul se mai maturizeaza putin, cand deja are n modificari facute pe logica de business. Cand apar integrari cu 3rd party-uri care inteleg numai de X protocol. Si nu o sa mearga sa le zici ca nu te intereseaza…ca tu ai lambda pe backend si sa se descurce din Api Gateway cumva.
Si sa nu se inteleaga ca sunt dogmatic. Pro containere si anti serverless…desi am un oarecare bias spre containere, folosesc serverless. Usecase-ul meu favorit este…upload si resize de imagini.
Am de toate la mine
- bare metal - ca sunt restrictii de securitate
- VM-uri
- In AWS cu Docker containers
Uneori mai pierd timpul incercand sa inteleg fisiere yaml 
Am un coleg care lucreaza cu functii lamnda la aws. Ia numa 3 secunde sa deschida o conexiune la baza de date. Cica banii nu sunt o problema 
Din continutul articolul, autorul zice asa
A serverless project typically includes a fully serverless stack which can include (using a non-exhaustive list of AWS services):
API Gateway
Cognito
Lambda
DynamoDB
DAX
SQS/SNS/EventBridge
Desi, si eu eram tentat sa cred ca serverless inseamna, basically, lambda, de fapt, citind si o parte din articol, am realizat ca serverless inseamna sa folosesti servicii managed by the provider.
Daca vorbim de DynamoDB, e un serviciu managed by AWS. Nu-ti bati tu capul sa ai un EC2 instance pe care sa-i faci deploy.
Daca vorbim de SQS/SNS/EventBridge, la fel. Nu le faci tu deploy. Nu ai un server managed de tine pe care sa tii RabbitMQ, spre exemplu. Le ai disponibile, out of the box, cu tot cu management.
Daca vorbim de Kubernetes, serverless inteleg sa folosesti serviciul de EKS de la AWS, in loc sa-i faci tu deploy pe un server managed by you.
S-ar putea tu sa confunzi SaaS cu IaaS (Infrastructure-as-a-Service). SasS-ul e o solutie, de obicei web-based, pe care clientul doar o acceseaza si o poate folosi instantaneu, fara sa fie nevoie de vreun setup sau management din partea lui. Asta inteleg eu. SaaS are legatura cu modul in care clientul foloseste solutia ta, nu cu arhitectura solutiei tale.
Oposul la SaaS as vedea ca fiind o solutie self-hosted sau desktop.
Eu am lucrat pe 3 proiecte, in ultimile luni, care au arhitectura serverless.
Procentul ar fi direct propritional cu numarul de proiecte scalabile la care lucrezi si care n-au vrut sa se complice cu multi DevOps sau sa-si asume riscuri.
Un proiect care n-are nevoie sa fie super scalabil, n-o sa aiba nevoie de arhitectura serverless.
Există soluții serverless elegante, nu trebuie să fie total serverless.
Exemple:
Resize la imagine, verificare vulnerabilități la ceva imagine in pipeline, scanare virusi la ceva incarcat, crearea unei imagini de pe un grafic complex (cu chromium), adaugarea unui watermark, generarea unui pdf, unei facturi, procesarea unei facturi incarcate cu AI, trimiterea unui email, unei notificari, OAuth cu two-factor.
Acum, revenind la ideea articolului initial.
Se pare ca autorul nu s-a sinchisit sa dezvolte subiectul alternativelor. Probabil din cauza ca nu sunt multe, dupa cum spuneam.
Cert e ca m-am lovit si eu de aceste incomoditati, cand am lucrat pe proiecte serverless, dar am realizat ca asta e crucea pe care trebuie s-o duci.
Cel mai elocvent exemplu e proiectul Expedia, care avea mii de repositories/servicii. Avea arhitectura serverless, pe AWS. La acest nivel si daca nu ai arhitectura serverless, tot va fi greu sa faci teste de integrare. Atlfel ce o sa faci? O sa-ti instalezi toate alea 100 de servicii pe localhost ca sa poti testa tot flow-ul? Oricum va trebui sa faci mocking la greu. There is no an easy way.
Dupa cum spuneam, se ingusteaza optiunile si comoditatile de la un nivel incolo.
Mi se pare ca confundam serverless cu cloud computing in geneeral si IaaS in particular. Si chestiile astea raman scrise, ajunge lumea la threadul asta din Google si nu mai intelege nimic.
In articol autorul doar da exemplu de stack. Pentru ca realist vorbind nu ai cum sa ai in proiect doar Lambda. Iti trebuie si o baza de date, iti trebuie si o componenta de comunicare intre servicii cum e SQS, iti trebuie si o componenta de storage cum e S3.
Ideea era ce faci cand backend-ul tau este exclusiv doar Lambda + serviciile aws mentionate. Pentru ca poti sa il ai doar asa.
Faptul ca mai ai niste lambda (care fac ce zice @isti37 mai sus), dar core business logic se executa in kubernetes, vm-uri sau chiar si bare metal, eu zic ca e ok.
@iamntz , uite inca ceva care cred ca sustine ce spuneam mai sus
Source: https://www.cloudflare.com/learning/serverless/what-is-serverless/
A company that gets backend services from a serverless vendor is charged based on their computation and do not have to reserve and pay for a fixed amount of bandwidth or number of servers, as the service is auto-scaling.
E vreun provider care sa te taxeze doar pentru timpul folosit fara a reporni intr-una aplicatia? Undeva unde sa pun un binar ce consuma 10 GB memorie, dar daca nu primeste nici un request azi sa nu ma coste nimic; dar cand vine un request sa raspunda instant?