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


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • 以人为本

    by Jiang YD,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    organisational factors 比 technical factors 更实在。我觉得技术因素需要适应组织因素并为其改变

  • The title is a little misleading

    by Ethar Alali,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The conflation of organisational and technical optimisation isn't actually a problem. You should optimise ONLY for organisational factors. The technical optimisation should come to support that, since an optimised technical factor should only ever be aligned to the overall performance of the business. A dichotomous relationship is symptomatic of still somewhat siloed thinking (i.e. IT even if agile and DevOps in one place, the bulk of the business itself in another and perhaps BI in a third place - all aligned to different needs).

    Microservices are not a solution to that, at that point in time, since the organisation isn't mature enough to support these apparently 'conflated' microservices. Microservices just appear that way. Slowly evolve the company and eventually microservices wil become an appropriate fit. Until then, they are each other's antipatterns.

  • Link to the presentation?

    by Anders Norgaard,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Do you have one?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p