¡Eso no se puede virtualizar!

En el mundo de TI nos encontramos con esto constantemente: un proveedor nos dice que un sistema no se puede virtualizar. Las razones son numerosas. Desde el lado de TI, siempre nos sorprende que un proveedor haga una afirmación tan escandalosa; y a menudo nos sorprende igual de que un cliente (o un gerente) les crea. Los proveedores han trabajado duro durante años para perfeccionar este argumento de venta y creo que es importante diseccionarlo.

La causa raíz de los problemas es que los proveedores casi siempre buscan maneras de reducir sus propios costos a la vez que aumentan las ganancias que obtienen de los clientes. Esto impulsa gran parte de lo que de otro modo se consideraría un comportamiento extraño.

Algo que muchísimos proveedores intentan hacer es limitar los escenarios bajo los cuales su producto recibirá soporte. Al hacer esto, se preparan para simplemente no tener que brindar soporte: el soporte es caro y poco fiable. Esta es una estrategia común. En algunos casos, esto es tan agresivo que ni siquiera llega a existir un escenario de implementación aceptable y apto para producción.

Una manera muy común de lograr esto es no dar soporte a ningún sistema operativo que aún tenga soporte, dejando de facto obsoleto el propio software del proveedor (por ejemplo, hoy en día esto significaría dar soporte únicamente a Windows XP y versiones anteriores). Otro ejemplo es dar soporte solo a productos que no están licenciados para el caso de uso (un ejemplo sería exigir que un producto como Windows 10 se utilice como servidor). Y uno de los casos más comunes es prohibir la virtualización.

Estos escenarios colocan a los clientes en posiciones difíciles porque, por un lado, tienen las mejores prácticas del sector, las directrices estándar de implementación, las herramientas internas y las políticas que deben cumplir; y por otro lado tienen a proveedores que a menudo prohíben el diseño, la planificación y la gestión adecuados de los sistemas. Estas necesidades están en conflicto entre sí.

Por supuesto, nadie espera que cada proveedor dé soporte a todos los escenarios posibles. Hay que aplicar límites. Pero existe un abismo enorme entre dar soporte a sistemas razonables y bien implementados y exigir activamente implementaciones inaceptablemente malas. Esperamos que nuestros proveedores se comporten como socios de negocio y compartan un interés común en nuestro éxito o, como mínimo, en el éxito de su producto, y que no busquen directamente socavar ambas causas. Esperaríamos que, como mínimo absoluto, se brindara soporte de mejor esfuerzo para cualquier escenario de implementación razonable y que probablemente se ofreciera soporte garantizado para los escenarios diseñados correctamente conforme a las mejores prácticas.

¡Imagine un mundo en el que conducir respetando el límite de velocidad y llevando el cinturón de seguridad anulara la garantía de su automóvil y en el que solo recibiera soporte si condujera de forma temeraria y sin protección!

Hay que entender algunas cosas importantes sobre la virtualización. La primera es que la virtualización es una mejor práctica del sector desde hace mucho tiempo y se espera que se utilice en cualquier escenario de implementación de servicios en producción. La virtualización no es en absoluto nueva; incluso en el mercado de la pequeña empresa lleva más de una década en la categoría de mejores prácticas, y en el ámbito empresarial lleva muchas décadas. Hace tiempo que superamos el punto en el que ejecutar sistemas sin virtualizar se considera aceptable, y eso incluye las implementaciones heredadas que llevan mucho tiempo en funcionamiento.

Por supuesto, casi siempre hay excepciones poco frecuentes a cualquier regla. Algunos sistemas necesitan acceso a hardware muy especializado y puede que la virtualización no sea posible, aunque con el paso a través de hardware moderno esto es casi inaudito hoy en día. Y algunos sistemas de latencia ultrabaja no se pueden virtualizar, pero estos normalmente se limitan únicamente a los mayores bancos de inversión internacionales y a los fondos de cobertura más agresivos, e incluso la mayoría de esos casos de uso tradicionales han sido eliminados por las mejoras en la virtualización, lo que hace que incluso esas situaciones sean poco frecuentes. Pero la conclusión es que, si no puede virtualizar, debería lamentarlo, y sabrá claramente por qué es imposible en su situación. En todos los demás casos, su servidor tiene que ser virtual.

¿Acaso no es importante?

Si un proveedor no le permite seguir las mejores prácticas estándar para implementaciones saludables, ¿qué dice esto sobre la opinión que el propio proveedor tiene de su producto? Si estuviéramos hablando de cualquier otra implementación, de inmediato nos preguntaríamos por qué estamos implementando un sistema tan deficientemente si pensamos depender de él. Si nuestro proveedor nos obliga a comportarnos de esta manera, deberíamos reaccionar del mismo modo: si el proveedor no se toma en serio el producto en la misma medida en que nosotros nos tomamos el menor de nuestros servicios de TI, ¿por qué deberíamos hacerlo nosotros?

Esto es un «desajuste de impedancia», como decimos en los círculos de ingeniería, entre nuestras necesidades (sistemas de producción) y cómo el proveedor que fabrica ese sistema parece tratarlos (sistemas de afición o entretenimiento). Si necesitamos depender de este producto para nuestros negocios, necesitamos un proveedor que esté comprometido y que comprenda las necesidades del negocio: que tenga una mentalidad de producción. Si el producto no está orientado al negocio ni preparado para él, debemos ser conscientes de ello. Tenemos que preguntarnos por qué creemos que deberíamos usar en producción un servicio del que dependemos y para el que requerimos soporte, cuando no está destinado a usarse de esa manera.

¿Tiene soporte? ¿Se está probando?

Algo que a menudo se pasa por alto desde la perspectiva de los clientes es si existen o no los recursos de soporte necesarios para un producto. No es raro que el equipo que da soporte a un producto se reduzca, o incluso desaparezca, mientras la empresa sigue vendiendo el producto con la esperanza de exprimirlo todo lo posible y apostando por salir del paso ante un problema o simplemente devolver el dinero al cliente en caso de que el proveedor se vea atrapado en una situación en la que sencillamente no pueda dar soporte.

La mayoría de los contratos de software establecen que el daño máximo que se puede reclamar al proveedor es el costo del producto, o el importe gastado en adquirirlo. En un caso como este, el proveedor no corre ningún riesgo al ofrecer un producto al que no puede dar soporte, incluso cobrando una prima por el soporte. Si el cliente logra usar el producto, estupendo, cobran. Si el cliente no puede y el proveedor no puede darle soporte, solo pierden un dinero que de todos modos nunca habrían obtenido. El cliente asume todo el riesgo, no el proveedor.

Esto sugiere, por supuesto, que también hay pocas o ninguna prueba continua del producto, y esto debería ser motivo de preocupación adicional. El hecho de que el producto funcione no significa que vaya a seguir funcionando. Poner en marcha un producto sin soporte, o peor aún, imposible de mantener, significa que con el tiempo dependerá cada vez más de un producto con un nivel de soporte potencial probablemente decreciente, que empeora lentamente con el tiempo, justo cuando cabría esperar que la necesidad de soporte y la dependencia del software aumentaran.

Si se implementa un producto propietario en producción y se toma la decisión de renunciar a las implementaciones según las mejores prácticas para adaptarse a las exigencias de soporte, ¿cómo encaja esto en una matriz de decisión? ¿Debería esto implicar que no existe un soporte adecuado? Una vez más, como antes, esto implica un desajuste con nuestras necesidades.

 

¿Sigue en desarrollo?

Si las necesidades de implementación del software siguen prácticas antiguas y obsoletas, o requieren software o diseño obsoleto (o no razonablemente actual), entonces tenemos que cuestionar la probabilidad de que el producto se esté desarrollando actualmente. En algunos casos podemos determinar esto observando el ciclo de lanzamiento del software durante un tiempo, pero no en todos los casos. Existe un temor razonable de que el producto pueda estar muerto, sin ningún equipo de desarrollo que siga trabajando en él. El código puede ser simplemente antiguo, deuda técnica que se vende con la esperanza de sacar los últimos dólares de una base de código vieja y abandonada. Este proceso es en realidad mucho más común de lo que a menudo se cree.

Las casas de software más pequeñas a menudo logran desarrollar un paquete de software inicial, sacarlo al mercado y ponerlo a la venta, pero no pueden permitirse retener ni renovar su equipo de desarrollo tras el lanzamiento o lanzamientos iniciales. De hecho, este es un escenario muy común. Esto deja a los clientes con un producto que se espera que sea cada vez menos viable con el tiempo, con escenarios de implementación cada vez más arriesgados y datos cada vez más difíciles de extraer.

 

¿Cómo se le puede dar soporte si la plataforma no tiene soporte?

Una paradoja común de algunas situaciones más extremas es la del software que, para calificar como «con soporte», requiere otro software que está fuera de soporte o que nunca tuvo soporte para el caso de uso previsto. Ejemplos comunes de esto son exigir que un sistema servidor se ejecute sobre un sistema operativo de escritorio o exigir versiones de sistemas operativos, bases de datos u otros componentes que ya no tienen ningún soporte. Este último escenario es aterradoramente común. En una situación así, hay que preguntarse si puede llegar a existir alguna vez una implementación en la que el software pueda considerarse «con soporte». Si una parte de la pila está siempre fuera de soporte, entonces toda la pila carece de soporte. Siempre habría un motivo para denegar el soporte, sin importar nada. La misma razón por la que, por tanto, exigiríamos evitar las mejores prácticas descartaría igualmente la elección del propio software en primer lugar.

¿Faltan habilidades y conocimientos en el sector?

Quizá el problema al que nos enfrentamos con los problemas de soporte de software de esta naturaleza sea que el equipo o los equipos que crean el software simplemente no saben cómo se hace un buen software ni cómo se implementan buenos sistemas. Esta es una de las razones más razonables y válidas de lo que nos llevaría a esta situación. Pero, al igual que las otras razones hipotéticas, nos deja preocupados por la calidad del software y por la posibilidad de que el soporte esté realmente disponible. Si no podemos confiar en que el proveedor maneje correctamente las partes más visibles del sistema, ¿por qué acudiríamos a ellos como nuestros expertos para las partes que no podemos verificar?

El gran problema

El gran problema general del software que exige prácticas de implementación y mantenimiento cuestionables a cambio de desbloquear un soporte que de otro modo se retendría no es, como solemos suponer, una cuestión de la calidad general del software, sino de prácticas viables de soporte y desarrollo. El hecho de que estos problemas sugieran una preocupación significativa por el soporte a largo plazo debería hacernos cuestionar enérgicamente por qué elegimos estos paquetes en primer lugar y esperamos de ellos un soporte sólido cuando, desde el inicio, tenemos preocupaciones muy visibles y muy serias.

Existen, por supuesto, casos en los que no hay otros productos de software que cubran una necesidad, o ninguno de mayor viabilidad razonable. Esta situación debería ser extremadamente rara y, si existe, debería verse como una gran oportunidad de mercado para un proveedor que busque entrar en ese espacio en particular.

Desde una perspectiva de negocio, es imperativo que las mejores prácticas de la infraestructura técnica no se ignoren por completo a cambio de seguir ciega, o casi ciegamente, requisitos de proveedores que, en cualquier otra circunstancia, se considerarían temerarios o poco profesionales. ¿Por qué tan a menudo dejamos de exigir excelencia, de esta manera, a los productos fundamentales de los que dependen nuestros negocios? Pone en riesgo a nuestros negocios, no solo por la acción en sí, sino mucho más por los riesgos que implica la existencia de tal requisito.