El uso de características en Public Preview en productos de Microsoft genera un debate interesante dentro de la comunidad. Aunque no estamos acostumbrados a ver el uso de versiones Public Preview en producción en soluciones como SQL Server o la mayoría de servicios de Microsoft Fabric, en otros productos como Power BI sí que es más común que los usuarios adopten las nuevas funcionalidades de una manera más temprana. Lo mismo podríamos decir del SSMS, que muchos usuarios trabajan diariamente con versiones Beta.
Lo cierto es que existen ventajas y desventajas asociadas con el uso de estas funcionalidades antes de que lleguen a su fase de General Availability (GA). En este artículo vamos a ver si realmente es recomendable adoptar estas características en entornos productivos o si es preferible esperar a que se estabilicen con la liberación oficial.
Fases de Desarrollo: Hay más opciones que Public Preview o General Available
Antes de que una funcionalidad llegue a liberarse, existen varias etapas o fases en el ciclo de vida de desarrollo de un producto en las que los usuarios pueden participar. Estas fases permiten a las organizaciones y profesionales evaluar y probar características en distintos niveles de madurez.
Beta Interna
En esta fase, las funcionalidades son probadas internamente dentro de los equipos de Microsoft. Es una etapa completamente cerrada para el público externo y su principal objetivo es corregir los errores iniciales críticos.
Private Preview
Un grupo seleccionado de usuarios avanzados, generalmente MVPs, socios estratégicos o expertos en la materia, tienen acceso a esta etapa temprana del desarrollo. En esta fase el producto no está terminado aunque se presupone que ya tiene toda la funcionalidad necesaria (por eso la disponibilidad para probar) y, en ocasiones, podemos nosotros mismos solicitar el acceso. Durante esta etapa el feedback recibido por los usuarios es crucial para afinar la funcionalidad, pero se sabe que aún puede haber cambios significativos.
Public Preview
Esta fase abre la funcionalidad a un público más amplio y permite que cualquier usuario la pruebe bajo su propio riesgo. Las características aún pueden cambiar, pero es común que las funcionalidades ya sean bastante robustas. No obstante, Microsoft advierte explícitamente sobre posibles fallos y la falta de un Acuerdo de Nivel de Servicio (SLA) para esta etapa. Esta etapa tiene una doble función, por un lado, los usuarios prueban los productos y, en caso de detectar algún problema, pueden notificarlo a Microsoft. Por otro lado, esta prueba temprana puede ayudar a las empresas a asegurar la compatibilidad de sus soluciones nada más la versión definitiva sea liberada habiendo hecho previamente los cambios necesarios.
Release Candidate (RC)
Esta fase es el último paso antes del lanzamiento oficial. El producto está casi completamente terminado, y aunque puede haber pequeñas correcciones de errores, la funcionalidad ya está prácticamente estable. Es una fase clave para los usuarios avanzados que quieran probar en escenarios reales y asegurarse de que están preparados para la versión final.
General Availability (GA)
Por último tenemos la fase GA, esta es la fase en la que la característica se considera completamente lista para producción, respaldada por SLA y con soporte completo. A partir de aquí, la funcionalidad es considerada apta para cualquier entorno de trabajo, ya sea de misión crítica o no.
Estas fases permiten a los usuarios involucrarse en el desarrollo de las funcionalidades, influyendo en su evolución, pero también exigen un manejo cuidadoso del riesgo, especialmente en entornos productivos.
Ventajas de Usar Funcionalidades en Public Preview
Una de las principales razones por las que algunas organizaciones deciden implementar características en Public Preview es obtener una ventaja competitiva. La adopción temprana de nuevas capacidades en SQL Server, Power BI o Fabric puede permitir a las empresas explorar nuevas oportunidades o mejorar procesos antes que sus competidores.
Por ejemplo, cuando se lanzaron funcionalidades como Columnstore Index en SQL Server o avances en DirectQuery y Dataflows en Power BI, las organizaciones que adoptaron estas características en fases tempranas pudieron optimizar sus procesos de análisis y gestión de datos más rápidamente que aquellos que esperaron hasta la fase de GA.
Además, la fase de Public Preview ofrece a los usuarios la oportunidad de influir en el desarrollo del producto. Los comentarios proporcionados por los usuarios son fundamentales para corregir errores y ajustar las funcionalidades a los escenarios reales de uso.
Inconvenientes de Usar Funcionalidades en Public Preview
A pesar de las ventajas, las características en Public Preview también presentan inconvenientes. La principal preocupación es la estabilidad. Dado que las funcionalidades están en constante desarrollo, es posible que no sean completamente fiables o que presenten errores importantes, lo que puede tener un impacto negativo en entornos productivos.
Un ejemplo de este riesgo ocurrió con la implementación temprana de Columnstore Indexes en SQL Server. Aunque la funcionalidad prometía mejoras de rendimiento significativas, las primeras versiones presentaban limitaciones importantes que reducían su eficacia. Los usuarios que implementaron esta tecnología tuvieron que realizar modificaciones considerables en sus consultas para aprovecharla plenamente.
Además, las funcionalidades en Public Preview no suelen estar cubiertas por acuerdos de nivel de servicio (SLA), lo que significa que no hay garantía de resolución rápida de problemas. En entornos productivos , especialmente de misión crítica, este es un riesgo que muchas organizaciones no están dispuestas a asumir.
¿Cuándo actualizar?
Uno de los dilemas más comunes en la adopción de tecnología es decidir cuándo es el momento adecuado para actualizar a una nueva versión una vez que ha alcanzado la fase de General Availability (GA). Aunque las versiones GA son estables y están listas para producción, la decisión de actualizar inmediatamente puede variar según el entorno y las necesidades del negocio.
En entornos productivos críticos, como bases de datos o aplicaciones de análisis de datos, puede ser prudente esperar entre 3 y 6 meses tras el lanzamiento de GA antes de actualizar. Este margen de tiempo permite que se identifiquen y solucionen posibles problemas que no fueron detectados en las fases de prueba y permite beneficiarse de actualizaciones menores y parches que mejoran la estabilidad.
Sin embargo, en productos como Power BI, donde las actualizaciones suelen ser menos arriesgadas, algunas organizaciones optan por actualizar inmediatamente para aprovechar las nuevas funcionalidades y mejoras de rendimiento. Aunque no están libres de riesgo y en más de una ocasión he visto problemas graves. En resumen, la decisión debe basarse en el entorno específico y el nivel de riesgo que la organización esté dispuesta a asumir. Personalmente, para este producto con actualizaciones mensuales mi recomendación es tener los entornos productivos siempre una versión por debajo de la última, es decir, esperar un mes.
Para cerrar este apartado es importante destacar que no siempre es posible esperar para actualizar. En ocasiones, nos vemos obligados a actualizar nada más una versión es liberada para solucionar un incidente de la anterior. Por ejemplo la actualización acumulativa 15 de SQL Server 2022 soluciona una incidencia con CDC causada por la anterior actualización.
Estrategia de Pruebas con Public Preview
Si decidimos adoptar características en Public Preview o Release Candidate, es crucial tener un plan de pruebas bien estructurado. Implementar nuevas funcionalidades en entornos de pruebas antes de migrarlas a producción es una práctica esencial para mitigar riesgos.
Es imprescindible que las funcionalidades en Public Preview o RC se prueben en un entorno de desarrollo o pruebas separado de la producción. Esto evita que los problemas afecten al entorno productivo. Sin embargo, aunque separado, debería ser idéntico al entorno productivo. En este sentido, también es recomendable probar la funcionalidad bajo condiciones de carga similares a las de producción ayuda a identificar problemas de rendimiento que podrían no ser evidentes en pruebas ligeras.
Además deberemos implementar herramientas de monitorización y proporcionar retroalimentación a Microsoft sobre los problemas encontrados ya que esto permite un ajuste continuo de las funcionalidades y contribuye al desarrollo del producto.
Por último, siempre debemos tener un plan B, debe existir un plan para revertir los cambios si la nueva funcionalidad no funciona como se esperaba. Este es un paso crítico, especialmente en entornos de misión crítica.
Excepciones: SSMS Public Preview
Una excepción personal que sigo es con SQL Server Management Studio (SSMS). En este caso, Microsoft permite instalar las versiones en Public Preview junto con versiones estables anteriores sin desinstalar las mismas. Esto me permite probar nuevas características sin el riesgo de perder acceso a las herramientas que uso diariamente.
Mi estrategia es instalar SSMS en Public Preview en mi equipo de trabajo, pero no en los servidores de producción, obviamente. De esta forma, puedo probar las funcionalidades sin comprometer la estabilidad de los entornos críticos. Si las nuevas características funcionan correctamente, sigo usándolas; de lo contrario, siempre puedo volver a la versión estable. Además, reporto cualquier problema que detecte a Microsoft, lo que contribuye al desarrollo del producto.
Conclusión
La adopción de características en Public Preview o esperar a la fase de General Availability depende del nivel de riesgo que estemos dispuestos a asumir. Aquellos que buscan mantenerse a la vanguardia tecnológica y participar en el desarrollo del producto pueden beneficiarse de la adopción temprana, pero para entornos productivos críticos, es más seguro esperar hasta que la funcionalidad esté completamente probada y respaldada por un SLA. En algunos casos, como con SSMS, es posible adoptar un enfoque más flexible, probando las nuevas características sin comprometer la estabilidad operativa. Sin embargo, en general, la decisión de actualizar debe basarse en una evaluación cuidadosa del entorno, los riesgos y los beneficios esperados.
Y ahora os invito a debatir: ¿Cuál ha sido vuestra experiencia usando características en Public Preview? ¿Esperáis a la fase de GA para actualizar o adoptáis nuevas tecnologías en cuanto están disponibles? ¿Qué estrategias de pruebas habéis implementado para mitigar los riesgos?
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
