Otro aspecto donde el "más por menos" es intensamente aprovechado es el de los entornos de desarrollo, test y preproducción. La capacidad de generar servidores para nuestros entornos de prueba (normalmente con licencias de desarrollador de los productos, o licenciamientos especiales para pruebas, como Technet de Microsoft), junto con la capacidad de eliminar la necesidad de hardware para los mismos, ha sido, durante muchos años, un sólido argumento para la implantación de la virtualización de servidores en las compañías. De hecho estos entornos fueron y siguen siendo los primeros candidatos a ser virtualizados, precisamente porque son donde primero se observan los ahorros de la virtualización y el aumento de eficiencia en el entorno IT. Si antes tenías entornos limitados de test (normalmente confinados a máquinas abandonadas en el almacén o a nuevos servidores de gama baja), ahora puedes disponer de un "hueco" en la infraestructura virtual para estos entornos. Puedes prescindir de ese servidor SQL u Oracle donde aplicabas todas las configuraciones de la compañía (con los problemas que conlleva al no ser el entorno de desarrollo igual al de producción... no olvidemos que no todos podemos consolidar nuestras bases de datos en un solo servidor), generando y creando escenarios idénticos al de producción (a veces una simple copia o clonado del mismo) para probar el código con el nuestro departamento de desarrollo mantiene actualizadas nuestras aplicaciones.
No sólo el departamento de desarrollo se beneficia de los entornos de test. Sistemas también... ¿o es que nadie ha dudado en aplicar un fix a un sistema operativo porque no puede probar antes el impacto que tiene? En los entornos físicos, aplicar un fix o un service pack requiere de una buena dosis de backup, cruzada de dedos y algo de suerte.... o tener otro servidor idéntico, configurarlo como el de producción, aplicar el fix y rezar porque los resultados sean extrapolables. La virtualización también ha cambiado esto. Normalmente el proceso que he descrito se resume en la creación de un sandbox aislado (donde la aplicación de un fix o configuración puede alterar un entorno entero... exchange sin ir más lejos), clonar los sistemas implicados, aplicar el fix en los mismos, probar y después decidir si lo aplicas a producción.
El divertido mundo de las actualizaciones de versiones también sacó su tajada. ¿quién no ha montado un entorno paralelo con la siguiente versión de lo que sea (oracle, exchange, directorio activo, windows server, etc) en una plataforma virtual? Probar nuestras bases de datos SQL 2005 en SQL2008 nunca fué tan fácil.... y tan libre de riesgos.
También la evaluación de productos, pruebas de concepto y entornos asociados podían encontrar un hueco en nuestra infraestructura. No todo el mundo dispone (o quiere disponer) de un entorno separado para estas actividades, ya sea porque su coste no lo justifica (el presupuesto de IT es como las opiniones, cada uno tiene una), ya sea porque la evaluación no lo justifica (si para probar 10 virtual desktops hemos de forzar a nuestro presupuesto el incluir hardware, igual nos echamos atrás).
Por último, no olvidemos a todos esos Nagios, Cactis, syslogs servers, Fileservers de IT, NAS virtuales, etc... que encontraban un hueco - sin coste - en nuestra infraestructura virtual.
Otro escenario es el de "VDI Excepcional". Me refiero a esos entornos donde se mantiene un pequeño pool de desktops con un propósito específico (usuarios móviles, factorías de software, etc) que se sirven con Terminal server, con la edición free de Xendesktop o con brokers de bajo coste como SeedsFoundation y que acomodamos en un "huequito" de nuestra plataforma sin más coste que las CAL de TS. Conozco más de un entorno así corriendo en un resource pool.
Si todo lo descrito, que antes no requería inversión o esta era muy limitada, ahora tiene coste, evidentemente hemos de plantearnos o el prescindir de estos entornos.... o llevarlos a plataformas en las que el coste no venga dado por la manera en que usamos los recursos virtuales.
Matrimonios por interés.
Eso es lo que define nuestra relación con un producto o tecnología. Más allá de las preferencias como tecnólogos, es el interés económico el que nos lleva a usar de manera más o menos continuada un producto o tecnología. Por un lado, el uso que hagamos del mismo fomentará la expansión y desarrollo de la misma (eso que llaman presión del mercado), y por otro, el trato que recibes del fabricante (características, soporte y precio), por otro. Mientras esta relación sea beneficiosa para ambos (el win-win de los anglosajones), la relación no solo no se estancará, sino que crecerá. El usuario estará contento (y consecuentemente hará publicidad del producto) y el fabricante también (tendrá beneficios y podrá dedicarse a mejorar el producto o a sacar nuevos). Si uno de los dos pierde (el cliente deja de estar conforme con soporte, características o precio o al fabricante no le sale rentable), esa relación se altera.
Veamos ejemplos:
Oracle: Hubo un tiempo en que una base de datos que se preciara corría en Oracle. Rendimiento, soporte y homogeneidad eran el argumento. Cuando comenzó a aparecer competencia (Y hablo de Microsoft) Oracle decidió mantener su política de precios (En aquella época, entre tiers, cpus, site licences y demás, necesitabas un Cray MP para calcular el precio de tu implementación Oracle). ¿resultado? La compentencia (Microsoft, MySQL, PostGRE e incluso DB2) aprovecharon el hueco (en base a precio o ausencia del mismo) para meterse en el datacenter. En la actualidad no es extraño (de hecho lo sorprendente es lo contrario) torpezarse un Oracle, un par de SQL Servers y algún MySQL en nuestros datacenters, cada uno dedicado a su entorno sin que por ello se hayan abierto los infiernos. Hoy Oracle tiene licenciamientos desde 450€ anuales y compite con Microsoft en entornos antes impensables.
Linux: ¡¡Cómo no citarlo!! Por un lado el espíritu bohemo rebelde de la comunidad, el crecimiento de los costes, las funcionalidades y la aparición de ofertas de soporte serias, han supuesto que parte de la carga de sistemas propietarios (Windows, Aix, etc) se desplacen al sistema operativo del pingüino. Las herramientas cruzadas (ODBCs, JDBCs, SOAP, etc) permiten que aplicaciones basadas no sólo en sistemas operativos diferentes, sino incluso en lenguajes diferentes, se interrelacionen sin excesivos problemas, manteniendo los costes limitados)
Citrix: Tras años de posición preponderante en el mercado del SBC (Server Based Computing) donde la competencia no llegaba o no existía (Terminal Services, Tarantella o similares), hoy tampoco resulta extraño vernos con entornos mixtos XenApp y RDS y alguna otra solución dando servicio a entornos diferentes dentro de la misma organización.
¿Y en los hypervisores?
Hubo un tiempo (no hace demasiado) en que el "moverte" de hypervisor podía suponer un impacto en la operatividad de los sistemas, básicamente porque las características de uno no estaban disponibles en otros. Así mismo, VMware destacaba por su madurez y rendimiento, lo que justificaba la inversión en licencias, formación y conocimiento. Eran tiempos donde el live migration fuera de ESX suponía un riesgo. Así mismo, las grandes diferencias en estabilidad de las VM, gestión del almacenamiento de las mismas y las herramientas de gestión decantaban claramente la balanza en pro de VMware, justificando la inversión (nada despreciable ni antes ni ahora) en licencias. En esos momentos, la incertidumbre debida a las características de Hyper-V y Xen justificaban la recomendación de ESX como única plataforma viable en entornos predecibles, ya sean producción o no.
Todo ha ido cambiando: Live Migration ya no asusta a nadie (Tanto en entornos Hyper-V como Xen), la estabilidad y compatibilidad ya casi no se cuestionan, el compromiso de los grandes con sus plataformas de hypervisor es innegable y cada vez más tenemos claro qué características necesitamos y cuales no.
vSphere 5, como ya comenté en un post anterior, nos obliga ahora a pagar con la Memoria Virtual Asignada (vRAM), organizada en pools de memoria licenciada de una misma manera, lo que hace que muchos de los entornos antes descritos ahora compitan en presupuesto con la intocable producción. Ya no es cuestión de meter más host, de scale-up (pocos nodos grandes) o scale-out (muchos nodos pequeños). Ya es cuestión de que tu densidad de host YA tiene precio. Y si no la tiene hoy porque eres el feliz licenciatario de ediciones Enterprise + de vSphere, lo tendrá. (mira hacia el futuro y a tu densidad de VM. Calcula tu tendencia. No mires SOLO cuánto te va a costar hoy ya que tienes 3/4 años para amortizar).
La solución pasa o por prescindir de ciertos entornos, o por ir a un entorno mixto vSphere y Xen/Hyper-V.
En este escenario, es posible plantearse que todos los roles no directamente involucrados en la producción, o que no tengan una clara relación entre tecnología y negocio (o dicho de otra manera, inversión y retorno de la misma vía facturación) se desplacen a entornos de coste contenible o que al menos no escalen por el uso sino por el crecimiento del hardware subyacente).
Conozco varios casos donde estos entornos ya existen, ya sera vSphere + XenServer, o vSphere + Hyper-V.... o los tres, donde vSphere lleva la producción, XenServer VDI y parte de preproducción y Hyper-V el desarrollo y test. La aparición y maduración de herramientas de gestión como System Center Virtual Machine Manager (que incluso permite integrar los ESX existentes) o XenCenter, hacen que el gestionar los entornos mixtos cada vez sea más fácil. Así mismo, otros fabricantes del ecosistema VMware ya disponen o están adaptando las herramientas de gestión de infraestructura virtual a entornos multi-hypervisor (y esto lo sé de muy buena tinta). También hay herramientas de terceros, como Acronis Backup & Recovery Virtual edition nos permiten una migración de ida y vuelta de VM's entre entornos... a un precio significativamente más reducido que el derivado del licenciamiento de VMware.
Resumen.
Somos tecnólogos, no compradores pasivos de tecnología. Y el mercado y los productos avanzan gracias a nosotros que los compramos e implementamos.
No hay comentarios:
Publicar un comentario