De script de laboratorio a SaaS: el caso Pheflux en bioinformática

En los laboratorios de investigación se produce software constantemente. Scripts en Python, notebooks en R, pipelines en Bash que resuelven problemas reales y generan publicaciones científicas. Pero ese software rara vez sale del laboratorio. Está atado al computador de un investigador, depende de versiones específicas de librerías que nadie documentó y se ejecuta de una forma que solo su creador comprende. Este artículo cuenta cómo tomamos uno de esos scripts y lo convertimos en un servicio web funcional: Pheflux.

El algoritmo original

Pheflux es un algoritmo de bioinformática para el fenotipado de flujos metabólicos bacterianos. En términos simples, analiza datos genómicos de bacterias para predecir su comportamiento metabólico: qué nutrientes pueden procesar, qué compuestos producen y cómo se adaptan a diferentes condiciones ambientales.

El algoritmo fue desarrollado por un equipo de investigación como parte de una tesis doctoral. Funcionaba correctamente y había sido validado con publicaciones en revistas científicas. El problema era su forma:

• Un script monolítico de 3.000 líneas en Python 2.7.
• Dependencias instaladas manualmente, sin archivo de requirements.
• Rutas de archivos hardcodeadas al computador del investigador.
• Sin manejo de errores: si algo fallaba, el script simplemente se detenía sin explicación.
• La documentación era el artículo científico publicado, no documentación técnica.
• Ejecución por línea de comandos con 12 parámetros posicionales que había que recordar de memoria.

Para que otros investigadores pudieran usar Pheflux, necesitaban replicar exactamente el entorno del autor original. En la práctica, esto significaba que casi nadie lo usaba fuera del laboratorio de origen.

Fase 1: entender antes de reescribir

La tentación de reescribir todo desde cero es fuerte, pero es también la forma más rápida de introducir errores en software científico. Nuestra primera fase fue puramente analítica:

Lectura del código y la publicación científica en paralelo, para entender no solo qué hacía cada función, sino por qué lo hacía de esa manera. Descubrimos que varias decisiones de implementación aparentemente arbitrarias respondían a particularidades biológicas que no eran evidentes para un desarrollador sin contexto.

Creación de tests de regresión: antes de modificar una sola línea, ejecutamos el script original con datos de ejemplo conocidos y registramos todos los outputs. Estos se convirtieron en nuestros tests de referencia: cualquier refactorización debía producir exactamente los mismos resultados numéricos.

Mapeo de dependencias: rastreamos cada librería utilizada, su versión exacta y si existían alternativas más modernas o mantenidas.

Fase 2: refactorización del código

Con los tests de regresión como red de seguridad, procedimos a refactorizar:

Migración a Python 3: Python 2.7 llegó a su fin de vida en 2020. La migración implicó adaptar el manejo de strings (bytes vs unicode), actualizar la sintaxis de print, y resolver incompatibilidades en librerías numéricas.

Modularización: el script monolítico se dividió en módulos con responsabilidades claras: lectura de datos de entrada, preprocesamiento, algoritmo de flujo metabólico, postprocesamiento y generación de resultados. Cada módulo con su propia batería de tests.

Gestión de dependencias: creamos un pyproject.toml con todas las dependencias versionadas, haciendo el proyecto instalable con pip install. Esto parece básico, pero es el paso que más impacto tiene en la reproducibilidad científica.

Manejo de errores: reemplazamos los fallos silenciosos por excepciones descriptivas. Si un archivo de entrada tiene formato incorrecto, el sistema ahora indica exactamente qué línea tiene el problema y cuál es el formato esperado.

Parametrización: los 12 parámetros posicionales se convirtieron en un archivo de configuración YAML con valores por defecto sensatos y documentación inline.

Fase 3: interfaz web

Con el núcleo algorítmico estabilizado, construimos la capa web:

Formulario de carga: interfaz intuitiva donde el usuario sube sus archivos de datos genómicos, selecciona los parámetros del análisis y lanza la ejecución. Incluimos validación inmediata de los archivos subidos: si el formato es incorrecto, el usuario lo sabe antes de esperar por un análisis que iba a fallar.

Ejecución asíncrona: los análisis pueden tardar entre 30 segundos y 20 minutos dependiendo del volumen de datos. Implementamos un sistema de colas donde el análisis se ejecuta en background y el usuario recibe una notificación cuando los resultados están listos. Puede cerrar el navegador y volver más tarde.

Visualización de resultados: los resultados se presentan en gráficos interactivos que permiten explorar los flujos metabólicos predichos. Los investigadores pueden hacer zoom, filtrar por vías metabólicas específicas y comparar resultados entre diferentes muestras.

Exportación: todos los resultados se pueden descargar en formatos estándar de bioinformática (CSV, JSON, SBML) para su análisis posterior en otras herramientas.

Fase 4: despliegue en AWS

El despliegue fue diseñado para ser económico pero escalable:

• EC2 con instancias que escalan según la demanda de procesamiento.
• S3 para almacenamiento de archivos de entrada y resultados.
• RDS PostgreSQL para metadatos de usuarios, análisis y configuraciones.
• SES para notificaciones por correo electrónico cuando los análisis terminan.

El costo de infraestructura en estado base es mínimo. Solo escala cuando hay análisis en ejecución, lo que es ideal para un servicio con uso intermitente típico de herramientas de investigación.

Desafíos específicos del software científico

Trabajar con software científico tiene particularidades que no se encuentran en el desarrollo comercial convencional:

Precisión numérica: cambiar una librería de álgebra lineal puede producir diferencias en el decimocuarto dígito significativo. Aunque parezca irrelevante, en cálculos iterativos esas diferencias se acumulan. Nuestros tests de regresión verifican los resultados con una tolerancia definida por los investigadores.

Reproducibilidad: un resultado científico debe ser reproducible. Esto significa que la misma entrada debe producir exactamente la misma salida, independientemente de cuándo o dónde se ejecute. Fijamos las versiones de todas las dependencias y documentamos el entorno de ejecución.

Validación por expertos: no basta con que el código funcione. Los resultados deben ser validados por biólogos que entienden el significado de los números. Organizamos sesiones de validación donde los investigadores compararon los resultados del servicio web con sus análisis manuales.

Citabilidad: en el mundo académico, el software debe ser citable. Publicamos Pheflux con un DOI propio y una referencia bibliográfica estándar para que los investigadores puedan citarlo en sus publicaciones.

Resultados

Después del lanzamiento:

• Usuarios activos: investigadores de 4 universidades en 3 países diferentes están usando Pheflux regularmente.
• Tiempo de onboarding: de varias horas (instalación manual del script original) a 5 minutos (crear cuenta y subir datos).
• Errores de ejecución reportados por usuarios: reducción del 95%, gracias a la validación de entrada y el manejo de errores.
• Nuevas colaboraciones: el acceso fácil al algoritmo ha generado colaboraciones que no habrían ocurrido con el script original.

¿Te interesa?

Si tu laboratorio o grupo de investigación tiene software científico que podría beneficiar a una comunidad más amplia, podemos ayudarte a transformarlo en un servicio web accesible. También trabajamos en la modernización de pipelines de análisis, la creación de módulos instalables y la documentación técnica de software científico.

Contáctanos para discutir tu proyecto o explora nuestros servicios de desarrollo científico.