Informàtica sense servidor

La informàtica sense servidor és "una categoria de serveis al núvol en què el client pot utilitzar diferents tipus de capacitats al núvol sense que el client hagi de subministrar, desplegar i gestionar recursos de maquinari o programari, a part de proporcionar codi d'aplicació del client o proporcionar dades del client. La informàtica sense servidor representa una forma de informàtica virtualitzada", segons ISO /IEC 22123-2.^[1] Segons Sheen Brisals, la informàtica sense servidor és un ecosistema ampli que inclou el proveïdor de núvol, Funció com a Servei, serveis gestionats, eines, marcs, enginyers, parts interessades i altres elements interconnectats.^[2]

Visió general

Sense servidor és un nom inadequat en el sentit que els proveïdors de serveis al núvol encara utilitzen servidors per executar codi per als desenvolupadors. La definició de la informàtica sense servidor ha evolucionat amb el temps, donant lloc a interpretacions variades. Segons Ben Kehoe, sense servidor representa un espectre més que una definició rígida. L'èmfasi hauria de passar de les definicions estrictes i les tecnologies específiques a l'adopció d'una mentalitat sense servidor, centrant-se a aprofitar solucions sense servidor per abordar els reptes empresarials.^[3]

La informàtica sense servidor no elimina la complexitat, però en canvia gran part de l'equip d'operacions a l'equip de desenvolupament. Tanmateix, aquest canvi no és absolut, ja que els equips d'operacions continuen gestionant aspectes com la gestió d'identitats i accés (IAM), xarxes, polítiques de seguretat i optimització de costos. A més, tot i que la descomposició de les aplicacions en components de gra més fi pot augmentar la complexitat de la gestió, la relació entre granularitat i dificultat de gestió no és estrictament lineal. Sovint hi ha un nivell òptim de modularització on els beneficis superen la sobrecàrrega de gestió afegida.^[4][5]

Segons Yan Cui, només s'hauria d'adoptar sense servidor quan ajudi a oferir valor al client més ràpidament. I mentre s'adopten, les organitzacions haurien de fer petits passos i reduir els riscos al llarg del camí.^[6]

Reptes

Les aplicacions sense servidor són propenses a les fal·làcies de la informàtica distribuïda. A més, són propensos a les fal·làcies següents:^[7][8]

• La versió és senzilla
• Les transaccions compensatòries sempre funcionen
• L'observabilitat és opcional

Monitorització i depuració

La supervisió i la depuració d'aplicacions sense servidor poden presentar reptes únics a causa de la seva naturalesa distribuïda, basada en esdeveniments i entorns propietaris. Les eines tradicionals poden quedar curtes, cosa que dificulta el seguiment dels fluxos d'execució entre els serveis. Tanmateix, les solucions modernes, com ara les eines de traçat distribuïdes (per exemple, AWS X-Ray, Datadog), el registre centralitzat i les plataformes d'observabilitat independents del núvol estan mitigant aquests reptes. Les tecnologies emergents com OpenTelemetry, la detecció d'anomalies impulsada per IA i els marcs específics sense servidor estan millorant encara més la visibilitat i l'anàlisi de causes arrel. Tot i que els reptes persisteixen, els avenços en les eines de supervisió i depuració estan abordant aquestes limitacions de manera constant.^[9][10]

Seguretat

Segons OWASP, les aplicacions sense servidor són vulnerables a les variacions dels atacs tradicionals, el codi insegur i alguns atacs específics sense servidor (com la denegació de cartera^[11]). Per tant, els riscos han canviat i la prevenció d'atacs requereix un canvi de mentalitat.^[12]

Bloqueig del venedor

La informàtica sense servidor es proporciona com a servei de tercers. Les aplicacions i el programari que s'executen a l'entorn sense servidor estan bloquejats per defecte a un proveïdor de núvol específic. Aquest problema s'agreuja en la informàtica sense servidor, ja que amb el seu nivell d'abstracció augmentat, els venedors públics només permeten als clients carregar codi a una plataforma FaaS sense l'autoritat per configurar entorns subjacents. Més important encara, quan es considera un flux de treball més complex que inclou Backend-as-a-Service (BaaS), una oferta BaaS normalment només pot activar de manera nativa una oferta FaaS del mateix proveïdor. Això fa que la migració de la càrrega de treball a la informàtica sense servidor sigui pràcticament impossible. Per tant, considerar com dissenyar i desplegar fluxos de treball sense servidor des d'una perspectiva multinúvol sembla prometedor i comença a prevaler.^[13][14][15]

Informàtica d'alt rendiment

La informàtica sense servidor pot no ser ideal per a determinades càrregues de treball d'informàtica d'alt rendiment (HPC) a causa dels límits de recursos que sovint imposen els proveïdors de núvol, incloses les restriccions màximes de memòria, CPU i temps d'execució. Per a les càrregues de treball que requereixen un ús de recursos sostingut o previsible, els servidors de subministrament massiu de vegades poden ser més rendibles que el model de pagament per ús típic de les plataformes sense servidor. Tanmateix, la informàtica sense servidor és cada cop més capaç de suportar càrregues de treball HPC específiques, especialment aquelles que són altament paral·lelitzables i impulsades per esdeveniments, aprofitant la seva escalabilitat i elasticitat. La idoneïtat de la informàtica sense servidor per a HPC continua evolucionant amb els avenços en les tecnologies al núvol.^[16][17]

Anti-patrons

El "Gran de sorra Anti-patró" es refereix a la creació de components excessivament petits (p. ex., funcions) dins d'un sistema, que sovint provoca una major complexitat, sobrecàrrega operativa i ineficiències de rendiment.^[18] "Lambda Pinball" és un anti-patró relacionat que es pot produir a les arquitectures sense servidor quan les funcions (per exemple, AWS Lambda, Azure Functions) s'invoquen excessivament entre elles en cadenes fragmentades, provocant reptes de latència, depuració i prova i una observabilitat reduïda.^[19] Aquests anti-patrons estan associats a la formació d'un monòlit distribuït.

Aquests anti-patrons sovint s'aborden mitjançant l'aplicació de límits de domini clars, que distingeixen entre interfícies públiques i publicades.^[20][21] Les interfícies públiques són interfícies tècnicament accessibles, com ara mètodes, classes, punts finals de l'API o activadors, però no inclouen garanties formals d'estabilitat. En canvi, les interfícies publicades impliquen un contracte d'estabilitat explícit, que inclou versions formals, documentació exhaustiva, una política de desús definida i, sovint, suport per a la compatibilitat enrere. Les interfícies publicades també poden requerir el manteniment de diverses versions simultàniament i l'adhesió als processos formals d'abandonament quan s'introdueixen canvis de ruptura.^[21]

Sovint s'observen cadenes fragmentades de trucades de funcions en sistemes on els components sense servidor (funcions) interactuen amb altres recursos en patrons complexos, de vegades descrits com a arquitectura espagueti o un monòlit distribuït. En canvi, els sistemes que presenten límits més clars solen organitzar components sense servidor en grups cohesionats, on les interfícies públiques internes gestionen la comunicació entre components i les interfícies publicades defineixen la comunicació a través dels límits del grup. Aquesta distinció posa de manifest les diferències en les garanties d'estabilitat i els compromisos de manteniment, contribuint a reduir la complexitat de la dependència.^[22][23]

Principis

L'adopció de pràctiques DevSecOps pot ajudar a millorar l'ús i la seguretat de les tecnologies sense servidor.^[24]

A les aplicacions sense servidor, la distinció entre infraestructura i lògica de negoci sovint es difumina, amb les aplicacions normalment distribuïdes entre diversos serveis. Per maximitzar l'eficàcia de les proves, es fa èmfasi en les proves d'integració per a aplicacions sense servidor.^[25] A més, per facilitar la depuració i la implementació, l'orquestració s'utilitza dins del context acotat, mentre que la coreografia s'utilitza entre diferents contextos acotats.^[25]

Els recursos efímers normalment es mantenen junts per mantenir una alta cohesió. Tanmateix, els recursos compartits amb temps d'activació llargs, com ara clústers AWS RDS i zones d'aterratge, sovint es gestionen en repositoris, canals de desplegament i piles separats.^[26]