Controlar el coste de Oracle Cloud desde dentro

Casi todo lo que se escribe sobre el coste de Oracle Cloud lo compara con AWS, lo cual es útil cuando estás decidiendo dónde ejecutar algo e inútil una vez ya estás ejecutando ahí. La pregunta de la comparación está en por qué las facturas de Oracle Cloud se ven distintas. Esta es la otra mitad: los controles disponibles dentro de la tenencia, en el orden en que los aplicamos.

La buena noticia es que dos decisiones estructurales de la plataforma, los compartimentos y las formas flexibles, hacen esto más fácil que en otras nubes. La mala es que la mayoría de las tenencias se construyeron sin usar ninguna de las dos con fines de coste.

Los compartimentos son tu modelo de atribución, si los diseñaste así

Un compartimento es un contenedor lógico con sus propias políticas, y el análisis de costes agrupa por él de forma nativa. Eso convierte la jerarquía de compartimentos en la decisión de coste más importante de la tenencia, y se toma el primer día por alguien que está pensando en control de acceso y no en informes.

Una jerarquía organizada por entorno y equipo te da atribución de coste gratis. Una organizada por tecnología, con un compartimento para red y otro para bases de datos, te da una factura que no puedes asignar a nadie. Los principios de diseño están en los compartimentos no son carpetas, y la consecuencia de coste es la razón de acertar pronto, porque mover recursos entre compartimentos después es posible pero tedioso.

Encima de eso, usa etiquetas definidas y no de formato libre. Las etiquetas definidas viven en un espacio de nombres con esquema, lo que significa que la clave está controlada y el valor se puede restringir a una lista. Las de formato libre derivan hacia tres variantes del mismo nombre en un trimestre, y entonces la atribución falla en el paso del informe.

Dos funciones que merece usar a conciencia: los valores por defecto de etiqueta, que aplican una etiqueta automáticamente a todo recurso creado en un compartimento y resuelven el problema de cobertura en origen en vez de a base de insistir; y las etiquetas de seguimiento de coste, un conjunto designado que aparece como dimensión en el análisis de costes. Designa el conjunto pequeño sobre el que de verdad informas, porque el número de etiquetas de seguimiento está limitado.

Presupuestos, y lo que pueden hacer de verdad

Los presupuestos se asocian a un compartimento o a una etiqueta de seguimiento de coste, con reglas de alerta sobre gasto real o previsto como porcentaje del presupuesto.

No detienen el gasto, igual que en todas partes. Lo que los hace útiles aquí es la estructura de compartimentos: un presupuesto por compartimento de equipo con alerta al ochenta por ciento de la previsión pone la notificación delante del equipo que puede actuar, en vez de delante de una función financiera central que solo puede hacer preguntas.

Ponlos por compartimento, no uno para la tenencia. Un único presupuesto de tenencia se incumple en un punto en el que la causa ya tiene tres semanas.

Las formas flexibles hacen continuo el redimensionado

Es la función de coste más útil de la plataforma y la más desaprovechada.

En las formas de cómputo flexibles eliges el número de núcleos y la cantidad de memoria de forma independiente, en incrementos, en vez de escoger de una escalera fija de tipos de instancia. Eso convierte el redimensionado de una decisión a saltos, donde el tamaño siguiente hacia abajo es media máquina y no te atreves, en una continua donde puedes quitar dos núcleos y conservar la memoria.

En la práctica: mira la utilización de CPU y de memoria de tus instancias mayores durante treinta días y reduce núcleos hasta ajustar al pico observado más margen. Como las dimensiones son independientes, una carga intensiva en memoria ya no tiene que comprar núcleos que no va a usar, que en otras nubes es un desperdicio estructural significativo.

Los volúmenes de bloque son la misma forma de decisión. El rendimiento del volumen se factura aparte de la capacidad, como un nivel de rendimiento que eliges por volumen. Un volumen aprovisionado a rendimiento alto para una carga que hace lecturas secuenciales ocasionales está pagando operaciones de entrada y salida que nunca emite, y bajar el nivel de rendimiento es un cambio en caliente. Recorre la lista de volúmenes y comprueba el ajuste contra el uso real; es una de las victorias más rápidas en una tenencia madura.

Instancias interrumpibles, y para qué sirven

Las instancias interrumpibles llevan un descuento sustancial y se pueden reclamar con poco aviso. Las reglas son las de siempre: solo cargas sin estado, replicadas y tolerantes a reinicios, con un núcleo bajo demanda para todo lo que no pueda desaparecer.

El procesamiento por lotes, los agentes de compilación y los workers detrás de una cola son los encajes naturales. Un servicio con estado y una sola réplica no lo es, y la reclamación te encontrará en el peor momento.

La salida de datos cambia la aritmética

El precio de la plataforma para la transferencia de datos de salida es apreciablemente más generoso que el de las otras nubes grandes, con una franquicia gratuita bastante mayor y una tarifa menor por encima. Para una carga intensiva en salida, distribución de medios, distribución de datos o una API que sirve respuestas grandes, esta es con frecuencia la mayor diferencia individual en coste total y merece modelarse explícitamente en vez de suponer paridad.

Cambia además decisiones de arquitectura que otras nubes te empujan a tomar. Patrones que evitarías en otro sitio por el coste de transferencia, como servir directamente desde el almacenamiento de objetos o un diseño más parlanchín entre regiones, aquí penalizan menos.

Dicho eso, consulta las tarifas y la franquicia vigentes en vez de fiarte de una comparación de una charla, porque los precios se mueven y la ventaja es una cuestión de grado y no binaria.

El compromiso universal de crédito no es una reserva

Aquí es donde los equipos que vienen de otras nubes se equivocan de modelo.

En lugar de comprometerte con una familia de instancias concreta en una región concreta, el acuerdo comercial estándar es un compromiso de gastar una cantidad a lo largo de un plazo, consumida contra cualquier servicio. Obtienes un descuento sobre la tarifa a cambio del compromiso.

Las consecuencias son distintas de las de una reserva. Es mucho más flexible, porque se aplica entre servicios y regiones y no te ata a una forma, lo que elimina el riesgo principal de comprometerse antes de haber optimizado. Pero es un compromiso de gasto, así que el crédito no consumido se pierde en general en vez de devolverse, y la disciplina pasa de "¿usamos la instancia que reservamos?" a "¿vamos en camino de consumir lo que nos comprometimos a gastar?".

Eso convierte la pregunta mensual en un consumo acumulado: qué fracción del plazo ha transcurrido frente a qué fracción del compromiso se ha consumido. Síguelo desde el primer mes, porque el modo de fallo es descubrir en el mes diez que vas muy por debajo y comprar cosas que no necesitas para no perder crédito, que es el peor desenlace posible.

El principio de orden sigue en pie: reduce el desperdicio primero y después comprométete contra la línea base corregida. Es el mismo argumento que en la factura de Azure y en dónde se esconde la factura de AWS, e importa también aquí aunque el compromiso sea más flexible, porque el importe del compromiso se fija a partir de tu ritmo de gasto actual.

Lo que se va acumulando

• Volúmenes de bloque sin asociar de instancias terminadas, que persisten y facturan.
• Volúmenes de arranque que quedan atrás cuando se termina una instancia sin la opción de borrarlos.
• Copias de volumen y grupos de volúmenes viejos, con una política que nadie ha revisado.
• Almacenamiento de objetos sin reglas de ciclo de vida, incluidas las cargas por partes sin confirmar.
• Bases de datos autónomas encendidas en no producción, donde deberían estar configurados el escalado automático y la parada automática.
• IP públicas reservadas que quedaron tras cambiar un balanceador.

Qué hacer esta semana

Saca el análisis de costes agrupado por compartimento de los últimos tres meses y mira cuánto cae en un compartimento sin dueño. Después lista tus volúmenes de bloque con su nivel de rendimiento junto a su uso real de entrada y salida. El primer número te dice si tu modelo de atribución funciona; el segundo suele ser dinero inmediato. Hacemos las dos cosas en la fase de costes de un proyecto cloud.