Microservices vs Monolithic Applications
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.
"proper software engineering"
Re: "proper software engineering"
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
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015