Sistemas Auto-Contenidos

 

Explorando los SCS

Hace unos días leí un artículo en el que el autor mencionaba tres tipos importantes de arquitecturas de software: monolitos, microservicios y SCS (Self-Contained Systems). Aunque ya estaba familiarizado con los monolitos y los microservicios, la arquitectura denominada SCS me resultó un tanto extraña y me despertó la curiosidad. Decidí investigar un poco más sobre este enfoque y compararlo con otros más conocidos.

¿Qué es un SCS?

Los SCS (Self-Contained Systems), que en español se pueden denominar Sistemas Auto-contenidos o más comúnmente Sistemas Autónomos, son un enfoque arquitectónico donde cada sistema dentro de una aplicación más grande es completamente autónomo. Esto significa que cada SCS:

  • Gestiona su propia interfaz de usuario: Cada sistema tiene su propio frontend, lo que le permite operar de manera independiente en términos de presentación.
  • Implementa su propia lógica de negocio: Toda la lógica relacionada con un dominio específico del negocio está contenida dentro de ese SCS.
  • Maneja su propio almacenamiento de datos: Cada SCS tiene su base de datos o mecanismo de almacenamiento, evitando la dependencia de una base de datos centralizada compartida.

Este enfoque permite que los SCS se desarrollen, desplieguen y mantengan de forma independiente, lo que facilita la escalabilidad y la evolución del sistema en su conjunto. Los SCS se comunican entre sí de manera asincrónica o a través de APIs, pero con un enfoque en minimizar las dependencias directas, lo que los diferencia de otras arquitecturas.

Comparación con Monolitos y Microservicios

  • Monolitos: Un monolito es una aplicación grande y unificada en la que todos los componentes están interconectados y desplegados como una sola unidad. Aunque es simple de gestionar en sus primeras etapas, puede volverse difícil de escalar y mantener a medida que crece en complejidad.
  • Microservicios: Los microservicios descomponen una aplicación en servicios pequeños y autónomos que se comunican entre sí mediante APIs. Este enfoque facilita la escalabilidad y la evolución independiente de cada servicio, pero puede incrementar la complejidad operativa y los desafíos de coordinación entre servicios.
  • SCS (Sistemas Autónomos): Los SCS, por otro lado, son sistemas que funcionan como “mini-aplicaciones” independientes. Cada SCS gestiona su propio conjunto de funciones, datos y lógica de negocio, y se comunica con otros SCS de manera asincrónica o a través de APIs, pero minimizando las dependencias directas.

Por qué los SCS no son tan conocidos en EE.UU. o Latinoamérica

A pesar de sus ventajas, los Sistemas Autónomos no son tan ampliamente conocidos o adoptados en EE.UU. o Latinoamérica por varias razones:

  1. Origen y Popularidad Regional: El enfoque SCS se originó en Alemania y ha ganado popularidad principalmente en Europa, especialmente en empresas que gestionan sistemas de gran escala y que buscan modularidad sin la complejidad extrema de los microservicios. Este patrón ha tenido menos difusión fuera de Europa, lo que limita su conocimiento y adopción en otras regiones.
  2. Dominio de los Microservicios: En muchos entornos de desarrollo, especialmente en EE.UU. y Latinoamérica, la arquitectura de microservicios ha dominado la conversación sobre sistemas distribuidos y modulares. Debido a la vasta cantidad de recursos, herramientas y comunidades que apoyan los microservicios, muchas empresas prefieren este enfoque, dejando a los SCS menos explorados.
  3. Menor Disponibilidad de Documentación y Casos de Estudio: Comparado con los microservicios, que cuentan con una gran cantidad de libros, artículos y estudios de caso, los SCS tienen una documentación más limitada. Esto dificulta su aprendizaje y adopción en regiones donde los recursos y referencias son cruciales para tomar decisiones arquitectónicas.
  4. Preferencia por Modelos Centralizados: En algunas organizaciones de EE.UU. y Latinoamérica, hay una preferencia histórica por modelos centralizados y monolíticos, o bien una transición directa hacia microservicios. El enfoque SCS, que busca un equilibrio entre ambos, puede no haberse popularizado debido a esta tendencia hacia los extremos de centralización o completa descomposición en microservicios.

Cómo se Comunican los SCS entre Sí

Una de las preguntas que surgió al investigar sobre SCS es cómo estos sistemas autónomos se comunican y comparten información entre sí sin perder su independencia. Aquí algunos métodos comunes:

  • Comunicación Basada en Eventos: Los SCS publican eventos a un intermediario de mensajes cuando ocurren acciones importantes, como “Producto Actualizado” o “Estudiante Inscrito”. Otros SCS pueden suscribirse a estos eventos y reaccionar según sea necesario.
  • APIs RESTful: Aunque cada SCS es autónomo, pueden exponer APIs que permitan a otros sistemas recuperar o actualizar información en tiempo real cuando sea necesario.
  • Replicación y Sincronización de Datos: En algunos casos, los SCS pueden mantener copias locales de datos provenientes de otros sistemas, lo que les permite operar de manera independiente mientras sincronizan datos de manera periódica o bajo demanda.
  • Servicios Compartidos (Uso Limitado): Aunque se busca minimizar las dependencias, algunos servicios compartidos como la autenticación pueden ser utilizados para mantener consistencia en áreas comunes a todos los SCS.

Conclusión

Los SCS ofrecen un enfoque interesante para organizaciones que buscan modularidad y autonomía en sus sistemas sin la granularidad extrema de los microservicios. Aunque pueden parecer un conjunto de monolitos relacionados, los SCS se diseñan para operar de manera independiente y minimizar las dependencias, facilitando su evolución y mantenimiento. Explorar este tipo de arquitectura puede ofrecer nuevas perspectivas y soluciones a desafíos comunes en el desarrollo de software moderno