Hoy quiero hablar sobre una herramienta que traduce los procedimientos para aprobar y emitir máquinas virtuales al autoservicio completo, preservando la lógica de la cuota y agregando la capacidad de predecir la utilización de recursos.
Como ex ingeniero de infraestructura, sé lo que es utilizar múltiples nubes públicas o privadas en un equipo grande. Suele haber dos formas. O el proceso de asignación de recursos es demasiado burocrático: los equipos comienzan a esperar las máquinas virtuales durante una semana y las mantienen "vivas" el mayor tiempo posible para no repetir este camino. O sobreviene un verdadero caos, cuando nadie sabe qué equipo y cuántos recursos están consumiendo y qué cientos y miles de dólares se gastan mensualmente en el mismo AWS. Una forma posible de simplificar esta situación es mover a los desarrolladores al autoservicio en la nube utilizando el producto de nuestros socios: CloudMaster.
Cuál es el problema
Cuando una empresa emplea a cientos de desarrolladores y DevOps, cada equipo tiene su propio proyecto y necesidades de experimentos, no puede confiar en la responsabilidad de cada individuo por la capacidad asignada por la empresa. Para comprender la magnitud del problema, aquí están las estadísticas de un cliente de CloudMaster que usa nubes públicas y su propia virtualización en OpenStack.
Al desarrollar varios cientos de proyectos en paralelo, el cliente consume los recursos totales de AWS, Azure y GCP por medio millón de dólares al mes. Y crea y elimina alrededor de 350 mil máquinas virtuales al año.
Si se permite que el proceso siga su curso a tal escala, se producirá una verdadera anarquía. Cientos de máquinas virtuales se congelarán sin usar. Sin entender quién y por qué lanzó una máquina virtual en particular, será extremadamente difícil determinar si es necesaria en el trabajo y si será necesaria en el futuro. Esto conlleva gastos innecesarios de alquiler de recursos en la nube, y es básicamente imposible realizar ningún análisis de lo que está sucediendo o predecir la carga en estas condiciones.
Una forma lógica de evitar esto es prescribir un proceso empresarial de negociación de recursos. Por supuesto, esto complica el camino del desarrollador para obtener una máquina virtual: debe completar una solicitud y enviarla a la persona a cargo. Pero, si recopila los informes correctamente, el gerente tendrá una imagen completa: quién, cuándo y qué capacidad solicitó. Con un cierto retraso, incluso podrá analizar las necesidades de los equipos en capacidad virtual. Pero esto tampoco es una panacea. Con un volumen de solicitudes suficiente, los equipos con sus proyectos "cuelgan" esperando que el responsable mire y evalúe la próxima aplicación. Y cuanto más grande sea la empresa, más larga será la espera.
En este caso, todas las máquinas virtuales creadas no tienen una "fecha de vencimiento", es decir, entonces alguien tendrá que controlar que todos los recursos asignados se apaguen a la hora anunciada y esto no afectó a los proyectos.
Autoservicio a través de plataformas de gestión en la nube (CMP)
Para poner las cosas en orden en varias nubes utilizadas, privadas o públicas, las soluciones de la clase Cloud Management Platform ayudan. Quiero hablar sobre la alternativa rusa de nuestros socios: la plataforma CloudMaster, enfocada en conectarse a Azure, AWS y Google Cloud, así como regiones privadas bajo vCloud Director, vSphere y OpenStack.
Desde el punto de vista de un desarrollador, CloudMaster es un portal de autoservicio donde, a través de una única interfaz y sin burocracia (a través de la UI en el navegador, la aplicación móvil y los comandos de la consola (scripts Python)), se pueden obtener recursos en la nube corporativa o en el centro de datos. Y para la infraestructura, esta es una capa adicional de abstracción entre las plataformas en la nube y los usuarios finales, que preserva el uso compartido selectivo de recursos, políticas de seguridad, configuraciones estándar y otras herramientas necesarias como imágenes de máquinas y plantillas de Terraform.
La mayor parte de CloudMaster está basado en Java y en los frameworks Spring del lado del servidor y Dagger en la aplicación de Android.
Arquitectónicamente, CloudMaster está diseñado para trabajar con equipos grandes y volúmenes significativos de mensajes enviados: RabbitMQ se usa para procesar colas, MonogoDB se usa para almacenamiento de datos y Nginx se usa para equilibrar.
La herramienta se ha desarrollado desde 2012 y desde 2014 ha sido utilizada por un gran desarrollador de software.
Lógica CloudMaster
Desde la perspectiva del desarrollador, CloudMaster es una ventanilla única para lanzar rápidamente máquinas virtuales en todas las nubes y regiones disponibles. La herramienta le permite no esperar las aprobaciones, sino obtener un recurso aquí y ahora.
El registro en el portal es suficiente para acceder a esta “ventanilla única”. Y si CloudMaster está integrado con AD corporativo, los roles de los empleados en la empresa y en el proyecto se cargarán en esta herramienta, determinando automáticamente los proyectos y recursos disponibles.
Ventana de inicio de la máquina virtual
Si tiene los derechos adecuados, un comando puede iniciar hasta 10 máquinas virtuales de "formularios" típicos. En términos de CloudMaster, estas son configuraciones estándar que se asignan a las ofertas de recursos típicas de cada nube (y se personalizan para la tarea).
"Plantillas" comunes para diferentes nubes
Puede crear imágenes a partir de máquinas existentes, utilizar plantillas listas para usar como "infraestructura como código" o cargar las suyas propias (Terraform y CloudFormation).
Plantillas
En este caso, las máquinas virtuales se pueden crear de forma indefinida o trabajar de acuerdo con un programa específico. Esto da cierta libertad en el uso de recursos. Por ejemplo, una empresa puede permitir que los desarrolladores utilicen la nube corporativa para la experimentación personal y la comparación, pero solo por un día. Este es, por cierto, el cliente de esta plataforma haciendo un desarrollo personalizado. Todas las máquinas virtuales creadas de esta manera se eliminan por sí mismas dentro de un período específico.
Desde el punto de vista de un gerente, lo más útil de CloudMaster es que cuenta todas las máquinas virtuales en ejecución. Para ellos, existen secciones con información completa sobre las VM en la nube / región seleccionada, incluidas las creadas según plantillas específicas, con facturación de proveedores de nube, métricas de consumo de recursos por proyectos individuales, donde se pueden identificar capacidades no utilizadas o infrautilizadas.
Lista de recursos
Lista de máquinas virtuales
Además de mostrar información en la interfaz, CloudMaster genera alrededor de 60 tipos de notificaciones, incluidas las relacionadas con las finanzas.
Notificaciones entrantes
Y el texto de una de las notificaciones
La lógica del servicio es tal que cada VM tiene un propietario: la persona que creó esta máquina virtual o la persona a la que se transfirieron estas funciones. El propietario recibe todas las notificaciones sobre la utilización de recursos o cambios en el estado de la máquina virtual y también es responsable de los costos. En este sentido, CloudMaster ayuda a inculcar una cultura de control de la utilización de la capacidad y asumir la responsabilidad de las máquinas zombies abandonadas.
Las restricciones sobre la creación de nuevas máquinas virtuales se rigen por derechos de acceso y cuotas. Y aquí es posible personalizar cualquier flujo de trabajo, hasta admitir representantes de clientes en la nube. Puede prescribir cuotas para los equipos y prever varias acciones cuando se alcancen o se acerquen a un determinado valor umbral (digamos, el 70% de la cuota).
Facturación de proveedores en la nube
Ventana de administración de cuotas
Para nubes privadas (OpenStack y VMware), CloudMaster admite una especie de intercambio: una estimación del costo de ejecutar máquinas virtuales, con la que puede elegir un esquema de utilización de recursos más rentable. Los colegas dicen que en el futuro tal característica puede aparecer para las nubes públicas.
En este sistema, el rol de un ingeniero de infraestructura es el más cercano a mí, así que lo dejé para el final. Para DevOps, esta es, por supuesto, una nueva herramienta, pero es posible controlar lo que sucede con los recursos de la nube utilizándola únicamente. Las herramientas de configuración, supervisión y desarrollo populares como Chef y Ansible se pueden implementar de forma más rápida y sencilla.
Un SDK de Java está disponible para administradores y desarrolladores si es necesario.
Lo más importante es que CloudMaster, al igual que otros CMP, le permite pasar de la asignación de recursos de rutina manual a tareas más interesantes: desarrollar automatización basada en "infraestructura como código", etc.
En mi experiencia, la aparición de este tipo de herramientas se justifica si la empresa emplea al menos cincuenta máquinas virtuales y hay al menos quince usuarios activos de diferentes nubes. Por un lado, se trata de una cierta complicación de la infraestructura, pero por otro, está llevando nubes heterogéneas, cada una de las cuales tiene sus propias herramientas de gestión, a un denominador común con la garantía de que no viola los estándares corporativos internos. Al mismo tiempo, la herramienta "reduce" la responsabilidad de la utilización de recursos y la planificación presupuestaria al nivel de los directores de proyecto, lo que es ideológicamente más correcto.