Multi

Una ventana de mi casa necesita reparación. Sé que necesito hacerlo, pero terminó en el cuadro "demasiado difícil por ahora", así que no me apresuro a solucionarlo. La corriente de aire es realmente molesta en los nueve meses de clima del Reino Unido conocidos como "grises y húmedos".

Llevo dos años posponiendo el trabajo, pero me está costando. Es probable que muchos de los CIO que lean esto tengan sus propias tareas pendientes en la vida real y un dolor de cabeza mucho mayor en su vida laboral: el problema del bloqueo de la nube.

¿Qué es eso? Te oigo preguntar: ¿hay algún problema con la nube? Bueno, el regulador del sector de comunicaciones del Reino Unido, Ofcom, cree que sí. A principios de este año, conmocionó al mercado al anunciar que remitirá el mercado de la nube del Reino Unido para su investigación a la Autoridad de Mercados y Competencia.

¿Por qué? Bueno, Ofcom identificó características y prácticas que dificultan que los clientes cambien y utilicen múltiples proveedores de nube. Plantearon preocupaciones sobre las barreras a la interoperabilidad, como las altas tarifas de salida (los cargos que pagan los clientes para transferir sus datos fuera de una nube). El regulador cree que los hiperescaladores fijan estas tarifas a tasas significativamente más altas que otros proveedores. Ofcom también estaba preocupado por las restricciones técnicas a la interoperabilidad, así como por posibles problemas con los llamados descuentos por gastos comprometidos.

No voy a entrar en un largo debate sobre esto, pero creo apasionadamente en obtener todos los beneficios de la nube. Obtener estos beneficios no debería significar que usted tenga que romper su contrato actual y comenzar de nuevo, incluso si eso fuera posible.

Es muy posible que los asuntos relacionados con el contrato de la nube estén fuera de su control y se traten en un nivel superior de la empresa o directamente por el director financiero. Por lo tanto, es poco probable que puedas pasar de un hiperescalador a otro. Entonces, una parte de usted quizás esté tristemente de acuerdo con la evaluación crítica de Ofcom, pero ¿hay algo que realmente pueda hacer al respecto?

Sugiero que sí. A muchos desarrolladores y arquitectos de TI realmente les importa esto y, aunque el gran contrato puede firmarse a un nivel superior, somos personas como nosotros quienes somos responsables de hacerlo funcionar. Además, es su presupuesto el que se somete a escrutinio si termina excediendo el gasto acordado.

Veo dos formas en que los CIO pueden hacer retroceder la forma en que se gestiona la nube en sus negocios. Una es simplemente discutir su caso con su administrador de cuentas.

Pero también existe una segunda opción técnica que podría terminar beneficiándolo más, hasta que surjan nuevas libertades en la nube lideradas por los reguladores. Esto implica trabajar conscientemente con software y plataformas que no lo dejen completamente y de manera costosa dependiendo de la tecnología de un solo proveedor.

Esto se aplica a muchas áreas de aplicación, pero la que mejor conozco son las bases de datos, así que me centraré en esa. Cada hiperescalador tiene una asombrosa variedad de opciones de SQL, NoSQL, gráficos y lo que sea. También están escalonadas, por lo que puede elegir una base de datos para problemas de pequeña escala, de rango medio y de empresa/gran escala.

Pero no querrás quedarte atrapado en un único nivel de una sola pila de nube: querrás tener opciones. La buena noticia es que puede elegir 'Vanilla Postgres', la versión básica de código abierto del lenguaje Postgres SQL de cualquiera de los proveedores de nube que puede obtener en postgres.org.

Sin embargo, el peligro de este enfoque del 'mínimo común denominador' es que puede tener problemas si su aplicación crece y necesita agregar funciones de nivel empresarial. En este punto, podría resultar útil recordar por qué quería trabajar con bases de datos en la nube en primer lugar (y, lo que es más importante, si Ofcom y Gartner tienen razón y la nube múltiple es hacia donde todos deberíamos aspirar). Está modernizando su capa de datos para explotar todas las increíbles funciones nativas de la nube que le faltaban, incluida la escalabilidad y la resiliencia simples en las instalaciones. Si realmente no los está utilizando, entonces simplemente está haciendo un levantamiento y cambio y, por lo tanto, en términos financieros reales (pero también técnicos), no está experimentando los beneficios reales de la nube.

Una gran parte del traslado de sus aplicaciones a la nube, entonces, tiene que ser la modernización de la base de datos, pero no es obvio cómo llegar allí sin adoptar una oferta personalizada de uno de los grandes proveedores de la nube. Sería mejor elegir bases de datos que se ejecuten en diferentes nubes públicas y tengan API comunes. La guinda del pastel sería trabajar con tecnologías nacidas en la nube, ya que, si se analiza más de cerca, muchos de los productos que existen son simplemente tecnologías tradicionales reimplementadas en la nube.

Es perfectamente natural examinar lo que su proveedor tiene para ofrecer. De todos modos, estás en su nube y seguramente es una ventaja considerar la amplia gama de servicios y funcionalidades que a) funcionarán en tu entorno y b) nacieron en la nube.

También debe comprender que estos servicios y funcionalidades siempre se personalizarán de alguna manera para el entorno de nube específico. El motor de base de datos relacional totalmente administrado de AWS, Aurora, es compatible con MySQL y PostgreSQL, pero fue diseñado específicamente para ejecutarse en Amazon. Esto significa que no puede ejecutarse localmente y ciertamente no funcionará en GCP (la nube de Google).

El resultado es que pronto necesitará realizar cambios en su aplicación para adaptarla a una versión personalizada de Postgres que se ejecutará de manera muy eficiente en el entorno de nube de su socio hiperescalador, pero que reducirá su flexibilidad general. Hasta cierto punto, quedará atrapado en esa versión de la aplicación porque no puede funcionar en ningún otro lugar. Lo mismo se aplica al equivalente de Google de Postgres básico (CloudSQL para Postgres) o la versión de Microsoft (Azure PostgreSQL).

Como era de esperar, todos los hiperescaladores estarán encantados de ofrecerle una versión de 'Postgres', ya sea que esté interesado en comenzar en el extremo bajo, medio o alto. Piense en ello como una matriz de tres por tres, donde hay tres bases de datos en la nube SQL de bajo a alto para cada una de las principales plataformas de nube de Amazon AWS, Google Cloud Platform y Microsoft Azure. La parte inferior de cada pila está bastante cerca de Postgres básico, pero tan pronto como escalas, te ves obligado a alejarte cada vez más de ese estándar.

Cada proveedor que ofrece tres ofertas verticales es excelente (si desea ascender verticalmente con ellos). Pero, ¿qué sucede si desea cambiar de nube o agregar otra nube como parte de una nueva estrategia de múltiples nubes inspirada (o incluso obligatoria) por Ofcom?

Por ejemplo, ¿cómo se pasa del Google de gama media al Amazon de gama baja? Hablamos mucho de escalar, pero seguramente uno de los principales puntos de venta de la nube es que puedes bajar tan fácilmente como subir. En realidad, es casi imposible moverse a través de esta matriz, ya que no existe una API consistente que funcione en todos estos productos.

Mostraré esto con un ejemplo resuelto. Digamos que desarrollas en el nivel RDS en Amazon y decides que para la próxima iteración irás a Google AlloyDB en el medio. Usted se ve obstaculizado por el bloqueo en el nivel RDS y también tiene que migrar a través de las nubes, por lo que terminará reescribiendo y administrando mucha complejidad. Cada vez que hay una migración, hay una penalización temporal y económica.

Esta es la razón por la que, según los acuerdos actuales del mercado de la nube, no podemos tener cosas agradables como la multinube. No se puede tener una combinación de Aurora local y en la nube. No puedes tener múltiples nubes con RDS; solo puede hacer esto en el entorno de nube del proveedor. Y si desea ampliar o reducir, debe pasar por un proceso para cambiarlo.

Agregue los descuentos en gastos y será más fácil seguir con el mismo proveedor de nube para casi todo... y antes de que se dé cuenta, estará estancado para siempre. Y la ventana rota nunca se arregla.

La buena noticia es que existen varias bases de datos de código abierto basadas en Postgres que utilizan API comunes, lo que le brinda portabilidad y acceso a las excelentes funciones de la nube que desea explotar.

Si sigue este camino, en lugar de intentar navegar por el complejo laberinto de las bases de datos hiperescaladoras, puede mantener abiertas sus opciones cuando se trata de bases de datos en la nube y evitar algunas de las trampas de la nube que los proveedores nos presentan.

En pocas palabras: Pasarán al menos 18 meses (si es que alguna vez lo hacen) hasta que la CMA pueda intervenir en el mercado de la nube del Reino Unido y presionar para que la nube múltiple sea la norma, por lo que, debido a la forma en que está organizado actualmente el mercado de la nube, es necesario hacer opciones de bases de datos que le ahorrarán dolores y dinero en el futuro. Considerar las opciones de Postgres de código abierto le brindará muchas de las ventajas de la nube múltiple.

Aún mejor, si empiezas a pensar en esto ahora, puedes evitar cualquier movimiento de pánico como resultado de una posible futura regulación de múltiples nubes que Ofcom pueda imponer.

¿Sabes que? Me siento tan inspirado que hoy es el día en que finalmente arreglarán esa ventana.