Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Microservices vs Monolithic Applications

Microservices vs Monolithic Applications

This item in japanese


Using microservices is one way of breaking up a monolithic application to gain increased decoupling, separation of concerns and fast deployment but it’s not the only or even the best way, Todd Hoff states comparing the two architectural approaches.

Todd refers to a twitter debate earlier this year including Adrian Cockcroft, Sam Newman and John Allspaw (Etsy) comparing benefits and drawbacks of microservices and monolithic applications. Adrian started the debate by claiming that Etsy’s presentation at QCon London made it clear to him why monolithic applications are a dead end and that microservices should be used instead to achieve continuous scalable deployments. John claimed that microservices with more options also add more constraints and that a few well-understood tools and patterns bring advantages.

Todd describes Etsy as a successful company where about 150 engineers deploy a single monolithic application more than 60 times a day, and is in his mind a reference for how to build a great site doing things right, using e.g. continuous integration, push button deployment, good monitoring and basically always deploying from the main branch, even though monolithic applications by many are considered an anti-pattern.

One solution to the alleged monolithic application problem is to break it up into microservices, some goals being loose coupling and independent deployment, but Todd questions that microservices is the only or even the best way to achieve these goals and points to Etsy’s way of releasing small changes many times a day as an example of alternatives.

Arguing in favour of the monolithic approach Todd emphasizes that they have always worked. As within a monolith, complexity can also be found in services. He compares libraries with services claiming that as long as the interface is stable they can both be handled as separate products with their own lifecycle. If the interface changes a new version is created irrespective of using a library or a service. Todd believes that a monolithic code base can work well when based on proper software engineering.

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

  • "proper software engineering"

    by Thomas Bradford,

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

    Well that's the problem, isn't it? How many large companies building large monolithic applications are also managing their projects in such a way that it affords developers the time and freedom to perform "proper software engineering?"

  • Re: "proper software engineering"

    by Dan Creswell,

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

    The vast majority of companies understand next-to-nothing of what developers do or how they do it. Thus they cannot directly instruct one to indulge in improper software engineering practice because they don't know what that is anymore than they know what proper is.

    Which brings us to indirectly instructing one to indulge in improper software engineering practice. This is where constraints are set that supposedly force us to indulge in such practice. Except that just isn't true because we actively choose to satisfy the constraints by lowering our standards knowing fully well the consequences.

    In effect, when making that choice, we are complicit. We must blame ourselves as much as others and believing otherwise is one of the fundamental ills of our industry, a grand act of denial.

    Of course, we say we must compromise to ensure project success and keep our jobs. Except that such projects ultimately cost more, are often delivered late and are rarely fit for purpose. Do these companies change? No. They hurl around some blame (if they even notice they failed) and then do it all over again, often with all the same people and all the same results. So there is no success, we don't get fired and the company doesn't cease to trade.

    So projects will overrun with improper practice and with proper practice but inappropriate constraints/expectations. The decision as to which way we fail is ours. We just choose to pretend otherwise claiming we've lost our freedom and don't have time.

  • Microservices and the Big Ball of Mud

    by Jan Stenberg,

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

    Mark Little recently wrote an article about microservices and the big ball of mud.

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

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