The fad of "microservices" is a disaster start-to-finish.
Don't be fooled into believing that microservices are popular based on technical merit. As the parent noted, this will just make things harder by trying to micro-ize a startup. Microservices are a thing primarily for their political convenience and dynamic, and they're just dressed up as a technical thing.
[Sideline: most of our technical fads are this way. Err on the side of "letting developers feel important and special while requiring as little effort as possible". Cloud servers are this way because it makes Unix greybeards transparent, and the brogrammer won't have to feel inadequate next to him/her, OR worry about esoteric command-line incantations. Document databases are this way for the same reasons, but replace esoteric command-line incantations with esoteric SQL aggregates (or any useful schema development at all, actually) and greybeards with DBAs. Rinse and repeat for every major development fad.]
Microservices are popular due to Conway's Law [0]. They give an out to people who would rather avoid the difficulties of interfacing, deliberating, and collaborating with other people in their organization. They don't have to decide on a common language, they don't have to decide on a common style, they don't have to do anything; they can go run amok, treating the company codebase as their personal playground, under cover of "super cool new-wavy best practices". "Google is doing it. You want to be like Google, right?"
There are potential good designs that would qualify as "microservice architectures", but I've seen them only rarely. What I see more often is what I like to call "brittle-services": dozens of tiny, fragile, interdependent units that are virtually impossible to debug, instrument, or reason about cohesively.
At $DAY_JOB, we have tons of these; if one service starts to slack off, there is a giant waterfall -- ahem -- of failures that cascades across everything else. The software has been structured this way for purely political reasons, even though no one would be willing to admit it.
Like everything else important, good software design boils down to designers with substantial experience, good judgment, and the authority and respect to see their designs faithfully implemented. Unfortunately for the hoi polloi, it can't be generalized into a formula or paradigm like "use microservices", but it seems in any field, there are many posers eager to try.
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.
Don't be fooled into believing that microservices are popular based on technical merit. As the parent noted, this will just make things harder by trying to micro-ize a startup. Microservices are a thing primarily for their political convenience and dynamic, and they're just dressed up as a technical thing.
[Sideline: most of our technical fads are this way. Err on the side of "letting developers feel important and special while requiring as little effort as possible". Cloud servers are this way because it makes Unix greybeards transparent, and the brogrammer won't have to feel inadequate next to him/her, OR worry about esoteric command-line incantations. Document databases are this way for the same reasons, but replace esoteric command-line incantations with esoteric SQL aggregates (or any useful schema development at all, actually) and greybeards with DBAs. Rinse and repeat for every major development fad.]
Microservices are popular due to Conway's Law [0]. They give an out to people who would rather avoid the difficulties of interfacing, deliberating, and collaborating with other people in their organization. They don't have to decide on a common language, they don't have to decide on a common style, they don't have to do anything; they can go run amok, treating the company codebase as their personal playground, under cover of "super cool new-wavy best practices". "Google is doing it. You want to be like Google, right?"
There are potential good designs that would qualify as "microservice architectures", but I've seen them only rarely. What I see more often is what I like to call "brittle-services": dozens of tiny, fragile, interdependent units that are virtually impossible to debug, instrument, or reason about cohesively.
At $DAY_JOB, we have tons of these; if one service starts to slack off, there is a giant waterfall -- ahem -- of failures that cascades across everything else. The software has been structured this way for purely political reasons, even though no one would be willing to admit it.
Like everything else important, good software design boils down to designers with substantial experience, good judgment, and the authority and respect to see their designs faithfully implemented. Unfortunately for the hoi polloi, it can't be generalized into a formula or paradigm like "use microservices", but it seems in any field, there are many posers eager to try.
[0] https://en.wikipedia.org/wiki/Conway%27s_law