Last year I worked at an electronic publishing firm which had wasted $3 million and 5 years on a Ruby On Rails application which was universally hated by the staff, and which we replaced with 6 clean, separate services. The problem with the Ruby On Rails app is that it was trying to be everything to everyone, which is a common problem for monoliths in corporate environments. But the needs of the marketing department were very different from the needs of the publishing department. A request for a new feature would come in from the blogging/content division which would be added to the Ruby On Rails app, even though it slowed the app down for everyone else.
Six separate services allowed multiple benefits:
1.) each service was smaller and faster
2.) each service was focused on the real needs of its users
3.) each service was free to evolve without harming the people who did not use the service
There was some duplication of code, which suggests a process that is the exact opposite of "Monolith First":
Start with separate services for each group of users, then later look to combine redundant code into some shared libraries.
Six separate services allowed multiple benefits:
1.) each service was smaller and faster
2.) each service was focused on the real needs of its users
3.) each service was free to evolve without harming the people who did not use the service
There was some duplication of code, which suggests a process that is the exact opposite of "Monolith First":
Start with separate services for each group of users, then later look to combine redundant code into some shared libraries.