Terraform para la gobernanza de costes en la nube

Si ha llegado a este artículo de Hashicorp Terraform, es probable que tenga responsabilidades de DevOps (o arquitectura en la nube) y se pregunte: “¿Por qué debería preocuparme por la optimización de costos en la nube? Esa no es mi responsabilidad, no estoy en el gobierno ni en las finanzas de FinOps, ¿verdad? " ¡Incorrecto!

Los ingenieros y arquitectos de la nube se están convirtiendo en los nuevos gerentes de finanzas de tecnología de la información a medida que los equipos de gobierno y / o finanzas comienzan a perder parte de su control directo sobre los nuevos modelos de consumo de infraestructura de nube bajo demanda.

Entonces, la pregunta que muchos de nuestros clientes nos hacen sobre el gobierno de la nube es: ¿Cuáles deberían ser los procesos, el modelo de equipo y las tecnologías que puedo usar para respaldar esta transformación digital que la nube ha acelerado?

Centro de excelencia en la nube y Terraform

Si está interesado en definir procesos de centro de excelencia en la nube (CcoE), o simplemente definir roles y responsabilidades para el gobierno de la nube e implementar un proceso de optimización de costos utilizando hashiCorp Terraform Cloud, está en el artículo correcto. ¡Vamos juntos!

Este artículo en formato de guía proporcionará:

• Un modelo RASCI que asigna responsabilidades al equipo que administra y opera los costos de la nube;
• Una vista previa de cómo se puede realizar la administración de costos en la nube dentro de un flujo de trabajo de aprovisionamiento de Terraform;
• Recomendaciones de planificación para la previsibilidad y la gestión de costes en la nube (previsión) con Terraform;
• Una introducción al uso de las capacidades de estimación de costos de Terraform;
• Instrucciones sobre cómo integrar y usar herramientas de optimización de costos de proveedores de nube de AWS, Azure y GCP (Google Cloud Platform), así como de terceros, con los flujos de trabajo de Terraform;
• Ejemplos de políticas de Terraform que utilizan códigos con Sentinel, lo que permite bloquear automáticamente el gasto excesivo mediante reglas de costes, tipos de instancias y etiquetas.

La mayoría de las características que citamos en este artículo se centrarán en la funcionalidad paga de Terraform, como Estimación de costos y Gobernanza y política, pero el caso de uso clave en torno a la optimización de costos solo se puede lograr con la versión de código abierto.

Una encuesta sobre gastos innecesarios en la nube

Con el cambio a los costos de infraestructura y operaciones basados en el consumo; es decir, utilizando proveedores de servicios en la nube (CSP) o simplemente proveedores en la nube, paga por lo que usa, pero también paga por lo que proporciona y no usa.

Si no tiene un proceso continuo de gobernanza y optimización, existe una alta probabilidad de que su gasto en la nube sea excesivo y pague por lo innecesario.

Una encuesta reciente de Densify sobre el gasto en la nube encontró que:

• 45% de las organizaciones informaron que estaban por encima del presupuesto para su gasto en la nube;
• Más de 55% de los encuestados están utilizando procesos manuales complejos o simplemente no están implementando acciones y cambios para optimizar sus recursos en la nube;
• 34,15% de los encuestados creen que pueden ahorrar hasta 25% de su gasto en la nube y 14,51% creen que pueden ahorrar hasta 50%. El más impactante de la encuesta fue que 27,46% dijo: "No sé".

Por qué los ingenieros y arquitectos de la nube se están convirtiendo en los controladores financieros de los costos de la nube

Al migrar a la nube, la mayoría de las organizaciones han estado pensando en modelos de gobernanza básicos en los que un equipo, a veces denominado Centro de excelencia en la nube, se centra en áreas como estrategia, arquitectura, operaciones y costos.

La mayoría de estos equipos contienen una combinación de expertos técnicos en TI y gestión de la nube y áreas de finanzas comunes de TI. Sin embargo, los equipos de finanzas se encargan principalmente de la planificación de costos, la previsión de migración financiera y la optimización de contratos de software.

Debido a las presiones financieras, tienden a decir: "Necesitamos controlar los costos, los ahorros, las previsiones para los próximos períodos, etc." pero no tenemos control directo sobre el uso de costos.

Son los ingenieros y arquitectos de la nube quienes administran directamente la infraestructura y los costos y, de una manera aún más arriesgada, los corredores de la nube quienes “se hacen cargo” de estos costos.

En este caso, vemos un cambio de paradigma en la tecnología de la información y la gobernanza financiera donde:

• Los ingenieros y arquitectos de la nube ya no son solo responsables de las operaciones, sino también de los costos;
• Los ingenieros y arquitectos de la nube ahora tienen las herramientas y capacidades de la Plataforma de administración de la nube (CMP) para automatizar y administrar directamente los controles de costos;
• La planificación y previsión de costes (estimación futura) para la ejecución de Workflows en la nube no son de fácil comprensión para las áreas financieras;
• Las formas tradicionales de presupuestación financiera y planificación de la demanda de hardware en las instalaciones (como la presupuestación basada en contratos y las compras de Capex) no explican ni controlan la complejidad de los costos en los modelos basados en el consumo (es decir, en la nube).

Como enfoque y para obtener ganancias rápidas, las finanzas de TI deben mantener el control de las dos áreas principales de reducción de costos:

• Aprovisionamiento previo: Gobernanza y control limitados en la fase de aprovisionamiento de recursos.
• Post-aprovisionamiento: Gobierno y control limitados en la aplicación de cambios de infraestructura para reducir costos.

En las siguientes secciones, definiremos juntos las mejores prácticas para: Personas, procesos y tecnologías (plataforma) asociado con la gestión de prácticas financieras en la nube con Terraform.

Para simplificar las cosas, asumiremos que tienen una estructura de gobierno en la nube, es decir, el Centro de excelencia en la nube (CCoE) - quién es responsable de gestionar la gobernanza general de la nube.

En este equipo que hemos estructurado, hay cuatro roles principales:

• Gestión de TI (Gestión de TI);
• Finanzas (FinOps);
• Ingeniería en la Nube (compuesta por DevOps e Infraestructura y Operaciones);
• Seguridad (SecOps);

Este modelo se puede utilizar como base de roles y acciones para este equipo de Cloud Governance.

Este es un modelo que utilizamos, junto con modelos similares como Software Asset Management (SAM), para definir los roles y responsabilidades del Centro de excelencia en la nube para muchas organizaciones.

Planificación, optimización y gobernanza

¿Cómo pueden los ingenieros y arquitectos de la nube utilizar Terraform en todos los niveles del proceso de gestión de costes de la nube para ofrecer valor y minimizar el trabajo adicional?

Para comenzar, vea cómo la visualización ilustra el rol de Terraform en el ciclo de vida de la administración de costos en la nube. Empiece desde arriba con la fase de planificación o planificación:

Ahora resumimos los pasos:

• Empiece por identificar las cargas de trabajo que se están trasladando a la nube;
• Cree la configuración de Terraform;
• Ejecutar el plan de terraform para ejecutar la estimación de costos;
• Realizar la solicitud de terraform para la provisión de recursos;
• Una vez aprovisionadas, las cargas de trabajo se ejecutarán y las herramientas CMP (plataforma de gestión en la nube) proporcionarán recomendaciones de optimización;
• Integre las recomendaciones de optimización de un proveedor en Terraform y / o su tubería de CI / CD;
• Investigar y analizar recomendaciones de optimización e implementar políticas centinelas de Terraform para controles de costos y seguridad;
• Actualice la configuración de Terraform y ejecute el plan y aplique;
• Ahora se proporcionan funciones recientemente optimizadas y compatibles.

Planificación: pre-migración y previsión de costes en curso

Las migraciones a la nube requieren una evaluación multipunto para determinar si tiene sentido mover una aplicación / carga de trabajo a la nube. Los factores principales para la evaluación son:

• Arquitectura y dimensionamiento del entorno actual;
• Business Case;
• Costo estimado del cambio;
• Costos de utilización presupuestados / anticipados en curso para los próximos 1-3 años en promedio.

Dado que los ingenieros y arquitectos de la nube ahora están asumiendo algunas de estas responsabilidades, tiene sentido utilizar herramientas de ingeniería para abordarlas.

Terraform ayuda a los ingenieros y arquitectos de la nube a asumir estas nuevas responsabilidades con la estimación de costos, lo que ayuda a calcular los costos de infraestructura de cada aprovisionamiento realizado en función del plan de implementación real.

Al usar los archivos de configuración de Terraform como una definición estándar de cómo se estima el costo de una aplicación / flujo de trabajo, ahora puede usar las API de Terraform Cloud & Enterprise para proporcionar automáticamente información financiera con datos financieros estimados en la nube o usar la interfaz de usuario de Terraform para proporcionar información financiera directa. acceso a costos.

Al hacer esto, puede eliminar muchos procesos que no se han optimizado para la reducción de costos.

Recomendaciones de planificación:

• Utilice los archivos de configuración de terraform como la definición predeterminada de planificación de la nube y previsión de costos en AWS, Microsoft Azure y GCP (Google Cloud Platform), y proporcione esta información a través de la API de Terraform o los controles de acceso basados en roles dentro de la interfaz de usuario Terraform para proporcionar un estándar financiero para flujo de trabajo de aprovisionamiento automatizado.

Nota: muchas organizaciones llevan a cabo la planificación financiera con herramientas de Excel, Google Sheets y Cloud Management Platform (CMP). Para conectar y utilizar los datos dentro de estos sistemas anteriores, recomendamos usar la API de estimaciones de costos de Terraform para extraer los datos.

• Utilice los módulos Terraform como unidades estándar de infraestructura definida para la planificación de la demanda y el cálculo de costes en la nube.
  • Ejemplo: Defina un conjunto estándar de módulos para una aplicación Java estándar, de modo que el módulo A + B + C = $X por mes. Planeamos mover 5 aplicaciones Java este año. Esta puede ser una metodología rápida para evaluar los costos potenciales de ejecutar aplicaciones antes de definir los archivos de configuración reales de Terraform.

• Utilice Terraform para comprender el crecimiento de los costos de aplicaciones / cargas de trabajo a lo largo del tiempo, es decir, los costos de expansión y / o migración de la nube.
• Intente alinear estructuralmente las convenciones de nomenclatura de Terraform, Workspace y Resource Naming Organizations con el proceso de presupuesto / previsión.

Hay una guía para Empiece a utilizar Terraform Cost Estimation. Una vez habilitado, cuando se ejecuta un plan de Terraform, Terraform llamará a las API de estimación de costos de AWS, Microsoft Azure y / o GCP para presentar el costo estimado para ese plan, que se puede usar de acuerdo con su flujo de trabajo financiero. También puede exportar este informe de estimación como JSON.

Ejemplo de estimación de costos usando Terraform

Ejemplo de carga de API JSON de estimación de costos de Terraform

Tenga en cuenta que la estimación de costos de terraform proporciona costos basados en una vista del espacio de trabajo.

Si necesita una vista del espacio de trabajo más precisa con espacios de trabajo cruzados, deberá aprovechar la API de estimación de costos de terraform junto con una herramienta de informes de su elección, como Microsoft PowerBI.

Herramientas útiles para visualizar costos en múltiples nubes

HashiCorp Terraform ha creado una sencilla herramienta de código abierto que puede brindarle esa vista más alta y transversal del espacio de trabajo. La herramienta se llama Tint y puede visitar esta publicación de blog y el repositorio GitHub del creador Peyton Casper's GitHub para aprender a usarlo.

Si tiene requisitos de informes complejos o ya tiene un producto de informes empresariales existente (por ejemplo, Microsoft BI, Tableau, etc.), los datos de estimación de costos de HashiCorp Terraform también funcionarán con estas soluciones.

Optimización: operacionalización y realización de ahorros de costos continuos

La optimización de la nube es la práctica continua de evaluar la relación costo-beneficio del uso actual de la infraestructura de la nube.

Los proveedores de la nube (Amazon AWS, Microsoft Azure, GCP, Oracle Cloud, etc.) y otras herramientas de terceros pueden comenzar con algunas recomendaciones de optimización, pero algunas organizaciones no siempre aprovechan las recomendaciones debido a una brecha de automatización.

Los ingenieros y arquitectos de la nube no siempre se involucran con las plataformas y los temas de optimización, dejándolos sin conocimiento de cómo está funcionando su trabajo en términos de impacto en los costos.

Incluso en los casos en que están involucrados con estas plataformas CMP, a menudo se requiere un alto nivel de intervención manual para reducir los costos.

Automatización de conocimientos de optimización junto con el flujo de trabajo de aprovisionamiento

Es seguro decir que los principales CSP y la gran mayoría de herramientas CMP (Cloud Management Platform) como CloudHealth VMware y Embotics de software de nieve, le permiten exportar recomendaciones de optimización a través de una API o un método alternativo (referencias: AWS,  Azur,  GCP).

En esta guía, nos centraremos en el enfoque más básico para automatizar la ingesta de datos de optimización, que vendrá directamente de los CSP o de terceros como Densify que mantienen un módulo Terraform de HashiCorp. Usaremos Densify en los ejemplos que siguen.

También hay muchos usuarios de hashicorp que desean crear sus propios proveedores de Terraform para procesos similares.

Los conceptos y códigos se pueden utilizar como plantilla para sus propias implementaciones.

Cada proveedor proporciona un conjunto diferente de recomendaciones, pero todas brindan información sobre el procesamiento (informática), así que centrémonos en eso.

Cualquier información que reciba (por ejemplo, cálculo y procesamiento, almacenamiento, base de datos, etc.) puede consumirse según el patrón que se muestra a continuación.

Estándares básicos para recomendaciones de optimización con terraform

Para establecer un mecanismo para que Terraform acceda a las recomendaciones de optimización, presentamos algunos patrones comunes:

• flujo de trabajo manual - Revisión de recomendaciones de optimización del portal de proveedores y actualización manual de archivos HashiCorp Terraform. Como no hay automatización, esto no es ideal, pero un ciclo de retroalimentación para la optimización puede comenzar desde aquí.
• Flujo de trabajo de archivos: cree un mecanismo en el que las recomendaciones de optimización se importen a un repositorio local a través de un proceso programado (generalmente a diario).
  • Por ejemplo, los clientes de densify usan un script para exportar recomendaciones a un archivo densify.auto.tfvars y esto se descarga y almacena en un repositorio accesible localmente. Entonces la función búsqueda Terraform se utiliza para buscar actualizaciones de optimización específicas que se han definido como variables.

• Flujo de trabajo de API - Cree un mecanismo para que las recomendaciones de optimización se obtengan directamente del proveedor y se almacenen en un repositorio de datos accesible utilizando la funcionalidad http fuente de datos de Terraform para ejecutar la referencia de importación del conjunto de datos.
• Flujo de trabajo de emisión de tickets - Este flujo de trabajo es similar a los flujos de trabajo de archivos y API, pero algunas empresas ingresan a un paso intermedio en el que las recomendaciones de optimización van primero a un sistema de control de la mesa de servicio y operaciones de TI como ServiceNow o Jira. Dentro de estos sistemas hay un flujo de trabajo y una lógica de aprobación incorporada donde se establece una marca para los cambios aprobados y se pasa como una variable para ser consumida más adelante en el proceso.

Optimización de código: ejemplos de actualización de código de HashiCorp terraformar

En cualquiera de estos casos, especialmente si se implementan procesos de automatización, es importante mantener los datos de recursos clave como variables.

Las herramientas de información de optimización proporcionarán una recomendación de tamaño para los recursos o servicios (es decir, cómputo, base de datos, almacenamiento, etc.). En este ejemplo, usaremos recursos computacionales, pero el ejemplo es representativo para todos.

Como mínimo, recomendamos que tenga tres variables definidas para realizar la actualización de optimización en Terraform con alguna lógica básica: new_recommendations, current_fallback y resource_unique_id.

Como mencionamos, usaremos Densify. Puedes encontrar el piedra de molinoDDensificar Terraform  a través de Terraform Registry y Repo Do Densify-dev en GitHub.

En el blog de Terraform encontrarás varios códigos creados, recomendamos acceder e investigar.

Gobernanza: garantía de ahorros de costos futuros con HashiCorp Terraform

El último y crítico componente del ciclo de vida de la gestión de costos de la nube es tener políticas creadas y definidas para detener los sobrecostos y proporcionar informes para la operación de la nube.

En Terraform, puede automatizar estos informes con Sentinel, un marco de código similar a una política integrado en HashiCorp Terraform para la gobernanza y la política (Sentinel también se puede utilizar en otros productos de HashiCorp).

Cumplimiento de costos como código y política centinela como código

Sentinel incluye un lenguaje específico de dominio (DSL) para escribir definiciones de políticas que evalúan todos y cada uno de los datos definidos en un archivo Terraform.

Puede utilizar Sentinel para asegurarse de que sus recursos aprovisionados estén: seguros, etiquetados y dentro de las restricciones de uso y costo.

Para los costos, los clientes de Terraform implementan la política principalmente en torno a tres áreas: (pero recuerde, no está limitado solo a estas tres):

Áreas de control de costos:

• La cantidad - Controlar el monto de los gastos;
• Tamaño aprovisionado - Controlar el tamaño / uso de los recursos y el tamaño correcto;
• Tiempo de vida - Controla la vida útil (TTL) del recurso.

En las tres áreas, puede aplicar controles de políticas en torno a recursos como los espacios de trabajo de Terraform, por ejemplo: aplicaciones / cargas de trabajo, entornos: producción, desarrollo y aprobación, y políticas de etiquetas para optimizar los recursos y evitar gastos innecesarios.

El siguiente es un ejemplo de salida de la política centinela al ejecutar terraform plane. Centrémonos en tres políticas:

1. aws-global / limit-cost-by-workspace-type
2. aws-compute-nonprod / restrict-ec2-instance-type
3. etiquetas-aws-global / enforce-communities-

Sentinel tiene tres niveles de ejecución: consultivo, obligatorio suave y obligatorio estricto; consulte el enlace proporcionado para ver las definiciones. El nivel de ejecución dictará el flujo de trabajo y la resolución de las infracciones de la política.

Si está utilizando Terraform Cloud for Business o Terraform Enterprise, los usuarios pueden interactuar con Terraform UI, CLI o API para integrarse completamente en sus canales de CD / CD para el control del flujo de trabajo de políticas y en sistemas VCS como GitLab, GitHub y BitBucket para la creación y administración de políticas. .

Ejemplos de códigos de gobernanza de costes con Sentinel en terraform

En política aws-global / limit-cost-by-workspace-type definido para este espacio de trabajo (que puede ser definido individual o globalmente) aplicamos límites de gasto mensual y un nivel de ejecución.

Puedes ver extractos en el Enlace que muestran los limitadores de costos (US$ 200 para desarrollo, US$ 500 para control de calidad, etc.).

El nivel de ejecución como suave obligatorio, lo que significa que los administradores pueden anular las fallas de las políticas si existe una razón legítima, pero eso evitará que la mayoría de los usuarios gasten hasta esa cantidad.

El camino hacia la gestión de costes en la nube

A medida que las organizaciones utilizan cada vez más la infraestructura en la nube, la filosofía DevOps ya no puede ignorarse. A medida que los silos entre desarrolladores y operadores se rompen, los silos también pueden romperse entre finanzas e ingeniería / arquitectura.

Los ingenieros y arquitectos de la nube están mucho más capacitados para implementar la infraestructura que necesitan de inmediato. Esto significa una mayor responsabilidad para controlar estos costos por sí mismos. Tecnologías como Terraform y Sentinel brindan a la ingeniería los flujos de trabajo automatizados y supervisados por las finanzas que necesitan para administrar los costos y recuperar los recursos no utilizados, todo dentro de la herramienta que la mayoría de ellos ya usa.

Esto ayuda a las organizaciones a evitar un enfoque complicado y multiplataforma mientras evita el caos y el desperdicio de Shadow IT.

Fuente: https://www.hashicorp.com/blog/a-guide-to-cloud-cost-optimization-with-hashicorp-terraform

Etiqueta: terraform enterprise, terraform plan, terraform cli, google cloud, infraestructura como código, infraestructura en la nube, plataforma en la nube de google, clave pública, red virtual, lenguaje de configuración hashicorp, terraform por hashicorp, nube oracle, análisis de seguridad, necesidad de crear, código con terraform, legible por humanos, archivo maintf, proveedores de nube, variables de entorno, aws s3, plan de ejecución, vamos a crear, recurso aws, escribir código, de forma segura y predecible, configuración declarativa, microsoft azure, plataforma en la nube, archivos de configuración, visual studio, bases de datos , infraestructura como código, máquinas virtuales, alta disponibilidad, lenguaje de configuración, terraform para aprovisionamiento, archivos de configuración declarativos, nivel empresarial en la nube terraform, proveedores en la nube, proveedor en la nube, infraestructura como código, devops azure, centro de excelencia en la nube, gestión de activos de software, infraestructura como código, infraestructura de provisión, solución de código, línea de comando, acciones de github, ambi entidad de producción, vía terraform, plan de ejecución, módulos del registro, terraform puede ayudar, versiones de infraestructura, apis en configuración declarativa, generar un plan, integraciones de infraestructura, plan de comando, infraestructura como solución, control de acceso, nubes privadas, módulo de infraestructura, ejecutar terraform, flujo de trabajo típico, gestión de infraestructura, definir infraestructura, vmware vsphere, recursos aws, archivos de configuración, cuáles son sus aplicaciones, terraform vs, mejores prácticas, registro de módulos, varias nubes, cdk para terraform, plan terraform, registro terraform, fuentes de datos , contáctenos, terraform init, dependencias de recursos, módulo terraform, plataforma en la nube hashicorp, infraestructura aws, control de versiones, nube ibm, asociado terraform, gráfico de recursos, empresa terraform, nube google, infraestructura como código, proveedores de nube, ciclo de vida, lenguaje de configuración hashicorp , infraestructura que necesitaban, infraestructura en la nube, están usando, terraform por hashicorp, oracle cloud, de forma segura y predecible, plan de ejecución, infraestructura en la nube, plataforma en la nube de google, código con terraform, bases de datos, microsoft azure, archivos de configuración declarativos