Lambda, el servicio sin servidor insignia de AWS, permite ejecutar código en varios tiempos de ejecución. Sin embargo, PHP no aparece explícitamente en la descripción oficial del producto. ¿Significa que no puedes ejecutar código PHP en Lambdas? ¡No, no es así!
En esta serie (derivada de una charla que di al grupo de usuarios de AWS Poitiers), analizaremos qué es la tecnología sin servidor y cómo hacer que PHP (si ese es su lenguaje favorito) se ejecute en Lambda.
Serverless es un paradigma de alojamiento en el que el proveedor de la nube escala dinámicamente los recursos asignados a la carga de trabajo del cliente, mientras gestiona no solo la infraestructura física (servidores, refrigeración eléctrica) sino también hasta el tiempo de ejecución (parches, ...).
En sentido estricto, la computación se asigna para cada solicitud, lo que lleva a un modelo de precios de "escala a cero" (no se pagan recursos por hora, sino solo proporcionalmente a la demanda real), al tiempo que se proporciona un alto nivel de -disponibilidad.
Eso se suma a otros beneficios de la nube, principalmente el hecho de que todo viene con una API, lo que hace posible la automatización.
La suma de estos beneficios hace posible tener entornos efímeros con funciones prácticamente gratuitas, lo que aumenta la productividad y el tiempo de entrega de los desarrolladores.
Hay muchas soluciones en el ecosistema sin servidor. Cuando apareció la computación sin servidor (Lambda), allá por 2014, las colas administradas (SQS) existían desde hacía una década y S3 desde hacía 8 años.
Tenga en cuenta que en la diapositiva anterior, Aurora no coincide con nuestra definición estricta de Serverless ya que no escala a cero (v1 escalada a cero, pero luego podría tardar unos minutos en iniciarse, con v2 debe tener al menos al menos 0,5 ACU en las instancias de escritor y lector para que la base de datos esté lista para atender consultas.
A continuación encontrará una arquitectura típica para alojar una aplicación web que solo incluye servicios sin servidor. Alojar una aplicación de este tipo podría costar menos de 1 dólar al año para un número limitado de usuarios.
Sí... y no. Fue diseñado teniendo en cuenta los microservicios, pero aún puede implementar una arquitectura monolítica (siempre que no tenga una secuencia de inicio de larga duración cada vez que se lanza un nuevo entorno).
La arquitectura de microservicios permite reducir el acoplamiento entre los componentes de las aplicaciones (usando diferentes lenguajes, a través de patrones asincrónicos, mejorando la escalabilidad al eliminar el acoplamiento a nivel de infraestructura).
Sin embargo, cuando tenemos múltiples funciones con un solo propósito, implementar la lógica de negocios puede requerir coordinación entre funciones. Esta coordinación se puede implementar utilizando dos patrones fundamentales.
Lambda es la solución de función como servicio de AWS. Con Lambda puede implementar su código y obtener alta disponibilidad y escalabilidad instantáneas, sin preocuparse por la implementación de instancias y los parches del sistema operativo o del tiempo de ejecución.
Lambda se puede usar con invocaciones sincrónicas (a través de una puerta de enlace API, un balanceador de carga de aplicaciones o una URL de función Lambda) o invocaciones asincrónicas (que responden a eventos generados por AWS o por el usuario).
Cuando implementas un Lambda, eliges cuánta memoria necesita para ejecutarse. La CPU asignada es proporcional. Luego paga según la cantidad de milisegundos utilizados. Por ejemplo, una Lambda de 128 Mb cuesta 1,7*10^-9$/ms. Son 164 horas de computación antes de gastar su primer dólar.
Y escalas Lambda. Rápido. Mucho más rápido que cualquier otra cosa. No más errores 429 (o 500 si su carga de trabajo no está bien protegida) debido a la alta variación del tráfico.
Los entornos de ejecución Lambda procesan solo una solicitud en un momento dado y se reutilizan para solicitudes posteriores. Eso significa que, para que una función Lambda escale, o cuando una función Lambda no se haya invocado por un tiempo, Lambda tendrá que iniciar un nuevo entorno de ejecución: eso es un inicio en frío.
Si los arranques en frío son perjudiciales para su aplicación (nuevamente, probablemente sea mejor que todo el tráfico sea lento o llegue a 429), entonces existen algunas opciones. AWS tiene un buen artículo sobre el uso de calentadores Lambda o la configuración de la simultaneidad aprovisionada para solucionarlo. Además de esto, para los usuarios de Java, las funciones Lambda SnapStart permiten ofrecer un buen rendimiento de arranque en frío, al tomar una instantánea de la microVM después de que se inicia la JVM.
Las preguntas frecuentes oficiales del producto indican que "es compatible de forma nativa con código Java, Go, PowerShell, Node.js, C#, Python y Ruby, y proporciona una API Runtime que le permite utilizar cualquier lenguaje de programación adicional para crear sus funciones".
En las próximas publicaciones de blog de esta serie, explicaremos cómo ejecutar PHP en Lambda aprovechando dos marcos distintos, Bref y Lambda Web Adaptor, y compararemos las posibilidades que ofrece cada uno de ellos.
Descargo de responsabilidad: Todos los recursos proporcionados provienen en parte de Internet. Si existe alguna infracción de sus derechos de autor u otros derechos e intereses, explique los motivos detallados y proporcione pruebas de los derechos de autor o derechos e intereses y luego envíelos al correo electrónico: [email protected]. Lo manejaremos por usted lo antes posible.
Copyright© 2022 湘ICP备2022001581号-3