Escribe bibliotecas en lugar de servicios, cuando sea posible
Los defensores de “bibliotecas en lugar de servicios” sostienen que entregar código que los usuarios puedan ejecutar por sí mismos les da control sobre las actualizaciones, evita roturas inesperadas de APIs remotas y reduce la dependencia de infraestructura de terceros. Otros responden que los servicios suelen ser más fáciles de monetizar, observar y operar a gran escala, especialmente cuando hay estado compartido, bases de datos o soporte multilenguaje. Muchos concluyen que un enfoque pragmático es diseñar la funcionalidad central como bibliotecas reutilizables y, cuando haga falta, envolverlas en servicios ligeros o herramientas de CLI, eligiendo según la arquitectura, la estructura organizativa y las necesidades del cliente.
Alcance de “bibliotecas vs servicios”
- Muchos están de acuerdo con la intuición del artículo: por defecto, usar bibliotecas y añadir servicios solo cuando sea necesario.
- Otros sostienen que esto es una simplificación excesiva y depende del contexto (escala, cumplimiento, localidad de datos, tamaño del equipo, monetización).
Fallos, actualizaciones y control
- Las actualizaciones de bibliotecas solo se rompen cuando el usuario decide actualizar; pueden revertirse fácilmente.
- Los cambios en servicios pueden romper clientes en el momento elegido por el proveedor; los SLA y los contratos mitigan, pero no eliminan ese riesgo.
- Algunos ven las migraciones forzadas a través de servicios como algo hostil para el usuario; otros dicen que las actualizaciones coordinadas son el precio del coste compartido de desarrollo y de los arreglos de seguridad.
- Ambos modelos sufren problemas de versionado: bibliotecas con muchas versiones en circulación frente a servicios con capas de compatibilidad y API versionadas.
Almacenamiento de datos y arquitectura
- Objeción clave: muchos servicios dependen fundamentalmente de bases de datos y estado compartido; llevar eso a una biblioteca descarga operaciones complejas sobre los usuarios.
- Sugerencias: definir interfaces de repositorio y permitir que los usuarios “traigan su propio almacenamiento”; usar backends comunes (Postgres, APIs de S3) o personal data pods.
- Contraargumento: el almacenamiento es intrínsecamente complicado (latencia, rendimiento, instantáneas, cifrado, gestión de corrupción); las abstracciones tienen fugas y la coordinación es deficiente.
Dinámica organizativa y escala
- En muchas empresas, la nueva funcionalidad por defecto se convierte en un microservicio; las bibliotecas son menos comunes y más difíciles de coordinar entre equipos y repositorios.
- Las culturas de monorrepo a veces trasladan la carga de las actualizaciones a los propietarios de las bibliotecas, lo que desincentiva cambios de ruptura triviales, pero aumenta su responsabilidad.
- Algunos ven el uso intensivo de servicios como una solución alternativa a problemas políticos/de coordinación más que como una necesidad técnica.
Monetización, control y autonomía del usuario
- Los servicios son más fáciles de monetizar, observar y controlar; las bibliotecas son más difíciles de vender y dar soporte, pero ofrecen autonomía a los usuarios y evitan el bloqueo con un proveedor.
- Se citaron ejemplos: dispositivos IoT y productos SaaS que podrían haber sido bibliotecas locales pero en su lugar son servicios recurrentes y de coste opaco.
Guía práctica y enfoques híbridos
- Patrón habitual defendido: diseñar siempre la lógica central como una biblioteca y luego envolverla opcionalmente como:
- Un servicio ligero (HTTP/gRPC, etc.).
- Una CLI al estilo Unix que lee/escribe datos estructurados.
- Heurísticas: lógica pura/algorítmica → biblioteca; componentes ligados a almacenes de datos privados, estado compartido pesado o infraestructura especializada → servicio.
Confusión terminológica
- Varios comentaristas encuentran confusa la amplia definición de “biblioteca” del artículo (cualquier software que el usuario pueda ejecutar) frente al significado habitual de “dependencia no ejecutable”.