3 ms·
IMO it's not really about the build at all. It's about people and business. One, for microservices created by the companies themselves, those bascically grow o
by m0zg 6y ago
IMO it's not really about the build at all. It's about people and business.
One, for microservices created by the companies themselves, those bascically grow out of their org chart. It is well known that organizations ship their org chart, and this is no exception. Person A wants to become a manager to make more money and ascend the societal hierarchy. Person A's manager wants to grow their fiefdom and have more people under them (which is the only true measure of one's worth as a manager, as far longer term career is concerned), so the person A proposes to their manager that they use "best practices" and carve off a "microservice". Their manager happily obliges, because they don't know anything about distributed systems and consistency. Person A gets promoted. Now person B wants to become a manager to make more money and have their fiefdom... The end result is you have a nightmarish maze of microservices where a single simple monolithic binary would do a better job at one quarter the dev cost. You also have a very deep and branchy org chart, which is the preferred state for the management, since it lets them justify (and increase) their pay.
Two, for cloud microservices, they offer a simple way to create recurring, extremely sticky revenue.
That's not to say that microservices are useless - they are useful sometimes. It's just that "nobody ever got fired for moving to AWS", and when the incentive structure does not encourage more robust engineering and/or cost savings, your money won't be spent wisely, because nobody gives a shit about that.
As with any people problem, the only way to push back against this is by making the desired state the lowest energy state. This can be done several different ways, none of which have anything to do with engineering arguments, at least not if you want it be be effective against such very human things as greed and desire for social status.
- jeremyjh 6y agoI think its kind of both. When you have a lot of people working on a monolithic code base one of the places where you feel the most friction is at the build process. If CI takes 30 minutes for example and you have 80 developers working on the code base (roughly the stats from my previous job) then you can see how just coordinating the build/merge/rebase/build/merge cycle can be an issue without good tooling and practices. At some point service boundaries are inevitable and shipping the org chart is something we've always done. But what is actually happening in some companies is just so far beyond this. There are developers I've talked to at companies where the micro-services outnumber the developers by 5:1 or more. That is insane, and I imagine it did start with the kind of empire building you are talking about.
- m0zg 6y ago> I think its kind of both. Yes. I'm old enough to see nuance. I do not assert that these are the only causes. I only assert that they are the primary causes most of the time. As a side note, there's something deeply wrong if CI takes 30 minutes. This usually indicates that all tests are re-run every time, which is something you can easily avoid by e.g. using a modern build system such as Bazel, which will only re-run the affected subset of tests when something changes, because it is able to track all changes to the transitive closure, including data. Also 80 people on a team sounds like a nightmare. I don't think I've ever seen a monolithic team this large in my 25 years in the industry, some of which was spent at Microsoft, of all places. The best size is that of a large family - 5-7 engineers. That way communication overhead does not dominate, and you can still do very sophisticated and substantial things. Beyond this magic number the productivity growth is usually negative.