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á.

Finish Reading: Tu estrategia cloud pasa por (re)aprender a comprar

¿Psicosociales en el mundo de los contenedores? Kubernetes depreca a Docker

El día de ayer, buena parte del mundillo informático se sacudió con una noticia, que si bien ya se veía venir, por el lenguaje utilizado causo revuelo y preocupación, veamos:

Docker support in the kubelet is now deprecated and will be removed in a future release.

Esta nota formaba parte del log de cambios de Kubernetes, lo cual iba en la línea de un anuncio anterior donde se anunciaban este objetivo por parte de Kubernetes.

Obviamente las preguntas saltaron, ¿ya no podre seguir usando Docker si quiero trabajar con Kubernetes? ¿Qué pasara con el soporte para contenedores en Windows?, y la verdad la respuesta tardó algo en darse, y de eso hablaremos aquí, pero antes contextualicemos un poco.

Primero, veamos la parte técnica, a estas alturas en el mundo informático ya el concepto de contenedores esta mas o menos establecido, que la equivalencia con los contenedores usados en el transporte marítimo, que es una unidad de software con lo mínimo para ejecutar en un entorno destino y asi asegurar la portabilidad, las diferencias con las máquinas virtuales etc. Dicho esto, si que debemos repasar cual es el ciclo de trabajo que la mayoría de nosotros usamos al trabajar con contenedores, por simplicidad he quitado los componentes DevOps para enfocarnos en los contenedores, Docker y Kubernetes.

  • Tenemos un archivo llamado Dockerfile que define los componentes de software que queremos empaquetar y algunas acciones alrededor, este Dockerfile actúa como “receta” para que el comando “docker build” construya una imagen que la llamaremos X.
  • En este momento la imagen X esta en nuestro equipo, por lo que ya podríamos ejecutarla usando el comando “docker run”, o publicarla en un Registro tal como Docker Hub, Elastic Container Registry o Azure Container Registry, para lo cual usaremos “docker push”.
  • Con la imagen X subida en uno de estos Registros, ya esta lista para ser usada en diversos ambientes (generalmente en la nube), tales como Azure Container Instances, una máquina “convencional, Elastic Beanstalk y… Kubernetes, para lo cual este entorno destino deberá hacer un “pull” contra el Registro respectivo.

Entendiendo este gráfico podemos ver el porque de las dudas, si hemos subido nuestras imágenes apoyándonos en las funcionalidades de Docker… ¿quiere decir que en un futuro ese flujo va a cambiar?, bueno… para responder esta pregunta toca revisar un poco el como hemos llegado hasta aquí. Finish Reading: ¿Psicosociales en el mundo de los contenedores? Kubernetes depreca a Docker