Why our team cancelled our move to microservices

Why our team cancelled our move to microservices

  • September 8, 2019
Table of Contents

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. 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.

Source: medium.com

Share :
comments powered by Disqus

Related Posts

From Monolith to Microservices

From Monolith to Microservices

To tackle this monolith, we initially began exploring how the codebase was built. It had a high level of complexity with too many features baked into the all-in-one code, as well as thousands of unit tests. Without consistent APIs, many nonstandard integrations, or one-offs, had been deployed.

Read More