La nube elástica de Oracle

26 May 2014 en Management

Datamation entrevistó a Diego Sanchez, Principal Sales Consultant de Oracle, quién nos habló de la forma en que Oracle aborda los requerimientos para la implementación de nubes públicas, privadas e híbridas. Diego nos aclaró algunos conceptos acerca de cloud computing y enfatizó en las capacidades multi-tenant de Oracle 12.

 

La estrategia cloud de Oracle

Lo primero y bastante interesante de Oracle, nos dice Diego Sánchez, es que sus elementos cloud funcionarán del mismo modo tanto la nube privada, como la nube pública a la que alguien se pueda subir. Y eso no se debe a que Oracle tenga diferentes productos o alguna técnica escondida para que eso sea así. Con los mismos productos que Oracle arma su nube privada, se puede trabajar en la nube on-demand.

La infraestructura especializada

A nivel de infraestructura, encontramos a los Engineered Systems (Systemas pre-configurados, diseñados y ajustados a un determinado fin), ya se trate del Data Appliance, que es un equipo muy pequeño, hasta lo que son los equipos como Exadata o Exalogic. “La idea es que éstos sean los pilares fundamentales porque allí está pensado y construido todo el plano de hardware de una manera armoniosa,” nos dice Diego. “Recordemos que uno puede construir su nube en el datacenter con los elementos que ya tiene y que no tiene que ser todo exclusivamente de Oracle. Lo que hicimos en Oracle fue armar los Engineered Systems con lo mejor de cada mundo. La gente de Oracle se preocupó del balanceo tanto del I/O, como de la memoria, como de la CPU. De esta manera no hay que preocuparse por la capa inferior de la infraestructura. Está todo planificado y todo junto,” prosigue diciendo.

“Este aspecto suelo explicarlo mostrando la mitad superior de una lámina en la que hay una camioneta Hammer de última generación. El gerente de IT está subido a ella, pero cuando acelera, la camioneta no va a más de 60 km por hora. Entonces descubro la mitad inferior de la lámina en la que se ve que la camioneta tiene ruedas de carreta. Lo mismo puede ocurrir con el centro de datos. Dentro de toda esa tecnología que fue creada por mucha gente que trabajó con su mejor saber y entender, puede que haya algún punto que no esté acorde a al resto de esa tecnología o que no esté bien planificado.”

Según Sánchez, “es necesario ocuparse no sólo de tener los mejores productos, sino de interconectarlos de la manera óptima. Y así y todo, yo puedo tener el mejor producto en cada plataforma, el mejor servidor, el mejor storage, etc, todos pensados para hacer lo mejor de sus respectivas tecnologías. Un storage está pensado para mover los datos con velocidad; tener los datos en los cachés y otras funciones. Pero el storage no sabe conversar con la base de datos y le da lo mismo una base de datos que un file server o lo que corresponda. Y es aquí donde radica uno de los factores diferenciadores de Oracle Exadata. Este servidor puede delegar parte de lo que es la resolución de las consultas, las búsquedas de datos e incluso índices que son armados por el storage. Los Engineered Systems son la mejor forma que tiene Oracle de brindar esa flexibilidad y escalabilidad que constituye lo que llamamos los “building blocks” o elementos fundamentales para poder armar una nube. Si bien no es condición indispensable o necesaria, es la mejor solución que Oracle brinda para una infraestructura óptima de cloud,” agrega.

Oracle está adherido a OpenStack. Esto quiere decir que interopera con plataformas de otros proveedores que utilicen este estándar, lo cual garantiza una amplia ineroperabilidad con productos y plataformas de otros proveedores.

La importancia de multi-tenant

“La idea es que uno pueda armar una nube privada o pública, con on-demand o lo que sea necesario. Se puede, por ejemplo, generar un esquema de Data Base as a Service on-demand, con una base de datos “multi-tenant” (multi-tenencia) usando Oracle Data Base 12, pero también lo puedo hacer con la versión 11. Pero hay una diferencia. Para poder entregar Data Base as a Service con la versión 11, tengo que valerme de la entrega de no sólo la base de datos. También necesito un servidor virtual, con lo cual voy a tener una nube menos eficiente,” comenta Diego Sánchez. “Multi-tenant (o multi tenencia) está orientado casi exclusivamente a lo que son entornos cloud. Es la herramienta cloud del lado de las bases de datos.”

El concepto de multi-tenant, nos explica Diego, “consiste en tener una base de datos que llamaremos la base contenedora en la que luego iré creando o destruyendo otras bases de datos “plugable” (conectadas a la contenedora o dependientes de ella). Y esto tiene una ventaja, ya que me permite que toda la configuración, digamos la parte riesgosa de una base de datos, se haga una sola vez. Si no tuviéramos esta facilidad, por ejemplo con una versión anterior, para crear una nueva base de datos para un cliente tendremos que desplegar alguna forma de máquina virtual y configurarle una base de datos, etc. En este caso, usando la base contenedora, todo lo que es la configuración ya estará preparado. Para crear una nueva base para un cliente, basta con indicarle que hace falta un clon y todo se realiza con una operación interna de la base de datos. No tengo que adjudicar nuevos recursos ni crear nada nuevo. Toda esa complejidad le queda a la capa de la base de datos y me da una agilidad mucho mayor para este tipo de tecnologías.”

La administración

“Otra gran ventaja de este esquema es el que llamamos “Manage Many as One,” o administre muchos como si fuese uno. Puedo administrar todo ese conjunto de elementos como una instancia única. Por ejemplo, si tengo una base de datos contenedora con cinco bases de datos de clientes, hago el backup sobre la base contenedora. Si el día de mañana tengo diez o veinte bases “plugables” de clientes, seguiré haciendo un backup sobre la base contenedora. Evitamos la complejidad de tener que configurar su infraestructura, su backup, etc., cada vez que entrego una nueva base de datos. Pero esto no nos quita la granularidad necesaria para volver sobre la base de datos plugable que se desee y al punto en el tiempo que sea necesario. Esto es una ventaja respecto al esquema anterior que teníamos en Esquema como Servicio. Yo puedo tener un esquema por cada uno de los clientes y de hecho ese servicio existe,” continúa diciendo el entrevistado.

“Con las bases de datos plugable, hago un solo backup, pero cuando se hace el recovery, puedo tratar a cada base por separado y puedo establecer el momento en el tiempo al cual repongo. También puedo hacer Snapshoots y utilizar la tecnología copy on write, que es la capacidad de duplicar el espacio que tengo adjudicado sin duplicarlo físicamente. Se toma una copia de los punteros. En un momento tengo la información de las dos partes y parece que tuviese una. Esta tecnología se puede usar incluso en una PC con Linux, a través del File System Btrfs que Oracle ha puesto a disposición de la comunidad,” agrega.

El problema de la proliferación de VMs

“El armado de VMs en la nube es un peligro,” comenta Diego. “Se crea una primer máquina virtual, luego una segunda y se la va mejorando. Así, cuando se llega a la quinta se puede tener algo que funciona muy bien. Es aquí donde mucha gente comienza a replicar máquinas virtuales y eso es un error porque todos los usuarios lo hacen crecientemente y la situación se descontrola. Cuando llega el momento de aplicar patches o cambios, nos encontramos que existen cientos de esos servidores virtuales. Y este es precisamente el problema que ataca la base multi-tenant. Yo sigo teniendo una misma base contenedora y aplico el patch o el cambio en un solo punto. No tengo que vérmelas con todas estas tecnologías que se están dispersando. El servidor donde se instala la base contenedora puede ser físico y también virtual. Hay gente que piensa que porque puede crear máquinas virtuales tiene menos que administrar. Pero en esos casos, tenemos la máquina virtual, el sistema operativo y la base de datos. Si tengo ocho máquinas, por ejemplo, tengo que mantener 24 elementos. En cambio, si utilizo el sistema multi-tenant, tengo un sistema operativo, una base de datos y ocho bases de datos plugable. En total, tengo que administrar diez elementos. Incluso, si quiero, tengo sólo dos, porque es el sistema operativo y la base de datos contenedora lo que tengo que administrar casi todo el tiempo,” prosigue Diego.

Seguridad y diseño de la nube

Refiriéndose a la seguridad de aplicaciones y de la nube en sí misma, Diego nos dice que “la parte de seguridad tiene dos patas. Por un lado la de la seguridad de bases de datos o las aplicaciones, con productos como Identity Management de Oracle. Pero también hay un tema de seguridad en lo que es la administración de la nube, donde hay que definir cuáles son los pools de recursos y quién tiene acceso a cada uno. Una nube privada no tiene porqué ser a nivel de todo el centro de datos, donde cualquiera que entra puede solicitar cualquier cosa, ya sea de producción, de test u otros. Aquí es donde es importante el diseño lógico de la nube, además de los productos de seguridad.”

El papel de WebLogic

WebLogic, una plataforma que Oracle adquirió con la compra de Bea Systems, juega un papel central en la creación de un entorno de interoperabilidad entre nubes. “WebLogic es una tecnología con la capacidad que permite prestar Middleware as a Service. Una parte importante de WebLogic es la capa de SOA (Service Oriented Architecture), donde encontramos conectores que son por ejemplo, los que me permiten crear una nube híbrida. Estos conectores actúan tanto hacia adentro en mis sistemas, como hacia los de una nube pública. En una presentación pasada mostramos algo que podemos llamar “Arquitectura de SOA Accidental.” Es el caso en el que, por ejemplo, se tiene una nube privada bien estructurada y ordenada y, desde otro departamento, a veces sin el consentimiento de IT, se contrata algún servicio SaaS o de la nube. Y es posible que otro departamento contrate otro y así. Luego, irán a ver a la gente de sistemas para que haga funcionar todo porque el sistema que contrataron en la nube pública, tiene los datos en la nube privada de la empresa. En algún lado habrá que hacer las interfaces y generar la seguridad necesaria. La capa de SOA de WebLogic es la que nos da el control de todo eso y es el canal para la operación y se pueden usar sus productos de seguridad. Es una especie de bus empresarial cuyos conectores van más allá de lo que es habitual y me permite también poder hacer cambios. Está basado en OpenStack.”

Recomendaciones para el planeamiento de la nube

Cuando le pedimos su opinión respecto a un plano que suele descuidarse, el del planeamiento, Diego nos responde que “los elementos de seguridad, acceso y recursos de las aplicaciones, son temas que hay que definir en el momento de la creación de una nube privada. El planeamiento es importante ya que hay que tener en cuenta cuáles son las características que impone el negocio de la empresa. Hay muchos casos en los que se han embarcado en la creación de nubes privadas y la falta de un plan bien definido ha sentenciado a los proyectos.”

Luego nos dice: “aquí hay muchas cosas. En primer lugar, es muy importante que todo el grupo de participantes esté bien alineado. Tenemos muchos casos en los que la tecnología fracasa porque algunos no saben qué es una nube ni que esperar de ella. También hay gente que piensa que va a implementar la tecnología de cloud y va a reducir los costos. Y los costos no se van a reducir por el hecho de pasar a cloud. Es más, si se quiere pasar a cloud todo lo que actualmente se tiene en funcionamiento, se va a estar frente a un problema ya que eso que se tiene no está pensado para funcionar en la nube simplemente porque no existía. Los costos se van a reducir porque se comprará menos, porque se consolidará y porque se será más ágil. Una de las ventajas de la nube será la de poder presupuestar con mayor precisión. Por ejemplo, en la mayoría de los proyectos el costo previsto de hardware suele ser mayor al esperado y eso no va a suceder en la nube porque se tiene tal agilidad que no es necesario prever qué se necesitará en dos, tres o cinco años.

Uno de los principios de cloud es la elasticidad. Me puedo agrandar o achicar según sea necesario. Lo importante es entender bien el papel de cloud en el negocio. No se puede pensar en que se va a adoptar cloud y que eso hará bajar los costos.

Es bueno hacer una lista de los problemas que hay para resolver en la empresa y ver cuáles será positivo resolver con cloud. Una vez que se entiende para qué es la tecnología, buscar puntos de partida. Por ejemplo, darle a los desarrolladores un ambiente de prueba en la nube en lugar de pensar en poner un ambiente de producción directamente,” comenta Sánchez.

Las aplicaciones legacy y la nube

¿Migrar, transformar, reescribir? ¿Qué conviene hacer con las aplicaciones cuándo se decide adoptar cloud computing? “Una de las cosas importantes es hacer una buena elección respecto a dónde se va a dar la batalla. Pensar en la modernización o actualización de todo lo que ya se está usando y que se adoptó a través de años, es muy difícil. Para tener una estrategia cloud viable, por ejemplo, se puede establecer que la nube será el estándar a partir de un determinado momento en lugar de ponerse a revolver todo lo que existe para intentar llevarlo a cloud. Una buena estrategia es decir “de aquí en más voy a tener cloud y de aquí en más voy a poder capitalizar todos los beneficios.” En cloud pasa lo mismo que con otras tecnologías, hay que establecer las razones y el retorno de la inversión para adoptar algo nuevo. Y en cloud el ROI es muy difícil de estimar,” nos dice Sánchez.

La perspectiva del mercado en Argentina

Para finalizar esta entrevista, le preguntamos a Diego Sánchez cuál es su visión del mercado local, considerando su rol en el proceso de preventa y la experiencia que recoge directamente de los usuarios en las empresas. “Respecto a la actitud que tiene la gente de IT respecto a cloud, cloud es un tema que está en boca de todo el mundo. Pero también veo que hay mucho desconocimiento de lo que es cloud y de cuándo se puede o conviene implementarlo. Hay mucha gente que piensa que poder virtualizar un servidor es tener cloud. También tenemos a gente que entiende bien de qué se trata pero tiene versiones de bases de datos anteriores, Oracle 8, por ejemplo y a la que no le resulta posible hacer un upgrade a 12.”

En cuanto a la actitud de la demanda, de los comentarios de Diego se desprende que en algunos casos hay que evitar el shock y acercarse con prudencia a los clientes. “Si yo vengo y te digo que tienes que luchar con tus proveedores, con tu cultura organizacional y otros factores y que debes conseguir que te homologuen una aplicación que está en una base Oracle 8, no vas a concretar nunca,” nos dice Diego. “Con un enfoque así, ese cliente se va a ir quedando siempre atrás en el tiempo. Es por eso que le sugerimos un enfoque muy progresivo. Uno de esos enfoques puede ser el de armar un laboratorio, comenzar a jugar con la tecnología y hacer que la gente la vea. Con algo que, como cloud, es difícil de demostrar y de explicar el retorno de la inversión; donde todo es muy intangible, mi recomendación sería comenzar mirando hacia adelante y comenzar a hacer experiencia. Comenzar a usar multi-tenant o hacer una pequeña nube privada aunque sea para pruebas.”

“A la mayoría de la gente de IT le gusta la idea pero los complica pensar lo que significaría mover todo lo que ya tiene. La idea de comenzar hacia adelante les cae mejor. Hay mucha gente que sabe y a la que le gusta la idea. Todavía falta explicar y mostrar en forma correcta los caminos a seguir.

En general la actitud de la gente de IT es muy receptiva pero todavía falta un poco de determinación,” concluye Diego Sánchez.