Los productos de datos que añaden valor al negocio tienen un gran riesgo de éxito si se da un mayor uso del que fue previsto por los crearon dicho producto. Una forma de prevenir esto es usar solamente productos comerciales que vienen con una forma de despliegue integrado. Esto puede ayudar a escalar un producto de datos de forma eficaz. A la misma vez pueden tener la desventaja de alto costo cuando se quiere escalar al siguiente nivel.
January 25, 2023
Acompañamos en iniciativas y proyectos de ciencia de datos, ingeniería e infraestructura. Visita nuestra página ixpantia y contáctanos.
Los productos de datos que añaden valor al negocio tienen un gran riesgo si se da un nivel mayor de uso al originalmente previsto por los creadores de dicho producto. Una forma de prevenir esto es usar solamente productos comerciales que vienen con una forma de despliegue integrado. Aunque esto puede ayudar a escalar un producto de datos de forma eficaz, tiene la desventaja de alto costo cuando se quiere escalar al siguiente nivel.
Tener múltiples ambientes de desarrollo es una mejor práctica que protege al negocio de productos con errores, y da la libertad a quienes están desarrollando de experimentar e innovar sin tener que preocuparse del impacto que pueden tener sobre los procesos activos mientras trabajan. Cuando trabajamos con código esta forma de trabajar viene naturalmente. Cuando usamos herramientas que incluyen su ambiente de despliegue, típicamente el poder tener múltiples entornos viene a un costo adicional, justamente por el valor que añade. En un ejemplo más adelante veremos cómo es esto con PowerBI.
Un ambiente de despliegue es el lugar donde un producto de datos funciona de forma integral. Lo que marca la diferencia son los datos que se usan (fuentes que están conectadas) y los datos que se guardan. Típicamente un producto de datos pasa por tres ambientes:
En este blogpost damos una descripción general de los tres, con la intención de lograr transmitir el valor de tenerlos disponibles. En cada una de estas etapas tenemos actividades diferentes, todas para asegurarnos de que el producto final que se lleva a producción da el servicio acordado con el negocio.
El ambiente más importante desde la perspectiva de negocio es el ambiente de producción, porque aquí es donde impactamos los procesos de negocio directamente. Y si bien parece que tendría sentido arrancar con el ambiente de Desarrollo al describirlos, creo que lo correcto es comenzar con Producción, porque en el mejor caso arrancamos con desarrollo de un producto de datos, entendiendo dónde lo vamos a desplegar. Se puede hacer, después - pensar en el despliegue - y eso pasa frecuentemente en organizaciones que están arrancando. A medida que llegamos a un siguiente nivel de madurez, vamos a poder pensar desde producción hacia atrás.
En el ambiente de producción el producto de datos funciona, es accesible a quienes están autorizados, y tiene un desempeño óptimo. Decimos óptimo y no máximo porque todo tiene un costo (y ya hablaremos de acuerdos de servicio, pero eso es para otro blog post!). Lo que buscamos es adecuar el costo al uso que se le va a dar, y tener los mecanismos en su lugar para incrementar la escala del producto de datos cuando el uso incrementa.
Un ambiente de producción maduro requiere bitácoras y alertas. Las bitácoras son clave para monitorear el servicio y tener un registro de errores técnicos. De esta forma si hay mención de un incidente por parte de un usuario, es más fácil validar el error y dar la respuesta adecuada. Además, en muchos casos podemos anticipar reportes de incidentes por parte de usuarios.
Las alertas pueden estar conectadas con las bitácoras, pero no es así en todos los casos. Pueden ser alertas de ejecución de un servicio, o una alerta de que se aproximan límites de la infraestructura. En una organización con alto nivel de madurez DATA el éxito de productos de datos en producción se mide en primera instancia validando si cumplen con los acuerdos de servicio con el negocio. Además monitoreamos el uso por los diferentes actores en la organización como una de las métricas claves de éxito.
Antes de llevar un producto de datos a producción y exponerlo a procesos y usuarios que están activamente en la ejecución de procesos de negocio, llevamos el producto de datos a un entorno para hacer pruebas. Se usa mucho el nombre en inglés staging que viene del concepto de un staging area. Es el lugar donde nos preparamos para algo. En este caso nos preparamos para llevar el producto de datos a producción. Hay tres tipos de pruebas que ejecutamos aquí: pruebas funcionales, pruebas unitarias y pruebas de integración.
Las pruebas funcionales buscan repetir acciones de usuarios sobre el producto de datos para anticipar fallas. Consisten de listas de acciones por tomar y en gran medida se ejecutan de forma manual, aunque en lo posible los buscamos automatizar. Las pruebas de integración buscan validar que el servicio que queremos desplegar funciona bien con los demás servicios con los que tiene que interoperar. Para que la prueba sea válida buscamos repetir el entorno de producción lo más fielmente posible. Sólo si todas las pruebas pasan satisfactoriamente vamos al siguiente paso y hacemos un despliegue en producción. De otra forma regresa al ambiente de desarrollo con una serie de tiquetes, con descripciones de incidentes que se han de solucionar.
Típicamente el ambiente de desarrollo es la máquina donde profesionales de datos están creando y mejorando los productos de datos. En ixpantia generalmente trabajamos en una máquina virtual dentro de la infraestructura donde vamos a hacer los despliegues a pruebas y producción. Si estamos desarrollando un servicio que va a correr en Azure, por ejemplo, desarrollamos sobre una máquina en Azure para así tener todos los servicios relacionados con el producto de datos que desplegamos. Estos servicios son los mismos que vamos a usar en otros ambientes, pero para cada ambiente levantamos instancias diferentes. De esta forma mantenemos los ambientes separados lo máximo posible para no crear dependencias que pueden llevar a un error imprevisto después.
Imagínate el siguiente producto de datos. Tenemos un modelo predictivo desplegado como un API usando por ejemplo los container instances de Azure. El API consume datos de una base de datos en Cosmo DB y escribe la predicción que genera, un score, a una tabla en la misma base de datos todos los días a las 02:00 AM. Este score a su vez alimenta un tablero en PowerBI donde ejecutivos de ventas usan los resultados para priorizar oportunidades con una mayor probabilidad de conversión.
flowchart TD subgraph DEV PowerBIDev[[PowerBI]] --> DataBaseDev[(database)] DataBaseDev --> APIDev((API)) APIDev --> DataBaseDev end subgraph STAGE PowerBIStage[[PowerBI]] --> DataBaseStage[(database)] DataBaseStage --> APIStage((API)) APIStage --> DataBaseStage end subgraph PROD PowerBIProd[[PowerBI]] --> DataBaseProd[(database)] DataBaseProd --> APIProd((API)) APIProd --> DataBaseProd end
Al tener tres ambientes podemos trabajar de la siguiente forma. Desarrollamos el API en una máquina virtual y validamos que lee y escribe correctamente a la base de datos de desarrollo. Esta base de datos tiene un dataset limitado, que podría ser una copia de los datos que están en producción, pero típicamente en desarrollo no se usa una copia completa. Esto por razones de seguridad de datos y por desempeño. Un desarrollador siempre busca dar iteraciones rápidas, y busca datos extremos para validar situaciones limítrofes (edge cases) que están descritos en la documentación. Desde la máquina de desarrollo puede desplegar al entorno de pruebas, donde hay más datos en la base de datos, y donde puedes escribir libremente en son de prueba porque nadie en el negocio va a hacer uso de los datos que se producen. Finalmente lo llevamos al entorno de producción, donde los datos de entrada son los que están vigentes y actuales en el proceso de negocio, y donde lo que escribimos a la base de datos se va a usar en el proceso de ventas.
A cuál de los entornos conectamos los diferentes estados de PowerBI depende del tipo de desarrollo que hacemos allí, y quien lo está desarrollando. La documentación de Microsoft tiene una buena descripción del tema aquí.
Finalmente queremos introducir dos términos más en este contexto, porque se escuchan con frecuencia: despliegue continuo e integración continua. Se refieren a una infraestructura donde siguiendo las mejores prácticas de DataOps un despliegue se realiza de forma automática cuando hacemos un cambio en el código. Trabajando desde entornos en la nube como Azure, AWS, o Google Cloud, esto es accesible para equipos que trabajan creando infraestructura de datos. Hemos visto que se requiere un buen nivel de madurez por parte de los equipos de datos para adoptar estas prácticas.
Lo mínimo que necesitas en tu organización es separar el entorno de desarrollo del entorno de producción. Desarrollar - hacer cambios y correcciones - sobre algo que está en activo uso por usuarios en la organización nunca es una buena idea (y sólo se hace cuando no hay alternativa por los riesgos que conlleva). Si los cambios no son una mejora, pero si hacen caer el producto de datos y afecta el proceso de negocio tenemos que poder hacer un roll-back (regresar al estado anterior). Una separación de entornos además permite ejecutar procesos que garantizan calidad, y dan la libertad a los profesionales de datos de experimentar en un entorno que no afecta el negocio para innovar y encontrar soluciones óptimas.
Este blog lo mantiene el equipo de ixpantia y la comunidad de gente interesada en datos de la cual estamos contentos de formar parte ¿Tienes una idea para publicar algo aquí? ¡Escríbenos! Estamos siempre interesados en material e ideas nuevas. © 2019-2022 ixpantia