Be Wise Apps
Read in English · Lire en français · Auf Deutsch lesen
Sección 10.8 de 10.8 · Intermedio · 22 min de lectura
FinOps, arquitectura de costos y dependencia del proveedor (lock-in)
Videolección
5 min · narrado en inglés, con subtítulosSolo escuchar (audio)
Leer la transcripción
En la nube, cada decisión arquitectónica es también una decisión de compra. En esta última lección del capítulo aprenderás a tratar el costo como una cualidad, y a ponerle precio al lock-in en lugar de temerlo.
Alquilar un vehículo por un día es barato. Alquilar uno todos los días durante tres años es mucho más caro que comprarlo. Dejar el motor en marcha en el estacionamiento gasta combustible para nada. Y si contratas en leasing uno con un conector de carga especial, cambiar de marca implica cargadores nuevos. FinOps es el hábito del presupuesto doméstico aplicado a la nube. El lock-in es el conector especial: cierta dependencia merece la pena, si la elegiste a propósito y sabes cómo saldrías.
FinOps, definido por la FinOps Foundation, reparte la responsabilidad financiera entre ingeniería, finanzas y negocio. En su centro está la propiedad compartida, no un equipo central que vigila el gasto. Informar hace visibles los costos: asígnalos a los equipos que los generan, muéstraselos a sus dueños y haz previsiones. Optimizar reduce el despilfarro y mejora las tarifas, mediante el ajuste de tamaño, la programación de horarios, los compromisos de uso y el rediseño de las rutas costosas. Operar crea los hábitos que mantienen los costos bajo control: políticas, presupuestos, responsables y el costo en cada decisión de diseño. Después el ciclo se repite, madurando de gatear a caminar y a correr.
Una factura de la nube que sube de ochenta mil a cien mil al mes puede ser un desastre o un triunfo, según si el negocio creció un cinco por ciento o un cincuenta. La economía unitaria expresa el costo por unidad de valor de negocio: para la plataforma de reparto de comida, el costo por pedido. Separa la eficiencia del crecimiento y da a los equipos un objetivo sobre el que pueden influir. La mayoría de las facturas que sorprenden proceden de unos pocos factores: la transferencia de datos, los recursos ociosos y sobredimensionados, el volumen de logging, los sobreprecios de los servicios gestionados y el almacenamiento que nunca se borra. Casi todos dependen de la arquitectura.
Este es un día de cómputo. El mínimo siempre encendido se cubre con un descuento por compromiso de uso a uno o tres años. Comprométete solo con la base que seguro vas a necesitar; comprometerse con el pico convierte un descuento en despilfarro. La capacidad spot es capacidad sobrante con grandes descuentos, a menudo del sesenta al noventa por ciento, pero el proveedor puede recuperarla con poca antelación. Conviene para el trabajo interrumpible y reintentable, como los trabajos por lotes nocturnos, nunca para las bases de datos. Los picos del almuerzo y de la cena se cubren con capacidad bajo demanda que se autoescala. Y ajusta el tamaño antes de comprometerte.
Apliquémoslo. La plataforma gestiona uno punto dos millones de pedidos al mes, con una factura de noventa y seis mil libras. Eso son ocho peniques por pedido. Primero, las solicitudes de recursos de cómputo duplicaban aproximadamente el uso medido. Fijarlas a partir de mediciones redujo los nodos en una cuarta parte, y solo entonces se comprometió la parte estable durante un año. El cómputo bajó de cuarenta y dos mil libras a veinticinco mil ochocientas treinta. Segundo, la mitad del volumen de logs era salida de depuración. Desactivarla, muestrear las solicitudes exitosas y conservar los logs en caliente catorce días en lugar de noventa redujo la observabilidad de catorce mil libras a seis mil quinientas. Tercero, los servicios de pedidos y de precios intercambiaban unas cuarenta llamadas por pedido entre zonas. Trasladar los precios de la ruta crítica al servicio de pedidos y servir las imágenes de los restaurantes desde una CDN ahorró cinco mil libras netas. La factura bajó a sesenta y siete mil trescientas treinta libras, unos cinco punto seis peniques por pedido: un treinta por ciento menos, con las mismas funcionalidades y los mismos objetivos de fiabilidad.
Ahora, el lock-in: el costo de abandonar algo una vez que dependes de ello. Gregor Hohpe sostiene que evitar el lock-in a toda costa es en sí mismo una trampa. Ponle precio: el costo de cambio multiplicado por la probabilidad de cambiar. Un cambio que costaría cincuenta mil, con un cinco por ciento de probabilidades de producirse, tiene un costo esperado de dos mil quinientos. Gastar mucho más que eso para evitarlo es un mal negocio. Su matriz enfrenta la utilidad única con el costo de cambio. Los servicios genéricos que son baratos de sustituir son desechables: úsalos sin reparos. Cuando un servicio aporta un valor único que vale su costo de cambio, acepta el lock-in, de forma deliberada. Ten cuidado cuando marcharse es caro pero el beneficio único es pequeño. Y lo ideal, único y fácil de dejar, es raro.
La portabilidad no es gratuita: significa usar solo las funcionalidades que comparten todas las nubes y construir capas de abstracción que tienen fugas. Muchas estrategias multinube acaban con los costos de todos sus proveedores y las ventajas de ninguno. Una posición intermedia sensata: acepta el lock-in donde aporte un valor claro, mantén la lógica de negocio detrás de puertos y adaptadores en los pocos puntos de unión con más probabilidades de cambiar, y guarda los datos en formatos que puedas exportar. Y deja por escrito una estrategia de salida, y ensáyala al menos en parte. En la UE, el Reglamento de Resiliencia Operativa Digital ya exige a las empresas financieras tener una para los servicios críticos.
Con esto termina el Capítulo 10. Cuando estés listo, haz la prueba opcional del capítulo: veinte preguntas de opción múltiple y dos respuestas escritas, con una nota de aprobado del ochenta por ciento. Después, continúa con el Capítulo 11, sobre evaluación, toma de decisiones y gobernanza. Nos vemos allí.
Lo que necesitas saber
- En la nube cada decisión arquitectónica es también una decisión de compra, por lo que el costo es un atributo de calidad que cambia con cada despliegue y se expresa mejor por unidad de valor de negocio, como el costo por pedido.
- FinOps, definido por la FinOps Foundation (un proyecto de la Linux Foundation), reparte la responsabilidad financiera entre ingeniería, finanzas y negocio mediante tres fases iterativas: informar, optimizar y operar.
- Los factores de costo habituales son la salida de datos (egress) y la transferencia entre zonas, los recursos ociosos y sobredimensionados, el volumen de logging, los sobreprecios de los servicios gestionados y el crecimiento descontrolado del almacenamiento; la mayoría son consecuencia de la arquitectura.
- Los descuentos por compromiso de uso solo convienen para la base que se necesitará con certeza, la capacidad spot conviene para el trabajo interrumpible y reintentable, y el autoescalado bajo demanda cubre los picos; ajusta el tamaño antes de comprometerte.
- El etiquetado permite la asignación de costos; el showback informa de los costos a los equipos, y el chargeback los carga a sus presupuestos y necesita una asignación precisa y reglas acordadas para los costos compartidos.
- El lock-in es un compromiso: Hohpe (2019) distingue muchos tipos y compara el costo de cambio multiplicado por su probabilidad con el costo de evitarlo; acéptalo cuando aporte un valor único.
- La portabilidad tiene costos reales; mantén la lógica de negocio detrás de puertos en los puntos de unión probables, conserva los datos exportables y mantén una estrategia de salida probada, algo que la regulación financiera de la UE ya exige para los servicios críticos.
El costo es una cualidad arquitectónica
La sección 2.7 (seguridad, usabilidad y más) incluyó el costo entre los atributos de calidad y recomendó expresarlo por unidad de trabajo. En un centro de datos, el costo era mayormente fijo: el hardware se compraba cada pocos años y las decisiones de un arquitecto apenas movían la factura mensual. En la nube, cada decisión arquitectónica es también una decisión de compra, que los ingenieros toman de forma continua en lugar de que la tome compras una vez al año. Un límite de servicio con demasiadas llamadas, un nivel de log de depuración, un entorno de pruebas olvidado o una llamada síncrona entre regiones aparecen en la factura del mes siguiente. El costo se ha convertido en un atributo de calidad que cambia con cada despliegue.
Dos disciplinas ayudan. FinOps es la práctica operativa que hace que el gasto en la nube sea visible, tenga dueño y se gestione. La arquitectura consciente del costo es la práctica de diseño que hace que los sistemas sean baratos de operar por unidad de valor desde el principio. Esta sección trata ambas y luego pasa a su incómodo vecino: el lock-in (la dependencia del proveedor), el costo de marcharse.
FinOps: fases, principios y quién hace qué
La FinOps Foundation, un proyecto de la Linux Foundation, define FinOps como un marco operativo y una práctica cultural que maximiza el valor de negocio de la tecnología mediante decisiones oportunas y basadas en datos, y una responsabilidad financiera compartida entre ingeniería, finanzas y negocio. El nombre recuerda deliberadamente a DevOps: así como DevOps derribó el muro entre construir y operar software, FinOps derriba el muro entre gastar dinero y decidir cómo se construye el software.
El FinOps Framework organiza el trabajo en tres fases iterativas. Informar: hacer visibles los costos, asignarlos a los equipos y productos que los generan, hacer previsiones y compararse con referencias. Optimizar: reducir el despilfarro y mejorar las tarifas, mediante el ajuste de tamaño, la programación de horarios, los compromisos de uso y los cambios de diseño. Operar: crear los hábitos que mantienen los costos bajo control, como los presupuestos, las políticas, la asignación de responsables y el costo considerado en cada decisión de diseño. Las organizaciones recorren el ciclo una y otra vez, madurando en cada capacidad de gatear a caminar y a correr. Entre los principios del marco están que los equipos colaboran, que el valor de negocio guía las decisiones tecnológicas, que todos se responsabilizan de su uso de la tecnología, que los datos de costos son accesibles, oportunos y precisos, que FinOps se habilita de forma centralizada y que el modelo de costo variable de la nube debe aprovecharse como ventaja. Las versiones recientes amplían el marco más allá de la nube pública a otros gastos tecnológicos, como las licencias SaaS, los centros de datos y los servicios de IA.
El ciclo de FinOps
Economía unitaria: el costo por pedido
Una factura de la nube que sube de 80 000 a 100 000 al mes puede ser un desastre o un triunfo, según si el negocio creció un 5% o un 50%. La economía unitaria expresa el costo por unidad de valor de negocio: el costo por pedido para la plataforma de reparto de comida, por cliente activo para un servicio de streaming, por cada mil llamadas a la API para una plataforma para desarrolladores. Separa la eficiencia del crecimiento, conecta las decisiones de ingeniería con los resultados de negocio y da a los equipos un objetivo sobre el que pueden influir.
Calcularla bien requiere tres cosas. Primero, una unidad que importe al negocio, elegida con finanzas y producto, no inventada por los ingenieros. Segundo, la asignación de costos: los costos directos (el cómputo y la base de datos del servicio de pedidos) se asignan mediante etiquetas o namespaces, y los costos compartidos (el plano de control de Kubernetes, la pila de observabilidad, las herramientas del equipo de plataforma) se reparten según una regla acordada, como el uso proporcional. Tercero, distinguir entre costo medio y costo marginal: el costo medio por pedido incluye costos fijos que no crecen con los pedidos, así que el costo de los próximos mil pedidos suele ser menor de lo que sugiere la media, lo que importa al poner precio a una promoción o al prever el crecimiento.
Adónde va el dinero: los factores de costo habituales
La mayoría de las facturas de la nube que sorprenden proceden de unos pocos factores, y casi todos dependen de la arquitectura más que de negociar mejores precios.
Factores de costo habituales y respuestas arquitectónicas
| Factor | Por qué crece | Respuestas arquitectónicas |
|---|---|---|
| Salida de datos (egress) y transferencia | Los proveedores cobran por gigabyte los datos que salen a internet y, a menudo, el tráfico entre zonas y regiones y a través de las pasarelas NAT gestionadas. Los servicios con demasiadas llamadas repartidos entre zonas pagan en cada llamada. | Servir el contenido público a través de una CDN; mantener en la misma zona los servicios con muchas llamadas entre sí (enrutamiento consciente de la topología); usar endpoints privados hacia los servicios del proveedor; comprimir; evitar el tráfico síncrono entre regiones. |
| Recursos ociosos y sobredimensionados | Entornos de prueba encendidos 168 horas a la semana para 50 horas de uso; solicitudes de recursos de los contenedores fijadas muy por encima del uso real; volúmenes, snapshots y balanceadores de carga huérfanos. | Ajuste de tamaño (rightsizing) a partir del uso medido; horarios y autoescalado a cero para los entornos que no son de producción; entornos de vista previa con límite de tiempo; limpieza automática de los recursos no asociados. |
| Volumen de logging y de observabilidad | La ingesta y la retención se cobran por gigabyte; los logs de depuración en producción, el registro detallado de solicitudes y las etiquetas de métricas de alta cardinalidad crecen con el tráfico. | Niveles de log y muestreo de las solicitudes exitosas; retención por niveles (en caliente durante días, en archivo durante meses); métricas en lugar de logs para los recuentos; muestreo de trazas. |
| Sobreprecios de los servicios gestionados | Un servicio gestionado cuesta más por unidad de capacidad que operar el software uno mismo; el precio por solicitud crece linealmente con el volumen. | Comparar el costo total de propiedad, incluidas las personas y el riesgo; revisar los servicios con precio por solicitud cuando el volumen es alto y estable (consulta serverless); usarlos donde el sobreprecio compre fiabilidad o velocidad reales. |
| Crecimiento del almacenamiento | Los datos que nunca se borran, las versiones de objetos, las copias duplicadas y las copias de seguridad antiguas se acumulan sin hacer ruido. | Políticas de ciclo de vida hacia niveles más baratos y borrado; reglas de conservación acordadas con el negocio y conformes a la ley; copias de seguridad incrementales y deduplicadas. |
Pagar menos por la misma capacidad
Una vez eliminado el despilfarro, se puede reducir la tarifa que se paga por la capacidad restante. La capacidad bajo demanda es la más flexible y la más cara. Un descuento por compromiso de uso cambia flexibilidad por precio: las Reserved Instances y los Savings Plans de AWS, las reservas y los planes de ahorro de Azure, y los committed use discounts de Google Cloud ofrecen reducciones sustanciales (AWS cita hasta un 72% para algunos compromisos) a cambio de comprometerse con un nivel de uso o de gasto durante uno o tres años. Los compromisos solo deben cubrir la base que con certeza se necesitará durante el plazo; comprometerse con la capacidad de pico convierte un descuento en despilfarro.
La capacidad spot (AWS Spot Instances, Azure Spot Virtual Machines, Google Cloud Spot VMs) vende la capacidad sobrante con grandes descuentos, a menudo del 60% al 90%, pero el proveedor puede recuperarla con poca antelación: dos minutos en AWS y unos 30 segundos en Azure y Google Cloud. Conviene para el trabajo sin estado, interrumpible y reintentable, como el procesamiento por lotes, los runners de CI, el renderizado y algunas capas web sin estado repartidas entre muchos tipos de instancia. No conviene para las bases de datos ni para nada que no pueda detenerse a mitad de una tarea. La arquitectura decide qué parte de una carga de trabajo puede usar spot: los trabajos idempotentes y con puntos de control pueden; los largos y con estado, no.
Adaptar los modelos de precios a la forma de la demanda
Etiquetado, showback y chargeback
Nadie optimiza un costo que no puede ver. La asignación empieza con una política de etiquetado: cada recurso lleva un pequeño conjunto de etiquetas obligatorias, como el equipo responsable, el servicio, el entorno y el centro de costos, que se hacen cumplir con guardrails en el código de infraestructura y en las políticas de organización de la nube, porque las etiquetas añadidas a mano pronto faltan. En Kubernetes, los costos se asignan por namespace y por etiqueta con herramientas como el proyecto de código abierto OpenCost o las funciones de asignación de costos de los propios proveedores. La especificación FOCUS de la FinOps Foundation define un formato común para los datos de facturación, de modo que los costos de varios proveedores puedan combinarse.
Con los costos asignados, una organización elige cómo usarlos. El showback informa a cada equipo de sus costos sin tocar su presupuesto; genera conciencia y es el punto de partida habitual. El chargeback (imputación de costos) carga los costos al presupuesto de cada equipo, lo que crea incentivos más fuertes, pero requiere una asignación precisa, reglas acordadas para los costos compartidos y una forma de resolver las disputas. En cualquier caso, publica la parte del gasto que no se puede asignar: una parte sin etiquetar de más de un pequeño porcentaje significa que las cifras todavía no son lo bastante fiables como para actuar en consecuencia.
Decisiones arquitectónicas que determinan el costo
Los mayores ahorros provienen del diseño, no de los descuentos, y son más baratos de obtener antes de construir un sistema. Cada una de las decisiones siguientes tiene un perfil de costo predecible. Granularidad de los servicios: cada salto de red cuesta cómputo, serialización y posiblemente transferencia de datos, así que los servicios de grano fino repartidos en muchas zonas cuestan más por solicitud que un monolito modular. Fan-out síncrono: una solicitud que llama a diez servicios mantiene ocupados once conjuntos de recursos mientras dura. Número de entornos: las copias completas de producción para cada equipo y cada rama multiplican la factura; los entornos compartidos con aislamiento o las vistas previas de corta duración cuestan mucho menos. Retención y replicación de datos: cada copia adicional y cada región adicional multiplican el almacenamiento y la transferencia. Caché y CDN: un acierto de caché suele ser mucho más barato que volver a calcular, y un acierto de CDN evita la salida de datos desde el origen. Modelo de cómputo: el precio serverless por solicitud es más barato que la capacidad siempre encendida por debajo de un volumen de cruce y más caro por encima de él.
Registra las consecuencias de costo significativas en los registros de decisiones junto con los demás compromisos de calidad, y plantéate añadir el costo a las funciones de aptitud que protegen la arquitectura: por ejemplo, una comprobación mensual de que el costo por pedido no ha subido más de un 10% sin una explicación.
El lock-in es un compromiso, no un pecado
El lock-in es el costo y la dificultad de abandonar algo una vez que dependes de ello. Suele tratarse como algo que hay que evitar a toda costa; el artículo de Gregor Hohpe de 2019 en martinfowler.com, Don't get locked up into avoiding lock-in, sostiene que eso es en sí mismo una trampa. Distingue varios tipos de lock-in: de proveedor (contratos y condiciones comerciales), de producto (las API y funcionalidades de un producto concreto, aunque sea de código abierto), de versión, de arquitectura (un estilo como serverless), de plataforma (cuentas, identidad y modelos de seguridad), de habilidades (lo que sabe tu gente), legal (cumplimiento normativo y licencias) y mental (suposiciones que te impiden considerar alternativas). Usar software de código abierto reduce el lock-in de proveedor, pero deja la mayoría de los demás.
El paso clave es tratar el lock-in como un problema de valoración de opciones. El costo de cambio es lo que costaría trasladarse; multiplicado por la probabilidad de llegar a hacerlo, da el costo esperado de estar atado. Reducir el costo de cambio tiene su propio precio: abstracción adicional, diseños de mínimo común denominador y funcionalidades a las que se renuncia. Un cambio que costaría 50 000 y tiene un 5% de probabilidades de producirse tiene un costo esperado de 2500, así que gastar mucho más que eso para evitarlo es un mal negocio. La matriz de Hohpe de utilidad única frente a costo de cambio convierte esto en una clasificación rápida.
Utilidad única frente a costo de cambio
El costo de la portabilidad y la estrategia de salida
La portabilidad no es gratuita. Diseñar cada componente para que funcione en varias nubes significa usar solo las funcionalidades que todas comparten, construir y probar capas de abstracción que tienen fugas (consulta ocultación de información y abstracciones con fugas), mantener habilidades en varias plataformas y renunciar a servicios gestionados que habrían ahorrado esfuerzo. Muchas estrategias multinube (multi-cloud) acaban con los costos de todos sus proveedores y las ventajas de ninguno. La portabilidad es más barata donde ya existen estándares abiertos: las imágenes de contenedor OCI, los manifiestos de Kubernetes, las bases de datos compatibles con PostgreSQL, las API de almacenamiento de objetos compatibles con S3, los protocolos estándar como HTTP, AMQP y el protocolo de Kafka, y OpenTelemetry para la observabilidad. Incluso las herramientas que se usan para seguir siendo portables, como Terraform u OpenTofu, son dependencias por derecho propio.
Los profesionales no se ponen de acuerdo sobre hasta dónde llegar. Los defensores de la portabilidad señalan las subidas de precios, las caídas del servicio, las sanciones, la regulación y los casos en que salir de la nube resultó rentable (consulta la repatriación desde la nube en la sección 10.1). Los partidarios de comprometerse con un solo proveedor señalan la velocidad y la fiabilidad que se obtienen al aprovechar a fondo los servicios gestionados. Una posición intermedia sensata es aceptar el lock-in deliberadamente donde aporte un valor claro, mantener la lógica de negocio independiente de las API del proveedor detrás de puertos y adaptadores en los pocos puntos de unión con más probabilidades de cambiar, guardar los datos en formatos que se puedan exportar y dejar por escrito una estrategia de salida.
La regulación exige cada vez más ese último paso. El Reglamento de Resiliencia Operativa Digital de la UE (Digital Operational Resilience Act, Reglamento (UE) 2022/2554, aplicable desde el 17 de enero de 2025; no debe confundirse con las métricas de entrega DORA) exige a las entidades financieras disponer de estrategias de salida para los servicios TIC que respaldan funciones esenciales o importantes. Las normas sobre el cambio de proveedor de nube del Reglamento de Datos de la UE (Data Act) se aplican desde el 12 de septiembre de 2025: los clientes pueden cambiar de proveedor con un preaviso de dos meses como máximo, y los proveedores solo pueden cobrar sus costos directos por el cambio, incluida la salida de datos, hasta el 12 de enero de 2027, y nada a partir de entonces. En 2024 los mayores proveedores también anunciaron la transferencia de datos gratuita para los clientes que los abandonan, sujeta a condiciones. Una estrategia de salida debe nombrar el sustituto de cada servicio crítico, estimar el tiempo y el costo del traslado, demostrar que los datos pueden exportarse en un formato utilizable y ensayarse al menos en parte, por ejemplo restaurando una copia de seguridad en otro entorno.
Ejemplo práctico
Ejemplo práctico: el costo por pedido y tres cambios arquitectónicos
La plataforma de reparto de comida gestiona 1.2 millones de pedidos al mes. Su factura mensual de la nube es de 96 000: cómputo 42 000, bases de datos gestionadas 18 000, observabilidad 14 000, transferencia de datos 12 000, otros servicios gestionados 6000 y almacenamiento 4000. Todas las cifras son ilustrativas, en libras.
| Punto de partida | 96 000 / 1 200 000 pedidos = 0.080 por pedido. El showback revela que las solicitudes de recursos de cómputo duplican aproximadamente el uso medido, que la mitad del volumen de logs es salida de depuración y que los servicios de pedidos y de precios intercambian unas 40 llamadas por pedido entre zonas de disponibilidad. |
|---|---|
| Cambio 1: ajustar el tamaño y luego comprometerse | Las solicitudes fijadas a partir del uso p95 medido reducen el número de nodos en un 25%: el cómputo pasa de 42 000 a 31 500. El 60% estable de esa cifra (18 900) se cubre con un compromiso de un año con un descuento de alrededor del 30%, lo que ahorra 5670. El cómputo queda en 25 830, un ahorro de 16 170. |
| Cambio 2: registrar menos y durante menos tiempo | Logging de depuración desactivado en producción, solicitudes exitosas muestreadas al 10% y retención en caliente reducida de 90 a 14 días, con un nivel de archivo. La ingesta cae alrededor de un 60%: la observabilidad pasa de 14 000 a 6500, un ahorro de 7500. |
| Cambio 3: dejar de pagar por la distancia | La lógica de precios se traslada al proceso del servicio de pedidos para la ruta crítica (lo que elimina la mayoría de las 40 llamadas), con enrutamiento consciente de la zona para las llamadas restantes e imágenes de restaurantes servidas desde una CDN en lugar del origen. La transferencia de datos pasa de 12 000 a 6000; la CDN añade 1000. Ahorro neto: 5000. |
| Resultado | 96 000 menos 28 670 = 67 330 al mes, o 0.056 por pedido: un 30% menos por pedido, sin cambios en las funcionalidades ni en los objetivos de fiabilidad. |
| Lo que no cambió | Los costos de bases de datos y de almacenamiento no se tocaron este trimestre porque los ahorros posibles eran pequeños en relación con el riesgo; siguen en el backlog. |
El mayor cambio estructural fue arquitectónico (eliminar un límite con demasiadas llamadas e introducir una CDN), el cambio de logging fue una decisión de diseño sobre la observabilidad, y el descuento de tarifa se aplicó solo después del ajuste de tamaño, de modo que la empresa no se comprometió con el despilfarro.
Seguir el costo por pedido en lugar de la factura total muestra si el crecimiento futuro mantiene la mejora: si los pedidos se duplican y el costo por pedido se mantiene cerca de 0.056, la eficiencia se ha sostenido.
Preguntas frecuentes
¿Debe cobrarse a cada equipo por sus costos de nube?
Empieza con showback, para que los equipos vean sus costos y puedan actuar, y pasa a chargeback solo cuando la asignación sea precisa y los costos compartidos se repartan según reglas que todos acepten; cobrar cifras imprecisas genera discusiones, no ahorros.
¿Es la multinube la mejor protección contra el lock-in?
Rara vez por sí sola. Ejecutar el mismo sistema en varias nubes es caro y te limita a las funcionalidades comunes. Usar proveedores distintos para cargas de trabajo distintas e independientes, junto con una estrategia de salida probada para las críticas, suele dar la mayor parte de la protección por una fracción del costo.
¿Cuándo es prematura la optimización de costos?
Cuando el producto no ha encontrado su mercado y el tiempo de ingeniería es el recurso más escaso. Aun así, etiquetar desde el primer día y tener un costo aproximado por unidad es barato y facilita mucho la optimización posterior.
Comprueba lo que has entendido
¿Por qué el costo por pedido es más útil que la factura mensual total?
Separa la eficiencia del crecimiento: una factura creciente con un costo por pedido decreciente es sana, mientras que una factura estable con pedidos decrecientes no lo es.
¿Por qué el ajuste de tamaño debe ir antes de comprar descuentos por compromiso de uso?
Un compromiso fija un nivel de gasto durante uno o tres años; comprometerse antes de eliminar el sobredimensionamiento convierte el despilfarro en una obligación a largo plazo.
¿Qué tipo de carga de trabajo conviene para la capacidad spot y por qué?
El trabajo sin estado, interrumpible y reintentable, como los trabajos por lotes y los runners de CI, porque el proveedor puede recuperar la capacidad spot con segundos o minutos de antelación.
Según Hohpe, ¿cuándo es aceptable el lock-in?
Cuando aporta una utilidad única que vale el costo de cambio, o cuando el cambio es tan improbable que el costo esperado es menor que el costo de evitar el lock-in.
Fuentes y lecturas recomendadas
¿Tienes una pregunta sobre esta sección? ArchitectBot, el asistente de estudio con IA del curso, responde primero a partir del curso.
Pregunta: “Nuestra factura de la nube creció un 40% este año, mientras que los pedidos crecieron un 15%. ¿Cómo averiguo qué decisiones arquitectónicas están impulsando el costo y qué soluciones debo probar primero?”