Dividing two pieces of work before you figure out what the right 'two pieces of work' are makes it very, very difficult for someone to refactor it later. As feature sets expand and expand, we frequently discover that two things are really three, or three things should be two with a bit of configuration. If they are in separate modules this is challenging. If they are in separate deployments people will just hack and get away from the code as fast as they can.

This sort of thing is a much overlooked aspect of YAGNI, and the related but lesser known concept of Reversible Decisions, which in a nutshell is: Any decision that can be changed easily, make it as cheaply as possible (time, emotional investment, etc. Chosing at random can work here, or quick show of hands without commentary - grandstanding is expensive). Any decision that will be difficult to unmake later? Play for time to allow more data points to come in before making the decision.

I kind of alternate between toolsmith and team lead, depending on the political landscape of the company. My philosophy is basically this. I say 'tool' below but it also usually works for processes (tools work better in times of high stress):

- Give people tools so they can do better (ie, make higher quality code changes)

- Make the tools foolproof, so they are more help than hindrance

- Apply social pressure (encouragement first, shaming for stragglers) to get people on board for using the tools

- repeat step 2 as new users find new problems

- Change development process to include the tool

So my first question is, is your plan to use microservices going to emulate this pattern, or are you just continuing a war of words by adding friction to the system? If you see people are writing bad code now, how much bad code that you don't see is going to be in microservices you don't care much about?

Are those microservices going to have an effect on your quality of life, the esteem of your team among other divisions of the company? Then you probably care what's in them and "out of sight out of mind" is a terrible strategy.

I won't let my devs build a microservice unless we already have two disparate systems (in development or production) that can use it immediately when it's ready (or very shorty thereafter). That rule seems to keep things in check, and everyone knows when they can pitch a microservice, so we don't have to keep justifying why we won't.

What exactly do you consider disparate? And how big is the company?

Medium size printing, manufacturing, and fulfillment company with a small dev team. We have a few different systems for product manufacturing and fulfillment, and they use microservices for common tasks like combining PDFs for print, product serialization (keeping track of which numbers get assigned to which products), getting shipping labels, etc.

In microservices, the common opposite of 'good boundaries' is duplicated effort. It might apply a little back pressure, and eventually the problem will be so big it's noticeable. Call me crazy, but I'd rather notice problems without having a giant cleanup effort to go along with it.

The 80/20 rule tends to rule, and the whole mess never gets close to being cleaned up.

Doesn't google essentially have a monolith that's distributed across a network?

Monorepo, but not really a monolith. Search, for example, has basically zero dependencies on GMail, while much of the common code (BigTable/MapReduce/Flume/Colossus/Closure/etc.) has clean published RPC interfaces.

Well, in today's world, whether it's a monolith, or composed of microservices, a system will be distributed across a network. That's just the world we live in, no question.

I think the material point is that microservices can have drawbacks just as any other architecture or technology can have drawbacks. Whether it's microservices, or monoliths, or functional programming, or whatever language people are pushing instead of C, whatever it is, there will be drawbacks. And I think people are speaking to their annoyance at other developers for not recognizing the drawbacks of various technologies.

(Interestingly, this probably means that the people advocating for those technologies also don't really have a good appreciation of the appropriate uses of the strengths of the technologies in question.)