Conecta con nosotros

Entrevistas

Oracle: «Nuestra visión es llegar a las bases de datos que se auto reparen»

Hablamos con Elena Montoya, Business Development, Coretech and Big Data de Oracle sobre los nuevos desarrollos de la compañía: Autonomous Database y Autonomous Data Warehouse.

Elena Montoya

Business Development, Coretech and Big Data Director de Oracle

Publicado el

Este 2018 Oracle ha iniciado una enorme transformación de su portfolio de productos revolucionando el paradigma tradicional. Añadir IA y Machine Learning a las bases de datos es una decisión que, en palabras de Larry Ellison, CEO de Oracle, «es la más importante que nunca hemos tomado» y quieren aplicarlo en todas las capas del software. Aprovechando el anuncio de los primeros productos y servicios de bases de datos autónomas (con inteligencia) que ha hecho Oracle Ibérica, hemos charlado con Elena Montoya, Business Development, Coretech and Big Data Director de la compañía en España.

MCPRO: Oracle acaba de hacer varios anuncios sobre bases de datos inteligentes, en las que determinadas tareas se realizan sin que el usuario tenga que ordenarlas explícitamente. Para entender bien el cambio que esto significa, me gustaría saber ¿cómo eran las BD hasta ahora? ¿qué es lo que cambia con esta nueva oferta?

Elena Montoya: Lo que hemos anunciado en todo nuestro offering de PaaS (Product as a Service) es el software autónomo. Que pueda conseguir esa autonomía. De entre nuestra oferta de PaaS, la 1ª plataforma que sale como software autónomo es Autonomous Database, la capa original de Oracle, la capa central que es la de la base de datos.

Y luego el primer producto que hemos lanzado es una nueva versión de Autonomous Database porque para que los productos sean autónomos tienen que aprender, se les tiene que entrenar. Nosotros estamos entrenando ahora mismo a Autonomous Database en cargas de trabajo que tienen que ver con Data Warehouse. Por eso el «sabor» que sacamos es Autonomous Data Warehouse. A finales de este año tendremos Autonomous OLTP, para cargas de trabajo OLTP, y finalmente esas dos capas confluirán en Autonomous Database para cualquier tipo de necesidad.

A tu pregunta de cómo cambian, nosotros en base de datos, si has seguido un poco nuestra historia,hemos ido dotando a la base de datos de un montón de funcionalidad, digamos, automática. Es decir, teníamos Advisors (Asistentes de recomendación) que nos permitían ayudar al usuario a controlar la base de datos. El sistema le daba sugerencias sobre planes de ejecución, sobre estructuras que tenía que crear, sobre problemas que se iban a producir.

Esta mañana nos contaban en el Keynote que es como si un coche tiene distintos automatismos. Tienes el control de velocidad, el pitido que te da cuando vas a aparcar,… Lo que se hace ahora es dar un salto más utilizando todos esos automatismos que hemos ido creando a lo largo de muchos años. Porque esto es algo que no se hace de la noche a la mañana. A lo largo de las versiones 10, 11, 12 se han ido creando todos estos paquetes automáticos que, ahora, pasan a ser utilizados por la base de datos sin necesidad de pasar por el DBA (Administrador de Bases de Datos) tradicional. Es decir, hoy la base de datos toma el mando como si fuera el coche autónomo y, con todos esos mecanismos, conduce sola.

La idea que subyace detrás de todo es que quien vaya a hacer uso de la base de datos tenga que preocuparse sólo de cargar los datos.

Toda esta línea de investigación del software autónomo no es nueva para nosotros. Hace unos 10 años que está Exadata en el mercado, y ya consiguió que la gestión de la base de datos se automatizase. Que fuera menos rudimentaria la gestión de discos, de contenidos, etc. Nosotros siempre hemos tenido una máxima en Oracle: llevar los algoritmos al dato. Exadata hizo esto en la parte de hardware, creó una estructura que gestionaba la base de datos. Ahora mismo todos los automatismos y el Machine Learning aplicado dentro de la base de datos lo que proporcionan es beneficio a la base de datos y a los usuarios que la gobiernan.

Gracias a estos avances se pueden automatizar tareas que estaban consumiendo mucho tiempo, y que además son la base de la mayoría de los problemas que tienen los usuarios, que normalmente son errores humanos. Errores como volúmenes que se han quedado sin espacio o cambios en las programaciones que se han hecho. Es decir, un montón de cosas que, con la mejor voluntad, al final son responsabilidad de quienes administran la base de datos.

Eso es lo que se sustituye por un sistema autónomo, que va aprendiendo tanto de la infraestructura como del propio gobierno de la base de datos. Y pone así todos los automatismos que se han ido creando al servicio automático de las personas que están utilizando los datos. Esta es la visión de Autonomous Database.

Esto no se consigue desde la primera versión que acabamos de sacar, digamos que ahora hay algunos clientes que lo están probando, los sistemas se van entrenando. De ahí que se entrenen en esta carga de trabajo que es típicamente Data Warehouse y que vayan incorporando todo el conocimiento para llegar a las tres cosas que estamos diciendo con respecto a Autonomous Database:

  • Que la BD sea capaz de automanejarse
  • Que la BD sea capaz de responder a violaciones de la seguridad.
  • Que la BD sea capaz de autoescalarse.

MCPRO: Siempre que se habla de IA se menciona su aplicación a un dominio concreto a un campo, a un contexto concreto. En este caso, ¿las capacidades de aprendizaje están contenidas en una parte común a toda clase de escenarios o tenéis previsto que más adelante, aparte de la distinción entre Data Warehouse y OLTP, haya incluso más aplicaciones verticales en distintos sectores?

Elena Montoya: En el caso de Autonomous Database la IA, el aprendizaje, es común para cualquier tipo de uso que se haga del software. Es verdad también que vamos a aplicar Machine Learning en toda nuestra gama de tecnologías y productos, tanto PaaS como SaaS. Esto lo llevamos haciendo fundamentalmente en aplicaciones desde hace varios años ya. En la capa de aplicación, que sí que puede ser más específica en caso de, por ejemplo, Recursos Humanos, o Supply Chain, o ERP, Machine Learning pone esos algoritmos dentro de las aplicaciones y, obviamente, aprenden dentro de un contexto más específico. Quizás no tanto industrial, pero sí aplicado a una parte dentro del negocio. Esa capa está dentro de las aplicaciones en SaaS, y fue la primera en incorporar Machine Learning. Ahora mismo lo que hemos incorporado de Machine Learning en bases de datos es de propósito general. Cualquier usuario en cualquier negocio que quiera hacer uso de una bases de datos autónoma se va a beneficiar de todo lo que el sistema ha aprendido de usuarios como él y de usuarios de cualquier otro negocio.

MCPRO: ¿Podemos decir que esta incorporación de Machine Learning va ligada a entornos Cloud?

Elena Montoya: Es algo íntimamente ligado a Cloud. Aquí hay dos cosas que son importantes. Por un lado los propios automatismos que tiene la BD y, por otro, la plataforma sobre la que funciona. Hay mucho aprendizaje que tiene que ver son la infraestructura en la que está situada esa base de datos.

Sabes que Autonomous Data Warehouse lleva por detrás, como plataforma, Exadata. Entonces, Exadata para el cliente es transparente. Nos garantiza tener rendimiento pero también nos garantiza el proceso de aprendizaje desde el disco hasta el software. Es decir, en todas las capas.

El aprendizaje en infraestructura es también muy importante. Por eso, para que el proceso de IA sea completo tenemos que controlar tanto la parte de infraestructura como la de software. Y eso ahora sólo puede hacerse en el cloud.

Con el tiempo, y eso ya lo anunció Larry Ellison, se incorporará también a la oferta de Cloud híbrida de Oracle, que es lo que llamamos «Cloud at Customer». Aquí las máquinas son propiedad del cliente y se instalan en su centro de datos, pero el modelo de «Delivery» es Cloud.

Hay algunos clientes que por seguridad en su negocio no pueden permitirse ir al Cloud público 100%, pero sí se pueden beneficiar de los sistemas de auto-parcheado, de prevención. Por eso los automatismos están presentes en la base de datos y están incorporados, pero la Inteligencia Artificial es mucho más que eso. La gestión autónoma de una plataforma, el auto-parcheado y la auto-reparación que tiene que ver con todas las capas incluyendo las capas físicas. Por eso está en el cloud.

MCPRO: El auto-parcheado, esto es, todas estas soluciones en las que el software es «consciente» en cierta medida, ¿hasta qué punto es realmente autónomo? Es decir, ¿son un conjunto de reglas que evolucionan o es una capacidad del software para detectar que algo no está bien y que tiene que ser solucionado?

Elena Montoya: Hoy por hoy lo que hace el software autónomo, en esta primera versión para Data Warehouse, es la detección y recomendación. El proceso de parcheado lo hacen nuestros especialistas en los Data Centers. El software hoy no se auto-parchea por su cuenta. Lo que sí tiene son patrones para detectar riesgos, intrusos, comportamientos anómalos,… con una serie de técnicas que le permiten detectar cuándo se están produciendo cambios en la plataforma que requieren algún tipo de intervención o de parcheado.

Los parches hoy los aplica una persona. Nuestra visión es llegar a la auto-reparación del sistema de base de datos. Hoy esto todavía no es así.

Lo que sí se resuelve es que nosotros damos un SLA de 99,995% de que el sistema estará completamente online. Que el parcheado se hará completamente online. Ninguno de nuestros clientes que han probado el software como «Early Adopters», nunca han notado que el sistema haya sido parcheado con distintos niveles de prioridad.

Si son parches que afectan a la integridad del sistema se aplican inmediatamente. Si son parches de incorporación de nuevas funcionalidades entonces es una persona la que decide cuándo se van a aplicar. Los parches de seguridad en su mayoría se aplican automáticamente y lo que sí existe hoy es que los parches se instalan sin interrumpir el servicio.

Los parches de nueva funcionalidad todavía se aplican en momentos de baja demanda. Estamos en el primer paso. Nunca podría funciona el auto-parcheado si no consiguiéramos esa capacidad de hacerlo completamente online.

MCPRO: Entonces, en el caso de esas implantaciones de «Cloud at Customer», entiendo que son empresas con un interés especial en la seguridad de sus datos. Por definición, si el sistema aprende es porque hay un feedback, de las instalaciones hacia la nube de Oracle. Es decir, sale cierta información de esas nubes tan privadas. ¿Esos clientes no tienen un interés especial en saber qué sale hacia fuera de sus sistemas?

Elena Montoya: En el caso de Cloud at Customer, los datos están en las máquinas del cliente, pero la operación es completamente Cloud. Hay un túnel privado con Oracle bajo un modelo estrictamente de servicio. Esto está operado por la misma Oracle o por un tipo de partners con los que tenemos acuerdos específicos.

Salen algunas cosas, como pueden ser recomendaciones, pero lo que jamás pueden ver las personas de Oracle que están en los Data Centers son los datos sensitivos, la información que el cliente almacena en las bases de datos. Como en toda base de datos existen sistema de alerta, de alarmas, detecciones, es decir, elementos incorporados en el propio software que alimentan la consola de administración o que disparan alertas.

MCPRO: En el caso de los anuncios por llegar, has hablado de la solución OLTP y también está prevista una solución NoSQL para entornos de cadencias muy altas de datos de pequeño tamaño como IoT y otra solución basada en grafos ¿Qué nos puedes avanzar sobre estos futuros servicios y productos?

Elena Montoya: Esta mañana también se ha presentado Automonous Analytics Cloud Service, que es la parte de explotación de los datos. Nuestro core es la gestión de la información, y cada cliente la gestiona desde distintos puntos de vista. Hay gente que utiliza más los datos estructurados (Autonomous Data Warehouse o Database), también tenemos muchos clientes que usan bases de datos NoSQL, como bases de datos no estructuradas. Autonomous NoSQL va a seguir la misma filosofía, vamos a tener NoSQL en el Cloud, On Premises e Híbrida. Y en estas bases de datos hay muchas necesidades de seguridad, de parcheo, de gestión. Tienen a veces que parametrizarse, configurarse la cantidad de procesos paralelos que va a tener, los niveles de concurrencia, los niveles de consumo de CPU, los niveles de crecimiento para saber cuándo te estás quedando sin espacio o no.

Es decir, toda esta problemática es común tanto a una base de datos relacional como Enterprise Edition como a una base de datos NoSQL. Aunque las formas de almacenamiento puedan ser diferentes, los problemas de la gestión son muy comunes en la mayoría de los casos. El aprendizaje automático y el uso Machine Learning es una decisión crucial y puede aplicarse en todas las partes del software. Siempre puedes ir un paso más allá y convertir muchos de los mecanismos de administración, por buenos que sean, en autónomos.

«Incorporar Machine Learning es la decisión más importante que nunca hemos tomado»
Larry Ellison

Autonomous Graph es un servicio que representa la información de un modo muy distinto y que ahora está muy de moda. Tiene dos partes muy diferentes: la propia construcción del grafo, que necesita mucho proceso para hacerla, y luego la analítica que emplea algoritmos propios de inteligencia que los clientes pueden utilizar sobre el grafo. Esto es lo que va a tener el servicio de Autonomous Graph.

Hoy tenemos Graph dentro de Enterprise Edition y de nuestros componentes Big Data. Pero hay gente que sólo quiere cargar datos, que se construya el grafo y analizarlo. Y esto es lo que va a permitir Autonomous Graph Service. Todavía no tenemos fecha definida, pero será uno de los próximos lanzamientos. Muchos de nuestros próximos anuncios incorporarán la etiqueta de «Autonomous».

Otra de las características que vienen en breve dentro de Autonomous Database y de Autonomous Data Warehouse es toda la parte de «In Memory». Sabes que tenemos también «In Memory Option», que es una forma de trabajo Data Warehouse In-Memory con los datos columnares. Esto vendrá pronto dentro de Data Warehouse. Y por supuesto la Analítica, que es la parte de Graph.

La idea de Autonomous Graph Service es que se pueda construir el grafo y hacer la analítica sobre datos que cargue la gente en el servicio no necesariamente requiriendo nuestro Autonomous Database por debajo. Es un poco el símil de quién se beneficia de Autonomous Database o Data Warehouse. Si en una compañía tienes cualquier herramienta de analítica de datos, de tratamiento de datos, tienes un beneficio inmediato de esto.

Cosas tan sencillas y tan difíciles como que los clientes hagan backups y los hagan bien, eso está incluido en el servicio de Autonomous Data Warehouse. Por defecto los datos están cifrados, están seguros. Las comunicaciones están securizadas y los backups se hacen sin intervención del cliente. Esto es muy importante. Cualquier aplicación se beneficia inmediatamente de esto. En Graph sucederá un poco lo mismo. Autonomous Graph tendrá inteligencia de por sí, otra gente querrá cargar datos que no necesariamente vendrán de nuestro propio software. De entornos Big Data, de base de datos, para hacer Graph Analytics.

MCPRO: Por terminar, tiene todo el sentido que en los entornos Cloud la propia arquitectura ayude a autogestionarse, por oposición a los entornos On Premises. Acaba siendo redundante que tengas un panel que te diga «Te estás quedando sin memoria, haz esto». Y si no lo haces, tengo un problema. ¿No tiene mucha más lógica que se defina un «campo de juego», con unos límites, con unas alarmas, con unos thresholds y que el propio sistema, en función de una realidad que puede ser que haya unos picos de sobrecarga, se adapte a eso y aprenda y sepa cómo gestionarse? Evitar eso en otros campos ya está resuelto.

Elena Montoya: La verdad es que esa definición de límites, thresholds, alarmas, ya existe. Hay gente que gestiona muchas cosas. Mucha gente está constantemente añadiendo espacio. O gestionando concurrencia, gestionando picos. Hablando de costes, hasta ahora los sistemas se diseñaban para el pico máximo de utilización. El sistema Autonomous Database es autoelástico. Es capaz de saber dónde está respecto a los márgenes que le ha indicado el cliente. Cuáles son sus políticas.

Hoy también existe diferenciación de usuarios, se les puede asignar un perfil de consumo máximo o de consumo mínimo. Pero a partir de ahí el sistema es capaz de saber y de anticipar cuando estará más o menos utilizado. Y podrá dar de baja cores por los cuales el cliente paga. Si no tienes actividad por la noche, las CPUs se apagan y el cliente no paga por ellas.

O cuando estás llegando al umbral de la previsión de carga que sea capaz de aumentarlo. Son tareas que hoy sí que teníamos muchos mecanismos de aviso, recomendación y anticipación. Pero la orquestación de todas ellas es lo que conforma el paso de llegar a ser autónomo.

Por último, hay un aspecto que para nosotros es muy importante, como es la ciberseguridad. Securizar la base de datos desde el origen o el tema del backup. En el futuro también llegará el Disaster Recovery.

Todo eso hace que al final el foco de la preocupación de los clientes vaya más a qué datos tengo que meter aquí y cómo los voy a explotar que no a este tipo de tareas que ya estaban bastante automatizadas pero que no eran autónomas.

MCPRO: Muchas gracias por su tiempo. Ha sido un placer.

Lo más leído