Hana triunfa, MaxDB sigue vivo

¿Qué significan los nuevos planes de SAP para los usuarios que siempre han confiado en las bases de datos de SAP? ¿Cómo deben alinear su propia estrategia informática con la de SAP?

Cada vez son más las voces que quieren convencer a los usuarios de que MaxDB es un modelo descatalogado. Curiosamente, cuando se aconseja cambiar de DB, a menudo no se menciona Hana, sino que se recomienda ASE como el objetivo de migración supuestamente obvio.

Pero el hecho es: ASE no es una alternativa real a MaxDB, y MaxDB seguirá siendo un DBMS fiable y utilizable durante años.

Finales de los 80: SQL deja SAP a los demás

Cuando se creó R/3, a finales de los años 80, la estrategia de SAP en materia de bases de datos seguía siendo clara y sencilla. En aquel momento, SAP no era explícitamente un fabricante de bases de datos, sino que, como proveedor de ERP, confiaba en los sistemas de gestión de bases de datos SQL ya establecidos.

Al principio sólo se trataba de Oracle e Informix, y más tarde también de IBM DB2 y Microsoft SQL Server.

El hecho de que Oracle ya se hubiera introducido en el mercado con Financials a finales de los años 80, compitiendo así con SAP en el ámbito de las aplicaciones, se descartó en un principio como una "coopetición" habitual en el mercado.

Sin embargo, con el paso de los años, SAP se convirtió en el mayor distribuidor de valor añadido de Oracle, y transfería anualmente al competidor una cantidad millonaria considerable. Un dilema que llevó a SAP a cambiar su estrategia de abstinencia de bases de datos.

Los 90: la base de datos de SAP

Con ADABAS D de Software AG, SAP introdujo otra base de datos en la empresa a principios de 1992. Tras la certificación R/3 en 1994, se posicionó inicialmente como una alternativa de bajo coste a Oracle & Co.

Después de que SAP adquiriera los derechos del producto y gran parte del equipo de desarrollo de Software AG en 1997, SAP dejó de ser un mero revendedor de sistemas de gestión de bases de datos de terceros.

El primer DBMS propiedad de SAP se ofreció a partir de entonces con el nombre de SAP DB.

El objetivo obvio de SAP era avivar la competencia en el entorno de las bases de datos y romper el dominio de Oracle sobre la base de clientes de SAP con su propio producto.

Después de que las cifras de ventas no repuntaran notablemente, SAP lanzó la versión 7.3 de SAP DB bajo una licencia de código abierto en 2000.

2003: Renacimiento del código abierto

En 2003 se inició una cooperación comercial con MySQL AB. En el marco de la misma, el DBMS -a partir de la versión 7.5- se ofreció como "MaxDB by MySQL". Sin embargo, el soporte y el desarrollo continuaron en manos de SAP.

Esta cooperación llegó a su fin en 2007, y a partir de la versión 7.6 SAP MaxDB dejó de ofrecerse como producto de código abierto. Sin embargo, SAP decidió entonces ofrecer una alternativa para que MaxDB siguiera siendo utilizable fuera de las aplicaciones SAP: como "Community Edition" gratuita bajo una licencia comunitaria.

MaxDB sigue estando disponible hoy en día en forma de Community Edition gratuita, por lo que también puede utilizarse fuera del mundo SAP.

Dado que SAP no quería ser percibido como un fabricante de BD durante mucho tiempo, MaxDB existió en gran medida en la oscuridad. Sin embargo, esto apenas ha afectado a su éxito.

A pesar de la falta de impulso por parte de los departamentos de marketing y ventas de SAP, la base de datos se ha extendido definitivamente. Especialmente en las PYME de habla alemana, MaxDB goza de una aceptación ininterrumpida.

Razones importantes para ello son el favorable coste total de propiedad (TCO) y un funcionamiento silencioso y fiable. Los clientes de SAP utilizan al menos 27.000 servidores MaxDB.

Por cierto, esta cifra es varias veces superior a las instalaciones de SAP ASE en la base de clientes. MaxDB también se ha generalizado dentro de SAP, con más de 2.500 instalaciones. Según información privilegiada, alrededor de la mitad de los sistemas de producción internos de SAP se basan en este DBMS.

Novedades de SAP sobre MaxDB

SAP también desarrolló nuevas tecnologías sobre la base del núcleo MaxDB. A finales de los años noventa, se desarrolló SAP liveCache como una extensión basada en objetos del núcleo MaxDB para la gestión en memoria de objetos complejos (es decir, árboles y redes), dedicada a la solución logística SAP SCM/APO.

En la actualidad, todavía hay más de 5.000 instalaciones de SAP liveCache en el contexto de la gestión de la cadena de suministro y la planificación y optimización avanzadas.

MaxDB también sigue desempeñando un papel especial en relación con SAP Content Server: sin MaxDB, no hay externalización de contenidos sin formato a una base de datos.

No se dispone de cifras oficiales sobre este escenario de despliegue, pero cabe suponer varios miles o incluso más de diez mil instalaciones. Puede que SAP MaxDB no lleve una existencia en el candelero, pero esto no ha perjudicado la popularidad de los usuarios.

En los últimos años, la base instalada de SAP MaxDB incluso ha crecido significativamente: más del 50 por ciento solo desde principios de 2013. Una de las razones de ello se refleja también en el reciente estudio "Relational OLTP-Midmarket DBMS" realizado por los analistas de "Research in Action": MaxDB goza de un nivel de satisfacción del cliente constantemente alto.

Sybase trae consigo ASE e IQ

A finales de la primera década de 2000, SAP emprendió una adquisición multimillonaria de relevancia estratégica: el 30 de julio de 2010 se hizo con el fabricante californiano de bases de datos Sybase.

El objetivo declarado de SAP era "llegar a miles de millones de usuarios" a través de ella.

Aunque las soluciones de movilidad y el acceso a clientes móviles fueron los principales motivos de la adquisición, SAP también incorporó a la empresa los productos de bases de datos originales de Sybase.

Entre ellas se incluían el DBMS OLTP Sybase Adaptive Server Enterprise (ASE) y la base de datos de almacén de datos Sybase IQ, que presumía de un alto rendimiento OLAP gracias a su organización de almacenamiento orientada a columnas.

Pero la adquisición de la tecnología DBMS fue más bien un "by-catch" y no un elemento constitutivo de la estrategia -aún no anunciada oficialmente en aquel momento- de querer estar a la vanguardia del mercado de bases de datos.

Aún no está claro qué pretendía hacer exactamente SAP con los productos DBMS adquiridos. En cualquier caso, nunca fue un objetivo declarado sustituir MaxDB por Sybase ASE.

SAP reaparece como fabricante de BD

A mediados de la primera década del nuevo milenio, Hasso Plattner ya había conseguido que se aprobara la realización de su visión de una base de datos en memoria de alto rendimiento y orientada a columnas.

Así, SAP ya había comprado en secreto en 2005 el fabricante californiano de software Transact in Memory y, con él, la base de datos OLTP en memoria P*TIME.

En 2009, SAP se dispuso a crear una nueva base de datos SAP, como una mezcla tecnológica del DBMS de almacenamiento en filas P*Time, el motor de búsqueda basado en almacenamiento en columnas TREX desarrollado años antes y MaxDB como capa de persistencia.

Inicialmente, esta nueva base de datos SAP se denominaba únicamente New Database o New DB. Cuando se entregó por primera vez en noviembre de 2010, se denominó temporalmente High Performance Analytical Appliance.

Más tarde sólo se hizo referencia a ella por la forma abreviada de este nombre: SAP Hana 1.0.

El futuro pertenece a Hana

Desde la presentación de Hana, a más tardar, ha quedado claro: SAP está tomando la ofensiva como fabricante de bases de datos y ha declarado la guerra a Oracle, el principal competidor en este campo.

El objetivo declarado es liberar las aplicaciones SAP de los RDBMS tradicionales, ya sean propios o de la competencia. Por este motivo, SAP está invirtiendo principalmente en la moderna plataforma Hana y apenas en el desarrollo ulterior de sus bases de datos relacionales clásicas.

La consecuencia de esta inequívoca estrategia de Hana es clara: a largo plazo, no hay perspectiva para ninguna de las bases de datos SAP más antiguas, ni para MaxDB ni para los legados de Sybase ASE e IQ.

El futuro de la base de datos de SAP es Hana. Quienes quieran seguir obteniendo sus aplicaciones empresariales de SAP no podrán evitar Hana.

Con el anuncio de S/4 Hana, la suite empresarial de nueva generación, SAP SE ha subrayado una vez más su pretensión de hacer valer la soberanía de las bases de datos en su territorio.

MaxDB: Caducidad mínima 2025

Queda por saber qué presión está ejerciendo ahora la orientación de SAP hacia Hana en las empresas que actualmente utilizan MaxDB. Por el momento, ninguna en particular.

No fue hasta principios de 2015 cuando SAP prorrogó el "Mainstream Maintenance" cinco años más, hasta finales de 2025, garantizando así el mantenimiento durante al menos otros diez años.

Más a menudo, se afirma que se ha interrumpido el desarrollo de MaxDB.

Esto es obviamente erróneo. Por ejemplo, Database Studio, la herramienta de gestión autónoma de MaxDB, ha sido ampliada recientemente por SAP para incluir una herramienta de análisis gráfico.

Otra forma sencilla de aumentar el rendimiento de una instancia de MaxDB es utilizar discos de estado sólido basados en memoria flash.

El cambio de HDD a SSD no es, por supuesto, una evolución del DBMS en sentido estricto, pero ahora es posible porque SAP ha certificado recientemente el hardware correspondiente.

ASE sin ventajas económicas

A menudo oímos que una migración de MaxDB a ASE tiene sentido. Al fin y al cabo, cada "Hana Runtime Edition for Applications and SAP BW (REAB)" ya incluye una licencia para MaxDB y para ASE, por lo que la migración sería posible sin costes de licencia, al igual que el funcionamiento en paralelo de ambos DBMS.

Sin embargo, a la vista de la clara orientación de SAP hacia Hana, dicha migración no es una medida de prolongación de la vida útil: Es probable que el ciclo de vida de ASE termine al mismo tiempo que el de MaxDB.

Los defensores de la ASE suelen citar la compresión de datos como principal argumento a favor de la migración. Pero sigue siendo válido el adagio estadounidense: "No hay almuerzo gratis".

El ahorro de espacio en disco tiene un alto precio, ya que ASE requiere mucha más potencia de cálculo. La ventaja de compresión de ASE se paga en última instancia con inversiones en potencia de CPU.

El problema de las copias de seguridad de ASE

Desde el punto de vista de un defensor de MaxDB, el concepto de copia de seguridad de ASE es una de sus mayores debilidades.

ASE no puede vaciar el registro durante una copia de seguridad completa. Esto significa: si la copia de seguridad dura demasiado, los registros se desbordan y el sistema se paraliza.

En cambio, la función de copia de seguridad en línea de MaxDB no conoce tales restricciones. La recomendación de que las copias de seguridad de ASE se realicen en momentos de baja carga simplemente suena ingenua e ignora las realidades operativas.

Si es migración, entonces en Hana

Así que resulta que ASE suele estar sobrevalorado, mientras que las capacidades de MaxDB siguen estando notoriamente infravaloradas.

La migración de MaxDB a ASE sólo puede suponer una ganancia de funcionalidad en algunos casos excepcionales expuestos, por ejemplo, cuando la mayor compresión es un factor decisivo.

Por otro lado, los costes de licencia y mantenimiento son más elevados (si la licencia no se adquiere a precio de coste como parte de una Hana Runtime Edition), el esfuerzo de formación necesario y los riesgos considerables.

Los usuarios que utilizan MaxDB no sólo con ERP sino también en forma de liveCache o como parte de Content Server no podrían migrar completamente a ASE de todos modos.

Mientras SAP no migre sus sistemas internos basados en MaxDB a Hana en un frente amplio, los usuarios de MaxDB pueden dormir tranquilos. Los que utilizan MaxDB hoy en día deberían seguir con él hasta que consideren que ha llegado el momento de pasarse a Hana.

Sin embargo, una doble migración sería completamente absurda. Tomar los desvíos vía ASE para el objetivo de Hana sigue sin tener sentido.