La mayoría de las aplicaciones Java/JEE que se despliegan en un application server vienen en dos sabores:

• Unas, llamadas aplicaciones web, están compuestas principalmente por servlets, JSPs y/o algún framework que las integra. Éstas se encuentran empaquetadas en un archivo con terminación .WAR (Web ARchive) y en su mayoría utilizan alguna conexión a base de datos mediante pools de conexiones JDBC proporcionados por el application server. Las más elaboradas pueden llegar a utilizar servicios especializados, como colas de mensajes (JMS) para publicar web services asíncronos.

• Las otras, denominadas “aplicaciones empresariales” implementan todo lo anterior más tecnologías exóticas como Enterprise Java Beans (EJB) o conectores basados en el estándar JCA con sistemas externos (por ejemplo Jolt, de BEA). Dichas aplicaciones se empaquetan como archivos con terminación .EAR (Enterprise ARchive).

El problema

Mi cliente posee aproximadamente 200 aplicaciones en Java/JEE que pueden desglosarse de la siguiente manera:

• El 95% son aplicaciones que requieren un pool de conexiones JDBC; el restante 5% se conecta de manera directa (algo mal hecho, pero la mayoría de estas aplicaciones son viejas o están por ser reemplazadas por una versión más “estándar”).

• El 20% son aplicaciones empresariales (EAR) que utilizan alguna combinación de EJBs, JMS o conectores JCA. El otro 80% son aplicaciones web (WAR).

• De ese 80% de aplicaciones web, cerca del 20% (un 16% del total) requieren algún servicio especializado como JMS o JCA. Las demás son aplicaciones “planas”.

Este desgloce nos permite diferenciar las aplicaciones en dos grupos: aquellas que necesitan servicios básicos de JDBC (64%) y aquellas que necesitan servicios más sofisticados como JMS y EJBs (36%).

El problema se da cuando TODAS estas aplicaciones están montadas sobre un application server comercial (en este caso, Weblogic) pues si consideramos los siguientes precios de licenciamiento y soporte:

• Costo de una licencia de Weblogic por CPU: 0.75 x US$25,000 = US$18,750

• Costo del soporte y de una licencia de Weblogic por un año: 0.20 x US$18,750 = US$3,750

Y eso lo multiplicamos por el número total de procesadores donde corren las aplicaciones (unos 268 CPUs en alrededor de 50 servidores):

• Costo de licenciamiento = 268 CPUs x US$18,750 = US$5,025,000

• Costo anual del soporte = 268 CPUs x US$3,750 = US$1,005,000

Esto significa que por cada WAR o EAR desplegado en un application server, estamos quemándonos poco más de US$25,000 en licencias y unos US$5,000 en su soporte anual.

Sin embargo, esto no tiene por qué ser así.

Servlet containers y EJB containers

Así como los diferentes tipos de aplicaciones Java/JEE, existen diferentes tipos de servidores de aplicaciones. Unos, denominados servlet containers, permiten desplegar aplicaciones que contienen servlets y JSPs; algunos más especializados ofrecen servicios adicionales como JDBC, correo y JMS. Es decir, estos servidores sólo permiten desplegar WARs y los ejemplos más conocidos de su tipo son Tomcat, Resin o el Sun Web Server.

Por otro lado, existen los EJB containers o servidores “empresariales” que permiten desplegar aplicaciones muy robustas que implementan EJBs, JCA adicionalmente a los JSPs, servlets, JDBC y JMS; estos servidores son generalmente utilizados para desplegar aplicaciones EAR y los principales proponentes de esta tecnología son Websphere, Weblogic, JBoss y Glassfish.

Entonces, mi cliente está tirando dinero a la basura si para desplegar un WAR debe comprar una licencia a BEA/Oracle; si el problema es utilizar un pool de conexiones a JDBC (el principal pretexto para usar Weblogic) puede utilizar un servlet container que soporte dicho servicio: el Web Server de Sun permite este tipo de funcionalidad; con un poco de ingenio es posible implementar el mismo servicio en Tomcat o Resin.

Con esta información, podemos presentar un comparativo entre lo que cuestan las licencias y su soporte anual contra el costo de una pequeña migración de los 128 WARs que sólo necesitan JDBC:

• Costo por migrar un WAR de Weblogic a un servlet container estándar: US$1,000 (un estimado exorbitante, pero síganme la corriente)

• Costo por el soporte de un servlet container: US$450 anuales (esto es por CPU).

Así entonces:

• Costo de migración = 128 aplicaciones x US$1,000 = US$128,000

• Número de CPUs = CPUs usados por las 128 aplicaciones que corresponden al 64% del total = 0.64 x 268 CPUs = 172 CPUs

Entonces, el costo anual del soporte para los WARs migrados sería de alrededor de 172 x US$450 = US$77,400; y modificando los valores de licenciamiento y soporte de las aplicaciones que no se pudieron migrar:

• 72 aplicaciones ocupando 96 CPUs = US$1,800,000 en licencias y US$360,000 en soporte

Gran total = US$360,000 (Soporte Weblogic) + US$128,000 (la migración) + US$80,000 (soporte WARs redondeado) = US$568,000

Entonces, el cliente se está ahorrando US$437,000 tan solo el primer año, y en los años sucesivos se estará ahorrando US$565,000 por cada año (es decir, ya no habrá costos de migración). Adicionalmente, cada licencia para desplegar un EAR o WAR ahora costará en promedio US$9,000 y su soporte unos US$2,175

Pic: WAR TCO

Gráficas comparando los costos de soporte durante 3 años. Al final de estos 3 años, de continuar con el esquema actual, el cliente habría gastado poco más de 4 millones de dólares en soporte. Usando una especialización de servidores, es posible ahorrar US$2,132,000 (poco más del 53% del costo original).

Conclusiones

Para desplegar WARs no es necesario adquirir un costoso application server pues con un servlet container puede bastar; dejemos las soluciones propietarias sólo para casos que realmente lo requieran* y si podemos generar un análisis de Costo Total de Propiedad (Total Cost of Ownership – TCO) demostrando los beneficios al optimizar recursos, podremos vender una migración al cliente ahorrándole casi el 50% de sus costos operativos y dándonos de paso una buena ganancia.

[*]. La adopción de opensource puede ser un tema bastante espinozo porque a muchos clientes les da frío debido a que “no tiene soporte”. Sin embargo, si podemos garantizar el soporte y mantenimiento de este tipo de productos (como parte de unos servicios profesionales), podremos echarnos al bolso hasta al cliente más anti-opensource.

Anuncios