Buzz se basa en la idea de que es hora de recuperar nuestros servicios en la nube y reconstruir una vez más el centro de datos de la empresa. Repatriación. Es el acto de sacar el trabajo de la nube y regresarlo al hardware local o autoadministrado. Y la principal justificación de este movimiento es sencilla, especialmente en tiempos de crisis económica. Ahorre dinero al no utilizar AWS, Azure u otros servicios de alojamiento en la nube. Ahorre dinero construyendo y administrando su propia infraestructura. Desde que una publicación de Andreesen Horowitz catapultó esta idea al centro de atención hace un par de años, parece estar ganando impulso. 37Signals, creadores de Basecamp y Hey (un servicio de correo web de pago), publican blogs periódicamente sobre cómo se repatriaron. Y un informe reciente sugirió que de todos los que hablaban de volver al autohospedaje, la razón principal era financiera: el 45% dijo que era por el costo. No debería sorprender que la repatriación haya ganado tanta expectación. La nube, que alcanzó su madurez durante un auge económico, está por primera vez bajo presión a la baja a medida que las empresas buscan reducir el gasto. Amazon, Google, Microsoft y otros proveedores de nube se han deleitado con la disposición a gastar de sus clientes. Pero la voluntad se ha visto atenuada ahora por los recortes presupuestarios. ¿Cuál es la respuesta más obvia a la sensación de que la nube se ha vuelto demasiado cara? Es el toque de atención de la repatriación: ¡devuélvalo todo a la empresa! Kubernetes es caro en la práctica. La nube ha resultado ser cara. El culpable pueden ser las tecnologías que hemos creado para utilizar mejor la nube. Si bien podríamos considerar innumerables servicios complementarios, el problema surge en el nivel más básico. Nos centraremos únicamente en la computación en la nube. La propuesta de valor original de las máquinas virtuales alojadas (la computación en la nube OG) era que se podía tomar todo el sistema operativo, empaquetarlo y enviarlo a otro lugar para ejecutarlo. Pero la parte operativa de esta configuración, lo que les pedimos a nuestros equipos de desarrollo e ingeniería de plataformas que se ocuparan, fue todo menos agradable. El mantenimiento era una bestia. Las herramientas de gestión eran primitivas. Los desarrolladores no participaron. Los despliegues fueron más lentos que la melaza. Llegaron los contenedores Docker. Cuando se trataba de empaquetar e implementar servicios individuales, los contenedores nos brindaron una mejor historia que las máquinas virtuales. Los desarrolladores podrían construirlos fácilmente. Los tiempos de inicio se midieron en segundos, no en minutos. Y gracias a un pequeño proyecto de Google llamado Kubernetes, fue posible orquestar la gestión de aplicaciones de contenedores. Pero lo que no notamos mientras construíamos este nuevo mundo feliz es el costo en el que estábamos incurriendo. Más específicamente, en nombre de la estabilidad, minimizamos los costos. En Kubernetes, la forma preferida de implementar una aplicación es ejecutar al menos tres réplicas de cada aplicación en ejecución, incluso cuando la carga entrante no lo justifica. Las 24 horas del día, los 7 días de la semana, todos los servidores de su clúster se ejecutan por triplicado (al menos), consumiendo energía y recursos. Además de esto, colocamos una gran cantidad de sidecares y servicios auxiliares, todo lo cual consumió más recursos. De repente, ese clúster de Kubernetes “inicial” de tres nodos tenía siete nodos. Luego una docena. Según una encuesta reciente de CNCF, el 50% de los clústeres de Kubernetes tienen más de 50 nodos. El costo del cluster se disparó. Y luego todos nos encontramos en esa innoble posición de instalar herramientas de “control de costos” para tratar de decirnos dónde podíamos incluir nuestro clúster de Kubernetes en nuestro nuevo presupuesto de jeans ajustados. Recientemente, al discutir esto con un amigo, admitió que en este punto su El clúster Kubernetes de la empresa estaba preparado para una gran apuesta: en lugar de provisionar la cantidad de recursos que necesitaban, lo hicieron de forma insuficiente con la esperanza de que no fallaran demasiadas cosas a la vez. Redujeron el tamaño de su clúster hasta que los requisitos de inicio de todos sus servidores, si se activaban mutuamente, agotarían los recursos de todo el clúster antes de que pudieran reiniciarse. Como patrón más amplio, ahora estamos intercambiando estabilidad y tranquilidad por un pequeño porcentaje de reducción en nuestros costos. No es de extrañar que la repatriación esté causando sorpresa. ¿Podemos resolver el problema en la nube? Pero ¿y si hiciéramos una pregunta diferente? ¿Qué pasaría si preguntáramos si hay algún cambio arquitectónico que podamos hacer y que reduzca enormemente los recursos que consumimos? ¿Qué pasaría si pudiéramos reducir ese clúster de Kubernetes a un tamaño de un solo dígito, no apretándonos el cinturón y esperando que nada se rompa, sino construyendo servicios de una manera que sea más sostenible en términos de costos? La tecnología y el patrón de programación ya están aquí. Y aquí está el spoiler: la solución es WebAssembly sin servidor. Tomemos esos términos uno por uno. Las funciones sin servidor son un patrón de desarrollo que ha ganado un gran impulso. AWS, el mayor proveedor de nube, dice que ejecuta 10 billones de funciones sin servidor por mes. Ese nivel de inmensidad es alucinante. Pero es un indicador prometedor de que los desarrolladores aprecian esa modalidad y están creando cosas que son populares. La mejor manera de pensar en una función sin servidor es como un controlador de eventos. Un evento particular (una solicitud HTTP, un elemento que llega a una cola, etc.) desencadena una función particular. Esa función se inicia, maneja la solicitud y luego se cierra inmediatamente. Una función puede ejecutarse durante milisegundos, segundos o quizás minutos, pero ya no. Entonces, ¿cuál es el “servidor” del que estamos prescindiendo sin servidor? No estamos haciendo la afirmación descabellada de que de alguna manera estamos más allá del hardware del servidor. En cambio, «sin servidor» es una declaración sobre el patrón de diseño del software. No hay ningún proceso de servidor de larga duración. Más bien, escribimos sólo una función, sólo un controlador de eventos. Y dejamos que sea el sistema de eventos el que active la invocación del controlador de eventos. Y lo que queda fuera de esta definición es que las funciones sin servidor son mucho más fáciles de escribir que los servicios, incluso los microservicios tradicionales. El simple hecho de que las funciones sin servidor requieren menos código, lo que significa menos desarrollo, depuración y parches. Esto en sí mismo puede conducir a grandes resultados. Como informó David Anderson en su libro The Value Flywheel Effect: “Una sola aplicación web en Liberty Mutual se reescribió como sin servidor y dio como resultado una reducción de los costos de mantenimiento del 99,89 %, de 50.000 dólares al año a 10 dólares al año”. (Anderson, David. The Value Flywheel Effect, p. 27.) Otro resultado natural de no utilizar servidor es que ejecutamos fragmentos de código más pequeños durante períodos de tiempo más cortos. Si el costo de la computación en la nube está determinado por la combinación de cuántos recursos del sistema (CPU, memoria) necesitamos y cuánto tiempo necesitamos para acceder a esos recursos, entonces debería quedar claro de inmediato que la tecnología sin servidor debería ser más barata. Después de todo, usa menos y se ejecuta durante milisegundos, segundos o minutos en lugar de días, semanas o meses. Las arquitecturas sin servidor más antiguas de primera generación redujeron un poco los costos, pero como debajo del capó había tiempos de ejecución voluminosos, el costo de una función sin servidor creció sustancialmente con el tiempo a medida que una función manejaba cada vez más solicitudes. Aquí es donde entra en juego WebAssembly. WebAssembly como un mejor tiempo de ejecución sin servidor Como tiempo de ejecución aislado altamente seguro, WebAssembly es una excelente estrategia de virtualización para funciones sin servidor. Una función WebAssembly tarda menos de un milisegundo en iniciarse en frío y requiere poca CPU y memoria para ejecutarse. En otras palabras, reducen tanto el tiempo como los recursos del sistema, lo que significa que ahorran dinero. ¿Cuánto reducen? El costo variará según la nube y la cantidad de solicitudes. Pero podemos comparar un clúster de Kubernetes que usa solo contenedores con uno que usa WebAssembly. Un nodo de Kubernetes puede ejecutar un máximo teórico de poco más de 250 pods. La mayoría de las veces, una máquina virtual de tamaño moderado alcanza los límites de memoria y potencia de procesamiento en tan solo unas pocas docenas de contenedores. Y esto se debe a que los contenedores consumen recursos durante toda su actividad. En Fermyon hemos podido ejecutar de forma rutinaria miles de aplicaciones WebAssembly sin servidor incluso en nodos de tamaño modesto en un clúster de Kubernetes. Recientemente cargamos 5000 aplicaciones sin servidor probadas en un clúster de nodos de dos trabajadores, logrando más de 1,5 millones de invocaciones de funciones en 10 segundos. Fermyon Cloud, nuestro sistema de producción público, ejecuta 3000 aplicaciones creadas por usuarios en cada máquina virtual de 8 núcleos y 32 GiB. Y ese sistema ha estado en producción durante más de 18 meses. En resumen, hemos logrado eficiencia a través de densidad y velocidad. Y la eficiencia se traduce directamente en ahorro de costos. Más segura que la repatriación La repatriación es una vía para ahorrar costos. Otra es cambiar los patrones de desarrollo de servicios de larga duración a funciones sin servidor impulsadas por WebAssembly. Si bien, en última instancia, no son mutuamente excluyentes, uno de los dos es de alto riesgo. Pasar de la nube a lo local es un camino que cambiará su negocio, y posiblemente no para mejor. La repatriación se basa en la La idea de que lo mejor que podemos hacer para controlar el gasto en la nube es mover todas esas cosas (todos esos clústeres, servidores proxy y balanceadores de carga de Kubernetes) de regreso a un espacio físico que controlamos. Por supuesto, no hace falta decir que esto implica comprar espacio, hardware, ancho de banda, etc. E implica transformar el equipo de operaciones de una mentalidad de software y servicios a una mentalidad de gestión de hardware. Como alguien que recuerda (no con cariño) almacenar servidores en rack, solucionar problemas de hardware roto y ver la medianoche ir y venir mientras lo hacía, la idea de repatriar inspira cualquier cosa menos una sensación de anticipación edificante. La transición de regreso a las instalaciones es un trabajo pesado, y uno que es difícil de rescindir si las cosas van mal. Y los ahorros aún no se verán hasta que se complete la transición (de hecho, con los gastos de capital involucrados en la mudanza, puede pasar mucho tiempo hasta que se realicen los ahorros). Por el contrario, cambiar a funciones sin servidor impulsadas por WebAssembly es menos costoso y menos riesgoso. Debido a que dichas funciones pueden ejecutarse dentro de Kubernetes, la tesis del ahorro puede probarse simplemente separando algunos servicios representativos, reescribiéndolos y analizando los resultados. Aquellos que ya han invertido en una arquitectura de estilo microservicio ya están bien preparados para reconstruir solo fragmentos de una aplicación multiservicio. De manera similar, a quienes invierten en cadenas de procesamiento de eventos, como canales de transformación de datos, también les resultará fácil identificar uno o dos pasos en una secuencia que puede convertirse en el banco de pruebas para la experimentación. Esto no solo es una barrera de entrada más baja, sino también si funciona o no. , siempre existe la opción de seleccionar la repatriación sin tener que realizar un segundo cambio, ya que las funciones sin servidor de WebAssembly funcionan tan bien en las instalaciones (o en el borde, o en cualquier otro lugar) como en la nube. Ahorro de costos a qué costo ?Ya es hora de que aprendamos a controlar nuestros gastos en la nube. Pero hay formas mucho menos drásticas (y riesgosas) de hacerlo que la repatriación. Sería prudente explorar primero las soluciones más baratas y sencillas antes de subirse al carro… y luego llenarlo de bastidores de servidores. Y la buena noticia es que si me equivoco, será fácil repatriar esas funciones de WebAssembly sin servidor de código abierto. Después de todo, son más livianos, más rápidos, más baratos y más eficientes que el status quo de ayer. Una manera fácil de comenzar con WebAssembly nativo de la nube es probar el marco Spin de código abierto. Y si Kubernetes es su entorno de implementación de destino, SpinKube de código abierto puede instalar y administrar un entorno WebAssembly sin servidor en el clúster. En tan solo unos minutos, podrá comprobar si la solución a sus necesidades de control de costes no es la repatriación, sino la creación de aplicaciones más eficientes que hagan un mejor uso de sus recursos en la nube. Matt Butcher es cofundador y director ejecutivo de Fermyon. el WebAssembly sin servidor en la empresa de la nube. Es uno de los creadores originales de Helm, Brigade, CNAB, OAM, Glide y Krustlet. Ha escrito y coescrito muchos libros, incluidos “Learning Helm” y “Go in Practice”. Es cocreador de la serie “Guía ilustrada para niños sobre Kubernetes”. Actualmente, trabaja principalmente en proyectos WebAssembly como Spin, Fermyon Cloud y Bartholomew. Tiene un doctorado. en filosofía. Vive en Colorado, donde bebe mucho café. New Tech Forum ofrece un lugar para que los líderes tecnológicos (incluidos proveedores y otros contribuyentes externos) exploren y discutan la tecnología empresarial emergente con una profundidad y amplitud sin precedentes. La selección es subjetiva y se basa en nuestra elección de las tecnologías que creemos que son importantes y de mayor interés para los lectores de InfoWorld. InfoWorld no acepta garantías de marketing para su publicación y se reserva el derecho de editar todo el contenido aportado. Envíe todas sus consultas a doug_dineley@foundryco.com. Copyright © 2024 IDG Communications, Inc.
