En este artículo, exploraremos los principales riesgos de licenciamiento Oracle en AWS y cómo las empresas pueden mitigarlos.
Es un hecho que cada vez más organizaciones están migrando sus aplicaciones y bases de datos a la nube en busca de mayor flexibilidad y escalabilidad. Sin embargo, cuando se trata de licenciar software, especialmente productos como Oracle Database, esta transición puede traer consigo un conjunto único de desafíos y riesgos.
El licenciamiento Oracle en AWS, no solo está sujeto a determinadas particularidades en licenciamiento sino que presenta ciertos riesgos de incumplimiento que, por su potencial impacto económico, es conveniente tener siempre en cuenta.
A lo largo de 2023, los principales riesgos de licenciamiento Oracle en AWS que hemos detectado son los siguientes:
Riesgo #1 Unlimited License Agreement (ULA)
La política ‘Licensing Oracle Software in the Cloud Computing Environment’ añade que existe la posibilidad de que si bien se pueden desplegar en los entornos cloud autorizados de manera ilimitada los productos contenidos en el ULA (y por tanto pueden cubrirse también escenarios de duplicidad durante la migración), ello no implica necesariamente que dicho despliegue pueda tenerse en cuenta en caso de certificación.
Es imprescindible tener siempre en cuenta si durante la vigencia del ULA se prevé una migración a Cloud y negociar una métrica única que pueda intercambiarse entre entornos on-premise y cloud así como incluir los despliegues en cloud en la certificación.
Los efectos de no gestionar debidamente este punto pueden suponer riesgos financieros devastadores al quedar expuestos sin licencias despliegues enteros en cloud al terminar el ULA por no considerarse su cómputo a la hora de la certificación y a pesar de que el ULA, durante su vigencia, efectivamente permita desplegar ilimitadamente en cloud sus productos.
Riesgo #2 Flexibilidad y Escalabilidad
Algunos de los principales beneficios de la nube, pueden suponer un arma de doble filo de cara a propiciar posibles situaciones de incumplimiento de licencia por alterar el requerimiento de las mismas tanto en su edición como en el número:
- Incumplimientos por uso del producto indebido: Si bien en cloud, como en entorno on-premise, el riesgo más habitual es la instalación/uso accidental de productos no licenciados, lo cierto es el propio funcionamiento de cloud contribuye a que nos podamos encontrar usando por ejemplo la edición de base de datos indebida en la instancia equivocada. Por ejemplo:
- Uso de Standard Edition 2 en instancias con más de 8 vCPUs (en lugar de usar Standard Edition).
- Uso de Standard Edition en instancias con más de 16 vCPUS (en lugar de usar Enterprise Edition).
- Incumplimiento por uso de la cantidad indebida: En AWS el requerimiento de licencias Oracle necesarias puede verse incrementado:
- Por el incremento de vCPUs disponibles en la instancia: cualquier ajuste en este sentido tiene un impacto en el requerimiento de las licencias necesarias.
- Por la desactivación del multi-threading de los cores del procesador, que doble el número de licencias requeridas ya que en estos supuestos una v CPU equivale a una licencia Processor frente al escenario de multi-threading activo en el que 2 vCPUs van a equivaler a una licencia Processor.
Riesgo #3 Entorno Disaster Recovery
Es un principio general en licenciamiento Oracle que por defecto (siempre que no exista una excepción explícita que nos autorice a actuar de otra forma) hay que licenciar siempre todas las instancias (con independencia de que sean productivas o no).
En AWS, en caso de que el cliente opte por una solución de failover de alta disponibilidad como implementaciones Multi-AZ, es necesario tener en cuenta que en los modelos BYOL hay que disponer de licencias suficientes tanto para cubrir la instancia principal como la instancia de respaldo en Multi-AZ.
Riesgo #4 Limitaciones geográficas
La instalación/uso de las licencias Oracle pueden estar geográficamente limitados por la licencia a un país determinado o región y migrar a cloud no implica automáticamente la derogación de estas limitaciones.
Es por ello que bajo el modelo BYOL hay que asegurarse si existe alguna limitación de este tipo en el contrato de la licencia y si por las características de la modalidad cloud por la que optemos, se permite el cumplimiento de todos los términos de la licencia.
Riesgo #5 Finalidad de Uso del Software
La licencia también va a determinar la finalidad que se tiene que dar al uso del software (normalmente es para operaciones internas de negocio) y la migración a cloud no implica el cambio o terminación de esta limitación.
En el modelo AWS LI, por ejemplo, queda claro que el uso de la licencia de SE2 incluida en el servicio únicamente puede hacerse en el marco de las operaciones internas de negocio del cliente (y no para dar servicio a terceros por ejemplo: Como hemos visto más arriba, tenemos constancia de que Oracle ya ha ido a los tribunales por esta cuestión (ej. Caso Oracle v. Envisage).
Bajo el modelo BYOL hay que asegurarse de saber para qué uso está destinada la licencia según el contrato para asegurar el cumplimiento de los términos de la licencia: aquí también va a tener impacto, por ejemplo, cuál es la definición de cliente para saber qué se considera tercero y qué puede entrar en la categoría de “operación interna de negocio”.
Riesgo #6 Duplicidades en Migración
Durante la migración a AWS pueden existir supuestos de duplicidad de requerimiento de licencias tanto para cubrir el entorno on-premise como el cloud de manera simultánea. Es imprescindible evitar cualquier tipo de incumplimiento en este ámbito, fundamentalmente porque el impacto económico de ello puede ser demoledor. Para ello, puede tenerse en cuenta:
- Planificar una migración escalable con duplicidades controladas cuyo despliegue pueda ser cubierto con las licencias que tenemos disponibles de manera que evitemos cualquier tipo de “descubierto” y que podamos justificárselo a Oracle en caso de auditoría.
- En caso de que no se puedan cubrir los escenarios de duplicidad simultánea con las licencias que tenemos disponibles, podría optarse por otras soluciones alternativas como la adquisición de licencias temporales a un año.
Los efectos de no gestionar debidamente este punto pueden suponer riesgos financieros enormes al quedar temporalmente expuestos sin licenciar despliegues en cloud.
Conclusión
El licenciamiento Oracle en AWS presenta desafíos únicos y riesgos financieros considerables que cualquier empresa responsable debe abordar necesariamente.
Algunas estrategias clave para mitigar los riesgos de licenciamiento Oracle en AWS son:
- Antes de migrar a la nube, llevar a cabo una auto-auditoría con la misma metodología del fabricante para conocer la situación actual y contar con información confiable sobre la que poder tomar mejores decisiones.
- Considerar la posibilidad de contar con expertos independientes en licenciamiento Oracle con la suficiente experiencia para disponer de orientación y asesoramiento específico según las necesidades reales.
- Mantener un seguimiento constante del entorno de AWS y llevar a cabo análisis periódicos para asegurar el cumplimiento con las políticas de licenciamiento Oracle.
- Desarrollar una planificación estratégica de las necesidades para el licenciamiento de Oracle, anticipando requerimientos futuros y evitando gastos innecesarios.
En Evergreen Compliance ayudamos a nuestros clientes a tomar la mejor decisión y a disponer de alternativas. Póngase hoy mismo en contacto con nosotros, charlemos tranquilamente sobre cuáles son sus planes a futuro en el camino a cloud, y conviértase en nuestro próximo caso de éxito.
