Making the case for Rails monoliths over microservices

A cautionary tale of a CTO and microservices. Here are some considerations that should be made before splitting a Rails monolith.Once upon a time, a small company was running an MVP Ruby on Rails monolith. Things seemed to be going well. Then one day, they hired a new Chief Technology Officer (CTO). He was a trusted individual with a strong background at other successful companies. He had some negative experiences with Rails monoliths in the past and wanted to get ahead of that here. He led the development team to split their monolith into microservices. As time went on, work slowed. More people were hired. Testing was isolated to within each microservice, providing less confidence. Microservices felt too coupled, leading to difficult local development setups. It became clear that the team was 40% LESS productive despite increasing the team size 400%! And there was a looming deadline to comply with new regulations! The team had to cut their losses and migrate back to a Rails monolith architecture – time and effort that could have been avoided if the team was able to sit with the following questions and considerations:.