Juego de Nubes: Se acerca un desenlace

Las cargas de trabajo "Nacido en La Nube" pudieron haber sido diseñadas para ser agnósticas de la plataforma, pero eso no significa que siempre será así ya que los "hiperescaladores" como Amazon Web Services y Microsoft Azure continúan agregando funcionalidades específicas y únicas a sus respectivos servicios.

En 2013 y 2014 discutíamos acerca del "Juego de servicios" y cómo, al igual que en la serie de fantasía épica de HBO "Juego de Tronos" que se ha desarrollado durante varias temporadas, han habido distintos capítulos en la evolución de La Nube del consumidor.

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.

Hasta ahora, las cargas de trabajo de La Nube empresarial se clasifican como IaaS (Infraestructura como servicio), PaaS (Plataforma como servicio), SaaS (Software como servicio) o una mezcla de los tres. Las cargas de trabajo que están diseñadas para ejecutarse en La Nube desde el primer día a menudo se denominan cargas de trabajo "Nacidas en La Nube", mientras que las cargas de trabajo cliente-servidor tradicionales (segunda plataforma) que se originan en los centros de datos locales que se trasladan a La Nube, son cargas de trabajo migradas a La Nube.

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 contenedores que se ejecutan en estándares de empaquetado de aplicaciones de código abierto como Docker, y que usan sistemas de orquestación como Kubernetes, son la próxima generación de cómputo y eso también se está convirtiendo en un producto básico, además de que han resultado ser más baratos y mucho más fáciles de escalar que las máquinas virtuales. Si tiene una aplicación basada en Docker en una Nube Pública, es bastante trivial portarla a otra Nube Pública con servicios de hosting de "contenedorización" similares.

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.

Estas cargas de trabajo ya son muy rígidas porque están vinculadas al mecanismo de autenticación de Active Directory de Microsoft, que es una tecnología fundamental para los entornos basados ​​en Microsoft. Estos clientes ya están bloqueados, pero no es como si estuvieran tratando de salir de estas plataformas de aplicaciones de todos modos, porque realmente no hay muchas alternativas buenas para ellos.

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.

Por ahora uno puede crear aplicaciones en AWS, utilizando IaaS y sistemas basados ​​en contenedor y respaldarlas en DocumentDB, para que en una fecha posterior devolverlas a las instalaciones locales o incluso a otra Nube de hiperescala que compita, como Microsoft Azure o Google. Esto es Plataforma en la Nube, pero este puede no ser el caso por tiempo indefinido.

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.

Esa es una de las razones por las que se están moviendo a PaaS, en "contenedorización" y microservicios en La Nube. En primer lugar, para crear verdaderas aplicaciones "Nacido en La Nube". Además pueden centrarse en ejecutar una plataforma de aplicaciones y su código en lugar de preocuparse por la infraestructura subyacente. IaaS es realmente solo un paso intermedio hacia La Nube para transformar las cargas de trabajo, ya que aún debe preocuparse por mantener al sistema operativo.

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.

A modo de ejemplo, nos viene a la mente un cliente bancario de IBM tenía 800 procedimientos almacenados y activadores en Oracle, lo que les habría costado millones eliminarlos y mover la lógica a middleware en J2EE. Aunque DB2 hubiera sido más barato que Oracle en términos de licencias, los costos de desarrollo de software hubieran sido mucho más caros. Terminaron simplemente apegándose a Oracle, pero cambiándolo a un sistema operativo y plataforma de hardware diferentes (IBM AIX y POWER) para obtener el rendimiento que necesitaban. Al final se vieron atados y encerrados a esa base de datos.

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.

Cuanto más se pierda el control de la infraestructura, mueva su enfoque en ejecutar estrictamente el código de su aplicación y tenga que depender de una plataforma de alojamiento, mayor será la posibilidad de que esa plataforma se vuelva pegajosa, que es precisamente lo que desean los proveedores de "hiperescala" como AWS y Microsoft.

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.

Bases de datos que aprenden

En 1952, el IBMista Arthur Samuel creó la primera implementación de un sistema de aprendizaje automático en América: jugar "Damas Inglesas".

Al principio, el sistema era derrotable. Samuel continuó mejorando las capacidades de aprendizaje de su programa de Damas y en parte entrenó el programa, haciéndolo jugar miles de juegos contra sí mismo. En 1961, los programas de Samuel jugaron el cuarto jugador de damas en América y ganaron. Esto demostró un nivel de juego aún no alcanzado por una computadora. La evolución del aprendizaje automático continuó y se amplió el rango de dominios aplicables.

En 1997, la computadora IBM Deep Blue logró rivalizar con los mejores prodigios del ajedrez del mundo, superando al Campeón Mundial de Ajedrez Gary Kasparov. ¡En 2011, la tecnología de IBM Watson compitió contra el legendario Jeopardy! los campeones Brad Rutter y Ken Jennings, ganando el primer premio de $ 1 millón de Dólares.

En la actualidad, las mejoras en los algoritmos de aprendizaje, combinados con una capacidad de cómputo más barata y más potente, así como también una gran cantidad de datos, hacen posible que el aprendizaje automático se convierta en la corriente principal. Los algoritmos computacionales que pueden realizar hazañas análogas que potencian el aprendizaje automático, ahora están automatizando lo mundano y proporcionando una visión profunda de lo complejo, sin la necesidad de una programación humana explícita de reglas y heurística.

Procesamiento SQL de última generación con tecnología de aprendizaje automático

El aprendizaje automático se está utilizando en el corazón de los métodos de próxima generación para autos autodirigidos, reconocimiento facial, detección de fraude y mucho más. En IBM, están aplicando métodos de aprendizaje automático al procesamiento de Lenguaje de Consultas Estructurado (SQL por sus siglas en inglés) para que las bases de datos puedan aprender literalmente de la experiencia.

SQL es el lenguaje estándar de la industria para acceder, consultar y manipular datos estructurados. Es utilizado por los mercados de valores, bancos de inversión, hospitales, empresas de logística, compañías de seguros, fondos de pensiones, fabricantes, pequeñas y grandes empresas. Es un lenguaje de datos que es a la vez rico en capacidades, elegante en su poder descriptivo y de uso ubicuo. Está en todas partes. Mejorar el procesamiento de SQL literalmente ayuda a una amplia sección de industrias.

SQL ofrece una oportunidad fascinante para la aplicación de aprendizaje electrónico o de máquina. En particular, para el procesamiento de consultas complejas, una consulta individual puede tener miles o incluso millones de posibles estrategias de ejecución, que producirán un resultado correcto. Si bien todas estas estrategias son correctas, algunas se realizarán mucho más rápido que otras.

El rol del compilador de SQL de la base de datos es definir la mejor estrategia de ejecución para usar para producir la respuesta a una consulta. Es muy parecido a conducir al trabajo. Hay muchos caminos que puede tomar, pero dependiendo del tráfico, la construcción, el clima y eventos imprevistos, algunas rutas pueden ser preferibles. La ruta óptima puede cambiar de un día a otro o de una hora a otra.

De la misma manera, la mejor estrategia para calcular una consulta SQL puede ser sutil de encontrar y puede cambiar fácilmente para una consulta dada, ya que los datos dentro de la base de datos cambian con el tiempo y las presiones de carga de trabajo varían.

Clásicamente, las bases de datos SQL, como Db2, utilizan un modelo sofisticado para evaluar y seleccionar la mejor estrategia de ejecución para cada consulta, basada en estadísticas de datos y modelado avanzado de CPU, RAM, Red y Entrada/Salida. Este método, utilizado ampliamente en la industria de bases de datos desde su introducción por IBM en 1979, realiza un gran trabajo.

Aun así, con la aplicación de métodos de aprendizaje automático, creemos que es posible que una base de datos aprenda de la experiencia y mejore continuamente. Esto nos llevará a niveles mejorados de estabilidad, consistencia y rendimiento nunca vistos en el dominio de décadas de investigación del SQL. Esto se logra aplicando métodos de redes neuronales al procesamiento de SQL en Db2. Las redes neuronales son un paradigma de aprendizaje automático, que emula la forma en que los científicos creen que nuestros cerebros aprenden con el tiempo.

Para todos los que trabajan en datos, mejorar la coherencia y el rendimiento del procesamiento SQL para que la base de datos encuentre mejores estrategias para calcular los resultados de las consultas, aporta beneficios emocionantes. El rendimiento será más constante y los administradores de bases de datos pasarán mucho menos tiempo ajustando el último porcentaje de rendimiento o depurando casos problemáticos.

¿Ya utiliza Usted una Base de Datos Relacional, con capacidades de aprendizaje?