Últimamente, he visto muchos descartes de sistemas Serverless y opiniones encontradas en Internet. Conmovieron a la comunidad y comenzaron un debate, lo que siempre es bueno.
En esta publicación, reflexionaré sobre el estado actual de la tecnología Serverless, compartiré mis pensamientos sobre los artículos sobre tecnología sin servidor de la comunidad y analizaré el futuro de la tecnología sin servidor.
Tabla de contenido
Introducción
Aunque han pasado casi cinco años desde que comencé a usar el modelo sin servidor, todavía me parece mágico. Implementar código sin administrar la infraestructura subyacente es liberador.
Además, la capacidad de crear arquitecturas basadas en eventos creadas a partir de recursos administrados por AWS o integraciones directas que reemplazan el código de los contenedores es asombrosa. Se pueden crear servicios que de otro modo llevarían años en tan solo unos minutos. Todavía me sorprende el rendimiento de replicación entre regiones de las tablas globales de DynamoDB.
La realidad es que Serverless ya no es el nuevo servicio de moda (sí, GenAI, estoy hablando de ti). Lambda ha celebrado su décimo aniversario este año. Es una locura: ¡ya han pasado 10 años! ¡Y también se podría argumentar que el primer servicio sin servidor fue SQS, que se lanzó hace dos décadas! El entusiasmo ha cambiado, y eso es normal.
Toda tecnología madura con el tiempo. Kubernetes ya no es "nuevo". ¡Incluso ChatGPT ya no es "nuevo"! Hace un año escribí una publicación al respecto sobre cómo mi abuela quería usarlo.
En algún momento, las tecnologías y los productos alcanzan la madurez, que es donde nos encontramos actualmente. Mi opinión es que Serverless ha madurado hasta convertirse en un verdadero "caballo de batalla" de la nube: una tecnología increíblemente escalable y confiable que resuelve muchos problemas pero (como cualquier otra) viene con su propio conjunto de limitaciones y aprendizajes (más sobre esto más adelante).
Lecturas sin servidor en la Web
Últimamente, he visto muchos descartes de sistemas sin servidor y opiniones encontradas en Internet. Conmovieron a la comunidad y comenzaron un debate, lo que siempre es bueno.
Me gustaría compartir mis pensamientos sobre algunas versiones descartadas de servidores sin servidor que he visto en los últimos meses.
Artículos de clickbait
Esta es una generalización de una tendencia de artículos que he visto: " El equipo X dejó de usar serverless y ahora son 1000% mejores ".
Hay mucha desinformación y conceptos erróneos sobre la tecnología sin servidor. Por lo general, en estos artículos, se hace referencia únicamente a Lambda.
Estamos en 2024 y, por alguna razón, la gente todavía considera que serverless es simplemente Lambda (* facepalm *).
Existe un hermoso mundo sin servidores con servicios básicos: S3, SNS, SQS, DynamoDB, EventBridge y muchos más, que puede (¡y debe!) utilizar con su clúster K8S. ¿Por qué utilizar Kafka cuando obtiene la misma experiencia, o incluso mejor, con MSK o SQS sin el costo de mantenimiento?
En segundo lugar, como cualquier otra tecnología, Lambda no es una solución mágica para todos los problemas. Hay problemas para los que Lambda no sirve ( ¡ja! ) o no tiene sentido, ¡y eso está bien!
A veces, necesitas sesiones de larga duración que duren más de 15 minutos, o usar GPU, o quieres manejar patrones de tráfico predecibles y no tienes problemas con la creación en ECS Fargate. Los contenedores son geniales, y no tener que administrar la infraestructura subyacente es aún mejor.
El punto principal que estos artículos pasan por alto es que el hecho de que Lambda no se haya utilizado en un caso de uso específico no significa que Lambda sea una tecnología defectuosa. Simplemente significa que no se ajustaba a los requisitos de ese servicio específico.
Por cierto, está bien mezclar. Diseñé un servicio en el que una parte es Lambda y otra parte son contenedores. No elijas una solución porque eso es lo que sabes y lo que siempre has hecho. Werner Vogels lo analizó en AWS re:Invent 2023. Elige la solución que mejor se adapte a los requisitos y las limitaciones del problema, punto, y no temas hacer las cosas de forma diferente a lo que estás acostumbrado.
Sin servidor e IA
A menos que hayas vivido bajo una piedra durante el último mes, probablemente hayas leído la publicación de Luc van Donkersgoed sobre la IA y la tecnología sin servidor. Si no la has leído, le pedí a ChatGPT que te la resumiera:
Luc expresa su preocupación por el hecho de que el intenso enfoque de AWS en la IA generativa (GenAI) eclipse la ingeniería de la nube tradicional y la infraestructura central. Destaca cómo los eventos y anuncios recientes de AWS se han centrado predominantemente en GenAI, dejando menos atención y recursos para otras áreas esenciales como bases de datos, infraestructura escalable y aplicaciones mantenibles. Luc sostiene que, si bien GenAI tiene sus beneficios, no puede reemplazar los elementos fundamentales de la ingeniería de la nube e insta a AWS a equilibrar su enfoque para brindar un mejor soporte a los desarrolladores y las necesidades comerciales existentes. - ChatGPT 4o
Como ingeniero y arquitecto, estoy de acuerdo en que preferiría ver menos funciones de IA y más funciones sin servidor o de infraestructura. Estoy harto de oír hablar de nuevas funciones de IA, pero no puedo ignorar que GenAI me ha convertido en un ingeniero mejor y más rápido. No puedo negar que algunas de ellas son realmente geniales y tienen un potencial increíble, como los agentes de Bedrock que llaman a las API (ver mi publicación e impresiones aquí ).
Ahora, si nos centramos en la obsesión de AWS por el cliente y sus necesidades comerciales, yo no soy cliente de AWS, pero mi empresa sí lo es, y esa es una distinción importante. Los clientes empresariales de CyberArk quieren que desarrollemos funciones de IA y muchas de ellas. Existe una demanda real y algunas de las implementaciones están mejorando la vida de nuestros clientes. Por lo tanto, desde esa perspectiva, AWS está haciendo lo que quieren sus clientes. Sin embargo, como AWS se incorporó tarde al juego, estamos viendo esta ola interminable de funciones de IA.
De cara al futuro, creo que la locura por la IA en AWS se calmará en un año o dos, a medida que se vaya cerrando la brecha, al menos hasta que llegue el próximo boom.
Serverless como producto de Halo
Gregor Hohpe publicó otro artículo interesante titulado: " ¿AWS Lambda es un producto de Halo? Brillante, avanzado, con muchos seguidores, pero sin una adopción generalizada: las características distintivas de un producto de Halo. ¿Suena como AWS Lambda?".
Hay algunos puntos sólidos y otros sobre los que personalmente tengo una opinión diferente.
Analicemos el aspecto general. ¿Qué significa realmente? ¿Es de conocimiento público y se utiliza, o son meros números de cuota de mercado?
Lambda no reemplazará por completo a ECS o EC2. No estaba previsto que lo hiciera.
Como ya he mencionado, cada una tiene su lugar. ¿Es algo común? Sí. La gente lo conoce y lo utiliza en grandes empresas.
Puedo decirlo con confianza porque cuando me entrevistan para puestos de desarrollador en CyberArk, recibo currículums de ingenieros que dicen conocer Lambda, SQS, DynamoDB y otros servicios sin servidor, y realmente los conocen.
Continuemos.
No estoy de acuerdo con frases como "Utilizo serverless principalmente para demostraciones" o "Los EC2 son confiables" (lo que sugiere que Lambda no lo es); bueno, como escribí al principio, serverless es más que solo Lambda. Otros serverless son útiles incluso si estás ejecutando EC2 o K8.
Además, muchas empresas utilizan la tecnología sin servidor en producción, y es muy confiable. De hecho, los resúmenes de eventos posteriores a fallas de AWS de los últimos 13 años muestran que EC2 tuvo cuatro interrupciones específicas el año anterior, mientras que Lambda tuvo solo una.
Hablemos de la siguiente cita:
Esas instancias EC2 no son tan atractivas, pero son bien entendidas, confiables y tienen costos predecibles.
Según el informe sobre el estado de los costes de la nube de DataDog, punto número 4, y cito:
Más del 80 por ciento del gasto en contenedores se desperdicia en recursos inactivos. Alrededor del 54 por ciento de este gasto desperdiciado se produce en clústeres inactivos, que es el costo de sobreaprovisionar la infraestructura del clúster.
Leámoslo de nuevo: ¡80 %! Vaya, qué desperdicio de recursos y dinero tan alucinante. ¿Quizás los EC2 que alojan soluciones basadas en contenedores y Kubernetes no son tan conocidos después de todo?
Con la tecnología sin servidor, no paga por recursos inactivos y no necesita administrar su infraestructura, lo que reduce drásticamente sus costos: una gran ventaja para la tecnología sin servidor.
Hablemos del mantenimiento continuo.
Proteger los EC2 a lo largo del tiempo no es fácil. Gestionar las actualizaciones del sistema operativo y de la biblioteca a veces no es nada sencillo. La semana pasada, literalmente, tuvimos una de las mayores interrupciones en años. ¡Gracias, CrowdStrike ! Eso sí que es tener un coste de mantenimiento predecible.
Eche un vistazo también a K8s. Escuchará muchas historias de terror sobre actualizaciones de versiones, configuración de un clúster o una malla de servicios y otros problemas. Entonces, ¿por qué se está criticando tanto el entorno sin servidor? Eso se debe a que, con K8s, el equipo de infraestructura se encarga de eso.
Con la arquitectura sin servidor, cada desarrollador debe aprender y comprender los conceptos y escribir IaC que construya las partes móviles de la arquitectura sin servidor.
Ampliemos este punto.
Desafíos de la tecnología sin servidor
Gregor también hace buenos comentarios. Serverless, y Lambda como parte de él, es único (similar a Halo), y como tal, necesitas aprender la tecnología; necesitas REALMENTE entenderla para aprovecharla al máximo. Me encontré con un artículo de Sheen Brisals que analiza si serverless es difícil o no. Te recomiendo que lo leas.
Analicemos en detalle el estado actual de los problemas de las tecnologías sin servidor. Quiero aclarar algo: cualquier tecnología conlleva su propio conjunto de desafíos. Todos los desafíos de las tecnologías sin servidor que menciono tienen solución; es solo una cuestión de costo, conocimiento y contar con las personas adecuadas para impulsar la tecnología dentro de su organización.
La tecnología sin servidor no es una solución milagrosa
El gran poder de las aplicaciones sin servidor es que empezar a trabajar con ellas y volverse productivo es mucho más fácil. Piense en cuánto tiempo le llevaría a un desarrollador que nunca ha visto Lambda ni Kubernetes implementar un backend de Hello World con API pública en ambos. A medida que comienza a crear aplicaciones de producción más realistas, la complejidad aumenta. Debe ocuparse de la observabilidad, la seguridad, la optimización de costos, el manejo de fallas, etc. Con las aplicaciones sin servidor, esta responsabilidad generalmente recae en el equipo de operaciones. Con las aplicaciones sin servidor, generalmente recae en los desarrolladores, donde hay una confusión considerable.
Volvamos al ejemplo de la entrevista que estaba usando.
Los desarrolladores conocían los conceptos de serverless. Sin embargo, la mayoría de ellos se equivocaron y fallaron en cuanto les pregunté sobre técnicas de prueba o manejo de fallas con DLQ y reintentos .
Serverless no es una solución milagrosa que elimine la complejidad de crear y ejecutar aplicaciones en la nube. Puede ayudarlo a reducir significativamente la complejidad del mantenimiento de la infraestructura y centrarse en la capa de aplicación. Sin embargo, eso también conlleva la nueva complejidad de comprender y aplicar patrones de aplicaciones sin servidor, como el uso de DLQ , conceptos de arquitectura basados en eventos y más.
Desarrolladores que realizan DevOps e ingeniería de plataformas
Algunas empresas temen el cambio o quieren evitar invertir el dinero que implica hacerlo. La tecnología sin servidor requiere un cambio de cultura, una mejor incorporación de los desarrolladores y alguien que lidere el camino en las mejores prácticas y la gobernanza. En mi empresa, ha sido la responsabilidad de la ingeniería de la plataforma . Eso ha sido parte de mi trabajo. Sin embargo, muchas empresas no conectan la ingeniería de la plataforma con la tecnología sin servidor. A gran escala, es una necesidad; se necesita gobernanza, seguridad, optimizaciones de FinOps, mejores prácticas generales y alguien que se haga cargo.
Si no hay un propietario concreto, la responsabilidad recae sobre los hombros de cada uno de los promotores, y es demasiado.
Falta de experiencia para desarrolladores y demasiadas opciones
Si usar serverless fuera tan fácil y obvio, no habría necesitado escribir más de 50 artículos ni compartir mis puntos de vista sobre el pragmatismo serverless enAWS re:Invent 2023 con mi compañero del crimen, Heitor Lessa.
Cuestiones como las pruebas sin servidor, la observabilidad sin servidor, aprender a escribir un controlador Lambda adecuado, lidiar con el aislamiento de inquilinos, trabajar con herramientas de infraestructura como código (demasiadas opciones de AWS: SAM, CDK, Chalice, ¿cuál elegir y por qué?) y aprender todas las mejores prácticas abruman a los desarrolladores y gerentes por igual.
AWS ha publicado artículos sobre la mayoría de los temas, pero hay muchas opiniones, demasiados proyectos "hola mundo" que quedan obsoletos en seis meses y no hay suficientes casos de uso avanzados.
AWS debe brindar una mejor experiencia a los desarrolladores para que no tengan que preocuparse por estos temas y se concentren en escribir la lógica empresarial.
Es solucionable
Es solucionable, pero adoptar una nueva tecnología siempre, siempre, siempre (!) requiere inversión . En CyberArk, hemos reducido estos desafíos creando modelos de autoservicio y codificando modelos y patrones arquitectónicos para que nuestros desarrolladores obtengan todas las mejores prácticas desde el principio. Si a eso le sumamos talleres internos e intercambio de conocimientos, estará en el camino correcto. Hemos escalado de 10 desarrolladores sin servidor a cientos.
Se puede hacer.
He compartido muchas ideas sobreseminarios web sobre el horario de oficina sin servidor de AWS y un artículo de AWS , y compartiré nuestra experiencia en el AWS Community Day DACH este septiembre en Múnich.
La comunidad sin servidor
La comunidad sin servidor es nada menos que asombrosa .
Hay eventos globales, días sin servidor, día CDK, días de la comunidad de AWS con toneladas de contenido sin servidor, defensores de desarrolladores sin servidor de AWS, creadores de la comunidad de AWS especializados en sin servidor, héroes sin servidor de AWS, boletines informativos sin servidor, etc.
Los expertos comparten conocimientos como nunca antes. Incluso la documentación de AWS ha mejorado. Y con la revolución de la IA, escribir código sin servidor es más fácil.
Hace cuatro años no era así.
Las bibliotecas de código abierto como Powertools para AWS Lambda han cambiado la industria. Recientemente superaron los 100 mil millones de integraciones de API por semana. Powertools está haciendo que la vida de los clientes sea mucho más sencilla en todo el mundo.
Incluso hay una nueva comunidad sin servidor en Discord llamada "Believe in Serverless ", donde puedes conectarte fácilmente con expertos en tecnología sin servidor y participar en debates sobre ella. Se trata de un acceso sin precedentes a consejos pragmáticos de quienes realmente utilizan la tecnología.
El futuro de la tecnología sin servidor
Aclaremos este apartado. No soy un profeta, esto es una mera lista de deseos.
El futuro sin servidores será brillante; la tecnología sin servidores no desaparecerá y no está muriendo.
Sin embargo, si AWS quiere aumentar su adopción, necesita mejorar los siguientes aspectos:
Concéntrese en la experiencia del desarrollador para las funciones actuales y nuevas. No lance un servicio sin registros de depuración (estoy mirando sus canales de EventBridge , que tardaron un año en incorporar registros de errores).
¡Más AWS Powertools, por favor ! Más compatibilidad con entornos de ejecución (RUST, Golang) y que todas tengan la misma funcionalidad que la variante de Python, y que se extienda a los contenedores, no solo a Lambda. Por favor, inviertan en este increíble equipo de AWS DevEx.
No coloque la etiqueta "Serverless" en servicios que NO sean realmente sin servidor . Si necesito configurar una VPC o pagar por tiempo de inactividad, no es sin servidor. Se recomiendan los servicios más nuevos, como los permisos verificados, que cumplen con estos requisitos.
Todos los nuevos servicios que no sean de cómputo DEBEN ser sin servidor . No quiero volver a administrar infraestructura, por lo que el estándar debería ser sin servidor.
Concéntrese en una herramienta de IaC y haga lo mejor que pueda. Para mí, la opción obvia es CDK. Concéntrese en lanzar mejores construcciones de CDK L2 y L3 que implementen las mejores prácticas y seguridad para convertir las construcciones enpatrones productivos , como dice Jeremy Daly.
Pruebas y definición de funciones escalonadas: esto todavía es muy difícil de hacer. Cambiémoslo. Es un servicio obligatorio que recibe el odio de los desarrolladores debido a un DevEx deficiente.
Mantener los proyectos de muestra de GitHub durante al menos dos años después de su publicación y descontinuar los proyectos que ya no se mantengan.
Sea más pragmático. Empiece con las sesiones de AWS Summit y continúe hasta AWS re:Invent. Traiga más casos de uso técnicos de clientes. Queremos aprender de entornos de producción reales, no solo de teoría.
Proporcionar planos listos y seguros para producción y configuraciones de proyectos recomendadas, similares a lo que creé, el libro de recetas del controlador AWS Lambda . Tal vez incluso apoye proyectos comunitarios si no tiene la capacidad para desarrollarlos.
Ayúdenos a abordar el aislamiento de los inquilinos de una manera más genérica y segura. Cada empresa lo gestiona de forma diferente y es muy propenso a errores.
Vamos a ver cómo la IA se infiltra en el mundo sin servidor, especialmente en el dominio de IaC, y eso está bien. Todavía no he probado AWS App Studio . No se exceda (como escribió Luc).
Esfuércese por hacer que las características sean transparentes: Lambda Insights, por ejemplo, en lugar de que yo, como usuario, adjunte una extensión Lambda y administre su versión (lo que no es una gran experiencia; consulte mi publicación sobre capas Lambda ), permítame proporcionar un indicador CDK a la construcción Lambda, y usted adjuntará la extensión detrás de escena y la administrará por mí.
El acceso entre cuentas a gran escala con EDA y sin servidor es un desafío; podemos y debemos simplificarlo. Estos son desafíos que conlleva esta arquitectura. Los analizo en mi publicación sobre seguridad .
Resumen
Ha habido muchos descartes de servidores y opiniones encontradas en línea. Conmovieron a la comunidad y comenzaron un debate, lo que siempre es bueno. Me hizo tomarme un momento para pensar sobre el estado actual y organizar mis pensamientos.
Espero que hayas disfrutado leyendo mi visión. El tiempo dirá si tenía razón o no.
Gracias a Anton Aleksandrov, Bill Tarr y Johannes Koch por revisar esta publicación y ofrecernos sus ideas.
Comments