Únase a nuestra comunidad de Telegram para líderes tecnológicos de Web3
Aquí reuniremos a directores de tecnología, líderes de DevOps y otros expertos interesados en sumergirse en la infraestructura blockchain más allá de lo que puede encontrar en línea
Kubernetes frente a sistemas sin servidor: ventajas y desventajas
Todas las ventajas y desventajas de Kubernetes provienen de su naturaleza de plataforma multifuncional con un montón de posibilidades que no puedes cubrir solo o incluso con tu equipo durante un corto período de tiempo.
Necesitas un par de cerebros adicionales, como Dysnix.
Los beneficios de la arquitectura sin servidor son irremplazables para algunos tipos de proyectos, pero debes pensar con mucho cuidado si tu aplicación se ajusta a esta categoría.
¿En qué se diferencian mucho?
¿Qué tienen en común?
Ambas herramientas se pueden aplicar para un enfoque de microservicios.
Se pueden lanzar en la nube.
Las aplicaciones se inician de una vez (tarda unos segundos).
Ambos sistemas funcionan a través de herramientas de terceros a través de API.
Estas dos estructuras son entornos aislados.
Descripción general de los casos de uso
De acuerdo, eso fue enorme, pero solo nos hemos acercado a la parte más interesante de la descripción general de los casos de uso, donde podrás encontrar el caso de tu aplicación y ver nuestras recomendaciones.
Cuándo usar Kubernetes
La razón general para usar k8s es la necesidad de flexibilidad y la ausencia de problemas cuando se trata de la migración de proyectos heredados con una miríada de conexiones y flujos de datos de terceros para ejecutar todo tipo de aplicaciones, ya sea una aplicación distribuida moderna nativa de la nube o un montón de sitios web simples con una base de datos MySQL.
Sus otras posibles demandas:
Si quieres escalar tu aplicación en el futuro de forma constante y estar siempre preparado para las últimas innovaciones.
Si su proyecto necesita tratar con diferentes versiones, tanto antiguas como nuevas, del software en diferentes plataformas. Con los contenedores, obtendrás el suelo que mejor se adapte y responda mejor a la hora de crear todos los requisitos de tu aplicación.
Si hace mucho tiempo desarrolló software heredado que desea modernizar con un entorno en contenedores con la esperanza de obtener una mayor productividad, o si tiene una aplicación monolítica que desea reconstruir en microservicios.
Quiere implementar CI/CD para su proyecto.
Tiene requisitos adicionales de seguridad, asignación de recursos o política administrativa.
Sus requisitos de aplicación son complejos: ciertos lenguajes de programación que pueden no ser compatibles con un proveedor de nube; API de bajo nivel, como el control de subprocesos; componentes con estado o tareas de larga ejecución; uso intensivo de la JVM, especialmente la concurrencia; sistemas distribuidos en tiempo real.
Si tiene un proyecto de comercio electrónico enorme, todos los procesos y funciones se pueden volver a empaquetar en contenedores sin cambiar la lógica empresarial.
Su equipo tiene una parte de DevOps o ingenieros de k8s, por lo que no necesita contratar personal adicional para lanzar k8s.
Actualmente, ejecuta su aplicación de forma local, en la nube o híbrida en servidores dedicados o máquinas virtuales y busca modernizar y optimizar su entorno.
No existe la opción de depender de un proveedor para su proyecto.
Está listo para invertir recursos en k8s para reducir los costos en el futuro.
Cuándo no usar Kubernetes o considerar que el proceso puede requerir esfuerzos adicionales debido a los siguientes posibles riesgos:
Incluso si configuras el control automático del escalado para los cambios de tráfico en dos niveles (pods y nodos), el proceso de reacción a los picos bruscos puede tardar un tiempo considerable en activar la reserva suficiente de instancias. Para algunos proyectos, cada segundo importa, por lo que debemos mencionar este punto. Por cierto, el escalado sin servidor, por ejemplo, Lambda y Google Function, también puede llevar tiempo.
Los costos de tiempo de ejecución son inevitables.
El apagado completo cuando no hay tráfico es imposible.
Kubernetes es una de las mejores soluciones para una amplia gama de aplicaciones y servicios: desde sitios web con bases de datos pequeñas hasta grandes aplicaciones heredadas. Y aunque la infraestructura de k8 exija un equipo más grande y su configuración y mantenimiento lleven más tiempo, la variedad de soluciones de código abierto simplificará enormemente sus tareas diarias. Por lo tanto, con Kubernetes, pagas por tener más control y opciones para reducir los costos en un entorno flexible pero estable.
Cuándo usar la tecnología sin servidor
Resumiendo, utilice Serverless si necesita «ir rápido, no muy lejos»: desarrollo e implementación rápidos, escalado automático y una disminución de los costos mínimos posibles de tiempo de ejecución.
Más detalles de los casos de uso sobre cuándo usar la arquitectura sin servidor:
Si tu equipo está formado principalmente por desarrolladores sin experiencia operativa (red, almacenamiento, supervisión, etc.), pero quieres probar tu idea de aplicación rápidamente. Y si funciona para el cliente, querrás escalar en un abrir y cerrar de ojos.
No tiene pensado migrar ni utilizar el mismo código entre proveedores de nube o no lo necesita.
Su equipo reacciona perfectamente bien ante los lenguajes de programación y las restricciones de herramientas de su proveedor.
Tiene el patrón de picos y caídas de tráfico y desea sacarle el máximo provecho ahorrando en costos de tiempo de ejecución en los puntos de tráfico cero o con poco tráfico.
Su equipo no quiere o no puede administrar ninguna infraestructura para su aplicación, sino que se concentra en ofrecer el valor al cliente final.
Puede hacer frente a los picos repentinos en las facturas mensuales. Esto puede ser un problema para las empresas emergentes, ya que una gran factura de la nube podría meterlas en problemas.
Su presupuesto no incluye ningún gasto en infraestructura de back-end.
Si tu aplicación (o partes de ella) está impulsada por eventos, no se ejecutará durante todo el tiempo.
Cuándo no usar Serverless y considerar la especificidad y los posibles riesgos:
La dependencia del vendedor. Es una gran cuestión de credibilidad. Además, al comparar Kubernetes con AWS Lambda, es posible que confíe en ellos de manera diferente y eso influya en su decisión... Aun así, cada proveedor de nube limitará sus necesidades en cuanto a fuentes de eventos, lenguajes de programación y tiempo de ejecución. Deberías estar preparado para ello. Y si está decidido a utilizar un proveedor, sería muy difícil migrar a otro o volver a utilizar la tecnología local.
Por cierto, háganos saber si lambda contra kubernetes es un tema interesante para usted.
No se puede aplicar a aplicaciones distribuidas en tiempo real, tareas o procesos de ejecución prolongada, procesamiento de streaming con estado, etc. Los eventos activan las funciones y todo debe ser lo más sencillo posible para obtener una respuesta rápida. Con una aplicación sin servidor, no puedes tener un control explícito sobre tu infraestructura para optimizar tu rendimiento de ninguna otra manera.
A veces, incluso Serverless puede resultar caro. ¿Qué pasa si la cantidad de eventos o procesos de ejecución supera sus expectativas? Y aunque todo se pueda controlar perfectamente y tú establezcas los límites de los costes de ejecución, una parte de los beneficios podría desaparecer. O si tenemos en cuenta los precios de las integraciones y sus políticas de pago, la comprobación final puede resultar espantosa.
Requisito de almacenar información persistente en el disco.
Soporte para protocolos específicos (mqtt para IoT, por ejemplo) que no son compatibles con la plataforma Serverless.
¿Pueden coexistir sin servidor y contenedores y crear una arquitectura híbrida confiable?
No viviremos en el siglo XXI si alguien no lo ha probado todavía o ha ido más allá de la comparación típica entre Kubernetes y Lambda. La práctica habitual consiste en dividir la aplicación en partes de contenedores basados en microservicios y funciones basadas en la nube. En estas combinaciones, es posible complementar los puntos débiles de cada parte.
AWS Fargate le brinda la libertad de experimentar con soluciones híbridas al permitirle trabajar con contenedores sin preocuparse por los servidores y los clústeres. Knative es otro ejemplo utilizado para k8s, que aplica el enfoque sin servidor e inhabilita los contenedores inactivos.
Háganos saber en los comentarios si desea obtener más información sobre las herramientas híbridas y el enfoque detrás de ellas.
En resumen
Hemos analizado el oscuro bosque de los defectos y beneficios de la arquitectura sin servidor, hemos analizado los pros y los contras de los k8 y hemos realizado una serie de resúmenes. Aunque los temas de nuestra investigación fueran totalmente nuevos para usted, esperamos haberle aclarado algunas cosas, especialmente en lo que respecta a las ventajas de la arquitectura sin servidor y Kubernetes en comparación con Kubernetes. Además, sería otra comparación si analizáramos AWS Lambda frente a Kubernetes. De todos modos, todo depende de la estructura, las preferencias de desarrollo y los recursos de su empresa. Y para tomar la decisión correcta, debe obtener información de verdaderos especialistas tanto en k8s como en Serverless, y tal vez incluso de un tercero que diga que no necesita ninguno, y ver cómo funciona para usted.
Si tienes un coche de transmisión manual que se adapta bien a tu estilo de conducción, te acostumbrarás a cambiar de marcha y no le tendrás miedo al embrague. Como resultado, te llevará a donde quieras hasta que el coche se quede sin combustible.
Pero si necesitas un coche en el que puedas subirte y conducir, tal vez una transmisión automática sea lo que más te convenga ahora.
Gracias por su atención. Mantengámonos en contacto para nuestros artículos futuros. Si aún tenemos algo que aclarar, puedes enviarnos tus comentarios.
.jpg)
