h1

Por que un WAR no deberia costar US$25,000

03/13/2009

Wizdoc [Icon By Buuf]  Tips & Tricks.
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

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). (Click en imagen para ver en mayor tamaño)

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.

2 comentarios

  1. me parece un excelente ejercicio de análisis de Costo – Beneficio el que describes, pero creo que además del "tema espinozo" que es el empleo de productos opensource para aplicaciones empresariales y a decir de los clientes "de misión crítica", también mencionaste otra palabra a la cual también temen MIGRACIÓN.Históricamente una MIGRACIÓN es compleja, todo un dolor de cabeza, un nuevo esquema (para que moverle, así como esta funciona re bien) y todo una acumulación de malas experiencias que sólo alimentan el miedo de los gerentes y directores a la hora de la toma de decisiones y que sólo conlleva a que un plan como el que muestras simplemente sea la última de las prioridades; pero nunca es tarde para cambiar esa forma de pensar.


  2. En efecto, una migración le pega a la inercia que reza "si funciona no lo arregles". Un par de estrategias que pueden aplicarse son primero, convencer al cliente (y posiblemente a nuestros propios jefes) de que es necesario hacer un estudio de factibilidad aplicación por aplicación sin costo adicional al cliente para determinar si puede o no ser migrada. Con ello, aunque implica un pequeño costo hacia nosotros, nos evitamos la pena de un proyecto batido e imposible de terminar. Por otro lado, podemos realizar nuestra migración iniciando con las aplicaciones de poco uso o criticidad y dejando al final las más complejas o de ruta crítica, previa identificación mediante nuestro estudio de factibilidad. Adicionalmente, podemos utilizar herramientas que automaticen nuestro trabajo (por ejemplo, el Glassfish posee su propia herramienta de migración de WARs/EARs desde otros application servers: http://java.sun.com/j2ee/tools/migration/index.html) acelerando los tiempos y reduciendo posibles "errores de dedo". Finalmente, podemos manejar escenarios con un mejor caso donde podemos migrar todo y un peor caso donde sólo podremos migrar una pequeña parte de las aplicaciones. Con ello podremos aún vender la idea de una migración sin comprometernos a tareas imposibles y acabar como otro “ejemplo de por que es mejor dejar las cosas como están”.



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: