Cloud managed services are not a Silver Bullet

Seguro que la mayoría de vosotros habéis vivido, alguna que otra vez, esa situación en la que debéis que construir una determinada infraestructura en la nube y la conversación acaba con un, “fantástico, nuestro proveedor cloud dispone de un servicio gestionado, hagamos uso de el”, sin siquiera haber pasado de la marketiniana pagina principal del mismo. ¿Cierto?

Este artículo no pretende quitar la venda de los ojos ante algo tan evidente como que, antes de tomar ninguna decisión, se han de analizar con calma y en profundidad, los pros y los contras de cada una de las alternativas y escoger aquella que se ajusta mejor al caso de uso en cuestión. Y no, tampoco es una cruzada personal contra estos servicios que tantas horas de trabajo y sufrimiento pueden llegar a ahorrarte.

Lo que mediante este escrito se pretende es invitar a reflexionar acerca de las creencias o percepciones que se tienen de los servicios gestionados, especialmente si no se ha trabajado con ellos, y entender que no son esa ansiada Silver Bulltet con la hacer frente a todas las situaciones posibles.

CLOUD Managed services

Antes de sumergirse de lleno en esta trepidante aventura literaria, permitidme un pequeño inciso: Es evidente que existen decenas de servicios gestionados, cada uno de su padre y de su madre, por lo que me veo obligado aclarar que el presente texto estará basado única y exclusivamente en la experiencia personal de un servidor, con los siguientes productos de uso general de la cloud de Amazon:

  • DynamoDB
  • Elastic Kubernetes Service (EKS)
  • Elasticsearch Service
  • Managed Streaming for Apache Kafka (MSK)
  • Relational Database Service (RDS)

Se podría entender como servicio gestionado en la nube, la práctica de delegar la responsabilidad de mantener y anticipar la necesidad de una variedad de procesos y funciones en el proveedor de la nube, con el fin de mejorar las operaciones y reducir los gastos.

Llevado esto a un ejemplo muy muy simplificado, suponed que se requiere aprovisionar una base de datos. La diferencia reside en que, en lugar de contratar una instancia de una maquina sobre la que posteriormente instalar y configurar de forma manual la base de datos, se contrata directamente la BD con el proveedor cloud y el se encarga de su aprovisionamiento y mantenimiento.

Una vez entendida la esencia más pura de esta idea, es hora de repasar una por una, aquellas características que se tienden a presuponer de un servicio gestionado.

Fuente Original

Provisioning and Configuration

La primera de las características más evidentes en la simplificación del proceso de aprovisionamiento y configuración de la infraestructura a construir, independientemente de su tipología.

Ya sea mediante la interfaz web o como infraestructura como código (IaC), la complejidad, expertise y el tiempo necesario para su aprovisionamiento se reducen significativamente, permitiendo desentenderse casi por completo de su proceso de instalación. Tan solo se debe proporcionar la configuración básica necesaria para que el proveedor cloud pueda llevar a cabo su trabajo y por lo general, suelen tender a simplificar al extremo estos requisitos. Es genial, ¿no?

Por desgracia, esta virtud a su vez puede convertirse en una losa para los usuarios más experimentados o casos de uso atípicos, pues no todos los parámetros de configuración del producto serán modificables. A fin de cuentas, los servicios gestionados están pensados para llegar al máximo numero de organizaciones posibles y de la forma mas sencilla, lo que delimita en gran medida el control sobre los mismos. Sobra decir que no es posible conectarse via SSH a la maquina o maquinas en cuestión y editar esta configuración manualmente, pues se trata, a todas luces, de un anti patrón.

Finalmente, antes de aprovisionar un servicio gestionado es capital conocer si hace o no uso de la versión open source del producto a construir, suponiendo que la hubiera claro. Es decir, muchos proveedores cloud ofrecen servicios gestionados que hacen uso de una implementación propietaria y tan solo ofrecen una interfaz compatible con el producto original, como es el caso de DocumentDB por ejemplo. Esto puede ser problemático a medio-largo plazo, si se quiere hacer uso de determinadas funcionalidades que pueden no estar soportadas o simplemente si se desea realizar una migración a otra nube (vendor lock-in puro y duro).

Otra variante mas enrevesada de esto lo protagoniza AWS Elasticsearch Service, que a pesar de utilizar la versión vanilla de Elasticsearch (Apache 2.0 license), no puede ofrecer todas las funcionalidades del archiconocido set X-Pack, ya que este fue liberado bajo una Elastic License, la cual que no permite la reventa o la redistribución del código a terceros. Y si, aunque Amazon ha contraatacado con una versión similar open source denominada Open Distro for Elasticsearch, lo cierto es que aún no esta a la altura.

En resumen, es fundamental conocer a ciencia cierta lo que se esta contratando, si no se quiere uno encontrar con disgustos mas adelante. Nada que no se deba aplicar a todos los aspectos de la vida.

Availability

Una de las grandes ventajas del uso de los servicios gestionados es que permiten delegar en el proveedor cloud la responsabilidad de garantizar que la infraestructura este disponible y funcione continuamente de forma optima, todo ello bajo estrictos SLAs con mínimos del 99% de uptime.

¿Quiere esto decir que no es necesario tener un equipo especializado que opere la aplicación en cuestión? No, nada más lejos de realidad. Que la nube se encarga de mantener vivos todos los nodos de una determinada infraestructura y sustituirlos si alguno de ellos falla, no elimina la necesidad de tener personal especifico que se encargue de gestionarla internamente.

Llevado esto a un sencillo ejemplo, puede ser que una base de datos esté funcionando y superando los health check pertinentes, pero que se este quedando sin espacio de almacenamiento. Por tanto, es necesario que uno o múltiples equipos, dependiendo de la organización, se encarguen tanto de establecer alarmas en el sistema de monitorización correspondiente, como de ampliar el disco duro cuando consideren oportuno.

En resumidas cuentas y aunque puede parecer algo evidentemente, la palabra “gestionado” no implica que uno pueda contratarlos y desentenderse por completo de ello.

SCALABILITY

Llega el momento de hablar de la escalabilidad, característica que por normal general más malentendidos tiende a generar. ¿Por qué?

La escalabilidad se define como la propiedad de un sistema para manejar una cantidad creciente de trabajo agregando recursos al sistema, ya sea de forma vertical (mas CPU | RAM | Storage) o horizontal (mas instancias). En este punto muy probablemente estéis pensando a santo de que se detalla algo tan evidente y la explicación es muy sencilla: el escalado no llevo implícito el autoescalado.

Que el proveedor cloud contratado permita aumentar a golpe de click el número de nodos del sistema, no implica que obligatoriamente tenga que ser capaz de ajustar de forma automática y transparente, los recursos de la infraestructura en base a la carga de trabajo. De hecho, esta capacidad está más relacionada con la característica del producto en si, que con el servicio gestionado.

De nuevo, llevado esto a un sencillo ejemplo, añadir nuevos nodos a un cluster de Elasticsearch cuando la carga aumenta es claramente contraproducente, ya que implica reubicar algunos de los shards en las nuevas maquinas, provocando un aumento del uso de CPU y ancho de banda, con la correspondiente degradación del servicio. Mas de lo mismo ocurre con Kafka, mientras que Kubernetes, por contra, si que lo soporta.

En definitiva, tratar de no confundir ambos conceptos si no se quiere caer en un mal diseño de solución.

Automatic Upgrades

Aunque por el título no parezca una característica muy rimbombante, delegar el proceso de actualización de un sistema en el proveedor cloud, no solo reduce ostensiblemente el trabajo del equipo que lo opera, sino que garantiza que se llevará a cabo siguiendo las mejores practicas posibles. Es decir, tratando de evitar o minimizar el tiempo de downtime mediante estrategias de rolling update, si bien es algo que depende de los productos per sé.

En lo que a la automatización de estas actualizaciones se refiere, algunos servicios permiten que la versiones patch sean instaladas de forma transparente por el proveedor cloud cuando lo estimen oportuno. Aunque a primera vista parezca algo fantástico, la experiencia personal dice que puede volverse fácilmente en tu contra, especialmente si se trata de una base de datos tradicional que al actualizarse tiene unos minutos de downtime y no todos tus aplicativos son capaces después de volver a conectarse…

Time to Market

Como consecuencia directa de todas las características descritas hasta ahora, los servicios gestionados en la nube permiten reducir de forma notoria el time to market.

Tanto si es para el desarrollo de una PoC como para un entorno productivo, el tiempo necesario para su despliegue es ostensiblemente menor a si se realizara de forma manual o automatizada sobre una o varias máquinas físicas. Tan solo paraos a pensar en las horas y perfiles técnicos necesarios para desplegar y configurar un cluster production-ready de cualquiera de los productos mencionados previamente.

Dicho esto, seguro que, en este punto, a todos los que os haya tocado pegaros alguna que otra vez con el equipo de IT por los mas que habituales elevados plazos de entrega, se os habrá dibujado una sonrisa en la cara.

COST SAVINGS

Finalmente llega el punto caliente del artículo, el supuesto ahorro de costes que en tantos y tantos lugares se publicita.

Lo primero de todo, es que, evidentemente, la factura emitida por el proveedor cloud es substancialmente mayor comparada con la de un despliegue manual sobre maquinas físicas, también en la nube claro está. Al fin y al cabo, todos los beneficios mencionados previamente tienen un coste.

Aquí es precisamente donde reside el el quid de la cuestión. Cuando se habla de reducción de costes, no se hace referencia al importe de facturas, sino al impacto indirecto que generan estos beneficios o facilidades, que reducen de forma notoria, el tiempo que los equipos encargados de operar la plataforma deben invertir, tanto en su construcción como en su mantenimiento.

Por contra, muchos de los servicios gestionados no pueden ser apagados, con el objetivo de ahorrar costes, durante los periodos de tiempo en los que no son utilizados, mientras que las maquinas físicas sí. Buen ejemplo de ello son Kafka (MSK), Elasticsearch o EKS (Kubernetes), entre otros, los cuales deben estar obligatoriamente encendidos durante las noches o los fines de semana, en entorno no productivos, a pesar de que nadie vaya a hacer uso de ellos. Y no, reducir el numero de nodos al mínimo no siempre es posible.

¿Entonces son o no son más baratos? Es difícil de cuantificar, pues depende mucho del caso de uso y grado de madurez de la organización, pero se podría decir que en general sí.

CONCLUSIONES

En conclusión, tal y como se ha comentado a lo largo de todo el artículo, los servicios gestionados ofrecen multitud de beneficios que pueden ayuda a reducir de forma considerable el tiempo y dinero requerido en la construcción y mantenimiento de la infraestructura. Posiblemente aun se encuentren en un estado poco maduro, pero parece evidente que son uno de los pilares de los proveedores cloud a corto plazo y que evolucionarán a pasos agigantados.

Ahora bien, esto no implica que sean por defecto la mejor opción disponible, pues no siempre será posible sacarles todo el provecho o simplemente no se ajuste al caso de uso en cuestión. Pueden parecer palabras vacías e inocentes, pero os puedo asegurar que, encontraros meses después de iniciar el proyecto, con que el servicio gestionado no soporta determinadas funcionalidades, puede ser un jarro de agua fría difícil de digerir.

Por tanto, haced siempre el ejercicio de leer más allá de la marketinia pagina principal de la misma y estudiar a fondo todas sus características, o al menos las que vayas a utilizar a medio-largo plazo.

REFERENCIAS

Se recomienda encarecidamente leer los siguientes artículos que han servido de base para el escrito:

  1. https://en.wikipedia.org/wiki/Managed_services
  2. https://en.wikipedia.org/wiki/Scalability

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s