Cuando diseñas un servicio sin servidor, cada pieza del rompecabezas, cada servicio administrado que seleccionas, es una opción de compra. Además, convertirse en un servicio en la nube de nivel de producción conlleva costos adicionales y los gastos pueden aumentar rápidamente si no prestas atención.
En este blog, aprenderá cómo una organización frugal prospera con una mentalidad FinOps, que es crucial para optimizar los costos y maximizar la eficiencia en los servicios en la nube. Compartiré estrategias y acciones para alinear los objetivos financieros y operativos en la nube.
Mientras analizo los servicios sin servidor como ejemplos, describo los conocimientos, la automatización y la cultura que benefician a cualquier servicio y tecnología en la nube que pueda elegir.
Estos conocimientos surgen de mi experiencia en el diseño de servicios sin servidor en CyberArk , un proveedor de SaaS basado en AWS.
Tabla de contenido
El concepto erróneo sobre el costo de los sistemas sin servidor
Como héroe sin servidor de AWS , me siento obligado a abordar el tema central cuando se habla de los costos de la nube y los servicios sin servidor.
Serverless ha sido el ejemplo perfecto de pagar solo por lo que se usa y escalar a cero.
Si ese es el caso, seguramente el costo de su servicio sin servidor de nivel de producción es menor que el de los servicios que no son sin servidor, ¿verdad?
Bueno, eso solo es cierto a veces. Claro, es una afirmación verdadera para los servicios sin servidor "reales", como Lambda, SNS, SQS y DynamoDB, pero el concepto sin servidor incluye muchos más servicios y cada año aparecen nuevas variantes de servicios de AWS sin servidor.
Por ejemplo, puede darse cuenta de que DynamoDB ya no se adapta a sus requisitos. Puede utilizar Amazon Aurora sin servidor, agregar caché a la combinación con Elasticache sin servidor u optimizar las búsquedas de palabras clave con OpenSearch sin servidor. Si bien estos servicios tienen una variante sin servidor, no se escalan a cero; siempre paga un precio mínimo incluso si no hay tráfico de clientes. Por lo tanto, tal vez sea mejor llamarlos servicios administrados por AWS, pero no verdaderos sin servidor. Además, estos servicios requieren una VPC, que agrega un costo predeterminado por mes de ENI, puntos finales de VPC, etc.
Como nota al margen, Jeremy Daly analizó la naturaleza sin servidor o no tan sin servidor de los servicios más nuevos de AWS en el excelente podcast de Allen Helton , que recomiendo encarecidamente.
El grado de producción implica un costo adicional
Independientemente de la tecnología que elija para sus servicios en la nube, en algún momento debe prepararse para la producción. Deben abordarse las normativas, la seguridad y los requisitos de observabilidad, que añaden costes adicionales que suelen pasarse por alto.
Agreguemos algunas de estas capacidades a nuestro servicio de preproducción.
Necesitamos agregar capacidades de cifrado de datos de clientes al servicio. Podemos usar una CMK de KMS para cifrar los datos de los clientes o facilitar la comunicación entre servicios. Una CMK cuesta 1 dólar por mes solo por su suministro, sin incluir las llamadas a la API, y 1 dólar adicional cuando se habilita la rotación automática de claves. ¿Espera tener 10 000 clientes? Genial, son 20 000 dólares adicionales por mes que se suman a su factura de AWS.
En cuanto a las prácticas de preparación para la producción, agreguemos seguridad web y observabilidad .
Podemos habilitar un firewall de aplicaciones web en la API Gateway o la distribución de CloudFront y mejorar la capacidad de observación con los paneles de CloudWatch . Estos recursos tienen un precio mensual constante solo por su aprovisionamiento, incluso si su servicio recibe cero tráfico mensual. Hay muchos ejemplos como ese.
Al convertir su servicio en un servicio listo para producción, se suman numerosos costos pequeños y las personas deben estar al tanto. Claro, es solo otra CMK; es solo una línea para crear en AWS CDK; ¿qué daño puede causar?
Si utiliza varias cuentas (como debería) (desarrollo, pruebas, producción), entonces cada costo adicional puede multiplicarse potencialmente por la cantidad de cuentas que posee. ¿Implementa en 5 regiones por cuenta? Eso son 15 CMKS adicionales (5*3 - cantidad de cuentas); multiplique nuevamente.
Estos costos se acumulan significativamente, especialmente en las cuentas de desarrollo donde los recursos se implementan, se eliminan y, a menudo, se olvidan porque se crearon manualmente a través de la consola. Pero AWS los recuerda y recibirá el cheque a fin de mes.
Los clientes están llegando
Por último, y espero que sea obvio para la mayoría de ustedes, cuantos más clientes obtenga, mayor será la escala, las llamadas a la API y la cantidad de datos que almacene, lo que se traduce en facturas más altas de la nube de AWS. Su empresa sobrevivirá solo si planifica estos costos adicionales y los incorpora a su modelo de ingresos.
La conclusión es que los servidores sin servidor de nivel de producción o los que no lo son tienen costos constantes adicionales que pueden escalar rápidamente; pagará por muchos bits y bytes y debe tener esto en cuenta desde el principio. Debe establecer su presupuesto para la escala de tráfico de clientes esperada y monitorearlo para que no se salga de control.
Ahora que entendemos el problema, analicemos cómo su organización puede abordar este asunto, reducir costos y mejorar la eficiencia adoptando una mentalidad FinOps.
Mentalidad FinOps
FinOps es un marco operativo y una práctica cultural que maximiza el valor comercial de la nube, permite la toma de decisiones oportuna basada en datos y crea responsabilidad financiera a través de la colaboración entre los equipos de ingeniería, finanzas y negocios. - FinOps Foundation
Adoptar FinOps y tomar conciencia de los costos es fundamental para cualquier miembro del personal de alto nivel de una organización. Sin embargo, como se mencionó anteriormente, cada elección de diseño, cada implementación de la pila CloudFormation y cada ejecución programada de trabajo de TI/DevOps es una elección de compra.
Sus equipos gastan dinero todos los días en sus cuentas de AWS.
Si desea cambiar la mentalidad de su organización para que sea más consciente de los costos, debe comenzar desde abajo. Los arquitectos y los líderes de equipo pueden liderar el camino, pero las tropas que están por debajo deben seguirlos y comprender el objetivo. Claro, puede agregar automatización que impida que los desarrolladores implementen todo tipo de recursos, pero a largo plazo, eso obstaculizará la independencia de los equipos de desarrollo y no escalará. Las personas deben adoptar la mentalidad de FinOps, comprenderla y pensar en el costo de la nube en todas las etapas del desarrollo.
En las siguientes secciones, describiré acciones concretas que puede implementar en su organización. Las personas pueden diferir entre arquitectos, DevOps, TI y desarrolladores, pero la idea es la misma: se necesita un pueblo para reducir el costo de AWS y todos deben participar.
Diseño teniendo en cuenta el costo
Como arquitectos de la nube, somos una de las pocas personas de la organización que más influyen en el costo total de AWS.
En el último evento re:invent de AWS, Vogels analizó las pautas de "The Frugal Architect" , que se correlacionan con mi publicación de blog, " Plantilla de diseño de alto nivel del arquitecto de la nube ".
Las principales conclusiones que saqué de su sesión son que cada elección de diseño de arquitectura de nube es una elección de compra.
Como arquitectos, influimos tanto en los diseños de alto nivel de nuestros servicios como en los diseños de bajo nivel. En mi empresa, los diseños de bajo nivel y las pruebas de concepto las realizan los desarrolladores con mi acompañamiento. Por ello, es fundamental tener en cuenta el coste en esta fase inicial.
Al diseñar servicios sin servidor, a menudo hay varias arquitecturas posibles; por ejemplo, se puede utilizar SNS o EventBridge para emitir eventos a los suscriptores.
Para tomar una decisión informada, recomiendo utilizar una matriz de decisión para comparar ambas soluciones y agregar el costo esperado como un requisito no funcional.
Describo ese proceso en detalle en esta publicación de blog: Plantilla de diseño de alto nivel de Cloud Architect.
Debe planificar con anticipación: piense en la cantidad esperada de clientes y la escala esperada e ingrese estos números en la calculadora de precios de AWS . No se sorprenda cuando el costo de AWS se dispare un año después y su costosa solución se implemente en producción. En esa etapa, será mucho más difícil reemplazarla.
Sin embargo, no termina ahí. Como arquitecto, no puedes supervisar todo y los desarrolladores toman decisiones de precios al implementar funciones. Por ejemplo, agregan métricas personalizadas de CloudWatch para paneles internos, pero usan demasiadas dimensiones, lo que aumenta drásticamente el costo (¡sucedió!). Es fundamental capacitar a los equipos para que tomen estas decisiones de manera independiente y de manera integral en cuanto a los costos. Deben comprender que casi todos los recursos que implementan o API a las que llaman generan costos adicionales en la nube.
Cultura de FinOps
Repasemos las prácticas culturales que permiten a los equipos de toda la organización comprender el costo de la nube y reducirlo y optimizarlo activamente.
Campeón de FinOps
La primera práctica es elegir un líder de FinOps en cada equipo (desarrolladores, TI, DevOps, etc.) que esté a cargo, además del arquitecto y el líder del equipo, de asegurarse de que las rutinarias PR de GitHub no provoquen un aumento inesperado de los costos. Ellos plantearán las preocupaciones sobre los costos durante las revisiones de diseño y ayudarán al equipo a tenerlos en cuenta.
Lo ideal es que los defensores de FinOps siempre consideren el costo de la nube, ya sea en la etapa de diseño, implementación o despliegue de producción.
Este campeón puede participar activamente en la sección 'monitorea tu factura' que describiré a continuación.
Gremio FinOps
La segunda práctica es el intercambio de conocimientos entre unidades y organizaciones. Supongamos que uno de los equipos de los campeones de FinOps descubrió una nueva práctica recomendada para reducir el costo de la concurrencia aprovisionada en Lambda . Es genial que un equipo haya resuelto ese problema, pero sería mucho mejor si se implementara la misma práctica recomendada en toda la organización, lo que generaría un mayor impacto en el ahorro de costos. Para que eso suceda, se necesita un mecanismo para compartir conocimientos.
Uno de esos mecanismos puede ser iniciar un gremio de FinOps donde todos los campeones de FinOps compartirán sus conocimientos una vez al mes.
Conocer personas fuera de tu organización interna y crear nuevas relaciones con personas de TI, DevOps, productos y más también son valores agregados.
Como nota al margen, si desea obtener más información sobre la concurrencia aprovisionada y los inicios en frío, consulte mi publicación aquí .
Cursos internos de FinOps
Las reuniones de gremio son una excelente manera de compartir información. Sin embargo, como están limitadas a una audiencia más pequeña y las mejores prácticas de reuniones anteriores pueden quedar en el olvido, es mejor documentarlas. Puedes comenzar con un documento interno simple o llevarlo un paso más allá y crear un curso de video interno. El curso no necesita ser un video editado profesionalmente; incluso puede ser una grabación de una reunión de Teams o Slack. El contenido debe servir como una forma rápida de incorporar nuevos campeones de FinOps y difundir prácticas de reducción de costos.
Hackatones de FinOps
Esta es una idea divertida. Gamifique FinOps y presente un hackathon donde los empleados puedan aportar ideas para mejoras, automatización y otros métodos de reducción de costos. Para darle un toque más interesante, ofrezca premios a las ideas más impactantes.
Celebrar el éxito
Esta acción podría ser la más importante de todas, ya que las ceremonias son parte integral de cada cultura. Todos agradecen los comentarios sobre un trabajo bien hecho, especialmente cuando ese trabajo mejora las ganancias de la empresa. Reconocer el éxito en toda la organización creará un efecto positivo y motivará a otros equipos a adoptar prácticas de FinOps y ser los próximos en celebrar la reducción de costos.
Monitorea tu factura
A la hora de gestionar las finanzas de la nube, es fundamental seguir un plan presupuestario para asegurarse de gastar el dinero de forma inteligente. Utilice herramientas como AWS Cost Explorer o servicios de terceros como Anodot para obtener información sobre sus patrones de gasto, centrándose en los costes asociados a cada equipo o servicio.
Configurar alarmas para gastos excesivos de presupuesto y monitorear regularmente sus gastos mensuales le permitirá comprender las implicaciones de costos de cada servicio de AWS y de cada equipo de la organización.
Puede identificar el costo para el equipo agregando etiquetas a cada recurso (el nombre del equipo, el nombre del microservicio o cualquier otra etiqueta que lo ayude a comprender el costo en los casos en que varios equipos comparten la misma cuenta de AWS). Luego, filtre en el explorador de costos de AWS por.
Además, si usted es un proveedor de SaaS (software como servicio), es esencial estimar (o "aproximadamente" en muchos casos) el costo de cada cliente para la elaboración de presupuestos, licencias y rentabilidad. Esta no es una tarea sencilla y sus desafíos difieren drásticamente si está utilizando una estrategia de aislamiento de inquilinos con un modelo de grupo o de silo . Sin embargo, este tema es demasiado amplio para cubrirlo en el alcance de esta publicación.
Para las organizaciones que administran múltiples cuentas o utilizan distintos proveedores de nube, una herramienta como Anodot puede ofrecer ventajas significativas, ya que proporciona un enfoque centralizado para la gestión de costos.
Por último, asegúrese de que sus defensores de FinOps y otras partes interesadas puedan acceder a estas herramientas, ver paneles y definir alertas.
Automatizar la protección de costos
Puede reducir los costos de la nube automatizando la eliminación de recursos y agregando políticas o mecanismos organizacionales que eviten la creación de algunos recursos en primer lugar.
Algunas ideas que me vienen a la mente incluyen:
Automatice la eliminación de recursos, como CMK de KMS no utilizados.
Automatizar la eliminación de las pilas de CloudFormation que no se pudieron eliminar y quedaron con recursos "zombi". Por ejemplo, una pila no pudo eliminar un depósito de S3 porque no estaba vacío.
Utilice una política que impida que los desarrolladores implementen en regiones no aprobadas. Los precios de los servicios de AWS varían según la región. Seleccione las regiones que tengan los servicios que necesita a un costo que esté dispuesto a pagar y que proporcionen una latencia lo suficientemente buena para sus clientes.
No permita la creación de recursos a través de la consola en cuentas que no sean de desarrollo; permita únicamente la creación a través del enfoque de infraestructura como código (IAC). Reduzca las posibilidades de crear recursos huérfanos olvidados.
Encuentre recursos "desviados" o huérfanos que no pertenecen a ninguna pila y nadie los usa, y elimínelos.
Configure alarmas para alertarlo sobre posibles picos de costos, lo que permite una gestión proactiva. Herramientas como la detección de anomalías de costos de AWS pueden ayudar a identificar patrones de gastos inusuales en una etapa temprana.
Escriba un trabajo programado que apague las instancias EC2 por la noche o automáticamente.
Y muchos más, dependiendo de sus casos de uso.
La lección más importante que se puede sacar de esto es adoptar un enfoque proactivo. No se sorprenda: haga un esfuerzo para reducir los costos de manera activa.
Aprendizaje continuo
El aprendizaje continuo a través de artículos, reuniones de AWS y otros recursos educativos es fundamental. Nunca se sabe cuándo se encontrará un nuevo mecanismo o característica que reduzca los costos. Mantenerse actualizado con las innovaciones y los anuncios de servicios también es esencial.
Se trata de cambiar y refactorizar.
A veces, cambiar los servicios, como optar por HTTP en lugar de REST API Gateway, aprovechar herramientas como Lambda Powertuning para optimizar funciones o reducir la retención de registros de CloudWatch y cambiar el nivel de registro, puede generar ahorros significativos.
Si bien los consejos pueden parecer exhaustivos, son solo la punta del iceberg. Cada servicio de AWS ofrece oportunidades de optimización únicas, ilustradas por las estrategias detalladas para DynamoDB disponibles en Desafíos y mejores prácticas de precios de DynamoDB de FinOut .
Haz tu tarea, investiga, aprende y optimiza. A largo plazo, valdrá la pena.
Resumen
En esta publicación, analizamos las prácticas que todas las organizaciones deberían adoptar para avanzar en una mentalidad de FinOps. Analizamos cómo se requieren los esfuerzos de toda la organización para mantener los costos de la nube de manera proactiva y esforzarse siempre por optimizarlos y reducirlos.
Espero que esta publicación ayude a su organización en su camino hacia FinOps y alcanzar el nirvana de los costos en la nube. ¡Buena suerte!
留言