Para resumir: la evolución de La Nube del consumidor ha ido de la mano y se ha vinculado a los servicios que los principales actores de la industria (Apple, Google, Microsoft y Amazon) ofrecen para quien deciden alojar sus cargas de trabajo en ellos, creando diferenciadores entre sí.
El Primer Capítulo de "Game of Services" fue sobre las plataformas de sistemas operativos móviles y que quedaría en pie. Ahora sabemos quienes ganaron: Apple y Google.
El Segundo Capítulo versaba sobre los servicios en sí mismos, lo que "Las Casas" tenían que ofrecer en términos de almacenamiento en La Nube, aplicaciones, mensajería, contenido (música/video/libros) y cómo estos continuarían evolucionando.
El Tercer Capítulo trata acerca de la contienda de las Interfaces de Programación para las Aplicaciones (API), hacia los servicios en La Nube pública de los consumidores. Google y Facebook en su mayor parte, siguen siendo Las Nubes para consumidores más importantes y el acceso a esas API, sigue siendo un objetivo en constante movimiento.
¿Cuál es el cuarto capítulo? La evolución de la empresa/nube comercial. Estamos hablando de "hiperscaladores" de La Nube pública como Amazon Web Services, Microsoft Azure, Google Cloud Platform y en menor medida, IBM Cloud.
Mientras que cuando combinamos La Nube Pública y la Privada, dividiendo así entre La Nube y las instalaciones locales, tenemos lo que se llama una Arquitectura de Nube Híbrida.
En su mayor parte, Las Nubes empresariales/comerciales han alojado servicios que podrían considerarse productos básicos o intercambiables. Las máquinas virtuales, el almacenamiento y las redes son servicios fundamentales de IaaS que en esencia son efectivamente los mismos entre los principales "hiperescaladores", así como entre los principales actores a los que se ha valorado igual, y que ahora van en carrera descendente.
Los "hiperscaladores" pueden intentar diferenciarse en rendimiento y algunas otras cosas, pero a un nivel fundamental, IaaS es IaaS y los Contenedores son Contenedores. Ya sea que lo ejecute en AWS, Azure o Google Cloud.
SaaS y PaaS es donde realmente ocurre la diferenciación en La Nube comercial. Para una empresa como Microsoft, sus SaaS como Office 365, PowerBI, Dynamics, SharePoint, Teams y Skype for Business son cosas que lo diferencian del resto de la industria. Estas son plataformas de aplicaciones que ya tienen una importante cuota de mercado con las instalaciones locales, por lo que mover a los clientes a versiones alojadas de estas basadas en La Nube no representa un gran reto. Podemos decir pues que SaaS es un negocio natural para la transición desde sus instalaciones heredadas.
Platform as a Service tiene todo tipo de servicios de aplicaciones terminadas, como bases de datos alojadas y sistemas de aprendizaje automático que se facturan de forma transaccional. Estos sistemas, cuando se combinan con PaaS basado en contenedores, permiten a los clientes empresariales construir sistemas altamente escalables que de otro modo serían de costo prohibitivo implementar en IaaS y se pueden aprovisionar a pedido.
Hasta ahora, muchos de estos sistemas se han construido en plataformas de código abierto como Hadoop o MongoDB. Pero ahora estamos empezando a ver a los proveedores de Nube de hiperescala, construir sus propios servicios back-end altamente escalables que son compatibles pero que no son lo mismo que sus homólogos de código abierto.
Un ejemplo de ello es DocumentDB, un servicio de base de datos alojado que es compatible con la API de MongoDB pero que no utiliza ningún código real de MongoDB, que Amazon lanzó esta semana en AWS.
Hoy en día muchos de estos servicios alojados usan APIs que son compatibles con sus contrapartes de código abierto. Por lo tanto, el código es portátil; no está atascado en ese proveedor de Nube.
Esto no es completamente diferente de, por ejemplo, el problema clásico de la transferencia de una base de datos basada en SQL a otra, siempre que estén codificadas según las especificaciones ANSI SQL. En ese nivel de compatibilidad, no importa si una base de datos comenzó en Oracle, luego puede moverla a IBM DB2 o incluso a Microsoft SQL Server.
Pero a medida que estos servicios se convierten en productos básicos, como lo hicieron IaaS para el cómputo y el almacenamiento. Los proveedores de La Nube agregarán sus propias mejoras de características que inevitablemente, se diferenciarán de las contrapartes de código abierto. Es bien sabido que a los desarrolladores de software les encanta aprovechar las nuevas funciones, especialmente si pueden aumentar el rendimiento, mejorar la escalabilidad y ahorrar dinero en costos transaccionales o computacionales.
Pero como hemos observado a menudo con los clientes, si se termina poniendo lógica empresarial en procedimientos almacenados y activadores en una plataforma de base de datos, en particular para aprovechar las optimizaciones de rendimiento, puede terminar teniendo verdaderos dolores de cabeza de compatibilidad.
En esos casos ya no es tan fácil pasar, por ejemplo, de Oracle a IBM DB2. Podría terminar costándonos una gran cantidad de tiempo de desarrollo de software (y dinero) para mover esa lógica de negocios fuera de la base de datos, de modo que pueda trasladarse de una plataforma a otra.
Podríamos ver muy bien que esto suceda con Nubes de "hiperescala". Claro que DocumentDB es compatible con MongoDB ahora. Pero, ¿quién puede decir que dentro de cinco años las API serán idénticas? Y DocumentDB es solo un servicio en La Nube. Una aplicación altamente escalable, nacida en La Nube podría estar diseñada para aprovechar una docena o más de servicios de Nube que son específicos de ese proveedor de Nube. Todo lo cual está en constante evolución y obteniendo nuevos conjuntos de características.
¿Cuántos servicios tiene, digamos, Microsoft Azure en su cartera? Dejamos de contar hace mucho tiempo. Claro, muchos de ellos utilizan estándares de código abierto, pero ¿cuántos de ellos no lo hacen? ¿Por cuánto tiempo estos servicios compatibles con Open Source permanecerán completamente de esa manera? A medida que AWS, Microsoft y Google Cloud e IBM se vuelven mucho más competitivos entre sí, es probable que no lo sean.
Ellos quieren que te quedes. Quieren que continúes comprando ciclos y transacciones. No quieren que te muevas de sus Nubes. Los sistemas SaaS como Office 365, Workday y Salesforce son, obviamente, de lo mas pegajosos.
Esto realmente no es diferente de tener plataformas de software locales, que son propietarias y utilizan código que no se puede trasladar fácilmente a otra plataforma. La diferencia es que, en lugar de otorgar licencias a estas plataformas, usted está alquilando tiempo en ellas, lo que prefieren los contadores en su organización, porque es un gasto operativo (OPEX) y no un gasto de capital (CAPEX).
Por lo tanto, ciertamente puede diseñar sistemas basados en La Nube que sean bastante autónomos y portátiles. Pero puede que no sea financieramente viable hacerlo a largo plazo. Los servicios en La Nube terminados serán más económicos de lo que puede alojar en máquinas virtuales de IaaS o incluso en contenedores. Con PaaS, la compensación será en última instancia el rendimiento, las características y el costo en comparación con la portabilidad.
¿Es inevitable el bloqueo de La Nube, a medida que dependemos más de los servicios en La Nube terminados? Usted tiene la respuesta y la última palabra.
