Cómo funciona el cloud rendering para impresiones: la explicación técnica

Impresión en la nube El cloud rendering traslada el paso en el que un documento se convierte en datos específicos para una impresora desde el dispositivo del usuario o un servidor de impresión hacia un servicio en la nube. La aplicación del usuario produce un documento. El documento viaja a la nube. La nube selecciona el controlador correcto para la impresora de destino, renderiza el trabajo según las capacidades reales de esa impresora y envía los datos listos para imprimir a un Connector local, que los pasa a la impresora.

El terminal nunca contiene un controlador de impresora. Ese simple hecho es la base de todo lo que se explica en este artículo, y es la diferencia entre la impresión en la nube y la mera gestión de un servidor de impresión a través de un navegador.

¿Por qué importa dónde se realiza el renderizado?

El renderizado es el único paso que requiere conocer la impresora específica, así que dondequiera que se realice el renderizado es donde tiene que estar el controlador.

En un entorno tradicional, el renderizado ocurre en el terminal o en el servidor de impresión. Por tanto, el controlador tiene que estar en el terminal o en el servidor de impresión. Todo lo que a los equipos de TI les desagrada de las impresiones se deriva de eso: el despliegue de controladores, los conflictos entre controladores, las pruebas de controladores con cada actualización de Windows, el print spooler que carga el controlador como SYSTEM y el servidor de impresión que existe, en gran parte, para distribuir controladores.

Traslada el renderizado a la nube y el controlador se traslada con él. La biblioteca de controladores de impresora sigue existiendo; simplemente no está en ninguna máquina que poseas y que tengas que gestionar.

¿Cuáles son las fases del proceso de cloud rendering?

El cloud rendering se desarrolla en cinco fases: envío, identificación, renderizado, entrega y salida.

Fase 1: Envío

El usuario imprime desde Windows, ChromeOS, macOS, iOS, o Android. Lo que sale del dispositivo es el documento más los metadatos del trabajo (qué impresora, cuántas copias, dúplex, color). Aún no es un flujo de datos específico para la impresora, porque nada en el dispositivo sabe cómo crearlo.

Fase 2: Identificación

La plataforma en la nube identifica la impresora de destino y consulta sus capacidades: lenguaje de descripción de página, tamaños de papel, compatibilidad con dúplex, bandejas disponibles, opciones de acabado y gestión del color.

Fase 3: Renderizado

Este es el paso que importa. La plataforma selecciona el controlador correspondiente de su biblioteca en la nube y renderiza el trabajo para el dispositivo de destino. ezeep mantiene una biblioteca de más de 6.000 controladores específicos de fabricante para este fin. El resultado son datos que la impresora puede procesar directamente, respetando las capacidades reales del dispositivo en lugar de una aproximación al mínimo común denominador.

Fase 4: Entrega

El trabajo renderizado se entrega al ezeep Hub en la ubicación de la impresora. El Hub mantiene una conexión persistente solo de salida con la nube, por lo que extrae el trabajo en lugar de recibir una conexión entrante. No es necesario abrir nada en el firewall.

Fase 5: Salida

El Hub pasa los datos listos para imprimir a la impresora a través de la red local o por USB. La impresora los procesa inmediatamente, porque ya están en un formato que entiende. No se requiere ninguna capacidad en la nube, ningún cambio de firmware ni ninguna certificación Mopria en el propio dispositivo.

¿En qué se diferencia el cloud rendering de la impresión gestionada en la nube?

Esta distinción es en la que los compradores más se equivocan, y los proveedores no están motivados para aclararla.

Impresión gestionada en la nube significa que el servidor de impresión, o los controladores en el ordenador del usuario, siguen existiendo y tú los administras desde una consola web. El print spooler sigue funcionando. Los controladores siguen desplegándose en los terminales. La máquina Windows sigue necesitando parches. Lo que se movió a la nube fue la interfaz de gestión.

Impresión renderizada en la nube significa que el propio paso de renderizado ocurre en la nube, por lo que no hay servidor de impresión, ni controlador en el terminal, ni print spooler local en la ruta.

La prueba es una sola pregunta: ¿Sigue habiendo una máquina Windows ejecutando el print spooler con impresoras instaladas? Si la respuesta es sí, eso es un servidor de impresión, sea cual sea el nombre que le ponga el proveedor, y tú sigues siendo responsable de sus parches, sus modos de fallo y su exposición a CVE.

Esto se aplica también al producto de Microsoft. Universal Print elimina los servidores de impresión solo para las impresoras que lo soportan de forma nativa. Todo lo demás requiere el Connector de Universal Print, que se ejecuta en una máquina Windows siempre encendida con impresoras instaladas localmente, alimentando el print spooler de Windows. Eso es un servidor de impresión con un nombre nuevo.

¿Qué elimina el cloud rendering del entorno de impresión?

Sigue el rastro de lo que desaparece cuando el renderizado abandona el terminal:

Vale la pena enunciar con precisión la consecuencia para la seguridad. Microsoft atribuye el 9 % de los problemas de seguridad de Windows reportados a su Security Response Center a la pila de impresión, y se han revelado alrededor de 53 vulnerabilidades del print spooler desde PrintNightmare en 2021. Eliminar el print spooler de la ruta de impresión elimina esa clase de exposición en lugar de parchearla.

Windows Protected Print convierte esto en una cuestión a corto plazo en lugar de teórica. WPP bloquea los controladores de terceros en el terminal y solo funciona con impresoras certificadas por Mopria. Una arquitectura de cloud rendering no exige que la impresora negocie IPP con Windows, porque el Hub entrega datos listos para imprimir independientemente del estado de certificación del dispositivo. Los MFP no certificados, las impresoras de etiquetas y los dispositivos más antiguos siguen funcionando.

¿Cuáles son las contrapartidas del cloud rendering?

Hay dos, y conviene nombrarlas en lugar de pasarlas por alto.

Conectividad. El cloud rendering requiere una conexión a la nube. Si Internet está caído, las impresiones se ven afectadas. Esto es inherente al modelo y es cierto para todos los servicios de impresión en la nube, incluido el de Microsoft, cuya documentación afirma claramente que un usuario no puede imprimir si el dispositivo no está conectado a internet. Si eso es aceptable depende de lo críticas que sean las impresiones cuando la conexión se cae, y es una pregunta justa que plantear a cualquier proveedor.

El trabajo sale de las instalaciones. El documento se renderiza en la nube, lo que significa que viaja a la nube. Los datos de impresión se cifran en tránsito con TLS y se renderizan en entornos tenant isolation. Para las organizaciones con estrictos requisitos de residencia de datos, esta es una conversación que conviene tener deliberadamente en lugar de descubrirla en una revisión de seguridad.

Ninguna es razón para no hacerlo. Ambas son razones para entender lo que estás eligiendo.

¿Estás pensando en pasarte a la nube?

Descubre cómo.

Ver nuestra demo