Hacker News Reader

Comment by jameshart | Hacker News Reader

I guess you just won’t get traction on HN writing ‘Disasters I’ve seen in a monolithic world’.

If you have never gone through a significant dependency upgrade on a large monolithic codebase, you might not appreciate the value of microservice architecture. I’ve been at companies where the number one technical achievement for a tech organization for an entire calendar year was ‘successfully moved the app from .net 2 to .net 4’. Have you ever gone through the process of integrating an acquired company’s monolith into an acquiring company’s monolith? It’s futile. With a microservice architecture though I’ve seen acquisitions integrate significant systems (things like billing and auth) in a matter of weeks where monolith projects dragged on for years.

Sure, there’s no silver bullets. But there are a lot of problems with monoliths which microservices eliminate. Not without trade offs, naturally.

View on HN

> I guess you just won’t get traction on HN writing ‘Disasters I’ve seen in a monolithic world’.

Though I think mostly that is because the discussion there has been well trodden already. Microservice Architectures are relatively new, less completely explored, and less familiar to many.

There are new and interesting mistakes to make (the biggest two being to use this model where it is not at all appropriate, or cargo-culting and not really understanding what its advantages are so not actually taking advantage of them) where most of the "interesting" problems to be had in the monolithic world have been well documented for quite some time (which is why new models pop up, to try remove the potential for these problems in some, many, or even most, cases (anyone who says method X is better in all cases should be treated with deep suspicion)).

In those organizations, I highly doubt microservices or monolithic decisions would have made a difference.

Disorganized management won't magically get fixed if the root problems of ASAP, priority, techinal debt, etc features aren't fixed.

The fact that the organization was trying to combine two large monolithic codebase into one is an obvious smell that technical decisions are made by someone non-technical.

Well yes, acquisitions are frequently decided by nontechnical people. That’s where the money comes from.

For better or worse, nontechnical people sometimes make decisions. One of the jobs of a software architecture is to be robust in accommodating the consequences of them. Monolithic architectures frequently aren’t.

Microservices was a terrible buzzword and definitely made me re-evaluate the kool-aids I had previously drank from Martin Fowler.

We already had services and service oriented architecture. Finding the correct size and establishing boundaries between services is a huge part of a correct architecture.

Building a monolith was a first step, then companies were branching out different parts in other services, when and if needed (eg. when doing acquisitions, as you mentioned).

Microservices just pushed companies to write services that were too small (I still remembers thought leaders praising 20 lines microservices) and declare dinosaurs everyone doing monoliths.

Your ‘successfully moved the app from .net 2 to .net 4’ becomes `updated all versions of the logger in all microservices`.

Key difference for me between microservice architecture and service oriented architecture is the move away from a shared database. Switching to small, single purpose datastores is the much bigger shift in thinking than small, single purpose components.

Reply on news.ycombinator.com