BT

Microservices Are Conceptually Too Big

| by Jan Stenberg Follow 34 Followers on Mar 09, 2015. Estimated reading time: 2 minutes |

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

Adoption Stage
Style

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.

Tell us what you think

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

Email me replies to any of my messages in this thread

以人为本 by Jiang YD

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

The title is a little misleading by Ethar Alali

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

Do you have one?

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

Email me replies to any of my messages in this thread

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

Email me replies to any of my messages in this thread

3 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT