Todos los inicios de año se llenan de predicciones que están llamadas a cumplirse, algo que es natural porque queremos estar preparados para lo que vendrá y aprovechar las tendencias en nuestro beneficio.

El problema surge cuando se generalizan tendencias malinterpretadas, ya sea por una imprecisión que provoca un efecto bola de nieve, ya sea porque se pasan por alto algunas consideraciones importantes. Es el caso de dos de las tendencias más repetidas: la importancia de transformarse en Cloud native, y el uso del Multicloud para evitar el vendor lock-in.

Las dos son tendencia, de eso no hay duda, y las ventajas de ser nativos del Cloud son muy numerosas, igual que los beneficios que aporta el Multicloud a la estrategia empresarial. En el primer caso, cuando desarrollamos aplicaciones nativas de la nube las diseñamos teniendo en mente la infraestructura y los servicios Cloud sobre los que va a ejecutarse.

En ese sentido, estamos diseñando una aplicación con una arquitectura especial compuesta por un conjunto de servicios pequeños, independientes y de bajo acoplamiento que colaboran para conseguir un determinado objetivo.

En el caso del Multicloud, una de las principales ventajas que se esgrimen cada vez que se intenta poner en valor el concepto es que pasaríamos a ser agnósticos en cuanto a proveedores de la Nube. Es decir, que, en teoría, dejaríamos de depender exclusivamente de un proveedor de la Nube en concreto.

Los matices clave sobre el nativo del Cloud y el agnóstico del Cloud

Ambos conceptos están muy bien y son interesantes, siempre que se interpreten bien. Es decir, en el caso del Multicloud, el problema surge si el beneficio percibido es que ser agnóstico de la nube se refiera a entornos que son capaces de operar con cualquier proveedor de nube pública con mínimas interrupciones para un negocio.

Este es un error de interpretación del concepto, porque, a pesar de que la idea parece convincente (se pueden aprovechar los mejores servicios de computación eligiendo el almacenamiento de dos o más proveedores, por ejemplo), la realidad es que las aplicaciones y los datos deben estar localizados en un proveedor de nube específico para que tengan un verdadero valor para la empresa.

Esto, inevitablemente, implica que debemos elegir un proveedor determinado para aprovechar realmente las capacidades que ofrece.

En el caso del nativo del Cloud, también es una idea interesante porque implica la refactorización de aplicaciones, o la creación de nuevas aplicaciones que aprovechen las características nativas o propietarias de plataformas de nube pública específicas.

Eso significa que esas aplicaciones se han codificado para aprovechar los servicios nativos proporcionados por un único proveedor de nube pública. Hablamos de la seguridad nativa, la gestión nativa o las bases de datos nativas, entre otras cosas. Es algo bueno, porque permite a los desarrolladores optimizar las aplicaciones y el almacenamiento de datos utilizando los servicios del proveedor de la nube en la que se ejecutan, así que proporcionan un mejor rendimiento, seguridad y fiabilidad.

El precio que hay que pagar es sencillo de entender: el «bloqueo» del proveedor de la nube pública. En el momento en que pretendamos cambiar de proveedor trasladando las aplicaciones y los datos a otro, será necesario acometer grandes cambios para que sean, a su vez, nativos de la nube en el nuevo proveedor. En otras palabras, ser cloud native no implica tener la capacidad de ser portables.

Teniendo estas puntualizaciones en cuenta, tanto decantarse por el Multicloud como diseñar aplicaciones nativas del Cloud aportan grandes beneficios a las empresas. Como en todo lo que se refiere a la tecnología, basta con tener muy claras las aplicaciones reales de cada solución.