Los tres pilares para construir una cultura de optimización de costos en tu empresa, con una guía paso a paso para lograrlo con los productos de DoiT.
En muchas empresas, la optimización de costos casi siempre llega en modo pánico, como reacción a algún evento externo: el equipo de finanzas se lleva un susto con la factura o hay que reducir el burn rate antes de una ronda de financiamiento.
Si esto te suena familiar, conviene empezar a fomentar un enfoque más proactivo en toda la empresa. La optimización de costos no debería ser tarea de una sola persona. A cada engineer y a cada usuario de la nube debería importarle.
Pero para que les importe, hay que generar un sentido de responsabilidad y propiedad sobre los costos en la nube entre todos los usuarios. Y eso solo se logra cuando cada usuario conoce sus propios costos. Lo cual, a su vez, solo es posible con una asignación de costos adecuada: el mapeo de los costos de la nube a sus responsables.
YouTube
Toca para activar el sonido
Error 153
Error de configuración del reproductor de video
Visita YouTube para buscar más videos
Cuando los usuarios de la nube conocen sus costos, empiezan a prestarles más atención. Hacen mejores preguntas sobre por qué pagan lo que pagan. Y se sienten con la autonomía para actuar de forma proactiva, ya sea considerando el costo en el diseño de funcionalidades o atajando a tiempo costos que van subiendo poco a poco.
A continuación repasamos los tres pilares para construir una cultura consciente de los costos en tu empresa, de modo que se convierta en un ejercicio continuo entre tus usuarios de la nube.
Consejo #1 - Alinea tu jerarquía de recursos con tu estructura organizacional
Lo ideal es que tus recursos en la nube estén organizados de una manera que refleje la estructura real de tu organización, y las Folders de Google Cloud o las Organizational Units (OUs) de AWS son una excelente forma de lograrlo.
Sirven para separar y categorizar recursos entre los distintos departamentos o equipos de tu organización. Dentro de ellas tendrás proyectos (Google Cloud) o cuentas (AWS), donde cada uno de tus workloads pertenece a un único proyecto/cuenta.
YouTube
Toca para activar el sonido
Error 153
Error de configuración del reproductor de video
Visita YouTube para buscar más videos
Sin esta estructura, lo que te espera son problemas como dispersión de recursos, dificultades para atribuir costos y dolores de cabeza en la gestión de accesos.
La idea no es nueva en programación. La Ley de Conway plantea que la forma en que los equipos se comunican y se organizan influye en los productos o sistemas que crean. Lo mismo pasa en cloud computing: cuando estructuras tus recursos imitando la organización de tu empresa, la gestión y la colaboración fluyen mucho mejor.
Aísla tus workloads en sus propias cuentas/proyectos
Además, conviene aislar cada workload en su propia cuenta de AWS o proyecto de Google Cloud. Con frecuencia nos encontramos con clientes que tienen todos sus workloads en una sola cuenta o proyecto, o que comparten proyectos/cuentas entre varios equipos.
Cuando agrupas workloads que no tienen relación entre sí en una misma cuenta o proyecto, gestionar costos y rastrear el uso se vuelve un dolor de cabeza.
YouTube
Toca para activar el sonido
Error 153
Error de configuración del reproductor de video
Visita YouTube para buscar más videos
Por ejemplo, imagina que tienes recursos de dos aplicaciones distintas en el mismo proyecto de Google Cloud. Al no aislarlos en proyectos/cuentas separadas, terminas dependiendo en exceso de mantener una higiene de tagging perfecta (ya hablaremos de esto en el próximo consejo). Y a medida que tu organización crece, este enfoque solo le añade complejidad a la atribución de costos.
Cuando sea posible, opta por un único workload por cuenta/proyecto. Aun así, a veces, cuando tienes workloads pequeños y similares en alcance, puede tener sentido agruparlos en la misma cuenta (ver ilustración abajo).
De nuevo, la idea no es nueva si vienes del mundo de la programación. Aislar workloads en cuentas o proyectos separados se alinea con el principio de " loose coupling", que consiste en diseñar componentes o módulos independientes que interactúan entre sí con el mínimo de dependencias.
Al separar los workloads en cuentas o proyectos distintos, creas entornos independientes con dependencias mínimas entre sí. Los beneficios van más allá de una asignación de costos más sencilla: también obtienes ventajas de seguridad operativa integradas, como estructuras de permisos y rate-limiting, gracias a esa separación.
Consejo #2 - Etiqueta tus recursos con tags y/o labels
Los Tags (AWS, Azure) y los Labels (Google Cloud) sirven para aportar información detallada sobre tus recursos en la nube.
Algunos casos de uso son:
- Enriquecimiento de la facturación (por ejemplo, añadir información del centro de costos a un recurso)
- Clasificación de entornos/aplicaciones (por ejemplo, especificar niveles de seguridad de datos)
- Automatización (por ejemplo, definir horarios de reinicio)
Centrándonos en el primer caso, los tags y labels cumplen un papel clave en la asignación y el seguimiento de costos.
Los tags te ayudan a categorizar recursos por entornos, equipos y demás, y dejan claro cómo se reparte el uso entre esas categorías. Combinados con cuentas bien definidas, hacen mucho más fácil personalizar los reportes para equipos, aplicaciones y demás, gracias a los filtros más específicos que puedes aplicar.
YouTube
Toca para activar el sonido
Error 153
Error de configuración del reproductor de video
Visita YouTube para buscar más videos
Reglas prácticas para etiquetar recursos en la nube
Con el tagging puede ser tentador definir una estructura súper detallada con muchos tags distintos para aplicar a cada recurso. Si bien ese nivel de detalle es admirable, no es realista al empezar. Recomendamos partir de algo simple, con solo 2-3 tags, pero siendo muy estrictos en su aplicación.
Los tres tags absolutamente imprescindibles (en nuestra opinión) son:
- Nombre de la aplicación (ej. "app_name")
- Equipo (ej. "team")
- Etapa/entorno (ej. "env")
Como los tags distinguen entre mayúsculas y minúsculas, recomendamos adoptar un estándar de nomenclatura, como snake case, para evitar duplicados. Los nombres pueden adaptarse a la cultura de tu empresa, pero deben ser descriptivos y claros. En este caso, "app_name" se refiere al nombre de un microservicio o workload, y "env" a una etapa de desarrollo, como "development", "testing" o "production".
Lo ideal es que los valores de ambos campos provengan de una lista relativamente estandarizada. De nuevo, si tus usuarios etiquetan sus recursos con variantes de "Website - Backend", vas a tener problemas para analizar los datos.
Un ejemplo donde los tags te ayudan a entender mejor tu consumo en la nube es cuando hay una cuenta de "recursos compartidos" en la organización y allí están todos los recursos de base de datos (que usan varios equipos). A cada base de datos puedes asignarle un tag o label que determine a qué equipo se le imputa el uso de ese recurso.
Profundizamos más en este tema en nuestro post Resource Labeling Best Practices.
Consejo #3 - Configura reportes en tiempo real y alertas personalizadas
Está muy bien definir una jerarquía de recursos bien organizada y etiquetarlos, pero si no les entregas a tus usuarios de la nube reportes y alertas en tiempo real con esos datos segmentados, ¿de qué sirve?
El "Efecto Prius"
En "Cloud FinOps" de O'Reilly, los autores explican el "Efecto Prius", trazando un paralelo entre el impacto de los reportes en tiempo real sobre el comportamiento consciente de costos de los engineers y la experiencia de manejar un Prius.
Cuando manejas un Prius, recibes información en tiempo real sobre tu consumo de energía y el tiempo que tardará en agotarse la batería. Pisas el acelerador a fondo y ves cómo aumenta el consumo y se reduce el tiempo restante de batería. Esa información puede llevarte a manejar de forma más sensata. O puede que decidas que, como vas apurado, vale la pena gastar batería más rápido.
Independientemente de lo que hagas con esa información, lo importante es que ahora tomas una decisión más informada con datos que antes no tenías.
Los reportes en tiempo real empoderan la toma de decisiones descentralizada e informada
Los reportes de costos en la nube en tiempo real, igual que un Prius mostrando el impacto del consumo de gasolina sobre la batería, dan visibilidad inmediata y empoderan a los usuarios de la nube para tomar decisiones informadas, de forma autónoma, sobre las partes de la infraestructura de las que son responsables.
Y aunque el cambio hacia una mayor conciencia de costos no se da de un día para otro, los reportes en tiempo real influyen en el comportamiento hacia decisiones más eficientes en costos a futuro.
Esto debe materializarse en reportes de costo y uso, dashboard(s), presupuestos y otras alertas personalizadas que entreguen información relevante para el usuario de la nube que la consulta. Es decir, cualquier reporte que esté viendo un usuario debe estar filtrado (con alguna combinación de tus tags y las cuentas relevantes) para mostrar únicamente el consumo del que él o su equipo son responsables.
Cómo impulsar una cultura consciente de costos con DoiT
Las organizaciones digital native se apoyan en el portfolio de productos de DoiT, junto con su red global de expertise en la nube para FinOps y soporte de infraestructura, para tomar decisiones informadas sobre su uso de la nube.
Aquí tienes una guía paso a paso de cómo muchos clientes de DoiT impulsan una cultura de conciencia y responsabilidad sobre los costos en sus equipos de Engineering.
Mapea los costos de la nube a tus categorías de negocio
El primer paso para hacer asignación de costos es definir las agrupaciones de negocio a las que quieres asignarlos. En DoiT Cloud Intelligence™, esto se hace usando Attributions. Las Attributions te permiten agrupar recursos en la nube y organizar los costos según la forma en la que quieres asignarlos.
A continuación, dos ejemplos de uso de Attributions para mapear costos a distintas categorías de negocio.
En el primero, definimos los costos de una aplicación agrupando tres cuentas de AWS distintas.
Mapeo de costos en la nube para una aplicación hipotética
En el segundo, definimos los costos de un equipo de product engineering (en este caso, "Team Bruteforce") como cualquier recurso con un Label "team" o un valor de Project Label igual a "bruteforce".
Mapeo de costos en la nube para un equipo de engineering hipotético
Crea reportes y dashboards en tiempo real
Luego puedes usar Attributions en Reports — y eventualmente en Dashboards — para filtrar el consumo específico de un equipo, entorno, app o lo que termines definiendo con Attributions.
Por ejemplo, abajo usamos nuestra Attribution "Application A" como filtro, desglosando esos costos por servicio y mostrando solo los 10 principales en términos de costo.
Un reporte de costos en la nube que desglosa los costos de una aplicación definida con DoiT Attributions
Después puedes programar este reporte para que se actualice y se envíe de forma recurrente a los usuarios de la nube a quienes les resulta relevante. Es una manera sencilla de empezar a hacer que las personas tomen más conciencia de su impacto en los costos en la nube.
Programar un reporte de costos en la nube para entregarse de forma recurrente
Además, puedes empezar a crear un dashboard específico para un equipo o app, para que los usuarios de la nube relevantes obtengan una visión integral de sus costos. Abajo, agregamos nuestro reporte "Application A - Service Cost" a un nuevo dashboard que contendrá otros reportes relacionados con el consumo de esta aplicación.
Añadir un reporte de costos en la nube de una Aplicación a un dashboard que contiene otros reportes sobre esa Aplicación.
El dashboard de abajo es un ejemplo de lo que puedes crear para tu equipo, además de programar reportes específicos para los usuarios de la nube a quienes les son relevantes.
Dashboard con reportes personalizados de costos en la nube sobre una Aplicación específica
Alertas personalizadas y Anomaly Detection focalizada
Más allá de los reportes, las alertas oportunas que avisan a los usuarios cuándo deben revisar más de cerca un aspecto de su gasto en la nube también ayudan a mejorar la conciencia y la responsabilidad.
Configura alertas granulares de costos en la nube para los stakeholders
Por ejemplo, los clientes de DoiT configuran Alerts cuando quieren que sus stakeholders estén al tanto del uso a niveles más granulares.
Abajo configuramos una alerta de costo, acotada a nuestra Attribution "Application A". Tal como está configurada, recibiremos una alerta cada vez que el costo de servir a cualquier cliente — definido al seleccionar el tag "customer" en el desplegable Evaluate for each — aumente un 25% o más, semana contra semana. El desplegable Evaluate for each es muy útil cuando quieres evaluar cada instancia de la misma dimensión por separado (por ejemplo, cada uno de tus namespaces de K8s).
Una alerta que nos avisa cada vez que el costo de servir a cualquier cliente — definido al seleccionar el tag "customer" en el desplegable Evaluate for each — aumenta un 25% o más, semana contra semana
Configura Anomaly Detection focalizada
DoiT Anomaly Detection funciona monitoreando de forma autónoma los picos de costo y te avisa cuando se detecta un gasto anómalo, para que puedas minimizar su impacto en la factura. Por defecto, busca comportamientos anormales para cada SKU, en cada cuenta o proyecto que tengas.
Ejemplo de anomalía detectada para el SKU DataTransfer-Out-Bytes de AWS S3
Los sistemas de detección de anomalías suelen entregar información sobre el uso de la nube de toda la organización. El problema es que este enfoque tan amplio termina bombardeando a los equipos con notificaciones que no son directamente relevantes para sus operaciones.
Pero con DoiT Anomaly Detection puedes suscribir a tus usuarios de la nube a alertas de anomalías específicas a los costos de los que son responsables, usando Attributions. Esto lleva las alertas de anomalías un paso más allá: tus equipos pueden afinar las alertas que reciben y enfocarse solo en los costos de la nube que les corresponden.
Una vez creada una Attribution, basta con activar Anomaly Detection para ella.
Activar Anomaly Detection para los recursos en la nube de una Aplicación específica
Después puedes entrar en la configuración de notificaciones de las personas responsables de Application A y suscribirlas a las alertas relacionadas con esa Attribution (o pueden hacerlo ellas mismas).
Cómo suscribirse a las alertas de anomalías de una Attribution específica
Instalar una cultura consciente de costos en tu empresa no es tan simple como pedirles a tus usuarios de la nube que se preocupen más por los costos. Hay que darles los datos que les permitan dimensionar el costo de su trabajo.
Y para entregar los datos más precisos sobre el impacto de cada persona o equipo en la factura de la nube, necesitas alinear tu jerarquía de recursos con tu estructura organizacional, definir los tags adecuados y aplicarlos de forma consistente. Pero el verdadero poder está en combinar estos pasos fundamentales con mecanismos de reportes y alertas en tiempo real.
Puedes lograr ambas cosas con DoiT, primero trabajando con nuestros expertos en FinOps para definir los tags que deberías crear — si aún no los has creado — y una jerarquía de recursos que tenga sentido según cómo está estructurada tu empresa.
Una vez establecido eso, puedes apoyarte en los productos de DoiT para entregar reportes y alertas relevantes en tiempo real a tus usuarios de la nube.
Si ya eres cliente de DoiT, puedes seguir lo que describimos arriba, paso a paso, en DoiT Cloud Intelligence ahora mismo. Si no, ponte en contacto con nosotros para descubrir cómo aprovechar los productos y servicios de consultoría de DoiT en cualquier etapa de tu camino a la nube.