Tu estrategia cloud pasa por (re)aprender a comprar

El reciente anuncio de AWS , sobre el lanzamiento y futura disponibilidad de Aurora Serverless V2 , me ha hecho regresar a unas reflexiones, acerca de cómo la nube nos obliga a enfocar las compras de otra forma, pues de otra manera no sacaremos ventaja real de las innovaciones que trae esta tecnología, que (se supone) queremos introducir como parte de nuestra estrategia tecnológica y (sobre todo) de negocios.

Empecemos con la contextualización, en una forma simpática:

En este tweet Javi nos recuerda, de manera sencilla, los esquemas de trabajo usuales en Bases de Datos (y extrapolables a casi servicio de cómputo): para evitar quedarnos cortos de capacidad de proceso las organizaciones estiman “hacia arriba” la capacidad que necesitarán (usualmente servidores y número de cores) para cierto requerimiento, con lo cual damos “tranquilidad” a la organización si dicha aplicación es de misión crítica (al precio de tener capacidad sin usar durante buenos tramos de la operación); vamos, lo usual en el mundo on-premise y tiene cierto sentido porque el agregar, retirar, o cambiar de uso a un conjunto de servidores no es cosa sencilla. Claro, me dirán que la virtualización y tal, pero nos olvidamos que aún en un esquema virtualizado trabajamos con un “colchón” grande para ir asignando sucesivamente la capacidad demandada, por lo que para este análisis prescindiremos del modelo de virtualización gestionado por la organización.

El caso es que el anuncio de AWS pone el foco en dos factores claves de lo que ha sido la “propuesta cloud”: escalabilidad y pago por uso. Sí pues… lo que hemos venido escuchando en los últimos 10 años “arranca con un servidor y escala automáticamente según la demanda y sólo paga a fin de mes por lo realmente consumido”; sí, el argumento no es nuevo y no deja de ser cierto, la diferencia es que usualmente este argumento ha sido orientado a las aplicaciones (generalmente web), no a las BD.

En ese sentido, esto continua la senda de los últimos dos o tres años: más ofertas de bases de datos serverless como SQL Database, la v1 de Aurora Serverless, y hace poco Cosmos DB. Estos movimientos de la industria deben indicarnos por dónde van las tendencias; que el viejo modelo de mirar sólo el número de servidores, nodos o cores a desplegar debe cambiar ya; que además de considerar PaaS y Serverless para el desarrollo de aplicaciones (como ya hemos hablado antes), no podemos ignorar ese rumbo de la industria.

A todo esto, si quieres entender un poco mas sobre el modelo serverless (y en este post hablaremos mucho de el), hace poco escribí la serie de artículos Serverless: Realidad y perspectivas (1), (2) y (3) que seguro te servirá.

Con esto en mente, ¿cuál ha sido el enfoque usual hasta ahora? En su gran mayoría, replicar el provisionamiento “on premise”, estimar la capacidad necesaria para el consumo medio-alto y reservar el presupuesto en periodos anuales. De ahí la pregunta que surge usualmente cuando se conversa sobre alguna nueva aplicación: “¿Cuánto me va a costar?”. Esto ha derivado en dos efectos:

  • Recelo de modelos “impredecibles” como serverless, no sólo por el cambio en el modelo de programación, sino porque en estas circunstancias la respuesta al costo nunca será un número exacto (iremos sobre eso más adelante). Esto último nos limita en cuanto a adoptar soluciones, nuevas sí, pero con el potencial de cubrir las necesidades futuras a un costo de operación mínimo en el presente.
  • Ya que no se puede predecir cuánto se gastará, se procura ahorrar en ese gasto indeterminado, lo cual lleva a buscar los descuentos por compra anticipada por volumen (ya sea por horas de cómputo/cores, número de usuarios, ), lo cual tiene todo el sentido del mundo si es que ya sabemos (de manera razonable) cual será nuestro consumo (lo cual, como estamos viendo, pocas veces es cierto), y si es que efectivamente vamos a basar nuestro desarrollo en IaaS (que son generalmente el tipo de recursos sobre el que se ofrecen estos tipos de descuentos).

Ok, ahora entendamos el por qué es “impredecible” un modelo de tipo serverless por consumo. Primero veamos cómo sería un patrón de consumo tradicional y esperado:

No reviste mucha ciencia: a*b nos da el número redondo (llamémosle P) para el horizonte de tiempo del proyecto, suponiendo (claro esta) que estamos totalmente seguros que b es el consumo fijo que necesitaremos de manera constante para cubrir nuestra operación, vamos.. mucho suponer.

Pero ahora veamos cómo esto se traslada a una operación basada íntegramente en componentes serverless (disculpen el pulso):

Upsss, esto nos complica un poco las cosas: uno porque de cara a periodos grandes de tiempo es complicado figurarnos que la curva saldrá así, y menos calcular el área bajo la curva azul punteada (*). Pero tranquilos, nuestro proveedor de nube periódicamente nos actualiza nuestros consumos y nos dirá cuál es el monto final que hemos gastado.

¿Queda más claro el problema? ¿No? Entonces, ¿qué podemos hacer?

En este momento sólo queda asumir que no tenemos toda la información, así que tocará dejar el consumo “libre” (pero llegado un horizonte razonable fijar una fecha de corte) tal como se ve en el gráfico:

Al llegar a esa fecha de corte ya tenemos información: tanto el monto de la factura que nos pasará nuestro proveedor de nube (llamémosle P’) , como el histórico de su uso (tendencias, correlación a eventos, consumo mínimo promedio, etc). Con esa información ya podemos, de manera más que razonable, estimar el valor P, donde f(P’)=P, siendo que P ya no es a*b ojo a ello.

Sí, todo bien, pero hay detalles que no podemos pasar por alto: hemos reducido la incertidumbre, pero ésta no se elimina del todo, y eso está bien. Por ejemplo, imaginemos que durante lo que resta del ciclo proyectado un producto se vuelve éxito de ventas y más usuarios visitan la web: ¿acaso esto no compensa el salir del presupuesto sabiendo que el sistema reaccionó adecuadamente?

Ya vamos entendiendo el asunto, la cosa se trata de medir y usar los resultados para ir mejorando el uso (no sólo el gasto) de los componentes a usar. Ahora supongamos que por la razón que sea no hemos ido a un modelo serverless bajo consumo, sino a un modelo PaaS o IaaS de recursos acotados. Pues bien, aquí debo insistir en que no podemos olvidar que en cloud las cosas cambian; ahora es más fácil crear, reconfigurar, y destruir los recursos que usamos para nuestras operaciones. Ya no es necesario esperar semanas para el clásico proceso de generar la orden de compra y esperar que llegue la importación de nuestro hardware.

Con esto en mente, en el libro Cloud Operations se nos plantea este sencillo flujo, que es de sentido común, pero que a veces nos olvidamos:

Y en el fondo es eso: reconocer que nuestras necesidades son variables (no es lo mismo el gasto en recursos cuando estamos en desarrollo y pruebas que cuando ya estamos en producción), que es necesario reevaluar periódicamente nuestros consumos y proyecciones (**), y aceptar que de cara a las organizaciones la necesidad de tener un presupuesto anticipado no es lo más eficiente ni rentable.

El reto es ése, repensar la forma en que consumimos y compramos, entender el nuevo modelo y abrazar las ventajas de esta evaluación frecuente de cara al impacto en el negocio. ¿Estamos en el rumbo de ese cambio?

(*) Una forma de verlo es que el gasto, durante un periodo de tiempo, corresponde a la Integral de la función que define la curva rara esa, el detalle es que de antemano no conocemos esa función, y lo mejor que podemos hacer es ir aproximándonos a los valores óptimos de manera sucesiva, lo cual sin duda es mucho mejor que creer (ilusamente) que conocemos los valores constantes para calcular el área de un rectángulo.

(**) En este punto me diran que con la escalabilidad, propia de la nube, ya podemos simplificar estos procesos, pues si y no, la escalabilidad nos ayuda a responder elegantemente ante picos de consumo, pero digamos que fijamos el gasto en 70, y en un momento dado el consumo se dispara a 120, el autoescalamiento nos ayudara a atender ese pico de consumo, pero…. ¿qué pasa si sabemos que el consumo usual esta alrededor de 50?, de una manera simple estamos viendo que hablamos de problemas diferentes, relacionados si, pero diferentes.

2 thoughts on “Tu estrategia cloud pasa por (re)aprender a comprar

Agregue un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *

Time limit is exhausted. Please reload the CAPTCHA.