En el módulo 1 viste que un portátil tiene una huella de fabricación y otra de uso. Esa manera de mirar un producto de principio a fin tiene nombre, análisis de ciclo de vida, y también se puede aplicar a una aplicación web. El resultado es un mapa de en qué momento se decide la huella de un producto digital, y la respuesta es casi siempre la misma: mucho antes de que alguien lo use.
1 // El análisis de ciclo de vida
El análisis de ciclo de vida (ACV, o LCA en inglés) es un método normalizado, recogido en las normas ISO 14040 e ISO 14044, para calcular el impacto ambiental de un producto desde la cuna hasta la tumba. Para un producto físico, las etapas son:
- Extracción de materias primas: minería, petróleo, agua.
- Fabricación: transformar esos materiales en el producto.
- Distribución: transporte y embalaje hasta el cliente.
- Uso: la energía y los consumibles durante su vida útil.
- Fin de vida: reciclaje, reutilización o vertedero.
La gracia del ACV es que evita trasladar el problema de una etapa a otra sin darse cuenta. Un coche eléctrico, por ejemplo, reduce mucho las emisiones de uso, pero su batería aumenta las de fabricación; sólo mirando el ciclo completo se puede saber cuál es el balance.
Sin ciclo de vida, una mejora puede ser un espejismo. Una decisión es buena si reduce el impacto total, no sólo el de la fase que estás mirando.
2 // Aplicado al software
El software no tiene materias primas ni se transporta en camión, pero necesita hardware y energía en cada etapa. Adaptando el esquema anterior:
| Fase | Qué consume | Ejemplos |
|---|---|---|
| Diseño y desarrollo | Equipos del equipo, entornos de pruebas, integración continua | Portátiles, servidores de CI, entornos de preproducción encendidos |
| Despliegue y uso | Centros de datos, redes y dispositivos de los usuarios | Peticiones, consultas, transferencias, procesado en el navegador |
| Mantenimiento | Todo lo anterior, de forma continua | Actualizaciones, copias de seguridad, monitorización, registros |
| Retirada | Migración y borrado | Exportar datos, apagar servidores, eliminar copias |
Y hay una fase que no aparece en la tabla, pero que conviene no olvidar: el hardware inducido. Si tu aplicación exige un móvil potente, o un servidor mayor, está provocando la fabricación de ese hardware, aunque no sea tuyo.
Cuidado con una trampa habitual: pensar que la huella del desarrollo es la importante porque es la que ves. Los ordenadores del equipo y los servidores de pruebas cuentan, pero en una aplicación con muchos usuarios la fase de uso suele ser muchísimo mayor, porque se repite millones de veces. Lo que no significa que puedas descuidar el desarrollo: un pipeline de CI que compila todo en cada commit, o un entorno de pruebas encendido todo el fin de semana, también suman.
3 // Decidir una vez, ejecutar millones de veces
El rasgo más característico del software es que se diseña una vez y se ejecuta una y otra vez. Eso convierte cada decisión en un multiplicador:
- Elegir un formato de imagen afecta a cada visita durante años.
- Añadir una librería de 300 kB afecta a cada carga de página de cada usuario.
- Consultar la base de datos sin índice afecta a cada petición que la usa.
- Programar una tarea que se ejecuta cada minuto afecta a las 525.600 ejecuciones que tendrá al año.
Un equipo decide cargar en la página principal una librería de gráficos de 300 kB, aunque sólo la usa una sección que visita el 5 % de los usuarios. La web tiene 50.000 visitas diarias sin la librería en caché.
- Datos extra al día: 300 kB × 50.000 = 15.000.000 kB ≈ 15 GB.
- Datos extra al año: 15 GB × 365 ≈ 5.475 GB, unos 5,5 TB.
- Datos realmente necesarios: sólo el 5 % de las visitas usa la librería, así que bastarían unos 275 GB al año si se cargara sólo en esa sección.
Existe una observación irónica, la ley de Wirth, que dice que el software se vuelve lento más deprisa de lo que el hardware se vuelve rápido. Es una exageración, pero describe algo real: si cada versión de una aplicación pide un poco más, el hardware de los usuarios envejece antes. En el módulo 7 volverás sobre esto.
4 // Retirar también es diseñar
La última fase es la que menos se planifica. Las empresas acumulan software zombi: servicios que nadie usa pero que siguen desplegados, bases de datos de proyectos cerrados, entornos de pruebas olvidados, copias de seguridad de datos que ya no hacen falta.
Todo eso consume electricidad y ocupa hardware sin aportar nada. Por eso un ciclo de vida sostenible incluye, desde el principio, preguntas como:
- ¿Cuándo dejará de ser útil esta funcionalidad y cómo la retiraremos?
- ¿Cuánto tiempo necesitamos guardar estos datos?
- ¿Quién es responsable de apagar este entorno cuando acabe el proyecto?
La huella de una aplicación se decide en el diseño, se multiplica en el uso y se olvida en la retirada. Mirar el ciclo completo es la forma de no optimizar lo que se ve y descuidar lo que más pesa.