Microservices Are a Tax Your Startup Probably Can’t Afford
23 points by rmoff
23 points by rmoff
grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
seem very confusing to grug
I kind of dislike the use of “architecture” to describe microservices and monoliths. Architecture in my mind is about how we draw the components; whether a line between them is a network call or a function call is largely an implementation detail. If your modules are all compiled into the same binary or separated by a network feels separate from the actual architecture—the way you break things out into modules.
I suspect mostly microservices just expose other architectural problems—like if a given user request causes one component to call another N times (or N^2) then you already have a problem, but you maybe don’t realize it until you have real users on your platform, but if there’s a network in the loop then you notice the problem right away. I suspect people fail against microservices for similar reasons static typing was unpopular for a while—they make bad ideas more immediately painful.
The article argues that startups can’t afford microservices, but I think really they just need a good architecture regardless of whether they choose microservices or monoliths.
whether a line between them is a network call or a function call is largely an implementation detail.
I don’t really agree. Even in the best case scenario of “both sides are always deployed at the same time on the same machine in sync”, network calls can still fail if the other process crashes or what have you, and it’s harder to enforce. And in a lot of cases your services are going to be deployed on separate cadences and possibly even on separate hosts so you have to deal with latency, version skew, and so on.
I would say that the in-process analogy would be closer to sending messages between threads.
Yes, you have to worry about latency and errors and skew, but I’m not sure that changes how I would modularize the application. And if I’m aiming for a fault tolerant design, I don’t care very much that the boundary is a function call or a network call because a function call could fail too—I need to commit the data at the boundary regardless so the operation can be retried on failure.
I think Conway’s Law pretty easily explains the tax of microservices. If you have microservices you are likely to have teams owning these services and thus not suited for start-ups. Monoliths suit start-ups better as one team owns everything and you don’t need multiple PMs/managers, and it allows all devs to have visibility and control over the entire code-base, vital when in the early stage of start-ups people wear many hats.
As usualy I’d recommend Dylan beatie’s talks on this e.g this one.