5 ms·

I think the underlying point, as expressed by the author, is that trendy new architecture patterns will never be a panacea for bad engineering, though that's of

I think the underlying point, as expressed by the author, is that trendy new architecture patterns will never be a panacea for bad engineering, though that's often how they're implicitly sold as ideas.

rjkennedy98 7y ago
It is actually sold as a way to fix bad engineering? I've literally never heard that before. I think almost everyone knows that microservices are hard. On the other hand they are often sold as a way to increase developer velocity. And I do sometimes wonder if that is the case (based on personal experience).
- bcrosby95 7y ago
  Yes. I see people push microservices all the time because their monolith is poorly designed. If your monolith is messy, it's on you, not monoliths.
- mrits 7y ago
  We did a massive rewrite of a 7 year old giant code base to microservices gradually over a couple years. One of the only few positives that we gained from it was that when we crashed we didn't bring down everything at once. The biggest negative was that we ended up with an extremely noisy event bus that made backups and diagnosing out of sync issues very problematic.
- cc81 7y ago
  Yes, it is a pretty common saying that it forces separation of concerns and avoids the spaghetti that monoliths end up like. People are selling it as easy. You can deploy them independently, each service is small with low complexity. That it is not that easy in reality and that the total complexity increase is so big is not told as often. There is a team at my work with 6 developers developing something that processes a couple of gigs of data each day and has a front end serving maybe a hundred users total, I would guess 20 would be logged in at the same time. Kubernetes, 10 microservices, 2 different types of databases.
dmos62 7y ago
> architecture patterns will never be a panacea for bad engineering That's undeniably true; but, it's too easy to slip from that to "good engineering doesn't require good architecture, good technology, etc." I think it has to be stressed that adapting the big picture features of a solution is as important as adapting the finer features.

rjkennedy98 7y ago

It is actually sold as a way to fix bad engineering? I've literally never heard that before. I think almost everyone knows that microservices are hard. On the other hand they are often sold as a way to increase developer velocity. And I do sometimes wonder if that is the case (based on personal experience).

bcrosby95 7y ago
Yes. I see people push microservices all the time because their monolith is poorly designed. If your monolith is messy, it's on you, not monoliths.
mrits 7y ago
We did a massive rewrite of a 7 year old giant code base to microservices gradually over a couple years. One of the only few positives that we gained from it was that when we crashed we didn't bring down everything at once. The biggest negative was that we ended up with an extremely noisy event bus that made backups and diagnosing out of sync issues very problematic.
cc81 7y ago
Yes, it is a pretty common saying that it forces separation of concerns and avoids the spaghetti that monoliths end up like. People are selling it as easy. You can deploy them independently, each service is small with low complexity. That it is not that easy in reality and that the total complexity increase is so big is not told as often. There is a team at my work with 6 developers developing something that processes a couple of gigs of data each day and has a front end serving maybe a hundred users total, I would guess 20 would be logged in at the same time. Kubernetes, 10 microservices, 2 different types of databases.

dmos62 7y ago

> architecture patterns will never be a panacea for bad engineering That's undeniably true; but, it's too easy to slip from that to "good engineering doesn't require good architecture, good technology, etc." I think it has to be stressed that adapting the big picture features of a solution is as important as adapting the finer features.