Hacker News Reader

Comment by smt88 | Hacker News Reader

A lot of people may not remember this, but the microservices bandwagon was pushed heavily by Heroku, which (at the time) was a ubiquitous and influential platform among devs working at startups.

Why did they care? Because their particular hosting model at the time really couldn't handle complex architecture, so microservices speaking to each other over HTTP was the only way to do things.

The arguments in favor of microservices at least sounded good enough that they were adopted at a lot of orgs before anyone actually needed the supposed benefits, and it turned into a big mess.

View on HN

Yep. Microservices were pushed hard by Martin Fowler who gives terrible programming advice that always yields extremely lucrative returns for cloud platforms.

I find all the programming advice espoused by all these "gurus" to be very suspect. Especially since most of them seem to come from a theory vs practice POV. For example "uncle bob" delivers a lot of his advice as gospel, but has he actually successfully delivered any software that's used at scale? Same with Martin Fowler et al. I've found advice by people like Linus Torvalds, Steve Yegge, etc. much more interesting/insightful/useful.

I've especially found anyone that is an "enterprise architectural consultant" to be especially suspect.

> For example "uncle bob" delivers a lot of his advice as gospel, but has he actually successfully delivered any software that's used at scale?

I fail to the the point in this cheap ad-hominem.

Uncle Bob is arguably best known by his seminal books: Clean Code, and Clean Architecture.

Clean Code talks about principles such as "you should name your variables well". Why do you believe scale is any relevant?

Clean Architecture talks about a general principle to organize software projects which has traits that are highly benefitial to maintenance, refactoring, and even re extensability. It's a nuanced take on the tried and true layered architecture. Why do you believe scale is remotely relevant?

I know personally Principal Engineers of a couple of FANGS who are great at selling ideas but are outright awful at writing code. One even famously handed POCs to SDE1s to have them rewrite and refactor his code to get some quality in it. Do you really believe in this appeal to authority fallacy to the point where the number of customers hitting a server are the measuring stick for competence and the quality of implementations?

Cuz they espouse advice without having proven it in practice. When I say at scale, I mean they literally haven't shipped any software of note, I don't mean software that's getting hit by an arbitrary number of req/s. Why I think this matters? They haven't demonstrated that their rather arbitrary list of Good Things help make successful software.

Also, some of the advice is just provably nonsensical. Like "uncle" bob says the "ideal argument's number for a function is zero (niladic function)" which is absurd. It either means your function is impure, or is literally a constant.

Most of it is just very shallow stuff that's mostly applicable to Java/C#/OO languages. A lot of the patterns might even be considered antipatterns in other languages.

I just don't find stuff written by these guys very insightful or useful.

Martin Fowler actually later retracted by writing "Monolith First" that's on his wiki.

  you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile.

https://martinfowler.com/bliki/MonolithFirst.html

Yup worked at a company that worshiped him and turns out that his ideas were bad, the architecture was a mess and didn’t work and the company went under.

Thanks for the awesome advice!

[Tangentially related] It’s funny, now that I’m fairly heavy into board gaming, I actually hear much more from Martin Fowler in the board gaming community than the software engineering community.

He plays a lot with the Heavy Cardbord group. [1]

https://martinfowler.com/bliki/HeavyCardboard.html

Does this apply to his books too or just what he says online?

I have read "Refactoring" by Martin Fowler loooong time ago and loved it. It truly made me a better programmer.

I haven't paid attention to his essays as I found them to be way too long and with too much prose and background.

Same with the whole "serverless" thing heavily pushed by Amazon and co which conveniently offer "serveless services". These trends are always pushed by marketing departments at SAAS companies.

> Same with the whole "serverless" thing heavily pushed by Amazon and co which conveniently offer "serveless services". These trends are always pushed by marketing departments at SAAS companies.

This take is pure nonsense. It's highly disappointing to see this blend of ignorant and uninformed take in HN of all places.

Amazon's serverless offerings are the ideal tool for many use cases, specially internal services. Instead of being forced to write, deploy, operate and maintain a dedicated service to handle events, just write the event handlers you need, get it to run in someone else's computer, and forget about it.

Internally, things like AWS Lambda saves a lot on wasted allocated capacity. You don't need to waste allocating a whole box to run a handler each time, say, someone uploads a file to S3.

Microservices are an option, serverless is an option. Use the right tool for the job as much as is required, but don't overdo something that causes unnecessary excessive maintenance.

> Microservices are an option, serverless is an option. Use the right tool for the job.

Developers don't need these "tools" pushed by marketing departments at first place. These aren't technical solutions, these are marketing considerations, solutions looking for a problem AKA "hype driven development".

> Use the right tool for the job

When losing an argument, some people resort to the "it's just a tool, use the right tool for the job" cop-out instead of admitting it's a bad tool and moving on. I don't think it's a good argument at all. It's a phrase you can use to defend anything.

Amazon did it for themselves first.

author of the tweet also worked at Heroku as vp engineering before joining GitHub

Which is probably how he got the idea of microservicing everything at GH

> really couldn't handle complex architecture

What is defined as complex architecture/could you elaborate?

Isn't it usually "a bunch of microservices talking to each other" is complex?

> > really couldn't handle complex architecture

> What is defined as complex architecture/could you elaborate?

Earlier in its lifespan, Heroku didn't have an easy way to add common components of infrastructure to an app. If you wanted to use Postgres + some Postgres plugins + Redis + some kind of queue manager, you basically had to split those out into separate apps that would run on their own "dynos" (to use the Heroku terminology).

That makes sense, right? We all do that now. We don't usually have Postgres running on our application server.

The difference is that Heroku only let those things talk to each other over HTTP at the time, so you essentially had to put a REST API in front of every component of your system.

It was, predictably, a huge mess that I honestly didn't see many companies fully adopting.

Reply on news.ycombinator.com