Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I count myself among those who are almost irrationally opposed to microservice anything.

However, in my quest for the holy monolith I came across small teams who against all odds were adequately functional despite this heretical paradigm. They were definitely building a distributed monolith which was a monster to run locally. But, it worked. They were shipping and most importantly it matched their culture of small isolated islands of functional specialists with as little communication between them as possible.

I will refrain from commenting on the virtue of communicating as little as possible, but sometimes you just got to make the best of a situation.



Did it seem like that team was aware of Conway's Law and was actively considering it in their architectural/system design decisions?


> Conway's Law

It can be the cause or the consequence. If your team peels a microservice out of a monolith and assign a couple of developers to work on the newly-created service, those guys will be heads down on their work and focusing on their project.

If management does not go out of it's way to rotate people around projects, you'll end up with ad-hoc organizations around their service architecture.


They can consider it all they want, that won't change the outcome. It is inevitable.


You can't avoid its impact, but you can either work with it or work against it. I assume that was more the point.


I don't think you can, actually, from the level of a team. If you're designing a bridge, you can work with gravity, or against it. But if you're a car on the bridge, you can't work with or against it; the bridge either will hold you up or it won't, your car will either go or it won't.

Conway's Law is about how your organization's communication structures work, and how that inevitably leads to specific outcomes. That outcome is an eventuality for the team, because the team can't change the communication structure. They can design the best damn microservice in the world, and the resulting use of it could still be shit, because the other teams aren't necessarily up to snuff. And you still have all the baggage of dealing with those intra-team, intra-service issues.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: