Posts Tagged ‘Weblogic’

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.

h1

Comparación BEA Weblogic 8.1 vs Sun Java System Application Server 8.2: Desempeño y Costos

01/13/2007

Wizdoc [Icon By Buuf]

 Tips & Tricks

Nota: Originalmente este documento forma parte de una presentación realizada a un cliente para sacarlo de dudas entre los ROIs y desempeños del Weblogic vs. el Sun App Server.

1. Desempeño

Consideraciones:

  • La aplicación utilizada para la prueba es la misma en ambos casos; lo único que cambió fueron los descriptores de despliegue. Esto implica que dicha aplicación era portable y se apegaba al estándar J2EE y requiriendo un esfuerzo de 60 hrs/hombre para su migración e instalación.
  • La aplicación fué migrada mediante la herramienta de migración de Sun.
  • La aplicación es considerada de media criticidad, siendo usada por 500 usuarios concurrentes en horario pico y requiriendo disponibilidad de 8×5.

Prueba 1 (10 series de pruebas)

  • 200 Usuarios concurrentes.
  • Delay de 30 segundos / usuario.
  • 30 minutos de duración.

Nota: El servidor donde reside el WLS es la máquina pertenece al clúster productivo.

 

BEA Weblogic

Sun App Server

Hardware

SunFire-V240 {2 procesadores SPARC V9 @ 1503 MHz, RAM @ 2048 MB}

SunFire-V240 {2 procesadores Ultra-SPARC IIIi @ 1536 MHz, RAM @ 4096 MB}

Sistema Operativo

Solaris 5.9

Solaris 10

Middleware

  • AppSvr: BEA Weblogic 8.1 SP4
  • WebSvr: iPlanet 6.0 SP6
  • Cluster habilitado (2 instancias lógicas).
  • Balanceo de carga vía web server.
  • JVM: BEA WebLogic JRockit(TM) 1.4.2_05
  • Tunning en servidor; no disponible para su revisión.
  • AppSvr: Sun Java System Application Server 8.2
  • WebSvr: Sun ONE 6 SP4
  • Cluster habilitado (2 instancias lógicas)
  • Balanceo de carga vía web server.
  • JVM: J2SDK 5.0_06 32-bit
  • Tunning en aplicación.
Aplicación (Tunning)

Código cumple con estándar J2EE

Código cumple con estándar J2EE

Se agregó el siguiente código al descriptor de despliegue (sun-web.xml):

<jsp-config development="false" mappedfile="false" trimSpaces="true" suppressSmap="true" fork="false" classdebuginfo="false" genStrAsCharArray="true"/>

Resultados

 

Resultado

Tiempo Promedio de Respuesta

59,743.51 ms

Tiempo Mínimo

42,344.00 ms

Tiempo Máximo

109,770.00 ms

Desviación Estándar

18,344.92 ms
 

Resultado

Tiempo Promedio de Respuesta

5,035.92 ms

Tiempo Mínimo

3,294.00 ms

Tiempo Máximo

6,075.00 ms

Desviación Estándar

621.15 ms
Conclusión

El Sun Application Server es 11.86 veces más rápido que WLS usando configuraciones parecidas.

Prueba 2 (5 series de pruebas)

  • 500 Usuarios concurrentes en rampa.
  • Delay de 15 segundos / usuario.
  • 5 minutos de duración.

Nota: Para el WLS, se implementó la suite contra el clúster productivo completo.

 

BEA Weblogic

Sun App Server

Hardware

2 SunFire-V240 {2 procesadores SPARC V9 @ 1503 MHz, RAM @ 2048 MB} con balanceo de cargas mediante un Sun Secure Application Switch N2000

SunFire-V240 {2 procesadores Ultra-SPARC IIIi @ 1536 MHz, RAM @ 4096 MB}

Sistema Operativo

Solaris 5.9

Solaris 10

Middleware

  • AppSvr: BEA Weblogic 8.1 SP4
  • WebSvr: iPlanet 6.0 SP6
  • Cluster habilitado (4 instancias lógicas por las 2 máquinas).
  • Balanceo de carga vía N2000 switch (hardware); para balanceo de instancias lógicas de una misma máquina se usa el web server.
  • JVM: BEA WebLogic JRockit(TM) 1.4.2_05
  • Tunning en servidor; no disponible para su revisión.
  • AppSvr: Sun Java System Application Server 8.2
  • WebSvr: Sun ONE 6 SP4
  • Cluster habilitado (2 instancias lógicas)
  • Balanceo de carga vía web server.
  • JVM: J2SDK 5.0_06 32-bit
  • Tunning en aplicación.
Aplicación (Tunning)

Código cumple con estándar J2EE

Código cumple con estándar J2EE

Se agregó el siguiente código al descriptor de despliegue (sun-web.xml):

<jsp-config development="false" mappedfile="false" trimSpaces="true" suppressSmap="true" fork="false" classdebuginfo="false" genStrAsCharArray="true"/>

Resultados

 

WLS

SunAppSvr

Tiempo Promedio de Respuesta

729.44 ms

1,115.44 ms

Tiempo Mínimo

202.00 ms

32.00 ms

Tiempo Máximo

2,323.00 ms

6,509.00 ms

Desviación Estándar

321.87 ms

875.98 ms
Conclusión

El WLS es 1.53 veces más rápido que el Sun App Svr cuando se encuentra en un clúster físico y el anterior no.



2. Costos, ROI[1]

    Consideraciones:

  • Las cifras presentadas son unidades de cotización redondeadas (equivalentes a varios miles de dólares).
  • Para el análisis se consideran 20 servidores dual-core (40 CPUs) para determinar los efectos de cotización CPU vs Socket.
  • De éstos, 5 son considerados como contenedores de aplicaciones de alta criticidad – requieren de una plataforma empresarial – y los otros 15 de criticidad media – sólo necesitan de web y application servers.
  • Generalmente las aplicaciones de alta criticidad – web services, web portals – requieren de una cola de mensajes (Message Queue) incluida en este análisis.
  • Todos los servidores requieren un web server para balanceo de cargas.
  • Cuando menos se requiere una instancia de un servidor lógico por CPU.
  • Se incluye el soporte técnico como parte de este análisis.
  • No se incluyen los servicios de instalación en este análisis.
  • Las Suites de Sun se cotizan por empleados por año, no importando el número de instancias instaladas; los application servers se cotizan por socket (o máquina, sin importar el número de CPUs que contiene), los web servers y message queues se cotizan por rango de sockets.
  • Las plataformas BEA se cotizan por CPU.

Opción

Año 1

Año 2

Año 3

Total (3 años)

ROI vs WLS

ROI vs WLP

5 AppSvrEE + 5 MsgQ + 5 Perpetual licenses for Sun Java Web Infrastructure Suite[2] (Standard, 3-year Support)

28

1

1

31

83

148

5 AppSvrEE + 5 MsgQ + 5 Perpetual licenses for Sun Java Web Infrastructure Suite[2] (Premium, 3-year Support)

29

2

2

32

82

147

5 AppSvrEE + 5 MsgQ + 5 Perpetual licenses for Sun Java Web Infrastructure Suite[2] (Standard Support)

27

3

3

34

81

146

5 AppSvrEE + 5 MsgQ + 5 Perpetual licenses for Sun Java Web Infrastructure Suite[2] (Premium Support)

27

4

4

35

79

144

5 AppSvrEE + 15 MsgQ + 5 AppSvr SE + 40 WebSvr (Standard Support)

48

4

0

52

62

128

5 AppSvrEE + 15 MsgQ + 5 AppSvr SE + 40 WebSvr (Premium Support)

49

4

0

53

61

126

5 AppSvrEE + 15 MsgQ + 5 AppSvr SE + 40 WebSvr (Standard, 3-year Support)

54

0

0

54

60

125

5 AppSvrEE + 15 MsgQ + 5 AppSvr SE + 40 WebSvr (Premium, 3-year Support)

56

0

0

56

58

123

Sun Java Application Platform Suite (Standard Support)[3][4]

28

28

28

83

31

96

Sun Java Application Platform Suite (Premium Support)[3][4]

33

33

33

100

14

79

40 BEA Weblogic Server 8.1 (1 per CPU)

112

1

1

114

0

65

5 BEA Weblogic Platform 8.1[5] + 35 Weblogic Server 8.1 (1 per CPU)

177

1

1

179

0

0

Conclusión

  • La opción más costosa de Sun tiene un margen de ahorro de 12.3% y 55.9% sobre las opciones de BEA (Weblogic Server o combinado con Weblogic Platform, respectivamente).
  • La opción menos costosa de Sun tiene un margen de ahorro de 72.8% y 82.7% sobre las opciones de BEA (Weblogic Server o combinado con Weblogic Platform, respectivamente).


Notas y pies de página

  1. Return Of Investment calculado en precios constantes a 3 años.
  2. El Sun Java Web Infrastructure Suite está compuesto por: Sun Java – Web Server, Proxy Server, Directory Server EE, Access Manager, Application Server SE, Studio Creator, Studio Enterprise.
  3. Los Sun Java Suites se cotizan por empleado por año; se utilizaron 2,000 empleados como comparativo.
  4. El Sun Java Application Platform Suite está compuesto por: Sun Java – Application Server EE, Web Server, Proxy Server, Portal Server, Message Queue, Directory Server, Access Manager, Service Registry, Studio Enterprise, Studio Creator.
  5. El BEA Weblogic Platform está compuesto por: Weblogic – Portal, Server, Workshop, Integration

Disclaimer

Los resultados mostrados se obtuvieron en base a las configuraciones de hardware y software mostradas; los resultados pueden variar en otras configuraciones. Los costos mostrados son reales, obtenidos de la última cotización disponible de los departamentos de marketing de ambas empresas.