Estamos en un momento de incertidumbre tecnológica. Sufrimos de saturación de nombres y siglas. Quemamos cada vez más deprisa la terminología que generan las consultoras de prestigio y/o los departamentos de marketing. Los CEO piden a los CIO que ayuden a los COO a transformar digitalmente el negocio, los CFO dicen que no hay dinero, los CDO que no cumplimos con la legislación. Aun así, hay que tomar decisiones al respecto de cómo evolucionar los servicios TI que ofrecemos a los usuarios.
La primera y más fácil sería no decidir nada, que ya en sí es una decisión. Dejar que nos lleve el tiempo hasta que despertemos, y como hizo Thomas Cook, declaremos la bancarrota. La segunda alternativa es hacer algo, pero ¿qué? Esto de la transformación digital se nos va a atragantar si lo hacemos a lo loco, o si quien decide lanzarse por su cuenta no tiene en consideración que las aplicaciones hay que evolucionarlas, no basta con desplegarlas… el famoso Día 2. Entonces llega la amenaza: “Si TI no lidera la transformación digital del negocio, será el fin del departamento de TI”. Tod@s a correr: desarrollo de servicios web, aplicaciones móviles mejor, ¿nos lanzamos por la IA, ML, DL, Big Data?, ¿por blockchain?, ¿por IoT?, nubes de todos los colores, etc. Y toca seguir tomando decisiones, “¿somos Agile?; ¿DevOpps?”; “Ponme una de Scrum master”; “Esto de los microservicios tiene buena pinta, pero deberíamos ir a un ServerLess”; “¿Somos de las de base de datos relacionales de toda la vida, o tiramos por el NoSQL?”; “¿Contene-qué? Eso se monta sobre una máquina virtual, y se deja uno de historias”… Y así hasta llegar a la infraestructura porque para una buena transformación digital, hay que empezar comprando un gran ‘cacharro’.
En fin, un tropel de términos y conceptos que dificultan tomar decisiones con una visión a medio plazo, y más cuando vamos con prisas. Sabemos que la tecnología aporta al negocio nuevas maneras de hacer las cosas, o hacer cosas que antes no se podían hacer, pero tiene que hacerlo de forma sostenible en el tiempo, lo que fuerza a que lo que construimos sea: flexible, escalable, modificable y portable. Y es en este último punto donde el vendor lockin entra en juego, y más cuando buena parte de los desarrollos se hacen directamente en la nube, haciendo uso de herramientas fáciles de usar, pero escasamente transportables entre proveedores de servicios de nube.
La aplicación se queda recluida en el proveedor de turno y si quieres cambiar algo, hay que rehacerla
Las aplicaciones se quedan recluidas en el proveedor de turno y si quieres cambiar algo, toca rehacer de cero la aplicación. Y cuanto más subimos en la escala de la complejidad del servicio contratado, mayor es el vendor lockin. PaaS, más vendor lockin que IaaS. ServerLess más vendor lockin que PaaS. Aunque me dicen que estoy equivocado, que todo esto funciona mediante la integración con API y que cambiar un servicio por otro no es complicado, yo no me lo termino de creer. Todo era estándar en SQL hasta que dejó de serlo. Esto quizás no facilita el camino en el corto plazo porque nos fuerza a ser analíticos a la hora de decidir las herramientas, pero sí lo allana en el medio plazo.
Desde Prosol insistimos en utilizar tecnologías con capacidad para ser usadas en diferentes entornos tanto on premise como en las nubes públicas. Tecnologías que permiten cumplir con la flexibilidad, la escalabilidad, la mutabilidad y la portabilidad antes mencionadas, y evitan en la medida de lo posible el vendor lockin.
Desde Prosol insistimos en utilizar tecnologías con capacidad para ser usadas en diferentes entornos tanto on premise como en las nubes públicas. Tecnologías que permiten cumplir con la flexibilidad, la escalabilidad, la mutabilidad y la portabilidad requeridas, y evitan en la medida de lo posible el vendor lockin.
