Rompiendo el monolito

En primer lugar, seamos claros en lo que queremos decir con "Monolito". Estamos hablando principalmente de una aplicación de software que se implementa como un artefacto único donde el código fuente reside en un único repositorio. Es probable que la aplicación exponga varias capacidades comerciales diferentes. Por ejemplo, tal vez tenga la capacidad de administrar los niveles de existencias, así como de aceptar pagos por las compras de los clientes y proporcionar la funcionalidad de informes. No hay nada intrínsecamente malo en esto hasta ahora. Y de hecho, como discutiremos más adelante en este artículo, hay mucho que decir sobre esta configuración. Sin embargo, “Monolith” a menudo se considera una mala palabra en la industria del desarrollo de software. La razón de esto es que la mayoría de los monolitos están mal estructurados. Como resultado, se vuelven difíciles de cambiar porque los cambios deben abarcar muchas áreas diferentes del código base. Con el tiempo, a medida que se agregan más y más cambios (incluso nuevas capacidades), la complejidad del código base aumenta y Monolith se convierte en un problema real para la organización, ya que se vuelve más difícil enviar nuevas funciones a sus clientes. En este punto, muchos equipos pedirían la necesidad de reescribir completamente la aplicación.

Pero... ¿realmente crees que esté es el único enfoque respecto al monolito?

Actualmente, las publicaciones de nuestro blog solo están disponibles en inglés