Citrix y el problema de los mensajes lapidarios

Como bien sabéis llevo muchos años con la tecnología de Citrix desde OS2 y me las he visto de todos los colores y ámbitos y me he movido en todos los ámbitos desde programador en varios lenguajes a diseño de arquitecturas entre otras muchas cosas, sin perder nunca el foco en la tecnología que me atrapó hace ya muchos años.

He leído verdaderas barbaridades, desde que esto se acaba, que esto no me sirve, que el precio es caro, que hay alternativas… y siempre sucede normalmente en los mismos procesos, es decir Citrix anuncia un cambio de producto, un cambio de licenciamiento, un cambio en el precio… o cualquier otra cosa… y a parecen cosas surrealistas que carecen de cualquier tipo de lógica y coherencia que casualmente aprovechan este tipo de cambios (porqué el cliente siempre es reacio al cambio) que benefician finalmente al cliente, y terminan tomando una posición catastrófica, como si el mundo se acabara como si Citrix como fabricante desaparecerá de la faz de la tierra de forma inmediata.

Seamos serios, por favor.

Citrix como fabricante a día en Virtualización de Aplicaciones y del puesto de trabajo (llamadlo como queráis, Workspace, VDI….) es el Lider absoluto, tiene el mejor protocolo el cual está muy por encima en estos momentos del resto de fabricantes y dispone de una solución totalmente robusta estable y sin problemas.

Pero como parece que muchos no saben como funciona el protocolo o cual es mejor dicho su Origen, voy a explicarlo en unas líneas, ya que esto es siempre interesante y básico para poder entender como avanza todo y como un fabricante evoluciona de una forma realmente impresionante. Así que tomad nota de ello porqué seguro que será de vuestro interés.

Evidentemente no cabe decir que quien valora esto no hace falta que se le explique el valor que tiene que un sistema nunca falle y sea totalmente fiable y estable.

Vamos a retroceder un poco en el tiempo,

Recodamos ICA verdad?, si el protocolo de Citrix denominada Independent Management Architecture, actualmente denominado HDX el cual a sufrido interesantes y grandes mejoras.

ICA fue y es un protocolo de presentación, un protocolo desarrollado para ejecutarse en entornos basados en dispositivos de cliente, pequeños o grandes, permitiendo una gran flexibilidad además de poder se integrado con Thin Client, lo que llamaríamos clientes ligeros, entre los que además están ya incluidos los Zero Client.

En el servidor ICA separa la parte lógica de la aplicación del interface del usuario y protocolo del transporte, lo que permite que este pueda ser utilizado desde cualquier lugar y dispositivo, trabajando de una forma más eficiente con la ejecución del 100% de las aplicaciones en servidor pero la visualización en el puesto cliente. Esto ya lo realizan otros protocolos, si, como RDP de hecho cuando ICA empezó a implementarse con infraestructura Microsoft empezando con Windows Server 3.51, en su NT 4 con Servicios de Terminal Citrix realizó un acuerdo muy importante con Microsoft, lo que permitió a ambos disponer de un entorno multiusuario y multisesión para dar acceso a las aplicaciones que normalmente utilizaríamos en un puesto cliente.

El protocolo ICA envía pulsaciones de teclado, pulsaciones de ratón, actualizaciones de pantalla y audio a través de la red, las aplicaciones solo ocupan una pequeña fracción n la red y el ancho de banda se ve reducido de forma muy considerable, mientras otros protocolos mandan la pantalla completa o bloques completos, ICA solo manda lo que se actualiza, siendo muchísimo más efectivo en redes con alta latencia o accesos muy lentos.

Veamos un poco sobre el funcionamiento del paquete ICA (Arquitectura del protocolo)

Los paquetes del protocolo ICA consisten en un requerimiento de on-byte command, seguido a continuación de forma opción por los datos.

Este paquete dispone de una serie de prefijos de preambles, con la negociación y conexión en tiempo para poder manejar la transmisión de los paquetes. La naturaleza es de transmisión media (LAN y Asyncrona) y las opciones de definición del usuario (user-defined) semejante a la compresión, influenciando al total de la definición de los paquetes.

La composición del paquete sería este:

Existe una primera parte que es el preámbulo el cual está compuesto por:

• Frame Head
• Reliable
• Encryption
• Compression
• Command

Otra parte a continuación denominada “Command Data.” dónde contine los datos (data), así como una parte finak denominada Trailer – Frame Trailer.

Pero aprendamos un poco más sobre ello:

• Frame Head: Es una parte opcional de la cabecera del protocolo. Esta parte es el preámbulo y está orientado para Farming Stream-Oriented communications, este es asíncrono y TCP. Es utilizado en conjunción con el Rediable Protocol para proveer el error-free data en la transmisión.
• Reliable: Este es una parte opcional de la cabecera del protocolo. Este es el preámbulo para la detección de errores y recuperación para el mecanismo de transporte cuando no se provee de una garantía del suministro. Es un sistema reemplazable y no está estrictamente definido en la definición del protocolo ICA.
• Encryption:Este es una parte opcional de la cabecera del protocolo, La encriptación es un preámbulo que permite manejarlo y encriptar los paquetes o el paquete de ICA. Es un sistema reemplazable y no está estrictamente definido en la definición del protocolo ICA.
• Compression: Es una parte opcional de la cabecera del protocolo. El preámbulo de compresión permite la compresión de los datos. Es un sistema reemplazable y no está estrictamente definido en la definición del protocolo ICA.
• Command: es obligado que este contenga un mínimo de 1byte, y es un requerimiento. Este es el inicio para la base del paquete del protocolo ICA.
• Command Data: Es una parte opcional del los bytes de los datos asociados a un comando específico (command) La longitud de los datos depende del comando y puede tender a cero. Command Data contiene los canales de los paquetes del protocolo.
• Frame Trail: Es opcional en el trailer de la granja (farm) del protocolo. Este completa el paquete por stream orientado a las comunicaciones, es de tipo asíncrono y TCP. Trailed depende de la negociación del ptranporte y este ocurre durante la inicialización. La presencial de Command Data depende del Command Itself.

El protocolo al final funciona con canales virtuales, cada canal está enfocado a un tipo de servicio concreto, por ejemplo uno específico para impresión, otro para USB, otro para audio, etc…. hasta formar un subconjunto de elementos que hacen del protocolo el más potente, ágil y eficiente que actualmente está disponible en estos momentos.

Todo ello al final a ido evolucionando, evidentemente, pasando por PortICA y otros cambios y mejoras en el mismo, llamándose en estos momentos HDX, El protocolo Citrix HDX (High Definition Experience) funciona como una tecnología de entrega de alto rendimiento que optimiza la experiencia del usuario virtual, simulando una PC local incluso en redes lentas. Utiliza compresión avanzada, renderizado gráfico inteligente y canales virtuales para priorizar el audio/video en tiempo real, garantizando fluidez y capacidad de respuesta.

HDX Adaptive Transport garantiza el correcto funcionamiento de todas las funciones de las sesiones de usuario, incluyendo los gráficos, incluso cuando cambian las características de la red. Esta optimización de la visualización se logra mediante el protocolo Enlightened Data Transport (EDT) de Citrix, que utiliza UDP de forma inteligente y fiable para un rendimiento óptimo. Adaptative Transport permite que las sesiones alternen sin problemas entre EDT/UDP y TCP según sea necesario, sin necesidad de configuración. El resultado final es una sesión con alta capacidad de respuesta para una amplia gama de terminales de cliente.

Citrix utiliza los códecs H.264 y H.265 para ofrecer una calidad de imagen superior con un consumo mínimo de ancho de banda. La codificación con estos estándares puede realizarse durante toda la sesión, ideal para el movimiento a pantalla completa, o de forma selectiva en ciertas regiones con movimiento, según sea necesario. Se aprovecha el hardware de GPU del servidor y del cliente, siempre que esté disponible, para obtener imágenes impactantes que, además, ahorran recursos.

Y un largo etc.. de funcionalidades realmente muy interesantes, que podría explicar de forma detallada posiblemente en otro artículo de opinión personal o puede que en CTXDOM.COM.

Que tenemos que valorar,

No siempre todo se mide en costes, a veces la tranquilidad de tener cero incidencias o bajar de 100 incidencias mínimas diarias a 1 o 2 como mucho tiene mucho más valor que ese coste (no olvidemos que todos los fabricantes suben costes cada año, y que siempre existen opciones para estabilizar esos costes a varios años vista), la fiabilidad de una solución es más importante, recordemos que si tienes un producto que se convierte en lento, con problemas y que esas incidencias no bajan, al final se traduce en una solución no fiable.

No todo vale, no lo más económico es lo más adecuado y en muchos casos hay que saber ver más allá y saber que estas ofreciendo a tus clientes y el cliente tiene que saber exactamente que está adquiriendo.

El mensaje de “tengo el producto que sustituye a Citrix” no existe y no es cierto a día de hoy, ahora, el producto que tiene algún de las funcionalidades que Citrix tiene desde hace más de 35 años es mucho más probable. Al final cada fabricante elabora su solución enfocada a un tipo de mercado concreto, pero no quiere decir que esa solución sea la mejor o la más adecuada siempre.

Que sucede cuando alguien no explica a los clientes que ha comprado, pues no os voy a contar nada nuevo, sucede lo de siempre, cliente molesto y que se siente engañado, tenemos que cuidar a los clientes y no venderles “la moto”, el decirle a un cliente que un producto que es estable que tiene sustituto, sencillamente demuestra un alto desconocimiento de la tecnología de Citrix y no solo en esta, si no del mercado a nivel global, como funciona, como se optimiza, como se implementa (porque no es Next, Next, Next quien se piensa que es así, es que no tiene la menor idea de lo que está haciendo)… y un largo etc. de cosas que es necesario saber, entender y haber pensado con anterioridad en ellas.

Es por ello que hay que nutrirse de buenos profesionales y sobre todo comprometidos y con pasión por lo que hacen, hay otras soluciones que hay ciertos aspectos que hacen mejor que Citrix, no podemos evitar lo evidente, porqué no todo es perfecto y maravilloso. Pero no en Virtualización de Aplicaciones y en escritorios de trabajo, ahí Citrix como fabricante es muy superior y es el líder absoluto.

Citrix lleva más de 35 años en el mercado iniciando su andadura en 1989 y ampliando su ámbito en Networking y Cloud Computing, con más de 400.000 clientes de envergadura incluidas el 99% de las empresas del Fortune 100. así que tan mal no lo estará haciendo, ¿No creeis?.

Si que es cierto que la estrategia a cambiado y las reglas del juego también, pero al final el cliente se ve beneficiado por un fabricante que apuesta por una suite completa de soluciones que engloban varias e interesante funcionalidades, aportando un gran valor. Pero claro!! estas cosas hay que explicarlas al cliente y nutrirse de especialistas que sepan explicarlo y aportar valor a lo que el cliente adquiere, dándoles ideas y acompañándoles durante ese período.

Existen otros muchos que dicen… “saca Citrix y ponemos xxxxx, te lo migramos en una semana”.. cuando existen mensajes de este tipo, muchas veces me sorprendo y me entristece enormente sobre todo de la gran falta de conocimiento y sobre todo de capacidad técnica, gente que se hacen llamar a si mismos expertos, con lo que se observa una clara incapacidad de evaluar, falta de análisis entre otros…. a ver! cualquier tipo de cambio no se hace en dos días, ni en una semana, claro!! que si solo usas dos aplicaciones simples es fácil evidentemente, pero cualquier proceso de cambio, es necesario entender muchos aspectos tales como por ejemplo (y pongo solo unos pocos de ellos):

• Necesidad real del cliente (no suposiciones).
• Entender su modelo de negocio.
• Entender que es critico para el.
• Entender como trabaja y de que forma.
• La tecnología debe de adaptarse a el, no el a la tecnología (evidentemente siempre hay cambios)
• Ver que aplicaciones utilizan
• Ver compatibilidades
• Ver y entender su sistema de impresión
• Grupos de usuarios, permisos, accesos a la información
• Evitar que los usuarios tengan permisos administrativos
• Securización del entorno, aplicaciones y escritorios.
• Compatibilidad entre aplicaciones, ya que no siempre todo puede residir en un mismo sitio.
• Cantidad de imágenes a distribuir.
• Carga de servidores, dimensionar adecuadamente.
• Comunicaciones.
• Puntos de acceso.
• Storage, configuración adecuada, tipos de disco, cache.. adaptarlo y dejarlo fino.
• Optimización de aplicaciones.
• Optimización de escritorios de trabajo.
• Optimización del protocolo
• Perfiles de usuarios.
• Tipos de usuarios.. etc…

Y muchos otros conceptos, que solo aparecen en un Assesment bien hecho, una prueba de concepto correcta, análisis de carga, análisis de rendimiento, una documentación correcta y una implementación bien hecha, que no siempre es así, pero si no se hace luego sucede lo que sucede.

Personalmente a todos estos tan alarmistas les diría, está bien buscar posibilidades de negocio y tener alternativas, pero cuando se dicen ciertas cosas que no son ciertas demuestran poco conocimiento y eso termina generando desconfianza y sobre todo perjudicando al cliente.

Seamos serios y evitemos manipular a los clientes o enfocarlos hacia soluciones solo por el afán de vender, la honestidad tiene que ser la primera de nuestras opciones, el resto llega solo. Vender puede ser fácil, pero mantener al cliente es lo realmente complicado.

Recordad–> No todo vale.

Artículo también publicado en LinkedIn: https://www.linkedin.com/feed/update/urn:li:ugcPost:7425963182046724096/