La última vez
hablamos sobre las herramientas y servicios más populares y discutidos para trabajar con registros y bases de datos. El tema de hoy es la
gestión de contenedores y el equilibrio de carga en la nube .
/ foto Nicolas Henderson CC BY
Apache OpenWhisk es una plataforma de nube abierta para la informática sin servidor. Este concepto supone que los recursos informáticos de la nube se utilizan como servicios. Por lo tanto, los desarrolladores y administradores no necesitan preocuparse por el mantenimiento de la infraestructura y el servidor. Resulta que OpenWhisk se ocupa de la escalabilidad, el soporte de código y los problemas de seguridad.
El trabajo en OpenWhisk fue iniciado por empleados de IBM Research en 2015. Y en 2016, el código fuente del proyecto
apareció en GitHub . La plataforma ganó popularidad rápidamente debido a la tendencia en rápido desarrollo de la informática sin servidor. Markets & Markets
predice que para 2021 el valor de este mercado será de $ 7.7 mil millones (en comparación con $ 2 mil millones en 2016). Ya hoy, además de IBM,
compañías como Adobe y Naver (el motor de búsqueda más popular en Corea del Sur)
utilizan la plataforma en sus soluciones.
Las ventajas de la plataforma también fueron apreciadas en Red Hat. Los representantes de la compañía
creen que otros proyectos abiertos (Fission, Kubeless, IronFunctions) son inferiores a OpenWhisk en términos de la base del código, la calidad de las funciones y el número de contribuyentes. Por lo tanto, los propios Red Hat trabajan con OpenWhisk y ayudan a que el proyecto crezca.
La plataforma también tiene desventajas. Los usuarios notan que OpenWhisk tiene demasiadas herramientas. Incluye: CouchDB, Kafka, Nginx, Redis y Zookeeper. La mera presencia de funcionalidad adicional no es algo malo, es solo que es difícil descubrir toda esta variedad.
Además, en 2018, la reputación de OpenWhisk fue "
arruinada " por vulnerabilidades que permitieron a un atacante cambiar las funciones del usuario bajo ciertas condiciones. Se
cerraron rápidamente , pero los desarrolladores
necesitaban actualizar las etiquetas Docker o Git a la última versión. Por lo tanto, se desconoce el número exacto de sistemas que permanecen vulnerables. Puede leer más sobre la seguridad de OpenWhisk en un
artículo sobre Medium . Aquellos que quieran conocer mejor la plataforma y probarla deben prestar atención a la
guía del blog de James Thomas, el desarrollador de IBM Cloud.
Esta es una nueva plataforma en la nube para desarrollar programas en JavaScript, Python, Go
, etc. Las aplicaciones listas para usar se pueden ejecutar en cualquier nube, incluido el uso de contenedores Kubernetes. Al mismo tiempo, Pulumi se basa en el concepto de infraestructura programable (infraestructura como código). Los usuarios tienen la oportunidad de trabajar con el hardware como un código (administrar la configuración del hardware mediante programación).
Todavía es difícil evaluar qué tan efectiva será la herramienta en proyectos reales. Varios residentes de Hacker News en el hilo temático
señalaron que Pulumi no es adecuado para trabajar en metal desnudo. Además, la herramienta no tiene ventajas serias sobre herramientas similares como
Terraform , que ha estado en el mercado durante cuatro años y ha logrado ganarse una comunidad.
Si todavía está interesado en evaluar las características de Pulumi, puede encontrar una guía de inicio rápido en el repositorio
de GitHub .
GLB Director es un equilibrador de carga de GitHub al que los desarrolladores abrieron el acceso a fines del verano pasado.
Hablamos sobre este evento
en uno de los materiales de nuestro blog .
La herramienta en sí era la respuesta al problema que enfrentaba la empresa. La solución anterior, haproxy,
no podía manejar la carga en GitHub. Al usar haproxy, puede escalar los servicios solo verticalmente: agregar procesador, memoria, recursos de disco, lo que no proporcionó un aumento tangible del rendimiento. Por lo tanto, los desarrolladores crearon su propia solución, adaptada a la carga del servicio web.
GLB Director no dirige los paquetes a un solo nodo, sino que los distribuye entre los proxys primarios y secundarios utilizando un sistema basado en hashing de encuentro ( HRW ). Si un servidor falla, los paquetes se redirigen al segundo. Debido a esto, el equilibrador admite la tolerancia a fallas de las conexiones TCP.
Los usuarios de Hacker News
creen que es difícil entender de inmediato cómo trabajar con el equilibrador. Sin embargo, es eficaz para el equilibrio de carga en grandes centros de datos. Al mismo tiempo, GLB Director puede ser inconveniente al equilibrar la carga entre los servidores de fondo. Para esta tarea, tiene sentido recurrir a otra solución abierta: el equilibrador de Facebook
Katran .
/ foto Christopher A. Dominic CC BY
Crossplane es una plataforma abierta de gestión de carga de múltiples nubes. Le permite transferir aplicaciones entre múltiples entornos de nube y es independiente de los tipos de clústeres y bibliotecas utilizados. La plataforma ayuda a diferenciar las responsabilidades de los desarrolladores y administradores, al tiempo que supervisa la estabilidad de los servicios.
La arquitectura de la plataforma se basa en el modelo de asignación de recursos que utiliza Kubernetes. En general, Crossplane es un híbrido de Kubernetes y la Terraform antes mencionada.
La diferencia de Crossplane es que en esta plataforma todos los archivos de configuración se recopilan en un solo lugar. Sin embargo, se
cree que la nueva herramienta tendrá que usarse junto con Terraform, y no en su lugar.
Para familiarizarse con la plataforma en la práctica, los autores sugieren iniciar una aplicación de Wordpress utilizando la
guía en el blog de la comunidad.
Titus es la plataforma de gestión de contenedores de Netflix, que se lanzó a código abierto el año pasado. Le permite a la empresa trabajar con 200 mil clústeres informáticos al día. La solución se basa en el sistema de gestión
Apache Mesos , que combina máquinas virtuales en un clúster. Se utiliza un enfoque similar en el kernel de Linux cuando es necesario compartir recursos de hardware entre procesos locales.
Se
cree que el descubrimiento de código es el intento de Netflix de mantener el proyecto a flote. Netflix necesitaba una solución de gestión de contenedores antes de que llegara Kubernetes. Por lo tanto, su sistema casi no tiene ventajas sobre la herramienta de Google (solo las empresas que ya trabajan con Apache Mesos pueden beneficiarse). Fue desarrollado más tarde y dirigido a entornos de múltiples nubes, por lo que una gran comunidad ya se ha formado a su alrededor.
En este sentido, es probable que en el futuro los propios desarrolladores de Netflix abandonen a Titus y se cambien a Kubernetes.
La próxima vez continuaremos hablando sobre herramientas populares de código abierto. Hablemos de soluciones que simplifican las tareas de los desarrolladores de software.
Materiales de nuestro blog corporativo:
Lectura adicional en nuestro canal de Telegram: