En el pasado, la construcción de sistemas era un asunto bastante sencillo. Se determinaban las fuentes, los integradores las colocaban en un rack. Para las que no podían estar en el rack, unos cuantos extensores para llevar la señal al procesador. Luego unos cuantos extensores más para llevar las señales a nuestras pantallas y ¡voilá! El proyecto estaba hecho. Vale, no es tan sencillo, pero la idea general es correcta.
Hoy en día, no es tan sencillo. Las entradas físicas han dado paso a cada vez más entradas virtuales. A nuestros clientes ya no les importa dónde están las cosas, sólo necesitan tener acceso a ellas. Esto empezó con las cámaras de seguridad. Los sistemas solían requerir un dispositivo de hardware que tomara la alimentación de la página web/cámara de seguridad y la convirtiera en un HDMI para luego conectarla al sistema. Esto estaba bien cuando el desarrollo web era nuevo... pero con el tiempo, empezamos a necesitar más y más de estas fuentes. Y con el tiempo, en muchos casos eclipsaban el número de entradas físicas de un sistema. Por si fuera poco, el auge de las plataformas de software de análisis de datos y de los cuadros de mando hizo que se necesitaran cada vez más entradas virtuales. Al fin y al cabo, ¿por qué dedicar 12 ordenadores a diferentes cuadros de mando cuando sólo se trata de una página web que está en la red?
En general, el factor impulsor ha sido la flexibilidad. Flexibilidad en las entradas, flexibilidad en la ubicación/distancia y flexibilidad en los sistemas. En un sistema basado en entradas físicas, si de repente queremos añadir unas cuantas entradas a un sistema que ya estaba lleno, o incluso añadir una entrada en un puesto de operador que no estaba previamente cableado para ello (¡o quizás estaba situado en otro continente!)... entonces tenemos que añadir hardware, tirar nuevos cables, instalar cajas. Nada de esto es deseable. Pero era necesario en el pasado.
Hoy en día, con un sistema que tiene la capacidad de añadir entradas virtuales, sólo tenemos que cargar un cliente de software, hacer que el cliente lo gestione como lo haría con cualquier otro recurso de red y en cuestión de minutos, tenemos esa nueva "fuente" disponible como una entrada para el sistema. Sin hardware, sin cables que pasar, sin cajas que instalar. Es imposible minimizar el beneficio que esto supone a la hora de construir sistemas. No sólo es más fácil, sino que es más resistente, más seguro y, en cuanto a la escalabilidad, sus opciones son ilimitadas. Ya hemos mencionado que las fuentes pueden estar en cualquier lugar, pero esa no es la única gran ventaja. En el pasado, si teníamos un cuadro de mando que se alimentaba de un PC, necesitábamos también una máquina de reserva por si la principal fallaba... o necesitaba mantenimiento/parches/actualizaciones del sistema. Eso significaba más hardware, más espacio en el rack, etc. Si accedemos a una fuente virtualmente, nada de esto entra en juego. Tanto si se trata de abrir una aplicación para extraer ese panel de control directamente en el procesador y, por tanto, en la pared, como si se trata simplemente de recoger un flujo de vídeo H.264 para garantizar que tenemos la alimentación de la cámara, la ausencia de hardware significa menos puntos de fallo y, en caso de que la cámara de origen tenga un problema, el cambio a una cámara diferente es sólo cuestión de un script para saltar a un flujo IP diferente. La carga general de soportar fuentes virtuales en la red se aleja del integrador de sistemas y vuelve a recaer en el cliente final, ya no hay que culpar al hardware que falla o a las fuentes que no están disponibles en un momento dado.
Ahora bien, aunque parezca fácil, ha dado lugar a un tipo de planificación del sistema muy diferente. El seguimiento de todas estas aplicaciones y fuentes es un requisito. Y como la mayoría de las redes utilizan DHCP para la gestión de los dispositivos, las direcciones IP por sí solas no siempre pueden ayudarnos. En consecuencia, el sistema necesita rastrear los nombres de los dispositivos y las direcciones IP con mucho más detalle para garantizar que no perdemos cosas después de una ventana de mantenimiento de la red. Además, necesitamos rastrear las credenciales de acceso para entrar en estas entradas virtuales. El uso más profundo de las API para iniciar sesión y comunicarse con los dispositivos también puede ser fundamental. Y, por último, este cambio a la red ha supuesto un enorme aumento de las necesidades de ancho de banda. Los fabricantes y los integradores de sistemas no pueden diseñar estos sistemas por sí solos, sino que deben colaborar estrechamente con diferentes grupos del lado del cliente. Y, lo que es más importante, los fabricantes DEBEN tener experiencia en este campo y disponer de los recursos necesarios para ayudarle a trabajar con los clientes.
El otro gran problema es tener cuidado con las empresas que viven en soluciones "centradas en el sector audiovisual". Mientras que la industria AV es lo que somos, estas soluciones viven en el mundo de las TI. Los clientes no van a crear nuevas VLAN para superar las posturas de seguridad "extrañas" o el funcionamiento específico del fabricante. Ya sean métodos de autenticación o puertos utilizados. A nivel empresarial, las ÚNICAS soluciones aceptables son las que son de grado empresarial y siguen las prácticas existentes en la industria. La integración en las políticas, los flujos de trabajo y los sistemas de TI es un requisito porque les facilita la vida.
Hacer un mayor uso de los insumos virtuales dará un giro radical a la potencia de las soluciones que construya para sus clientes. Dedicar tiempo a trabajar con empresas como Jupiter Systems le facilitará la tarea y le ayudará a venderla a sus clientes. Jupiter ha estado a la vanguardia de esta evolución durante toda su vida. Tienen una experiencia y unos conocimientos en este ámbito que no tienen parangón. Y a medida que seguimos evolucionando como industria hacia más y más de lo virtual, ellos pueden ayudarle a presentar opciones a sus clientes que tal vez ni siquiera sabía que existían.
