Gestión de presupuesto en la Nube
Puedo decir en base a experiencia que la gestión de presupuesto es un trabajo complejo. Partiendo desde la vida privada donde uno administra los ingresos que permiten tener una vida tranquila; hasta la gestión financiera de grandes programas transformacionales. Todo este periplo nace con la conformación de una estructura de costos.
La creación de un presupuesto consta de una la larga lista de tareas: levantamiento de las líneas de gasto, cálculo de los costos para cada una. Alineamiento a los objetivos financieros de la organización. Obtención de aprobación en comités estratégicos. Administración y control del gasto. Forecasting. Reportería.
Jamás debe sub estimarse el trabajo financiero. La proyectos son aprobados dado que reportarán beneficios económicos para la organización. Un proyecto en rojo se puede transformar rápidamente en un costo hundido y un dolor de cabeza (y de bolsillo).
También se debe tener en consideración que un presupuesto puede diferir bastante entre iniciativas. Un profesional con experiencia en proyectos de corto plazo podría subestimar el esfuerzo para un programa. Por otro lado profesionales acostumbrados a grandes proyectos transformacionales, pueden perder clientes rápidamente si sobre dimensionan esfuerzo y costo en pequeñas y medianas empresas.
Mi objetivo principal para este artículo es compartir mi experiencia presupuestando y controlando costos en la Nube Pública. No obstante quisiera tomar un breve tiempo para referirme a la capa superior que es presupuestando el proyecto. Manos a la obra.
Mi presupuesto para proyectos informáticos
Calculando mi Presupuesto
Un presupuesto está conformado por varios ítems financieros. El cálculo monetario para cada ítem llega luego de preguntas, análisis, definiciones, acuerdos, directrices y supuestos. Y mucho trabajo en equipo. Mi primera recomendación es que tengas a mano el detalle del cálculo, tus supuestos, áreas con las que trabajaste. Fórmulas utilizadas. ¡Jamás, pero jamás presentes números en duro en una planilla!
Aún cunado existen reglas financieras «universales«, los nombres y definiciones de los ítems financieros podrían variar entre organizaciones. Mi segunda recomendación es que antes de iniciar te informes correctamente de las políticas de tu organización. Siempre es bueno tener una charla con áreas como Finanzas, Procurement, Legales, Control de Gestión, para estar al día en información financiera, tributaria y legal. Este conocimiento es fundamental para reducir el riesgo de presentar un presupuesto que esté fuera de norma.
También es importante adecuarse a la cultura de tu organización. Mi tercera recomendación es que luego de los canales formales, te tomes un café con alguien que haya confeccionado presupuestos en tu organización. Consulta sobre casos prácticos, como presentarlos, cómo defenderlos, qué consideraciones culturales debes tener en cuenta. Qué errores no cometer.
Preguntas clásicas que deben ser respondidas:
- La moneda para el presupuesto.
- Formato de presentación.
- Período de tiempo para creación del TCO.
- Qué tasa de reemplazo aplicar.
- Qué impuestos y/o intereses se deben considerar.
- ¿Es un presupuesto corporativo?
- Si es así, ¿Cuál es el driver de distribución entre unidades organizativas?
- ¿Existe alguna política para estimar buffer?
Jamás te guardes ninguna pregunta.
Principales ítems en un presupuesto
Costos de Inversión. En general son los costos a incurrir en la adquisición de activos necesarios para iniciar y desarrollar tu proyecto. En muchas ocasiones incluyen costos de capital aunque siempre habrá excepciones. Considera aquí proveedores externos, tu equipo en caso pueda ser activado, algunos viajes y viáticos. Y en raras ocasiones software e infraestructura.
Ahorros. Es el ahorro a la organización proveniente de la ejecución y puesta en marcha exitosa de tu proyecto. Puede ser reducción de costes operativos, mejora en costes de infraestructura, aumento de tasa de conversión.
Costos Infraestructura. Son los costos requeridos para la puesta a producción de tu servicio. Aquí debes considerar qué será re utilizado; qué debe ser mejorado; y qué será nuevo.
Costos Operacionales. Son los costos que incurrirás para mantener tu servicio luego de la puesta a producción. Considera aquí el costo de infraestructura, licencias de software, equipo de continuidad operacional (DevOps, SecOps, NetOps). Mi experiencia ha sido calcular este costo de manera mensual. Luego extrapolo a la cantidad de años de nuestro TCO (normalmente 4), tomando debida nota de los re ajustes anuales. Gran parte de las partidas presupuestarias son para mantener el negocio, por lo que el cálculo debe ser lo más detallado posible.
Impuestos. Son los costos asociados a cualquier tipo carga impositiva, en base a las políticas de tu organización y de tu país. He sido testigo como en ocasiones se ignora este ítem, lo que además de tener impacto sobre tu presupuesto podría acarrear problemas legales. Un ejemplo clásico es el pago de proveedores extranjeros cuando no tienen cuenta en tu país. Siempre consulta con tus áreas Financieras, Tributarias y Legales al respecto.
Presupuestando costos de infraestructura
Presupuestando costos para la Nube
Luego de una resumida introducción a los presupuestos en general, he de retomar la idea central de esta entrada: Presupuesto para la Nube.
Me enfocaré principalmente en el concepto de Nube Pública. Ciertas particulares deberán ser consideradas para otras infraestructuras como On Premises, Nubes Privadas, Edge, etc. Pero creo que los puntos que tocaré servirán de una fuerte base transversal a este tipo de proyectos. ¡A redactar!
Sizing
Todo tipo de estimación de infraestructura tiene al sizing como uno su pilar fundamental.
Debemos ser capaces de calcular y/o estimar la capacidad requerida para la puesta a producción. Qué potencia de cómputo vamos a necesitar, cuánta memoria, cuánto espacio para almacenamiento de archivos. Qué servicios propios de la nube requeriremos (message brokers, data transformations, networking, IA and machine learning, file storage, data storage, monitoring and control, etc). Cuál o cuáles serán mis bases de datos, cuánto planeo almacenar, y cuánto estimo será el crecimiento. Qué tipo de seguridad será aplicada y cómo.
También debemos extrapolar estos datos para lograr estimar crecimiento y por ende escalamiento. Una pregunta clásica es cuántos requests espero manejar, tanto en normalidad como en peaks. Esto no sólo determinará el escalamiento, también ayudará para seleccionar la tecnología de desarrollo.
El trabajo de sizing debe seguir una metodología. Mi consejo es primero conocer la arquitectura propuesta para el proyecto. Luego definir qué sistemas serán utilizados tal y como están, cuáles deberán modificarse, y cuáles serán nuevos. En tercer lugar definir cuántos ambientes necesitarás por cada escenario. Como cuarto paso estimar el sizing y escalamiento por cada ambiente de cada escenario.
De esta lista, calcula los costos de adquisición, implementación y/o integración, y continuidad.
Y recuerda, antes de formalizar el presupuesto, reúnete con todas las personas que participaron en él, y refínalo al máximo.
Licencias de software
Ya conoces el costo de los «fierros«. Ahora necesitamos conocer el costo del software que será ejecutado sobre ellos.
Aún cuando estrictamente hablando no es «infraestructura«, es indispensable conocer costos asociados al uso de los servicios en la nube. Uno sin el otro no operan (estoy dejando fuera el concepto puro de serverless, quizás para otro tema futuro).
Luego de haber calculado los costos del sizing, habrás notado que algunos ítems son cubiertos por los servicios que te presta la nube, y que pueden ser listados dentro de «infraestructura cloud«. Por ejemplo hablemos de autenticación CIAM vía API. ¿Es un software en el concepto puro de la palabra? ¿O al configurar el sizing lo transformo en parte de la «nube«?
Mi sugerencia es que este tipo de costos los listes como parte de la «infraestructura cloud«, y simplifiques al máximo el proceso de facturación sin perder el detalle. A medida que más proyectos empiecen a compartir clusters en una misma suscripción, me lo agradecerás.
¿Entonces qué podríamos considerar como licencias de software? Yo categorizo en dos grandes conceptos: Third Parties y Project Accounts.
Third Parties serán todos los servicios que no están en la nube, pero que requerirás utilizar. Puede ser un nuevo servicio que requerirá negociación del costo y un contrato; o el escalamiento de un servicio existente. Para este punto ten en consideración cuál es el costo de suscripción, el costo mensual, cuánto tiempo demorará el contrato, cuántos proveedores deberás evaluar, driver de distribución cuando el servicio es compartido.
Project Accounts serán todas las cuentas de diversos softwares que requerirás para la gestión de tu proyecto y que por supuesto tienen costo por usuario. Diferencia el costo temporal (cuentas del proveedor), del costo operacional (cuentas para DevOps, SecOps, NetOps, BU). Ejemplos que me ha tocado presupuestar son cuentas en Jira, Slack, Trello, Gitlab, Confluence.
Presupuesto para el escalamiento de las aplicaciones
Escalamiento de Aplicaciones
En términos generales hemos cubierto hardware y software requerido para tu proyecto.
No he querido entrar en detalle de servicios de terceros podrías llegar a estimar; con la oferta que existe hoy en día esta entrada sería infinita. Mi objetivo es cubrir puntos que son relevantes y he visto no pocas veces cómo se ignoran con graves consecuencias.
El último tema de hoy es escalamiento de tus aplicaciones.
Un servicio de baja demanda en un ambiente controlado podrá tener un costo bajo. Pero qué pasa cuando construyo un complejo ecosistema de micro servicios, en decenas de clusters que a su vez son base para decenas de pods. Supongamos pensamos que tendremos poca demanda y para efectuar pruebas representativas, configuro todos ambientes de igual manera.
Lo que sucederá es que llegará una cuenta de decenas de miles de dólares. Porque no tomamos en cuenta cómo escala nuestra solución. Y por ende subestimamos el impacto no solo en nuestro ambiente productivo; sino también en Desarrollo, Staging, PreProd, etc.
Es importantísimo entender con todo el equipo cómo esperamos que escale nuestra solución, para estimar el costo que declararemos en el presupuesto, y formulemos un plan para la infraestructura.
En base a este plan, definir cuántos clusters y cuantos pods deberemos configurar. Qué contenedores deberán ir en qué pods. Cuantos logs y con qué detalle querremos almacenar. Sizing distintos para nuestros diferentes ambientes. Configura un tope en el crecimiento de tus componentes. Monitorea el tiempo que toma cada micro servicio y optimiza código. Menor tiempo es menor costo.
Si requieres un ambiente preprod, solo utilízalo para pruebas UAT y luego del release, deshabilítalo.
Define límites para el costo y configura alertas cuando los límites se superen. Sobre todo si es un sistema nuevo, debes poner una atención especial al menos seis meses luego del Go Live.
Enlaces
A continuación les dejo algunos enlaces que he encontrado interesantes:
- How to become a Cloud cost-control guru on GCP
- The hidden costs of cloud
- Create, edit, or delete budgets and budget alerts
Conclusiones al presupuesto
He querido cubrir en este tema, los puntos que considero más importantes a la hora de costear infraestructura en la nube.
Es muy probable que luego de publicado, leeré nuevamente y quedaré disconforme con algunos puntos; y con la sensación de haber pasado por alto otros igual de importantes. Es normal en mi, no obstante para este artículo en particular no haré ninguna corrección futura.
Me interesa poder conocer experiencias, ideas y puntos de vista de otros profesionales. De aquellos que estarán de acuerdo; y de aquellos que tienen un punto de vista totalmente distinto. Para eso prefiero conversar y debatir en los comentarios, dejar historia de mi artículo original, y todas las mejoras posibles.
Me encantaría contactar otras personas de mi país y de otras latitudes, y conversar largo al respecto. And if you want to do it in English, no prob! Since spanish is my native language, I prefer to redact using it. That being said, I will absolutely thrilled to know that I have readers from other countries.
Best!