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…