Tanquem el Capítol 28 amb una idea molt potent: executar lògica molt a prop dels usuaris, al «bord» de la xarxa. Fins ara, les nostres Lambdas (Capítol 14) s’executaven en una regió concreta. Però i si poguessis executar codi a les centenars d’ubicacions que CloudFront (subcapítol 16.2) té repartides pel món, just al costat de cada usuari? Això és el que permeten Lambda@Edge i CloudFront Functions: portar el còmput a l’edge (el bord de la xarxa) per respondre més ràpid i personalitzar el contingut.

Recorda del subcapítol 16.2 que CloudFront és la CDN d’AWS: té ubicacions repartides per tot el món (punts de presència o «edge locations») que serveixen contingut als usuaris des del punt més proper a ells, reduint la latència. Aquest conjunt d’ubicacions properes als usuaris és el que anomenem l’edge (el bord de la xarxa).

La idea d’aquest subcapítol: executar codi en aquestes ubicacions de l’edge, no només servir fitxers. Així, la lògica corre al costat de l’usuari, no en una regió llunyana.

Si tota la teva lògica s’executa en una regió (per exemple, a Europa), un usuari al Japó ha d’«anar i tornar» fins a Europa per a cada operació, cosa que afegeix latència (retard). Per a certes tasques senzilles que es podrien resoldre a prop de l’usuari, aquest viatge és un malbaratament. Seria millor executar aquesta petita lògica a la ubicació de l’edge més propera a l’usuari.

Executar lògica a l’edge vol dir córrer codi a les ubicacions properes als usuaris (les de CloudFront), en lloc d’una regió central. Això serveix per a tasques que convé resoldre just quan una petició arriba o surt de l’edge, sense viatjar fins a la regió:

• Personalitzar respostes segons l’usuari (el seu país, el seu idioma, el seu dispositiu).
• Redirigir peticions segons certes regles.
• Comprovar coses (autenticació bàsica, capçaleres) abans de continuar.
• Modificar la petició o la resposta al vol.

Analogia: executar lògica a l’edge és com tenir un recepcionista a la porta de cada sucursal d’un banc, en comptes d’haver de trucar a la central per a tot. Si entres i només necessites que t’indiquin una finestreta o et donin un fulletó en el teu idioma, el recepcionista local ho resol a l’instant, sense trucar a la central (que està lluny). Només les gestions complexes van a la central. Portar tasques senzilles «a la porta» fa tot més ràpid.

AWS ofereix dues formes d’executar codi a l’edge, una més potent i una altra més lleugera:

CloudFront Functions són funcions molt lleugeres i rapidíssimes, pensades per a tasques simples que s’executen en cada petició amb mínima latència. Són ideals per a manipulacions senzilles i de gran volum:

Lambda@Edge són Lambdas (Capítol 14) que s’executen a l’edge, més potents que les CloudFront Functions: permeten lògica més complexa (més temps d’execució, accés a més recursos, etc.), a canvi d’una mica més de latència i cost.

💡 Regla pràctica: per a tasques simples i de gran volum (manipular capçaleres o URLs), fes servir CloudFront Functions (més ràpides i barates). Per a lògica més complexa, fes servir Lambda@Edge. Tria l’eina més lleugera que resolgui la teva necessitat.

L’avantatge d’executar lògica a l’edge és doble:

• Menor latència: la lògica s’executa a prop de l’usuari, així que respon més ràpid (sense el viatge fins a la regió).
• Personalització global: pots adaptar el contingut a cada usuari (idioma, país, dispositiu) al punt més proper a ell, donant una experiència ràpida i a mida a tot el món.

Això encaixa amb el pilar d’eficiència del rendiment del Well-Architected Framework (subcapítol 27.1): fer servir la ubicació adequada perquè el sistema rendeixi el millor possible per a cada usuari.

Exemple del món real: una web global vol que cada usuari vegi el contingut en el seu idioma i sigui redirigit a la versió del seu país, el més ràpid possible. Fan servir una CloudFront Function que, en cada petició, mira el país de l’usuari (a partir d’una capçalera que CloudFront afegeix) i reescriu la URL per servir la versió correcta, tot a la ubicació de l’edge més propera, en mil·lisegons. Per a una altra tasca més complexa —comprovar un token d’autenticació i personalitzar la resposta segons el perfil de l’usuari— fan servir Lambda@Edge, que té la potència necessària. El resultat: usuaris d’arreu del món obtenen contingut personalitzat i veloç, perquè la lògica corre al seu costat, no a l’altra banda del planeta.

• CloudFront (subcap. 16.2) té ubicacions per tot el món (l’edge) properes als usuaris. S’hi pot executar codi, no només servir fitxers.
• Executar lògica a l’edge vol dir córrer codi a prop de l’usuari (no en una regió llunyana), ideal per personalitzar respostes, redirigir, comprovar o modificar peticions al vol. Com un recepcionista a la porta de cada sucursal en comptes de trucar sempre a la central.
• AWS ofereix dues opcions: CloudFront Functions (molt lleugeres i ultraràpides, per a tasques simples com reescriure URLs o capçaleres) i Lambda@Edge (més potent, per a lògica complexa).
• 💡 Fes servir la més lleugera que resolgui la teva necessitat: CloudFront Functions per al simple i de gran volum; Lambda@Edge per al complex.
• Aporta menor latència (lògica a prop de l’usuari) i personalització global, en línia amb el pilar d’eficiència del rendiment del Well-Architected Framework.

Has completat el Capítol 28 i domines les arquitectures serverless a escala: event-driven, el patró Saga, Step Functions i el còmput a l’edge! Al Capítol 29 canviarem de terreny cap a un altre gran domini: les plataformes de dades a AWS (data lakes, streaming i analítica a gran escala).