Compartido, no expuesto: cómo se están redefiniendo las nubes de pruebas

La evolución de las nubes de dispositivos: de públicas a privadas y compartidas

Como gerente de producto responsable de brindar capacidades administrativas dentro de la Digital.ai Plataforma de pruebas: mi perspectiva sobre la infraestructura es el equilibrio entre disponibilidad y control. Mi rol, el Administrador de la Nube, es el guardián. El administrador asigna recursos, gestiona los permisos de los usuarios y, sobre todo, garantiza que los recursos estén disponibles cuando los equipos de pruebas los necesiten.

Con los años, nuestra industria ha cambiado mucho. Pasamos del control total del hardware físico a la enorme flexibilidad de la nube pública. Pero ninguno de los extremos resolvió el verdadero problema. Hoy, estamos trazando un rumbo diferente, uno que desafía la falsa visión binaria que la industria ha aceptado durante tanto tiempo.

El futuro no se trata de elegir entre el confinamiento y la apertura a todos. Se trata de un tercer estado: Instancia compartida

Permítanme mostrarles cómo llegamos aquí y por qué esta distinción importa más de lo que la mayoría de los proveedores quieren admitir.

Fase 1: La era del "Hardware Hugging" (interno y local)

Todos recordamos el modelo tradicional: el laboratorio de dispositivos interno. Cables USB serpenteando por los escritorios. Baterías móviles hinchadas que hay que cambiar cada seis meses. Actualizaciones manuales del sistema operativo que consumían tardes enteras. Ese iPhone 6 que, por alguna razón, seguía funcionando cuando todo lo demás había sido retirado.

El control tangible era satisfactorio; uno podía acercarse y recoger el dispositivo que causaba problemas. Pero la carga operativa era abrumadora.

Para nuestros clientes preocupados por la seguridad, especialmente en los sectores bancario y de defensa, esto evolucionó hacia soluciones locales y aisladas. En estas configuraciones, la infraestructura está completamente aislada, por lo que los datos permanecen bajo control total.

Los dispositivos nunca tienen acceso a internet público. Los datos de prueba nunca salen del edificio.

¿Por qué surgió esto?

Aplicaciones bancarias que gestionan datos financieros. Aplicaciones de salud que gestionan historiales clínicos. Aplicaciones gubernamentales con información clasificada. Estas no podrían ejecutarse en una infraestructura donde las pruebas de otra empresa podrían haber tocado el mismo dispositivo horas antes.

La respuesta de la industria fue simple: «Estos dispositivos son tuyos y solo tuyos, aislados en tu entorno. Nadie más los toca».

Esto solucionó necesidades reales

• Aislamiento total de dispositivos y datos para aplicaciones que manejan información regulada o clasificada
• Configuración de infraestructura personalizada para adaptarse a los requisitos internos de seguridad, red y cumplimiento
• Residencia y soberanía de datos garantizadas, sin dependencia de recursos públicos compartidos
• Implementaciones con espacio de aire para entornos que no pueden conectarse a Internet público en absoluto

El problema que esto creó

Pero esto es lo que observé al gestionar estos entornos: esto resolvió el problema de seguridad pero creó uno nuevo: la economía.

• Alto costo totalLas organizaciones gastaban mucho tiempo, recursos y dinero en mantener la infraestructura.
• Acceso lento a nuevos dispositivosVi a clientes esperar tres meses para probar el iPhone 15 tras su lanzamiento. La compra tenía que ser aprobada por la gerencia. El departamento de compras tenía que encargarlo. El personal de TI tenía que configurarlo e incorporarlo al laboratorio. Mientras tanto, sus usuarios ya estaban descargando su aplicación en el último iPhone.

Las instalaciones locales brindaron a las empresas la seguridad que necesitaban, pero a costos que no se adaptaban a una cobertura de dispositivos que no podía seguir el ritmo de la fragmentación del mercado.

Sin embargo, para cargas de trabajo verdaderamente sensibles, esto sigue siendo válido. Las soluciones locales y aisladas no desaparecerán; son necesarias para datos clasificados y escenarios con restricciones legales. Sin embargo, no deberían ser la solución predeterminada para todas las necesidades de prueba.

Fase 2: La bifurcación de SaaS (nube pública vs. nube dedicada)

A medida que el mercado se orientó hacia el SaaS, se dividió en dos opciones binarias. Ninguna satisface plenamente al administrador de la nube empresarial moderno, que busca equilibrar seguridad, cobertura y costos.

Opción 1: La nube pública

Las nubes de dispositivos públicos surgieron como la primera solución a un problema que se estaba volviendo económicamente imposible: los desarrolladores no podían darse el lujo de comprar todos los dispositivos que poseían sus usuarios.

Dispositivos asignados dinámicamente por orden de llegada con control limitado y compartidos entre todos los clientes de la plataforma.

¿Por qué surgió esto?

A principios de la década de 2010, la fragmentación móvil se disparó. Android lanzaba docenas de nuevos dispositivos trimestralmente. iOS añadía nuevos modelos anualmente. Probar aplicaciones manualmente en dispositivos físicos se volvió económicamente imposible para casi todas las empresas, salvo para las más grandes.

Las nubes públicas ofrecieron un gran avance: acceso instantáneo a cientos de dispositivos sin comprar hardware.

Pago por uso. Sin configuración. Solo haz clic y prueba.

Para las empresas emergentes y los equipos de desarrollo de rápido movimiento, esto fue transformador.

Esto solucionó necesidades reales

• Se eliminó la necesidad de comprar y mantener laboratorios de dispositivos físicos.
• Permitió una validación rápida y bajo demanda sin necesidad de configuración ni planificación de infraestructura
• Hizo que una amplia cobertura de dispositivos fuera económicamente accesible, incluso con presupuestos limitados

Las limitaciones que surgieron

Pero a medida que las empresas adoptaron estas plataformas, surgieron problemas que escuché repetidamente en las conversaciones con los clientes:

• Control limitadoNuestra aplicación requiere configuraciones de red y VPN específicas para conectarse a entornos internos. Los dispositivos de nube pública dependen de configuraciones de red estandarizadas que no las admiten.
• Problemas de disponibilidadCuando Apple lanza un nuevo iPhone, la demanda se dispara al instante. Terminamos haciendo cola durante periodos de prueba críticos.
• Brechas de cumplimientoNuestro equipo de seguridad revisó la arquitectura y la rechazó. La infraestructura pública multiusuario no es aceptable para aplicaciones que manejan datos financieros confidenciales.

Las nubes públicas democratizaron las pruebas móviles, pero no fueron diseñadas para los requisitos de control y seguridad empresarial.

Opción 2: La nube dedicada

Para solucionar la brecha de seguridad, la industria estandarizó las ofertas de nube dedicada (privada). Entornos de un solo inquilino donde los dispositivos se reservan exclusivamente para un cliente.

Dispositivos reservados exclusivamente para un único cliente, ofreciendo control total sin necesidad de gestionar la infraestructura del laboratorio.

Esto solucionó necesidades reales

• Acceso a un entorno de nube privado de un solo inquilino dedicado a su organización.
• Cumplir con los requisitos de seguridad y reglamentarios mediante un aislamiento completo.
• Mantenga el control total sobre los dispositivos y las configuraciones para optimizar los escenarios de prueba.
• Reducir los gastos operativos relacionados con el mantenimiento del laboratorio, las actualizaciones y la administración de TI.
• Esto proporcionó a las empresas la postura de seguridad que necesitaban, pero heredó algunos de los problemas económicos de las soluciones locales.

Las limitaciones que surgieron

• Costo continuo de dispositivos dedicados, lo que resulta en una diversidad de dispositivos limitada y una cobertura de pruebas incompleta.
• La asignación restrictiva de dispositivos, especialmente durante períodos pico, como pruebas previas al lanzamiento o depuración específica del dispositivo, reduce la flexibilidad de las pruebas y puede generar demoras en el lanzamiento.

La desconexión: lo que los clientes realmente necesitaban

Para entonces, teníamos dos opciones extremas:

• PúblicoCobertura de dispositivos asequible, accesible y diversa, pero con preocupaciones de seguridad y control limitado.
• Dedicado:Seguro, controlado, compatible, pero costoso y con variedad de dispositivos limitada.

Pero cuando me senté con los clientes y les pregunté sobre sus flujos de trabajo de pruebas reales, describieron necesidades que no encajaban en ninguno de los extremos:

Nuestro flujo de trabajo de CI/CD ejecuta pruebas funcionales en 50 dispositivos cada hora. Necesitamos que estas pruebas se ejecuten en nuestra red privada con nuestra configuración de VPN, se ejecuten rápidamente y reutilicen las configuraciones de los dispositivos en diferentes suites de pruebas. Las nubes públicas no lo permiten, y los dispositivos dedicados son demasiado costosos de escalar.

Utilizamos dispositivos dedicados para las pruebas de producción con datos reales de clientes. Pero en cuanto al desarrollo, nuestros equipos solo necesitan validar rápidamente las correcciones de errores en una amplia gama de dispositivos. No necesitan recursos dedicados, sino cobertura.

El patrón era claro: Los clientes necesitaban algo entre público y dedicado..

Necesitaban:

• Economía de infraestructura compartida con acceso a dispositivos bajo demanda
• Amplia cobertura de dispositivos y sistemas operativos, comparable a las nubes públicas
• Seguridad y aislamiento de nivel empresarial, sin propiedad exclusiva del dispositivo
• Control total de la red, incluidas configuraciones VPN y de sitio a sitio
• Ejecución confiable de conjuntos de pruebas a gran escala, sin configuraciones ni desmontajes disruptivos entre ejecuciones

La industria había planteado el problema como una elección binaria. Ese planteamiento era erróneo, y fue así como empezamos a construir algo diferente.

Fase 3: Dispositivos compartidos en nubes privadas: la tercera vía

Aquí es donde Digital.ai Pruebas Se ha centrado en la innovación en los últimos años. No porque busquemos ser diferentes por el simple hecho de serlo, sino porque escuchamos las necesidades reales de los clientes y buscamos resolver una necesidad real.

Lo que esto significa

Dispositivos asignados dinámicamente por orden de llegada, pero con mayor control y flexibilidad que los dispositivos públicos. Ideales para ejecutar grandes conjuntos de pruebas, que requieren configuraciones específicas (p. ej., usar la misma configuración de VPN que los dispositivos dedicados) y un uso sin interrupciones.

Obtendrás la economía del uso compartido con la postura de seguridad de un entorno privado.

¿Por qué surgió esto?

Tres fuerzas convergieron para hacer que este modelo fuera posible y necesario:

1. La tecnología de seguridad en la nube maduró

La arquitectura de nube privada ha avanzado hasta el punto de permitirnos crear un verdadero aislamiento dentro de una infraestructura multiusuario. Sus dispositivos, configuraciones de red y datos permanecen completamente separados de los de otros clientes, incluso si la infraestructura de nube subyacente es compartida.

Este nivel de aislamiento no era alcanzable de manera confiable en 2015. Pero ahora se ha convertido en estándar en la arquitectura de nube empresarial.

2. Se intensificaron las presiones de costos

Los equipos buscaban las mismas garantías de seguridad con una mejor economía de uso. La antigua respuesta, "porque la seguridad lo requiere", ya no era satisfactoria.

3. Las necesidades de prueba se diversificaron

Hoy en día, los equipos no tienen solo un tipo de prueba, tienen múltiples cargas de trabajo, cada una con diferentes requisitos:

• Pruebas de producción de alta seguridad utilizando datos reales de clientes (requiere recursos dedicados)
• Pruebas funcionales de CI/CD a gran escala con datos sintéticos (prioriza la escala y la cobertura sobre la exclusividad)
• Pruebas de compatibilidad amplias en cientos de combinaciones de dispositivos y sistemas operativos (no es económicamente viable solo en dispositivos dedicados)
• Validación diaria del desarrollo de correcciones de errores (requiere acceso rápido y variedad, disponibilidad no garantizada)

Una infraestructura única, ya sea pública o dedicada, no refleja cómo se realizan realmente las pruebas hoy en día.

Qué significa esto para su estrategia de pruebas

Si hoy estás evaluando opciones de nube para dispositivos, te reto a que rechaces por completo la idea de "público vs. privado". Es obsoleta y no refleja cómo funcionan realmente las pruebas modernas.

En lugar de eso, base la decisión en cómo funcionan realmente sus equipos. Para ayudarle a encontrar esas respuestas, aquí tiene algunas preguntas útiles:

1. ¿Cuáles son sus necesidades reales de carga de trabajo?

• ¿Todas las cargas de trabajo manejan datos confidenciales o regulados, o solo algunas de ellas?
• ¿Necesita garantizar la disponibilidad del dispositivo en todo momento o solo durante períodos definidos?
• ¿Sus pruebas dependen de configuraciones de dispositivos persistentes o requieren entornos limpios en cada ejecución?

La mayoría de los equipos, cuando realmente planifican esto, descubren que tienen una mezcla.

2. ¿Puedes separar las cargas de trabajo según los requisitos de seguridad?

• Alta seguridad → SaaS dedicado o local (datos de producción, aplicaciones reguladas o restringidas)
• Seguridad media → Dispositivos compartidos dentro de una instancia privada (pruebas funcionales, CI/CD, compatibilidad)
• Baja seguridad → Dispositivos públicos o compartidos dentro de una instancia privada (desarrollo temprano, validación no sensible)

La conclusión clave es que no todas las cargas de trabajo de pruebas requieren el nivel de seguridad más alto.

Conclusión: evolución, no revolución

La evolución de lo público a lo privado y a lo compartido no se debió a la innovación por el mero hecho de innovar. Se debió a las necesidades de los clientes y a las fuerzas del mercado que la industria no podía ignorar:

Los dispositivos compartidos dentro de un entorno SaaS privado surgieron porque las organizaciones necesitaban equilibrar la economía que no podían ignorar, la diversidad de dispositivos sin los cuales no podían realizar pruebas y la seguridad que no podían permitirse sacrificar.

At Digital.ai Tras realizar pruebas, hemos aprendido que el futuro de la infraestructura de la nube de dispositivos no se trata de elegir un único modelo de implementación. Se trata de crear arquitecturas lo suficientemente flexibles como para adaptar las diferentes cargas de trabajo a los niveles adecuados, todo ello dentro de un entorno seguro y compatible que los administradores de la nube puedan gestionar.

La verdadera pregunta nunca fue “¿público o privado?”

La verdadera pregunta es: "¿Cómo brindamos a los equipos de pruebas la cobertura que necesitan sin exponer nuestros datos ni exceder nuestro presupuesto?"

Eso es lo que significa "Compartido, no expuesto". Y ese es el futuro que estamos construyendo.