Businesses can go pretty far with a monolith

In recent years and with the trend of Microservices, a lot of Software Engineering teams think that they need to jump into that bus right from the start; other teams just assume that a framework will provide the necessary structure not just for current problems but for future problems too.

Both assumptions are misleading because neither of them considers one crucial aspect of software development: Software Architecture.

Microservices doesn’t prescribe any type of architecture per service. The decisions related to the structure are up to the developers. Software Architecture problems won’t fade away if the team decides to migrate towards Microservices.

In a Monolithic Architecture, the tendency is to follow whatever pattern and structure the framework provides. On the opposite side, starting with a monolith also requires establishing a structure that supports the business, not one that supports the tool used to provide such a solution.

Several of us at Root had experienced the challenges of trying to grow an engineering team on top of a large Rails code base, and we knew at some point we’d want to consider alternative architectures. If all went well, we weren’t going to be staying small forever, and our initial Majestic Monolith wouldn’t end up being so majestic if we tried to continue down that path.¹

The architecture of a system is defined by how people communicate their manual processes.

The best course of action is to start with a monolith but not prescribed or attach the entire application to what any framework suggests should be the default structure. This will prevent not just having a hard monolith to maintain but also having an easy transition towards microservices if the need arrives.

[1]: [Dan Manges] (2018): The Modular Monolith: Rails Architecture(https://medium.com/@dan_manges/the-modular-monolith-rails-architecture-fb1023826fc4)↩︎↩︎