Why our team cancelled our move to microservices

Recently our development team had a small break in our feature delivery schedule. Technical leadership decided that this time would be best spent splitting our monolithic architecture into microservices. After a month of investigation and preparation, we cancelled the move, instead deciding to stick with our monolith. For us, microservices were not only going to not help us; they were going to hurt our development process. Microservices had been sold to us as the ideal architectural for perhaps a year now. So we were surprised to find out they weren’t a good fit for us. I thought it would be interesting to present a case study of our experiences, and why our team decided against them.

Identifying problems and early compromises

We were heavily reliant on a third-party

Our application is a custom UI over the top of an existing external product, integrating some of our custom business rules and presenting a touch-friendly user interface. Our client is a UWP app, and we have a range of back end services that transform between our domain and the third-party’s domain.

Building on top of a third-party impacted how we could divide our domain into microservices. For example, our application occasionally has to convert features between domains. Making one part of the third-party’s domain act and feel like it was part of a different domain in our UI. This swap was not so bad when we had a single service between our front end and the third-party. However, the domain switching caused us much confusion when we tried to split our domains into separate microservices. Did our microservices follow the same divisions as the third-party and we duplicate the front-ends requirements across both services? Or, did we divide the microservices according to our domains and have one microservice need to fetch from two separate areas of the third-party. Both felt like a violation of microservice guidelines and like they would lead to additional coupling.

We frequently worked in tandem with the external party, with features requiring both parties to make changes. Effectively, the third-party was an additional team. Working so closely together meant we had to lockstep our release process with theirs. A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams. Coordinating releases not just across teams, but across…