Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Microservices Are Conceptually Too Big

Microservices Are Conceptually Too Big

Microservices are conceptually too big; they conflate optimizing for both organisational factors and technical factors, but solutions to problems of respective type may not fit together very well, Phil Wills explained in a presentation at the QCon London conference promoting thinking about independent services and single responsibility applications, rather than microservices.

Wills, senior software architect at The Guardian, describes that ultimately their reason for turning to microservices is wanting to produce more useful and reliable software with a faster delivery, or sustainably deliver business impact with minimum lead time, referring to Dan North’s presentation earlier at the same conference.

2008 Wills and his teams completed a project building a new system as a large monolith which was successful in many ways, but they soon discovered that the cost for putting anything more experimental into production was just too high. Part of that was the sheer organisational complexity of making a change to the system; they even for a time had a full time release manager making the coordination needed in order to be able to release every fortnight. Trying to solve this they added placeholders allowing for what they called microapps to be plugged in, replacing parts of the system. This implementation did however not break parts out enough to allow them to fail independently meaning that each part still could bring the system down.

Independent products are for Wills a key factor for how they now think about doing things. Some characteristics of such products are that they have a stable well defined interface, they can be deployed independently and they must own its own data store. This only accomplishes part of their goals though, in achieving the benefits of breaking things down Wills uses the term single responsibility applications with a focus on how to make things resilient and small enough to be able to reason about. One characteristic of such an application is that it has one key metric telling if it performs the job it’s set to do. Another is that they must be isolated from each other; they are not allowed to impact the performance of other applications.

Wills concludes by stating that he is confident in that he has seen a really good team building a monolith but that he also has seen a really good team build something which is composed by a number of microservices and he is very clear that he prefers the latter.

Rate this Article