Common advice regarding microservice architectures is to begin with a monolithic application and then break it into microservices, such as per Martin Fowler’s observation of the difficulty of getting bounded contexts right from the outset. On the opposite side of the spectrum, others such as Stefan Tilkov make arguments for starting with a microservice architecture “to allow for fast, independent delivery of individual parts within a larger system.” We go one step further than Mr. Tilkov by proposing that it can be a good investment to start with a microservice architecture when long-term product design is not clear, in order to to be able to later identify business-critical components to merge and refactor into small, but highly maintainable monoliths while isolating low priority technical debt in non-critical microservices that require little to no maintenance. This approach aims to expedite initial release as much as possible, while both retaining development agility in response to customer feedback/usage and minimizing the long-term cost of strategic technical debt incurred along the way. We describe how this originally unintentional approach played out over two years for the information retrieval infrastructure of Watson Discovery Service and why we are now formalizing it.

You must be a Member to view this post and you are currently not logged in.

You can either log in below or sign up here.