Hacker News Reader

Comment by silisili | Hacker News Reader

> Usually, the comments on HN/Reddit are polarised by a single group of people who have the same opinion,

Can't speak for Reddit, but that's not at all the case here. For example, I often speak of my hatred of microservices here. I'll get some upvotes and agreement, some people telling me it's a dumb opinion, and some people telling me we're doing it wrong and explain their right way. Believe it or not, I learn a lot from different people and their experiences.

I can't think of a single topic that seems to be prevelant here that doesn't have a sizeable amount of disagreement, in fact. And I wouldn't have it any other way.

View on HN

I don't think microservices are silent majority. They seem like more of a blogger architect who likes to tinker with stuff thing.

I would expect the true silent majority just uses monoliths. If it works and doesn't make people complain every day when they work on it, why use a microservice? That's more work.

Everyone likes to think of microservices as a modern high tech thing, but to me it seems like old fashioned unix stuff, that appeals to people who enjoy doing simple weekend projects, trying to make their job into a series of tiny projects of the type they might do at home for fun.

The focus seems more on individual parts than on the vision of the complete project.

Of course it seems to just mostly move complexity into the high level gluing it all together, and spread it out in bits of interface code, but if you are more interested in working on simple but interesting challenges, and don't mind the more hands on dev ops maintenance work, and aren't that into building complex systems, I imagine you would like it.

I've joined a company with a silent majority monolith, and joined at the inflection point where they realise their monolith is strangling them...

If your dev guide in the wiki says "to run unit tests, use docker-compose exec monolith test some.package.test_class", you're in danger.

This company needs to start breaking the monolith down into, well maybe not microservices, but at least smaller monoliths, if they want to achieve what they want to achieve.

The hard part is to recognize when to start moving towards microservices.

As long as the team is small enough and the core product is still undergoing rapid development, I think it's premature to use microservices. Too much overhead without any tangible benefit.

But with multiple teams working on different parts of a profit-generating system, it makes sense to the transition - ideally, having a relatively stable core monolith and developing new services around it, occasionally extracting some core functionality as needed.

That's a deployment and dependencies issue, not a monolith issue.

The microservices equivalent needs Kubernetes to run your tests.

Usually not for unit tests.

Well you can do the same with a monolith too right, just pull some random code out of the codebase and compile it without anything else, plus the tests for it. It gives the same guarantees as the microservices unit tests.

Not when it's Django, sadly.

Can you explain what is wrong with the test command?

I don't know what _they_ think is wrong with it, but if you need docker-compose to run unit tests, they're not unit tests. Unit tests really shouldn't have external dependencies of the kind docker-compose helps to provide.

That's more of a terminology point IMO, and probably not what they were talking about.

I'm guessing it is something like "works with version X of dependency Y which is only available on Linux distro Z" and distro Z is only available with an ancient kernel which makes it a pain to run on modern laptops so everyone just develops in Docker.

I have no particular dog I wish to back in the Microservice vs Monolith debate. But I think since you joined at the inflection point it's probably worth it to take a good look at why their monolith landed them in such a poor place and so that no matter what direction you go for the future you can at least make different mistakes.

Microservices won't magically fix issues with tightly coupled components or poor achitecture. Those problems can and do still happen with them.

No, you just need a sane test architecture. I've worked on monoliths, and none of them required docker compose for unit tests.

Now, you may need some extra infrastructure for integration tests, depending on how you architect them, but that's also not a requirement. You could also use mock services, test containers, ... - essentially there's enough ways to make this sane.

It's annoying that people take badly written monoliths as an excuse to proceed to write badly written microservices.

Let me just say, Django was designed to be a monolith.

Also, people who put code that reaches out to external systems in __init__.py are the devil, but the people who decided "sure, let's execute code when we import a module or package, even if we're just importing it to use a class, that sounds reasonable" are the super-devil.

>The focus seems more on individual parts than on the vision of the complete project.

Quite the opposite - they think about architecture as opposed to a crappy unmaintainable hodgepodge that the vast majority of web applications are.

Inferiority of web-based apps doesn’t come from nowhere.

The silent majority are mostly corporate devs building internal tooling. Microservices are a fantastic method for building distributed, horizontally scaling, dynamic services in a way that's sane. But the overwhelming vast majority of services would be perfectly ok with a simple monolith that occasionally gets a VM spec bump.

> horizontally scaling

I have never seen services (of any size) succeed in a place that wasn't using them to do vertical partitioning of a system.

I imagine you are probably talking about horizontally scaling each of those vertical partitions, but the phrasing is really confusing.

Yeah, I'm probably just explaining poorly. That's what I was thinking: horizontally scaling subsets of your verticals that need it (they don't usually all need to scale at the same rate)

Oh, it's not you explaining it poorly. That's just the usual idiom, that anybody that already knows the meaning will instantly understand.

My criticism is more general, that the usual idiom is confusing and misleading for people that don't know it already. Maybe it shouldn't be usual.

> but to me it seems like old fashioned unix stuff

It's exactly this for me. Unix has been around longer than I've been around and will outlive my career if not my life. Components have been successfully updated and replaced mostly without significant disruption. Unix is a model for producing and maintaining complicated systems.

I forget the exact quote I read on HN once, but it made me laugh, all concurrent systems will eventually recreate Erlang. If you think of Microservices and even Kubernetes Clusters and company, they're all barely doing a fraction of what Erlang can do, because Erlang had the right concept, it was just 40 years ahead of its time.

Virding's First Rule of Programming:

"Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."

That's the one! Thank you! I didn't realize it was from one of the founders of the language, which actually makes a LOT of sense. I wonder what tech he saw back then that made him think of it, I can only come up with more modern examples.

He was writing in 2008, so probably some Java thing

http://erlang.org/pipermail/erlang-questions/2008-January/03...

I saw the quote attributed to a book they wrote back in the late 90s as well, but I'm not sure how accurate the attribution is... If it is accurate, I'm genuinely curious what project in the 90s was remotely comparable. The answer could be as simple as whatever they were using prior to creating Erlang.

I feel the same way about OAuth2.

It's very complex. It has it's business use cases, but if you don't need it (or don't need full-blown OAuth2) then don't use it. If you're worried about the future separate auth user from account internally in your application (SSO ready) and move on.

It sometimes feels like there's a cabal of people who think the more complex something is, the more skilled they are for being able to implement it. That's not really where the skill lies for an engineer.

Microservices vs monoliths with nothing in between is a false dichotomy itself of course. There's been SOA and n-layer applications for decades now. Not every service is a microservice and not everything bigger than a microservice is written as one big application.

From the discourse on forums these days, someone fresh to the field might think there's no such thing as an internal API or an ongoing ETL layer without breaking each feature down to its own container and throwing the whole thing on Kubernetes. All those systems that are two to four layers and decomposed into half a dozen or so parts at the outer interface still exist in the world, even if they're not on track to be one container per feature.

I think your experience actually proves the point and touches on why many dangerous and crazy POV have also been getting so much air time in the news.

Let's say you have 2 opposing POV: A or B

"A" has a silent majority so only 5 of the 5,000 people post a comment about A being the right POV.

"B" is a passionate minority so 5 of the 50 people post a comment about B being the right POV.

To the viewer, it looks like a balanced discussion and a topic open to much debate, both sides have equal voice but in reality "A" is by far the most accepted position.

It also shows up in bad news writing and science writing.

For example you have 99% of scientist agreeing about global warming.

You have 1% who disagree.

So they write that "Some scientist disagree" and it sounds like its up for debate or maybe a significant portion know something the others don't.

In the pursuit of a "Balanced" POV they tip the scales vs just reporting where the scales are at accurately.

> but that's not at all the case here.

Very sorry but it absolutely is the case here. Your anecdotal data is limited to you, but HN very much operates as a hive mind, it just hides it better.

Considering this place to be "superior" to other places only leads to complacence and further strengthens the echo chamber.

> HN very much operates as a hive mind

Most of us here agree with you.

The phrase "HN/Reddit" is weird by itself. This place feels so different from Reddit.

HN is like what Reddit used to be. Heavy emphasis on news, technology. Usually some interesting debate in the comments when they were added.

Found some screenshots from the early years:

https://www.reddit.com/r/historyofreddit/comments/q1zks/redd...

That's what I expected. It used to be niche.

It still is - it has just moved to the sub-reddit's now.

The only niche tech subreddit I know of that's anywhere near the level of discourse on HN is r/zfs, and even then, it's mostly people asking for help because they broke their zpool; it's just that the answers are often quite detailed in their explanation. r/sysadmin is Windows-centric but isn't awful in terms of depth of knowledge. r/kubernetes is mostly blog spam and "can you troubleshoot <problem I've put zero effort into solving> for me," and r/devops is mostly "how do I get a job in devops."

HN culture is quite like a subreddit IMO. The only real difference is that it doesn't receive drive-by comments and upvotes from redditors browsing /r/all while not subscribed to it. This helps to curb most forms of reddit humor

However; check out subreddits like /r/rust, it looks a lot like HN

For this reason alone, the two sites are night and day to me. I don't have the stomach or nerves for Reddit anymore, but I can sip the cool, refreshing draught that is HN all day long.

r/rust does look like HN, but that's for a very narrow topic. HN has broad topics with a niche user base.

Wonder how much of a difference it makes that most HN users can't downvote.

I have a slightly different view on microservices. They are not a technical solution but a business solution. Technically it's a fairly dumb idea ... but if every microservices is actually a tiny business function (that is some "atom" of the domain) then suddenly the business can see and manipulate and monitor and see stats in usage for each atom of its processes. Things become isibke that were hidden in giant "oh the refund section of screen four does that and bobbys team is working on that".

I think Programmer Anarchy was a early adopter of microservices and as they ran a business as developers I think this may have been useful

> Usually, the comments on HN/Reddit are polarised by a single group of people who have the same opinion,

> polarize: divide or cause to divide into two sharply contrasting groups or sets of opinions or beliefs. > "the cultural sphere has polarized into two competing ideological positions"

Hmm...

At school, they used to say that two don't fight if one doesn't want to. Except that was a lie. Bullies didn't get the memo, while teachers and parents were happy to repeat the lie, wash their hands and blame the victims.

I also think HN usually come from the same background with predominantly comments from California USA or USA in general.

Compare any topic relating to capatilism, the plights of the low income classes or politics in general. I often amuse myself comparing the takes between the two sites relating it those topics.

Also HN is more clinical, it discussed the death of Swedish reporter like it was a cold case ready to be ripped through.

And also more easily distracted by seemingly innocent open questions like in politics for example "Why is it X job to care about this?" since you can't dismiss it with a short meme it creates discussion that the OP only wanted to distract from the original article.

Apart from that HN discourse is 100% better than reddit and I agree with you in some terms.

It's getting better, but e.g. try talking about race.

Reply on news.ycombinator.com