Comment by staticassertion | Hacker News Reader

Comment by staticassertion | Hacker News Reader

Parent Full thread

staticassertion

I'm sorry that at your day job you deal with poorly built software, but that doesn't sound like an argument against microservices. Cascading failures are one of the first things you should have dealt with in your design (and eventually they would become a benefit since your failures have nice boundaries, and are explicit in your code).

You sound extremely bitter, and extremely pompous with your "all the other devs are just dumb, I'm the only one who can see through the hype" attitude; especially your comment about younger developers.

> good software design boils down to designers with substantial experience, good judgment, and the authority and respect to see their designs faithfully implemented.

Like this - projecting much?

Microservice architecture is a tool. It isn't a replacement for you or your job. It isn't a replacement for communication. There is a recognition that Conway's law is a serious problem in orgs as they scale - microservices (in part) attempt to deal with this.

There are many other benefits. It makes things like DDD easier, since your domains and services can be tied closely together.

It makes scaling at a finer grained level easier - a problem a lot of companies may run into as they scale from a few customers to many. I've certainly run into this problem at a company that was moving from distributed monoliths to microservices.

It has downsides - a more complicated rollout / deployment structure, less shared knowledge of services, and others.

Acting like it's only hype or just 'those darn young devs' makes you sound really silly, especially as someone who's seen Microservices both fail miserably and turn things around completely (in a positive way) for companies.

You say it comes down to experienced developers making good decisions - can you not see that Microservices are designed to help with that? The way you break apart your services, their domains, the 'bounded context', etc is all a tool to help you build things well.

>You sound extremely bitter, and extremely pompous with your "all the other devs are just dumb, I'm the only one who can see through the hype" attitude; especially your comment about younger developers.

I didn't say anything about "younger developers". Which comment are you referring to specifically?

Also, I hardly think I'm the only one who can see through the hype. Check out the rest of this thread. Most of the replies, including the parent post to which I was replying, could be characterized as anti-microservice.

Tech fads are rarely about good developers. They're normally about non-developer technical managers and/or bad developers, who are sometimes more self-aware than they appear at first glance and are consciously seeking diversions. Good inexperienced devs may be taken in by the first fad or two, but they generally come to realize that it's same shit, different day within a few years, and their skill level limits the direct damage (though their adherence to the fad may set the stage for additional indirect damage).

It was not my intent to offend or accuse anyone by criticizing this particular tech fad, and I'm sorry that you appear to have taken it personally.

---

I don't think we disagree about "microservice architecture" as a tool. Like all tools, it needs skilled practitioners to be used well. "Microservice architecture" is a bad descriptive term for a tool because it's too broad to have much specific meaning, but I accept that some people could use it to describe something decent, which I've already stated.

As my post said, however, I was discussing "microservice architecture" as a fad, which, let's be honest, is the case across the vast majority of cases in which the term "microservice architecture" is used.

People who aren't blindly chasing buzzwords are more likely to think of their architecture as a holistic entity built from a variety of useful and specific components rather than a zipped-up incarnation of a single $HOT_TREND, and are thus more likely to describe it descriptively, e.g., "we try to employ a reasonable separation of concerns", "we have a handful of independent services on the back-end", etc.

These things show a thoughtful, specific consideration of principles rather than literalist word-thought, and it's a good guideline (but, like all guidelines, imperfect!) for whether or not someone has processed what they're discussing or whether they're mindlessly mimicking the people they consider authoritative/influential.

It was not my intent to offend reasonable, thoughtful engineers who have implemented what they call "a microservice architecture". I meant only to indicate that this terminology is a red flag for a tech fad, under which many unreasonable, thoughtless "engineers" are seeking cover.

My personal recommendation would be to consider the terminology lost and not develop a new buzzword to replace it, as that will surely become lost too (see also: "SOA"/"service-oriented architecture", the previous incarnation).

You edited your original response. I was going to reply and say that HN is not a place that is safe to have an opinion that dissents from the hive mind. Unless you follow neatly along, be prepared for the blowback. ¯\_(ツ)_/¯

Yeah, I decided it wasn't worth the potential contention right now -- I have some stuff I'm trying to wrap up before I head out for some holiday festivities with the kids and I didn't want to worry about the shitstorm it may've stirred up. But I appreciate your comment; thanks for expressing it. As we know from the blurb I ended up snipping, I can vouch for that first-hand. I was just a little surprised to see it so blatantly.

Reply on news.ycombinator.com