Los trade-offs en ingeniería informática

Dicen que en la vida no se puede todo, y esta afirmación es aún más vigente en el campo de la ingeniería. Muchos problemas ingenieriles pueden resolverse desde diferentes perspectivas y mejorar una dimensión puede implicar perjudicar otra. Estos equilibrios, denominados en inglés trade-offs, significan que no hay una solución netamente mejor que otras y debemos escoger la opción más adecuada según el contexto y los objetivos deseados.

Debido a que no hay “recetas” universales, un trade-off es un punto donde la ingeniería aporta valor añadido. Saber reconocer el trade-off, conocer las posibles soluciones alternativas y saber elegir la más apropiada al contexto es donde reside nuestro valor diferencial como ingenier@s. Dedicaremos esta entrada a describir algunos de los trade-offs más comunes en el ámbito de la ingeniería informática.

En su versión más genérica, un trade-off refleja:

-Un equilibrio entre la calidad del resultado y los recursos consumidos por la solución

-Una relación entre los diferentes tipos de recursos necesarios para resolver un problema

-Un conflicto entre objetivos contradictorios

En el campo de la ingeniería informática, aparecen trade-offs de los tres tipos.  La calidad del resultado depende del problema concreto, mientras que los recursos pueden ser de diversos tipos:

-Software: Tiempo de ejecución, espacio de memoria

-Hardware: Retardo, área ocupada por el componente, consumo de energía, coste económico

-Redes y sistemas distribuidos: Número de mensajes enviados, ancho de banda, capacidad (memoria y tiempo de cálculo) de cada nodo

-Proyectos TIC: Tiempo de realización, Alcance del proyecto, Calidad del producto, Recursos (humanos y técnicos) disponibles.

–Algorítmica y estructuras de datos (tiempo versus espacio): A la hora de resolver un problema, en ocasiones es posible reducir el tiempo de ejecución almacenando cálculos intermedios que pueden reutilizarse.
Ejemplos: memorias cache, programación dinámica, lookup tables

-Gestión de proyectos (valor vs coste vs tiempo): Diferentes métodos de gestión de proyectos bloquean algunas de sus dimensiones para controlar mejor el proceso y los resultados obtenidos. Por ejemplo, el desarrollo en cascada empieza fijando el alcance del proyecto en sus etapas iniciales, mientras que el desarrollo ágil fija el tiempo (la duración de cada iteración) y a partir de aquí se deciden otros aspectos como el alcance de cada iteración.

-Ejemplos: triángulo de la gestión de proyectos

-Paralelización (tiempo versus coste económico): Hay varias estrategias para hacer que un cálculo sea más rápido a cambio de hacerlo más costoso económicamente. Una primera estrategia sería realizar un cálculo en paralelo en múltiples dispositivos (ordenadores y/o GPUs), ya sea dentro de una centro de cálculo o “granja”,  solicitando recursos a participantes voluntarios (o involuntarios) o bien solicitando recursos bajo demanda en la nube. De esta forma, cuantos más dispositivos participen en un cálculo, más rápido se completará). Por otro lado, otra opción es desarrollar hardware específico para resolver problemas concretos con grandes necesidades de cálculo, como por ejemplo el aprendizaje computacional. Ambas soluciones ofrecen un equilibrio entre el coste (número de dispositivos y su coste) y la eficiencia del cálculo.
Ejemplo: infraestructura como servicio (IaaS), uso de GPUs para cálculo masivo de propósito general (GPGPU), minería de criptomonedas, proyectos distribuidos colaborativos como SETI@HOME o Folding@HOME, unidades de procesamiento tensorial (TPUs), neural compute stick

-Usabilidad versus seguridad: Algunas técnicas que permiten asegurar la identidad o evitar accesos no deseados a la información también complican su uso por parte de los usuarios legítimos.
Ejemplo: gestión de contraseñas

-Sistemas distribuidos (consistencia versus disponibilidad versus tolerancia a fallos): El teorema CAP es un resultado teórico en el campo de los sistemas distribuidos. Este teorema afirma que un sistema no puede cumplir simultáneamente tres propiedades deseables: consistencia (asegurar que cualquier petición será respondida con los datos más actualizados en ese momento), disponibilidad (todas las peticiones podrán atenderse o bien avisar de que no podrán resolverse) y tolerancia a fallos (el sistema funcionará aunque algunos nodos fallen).

-Ejemplo: bases de datos NoSQL