Don't start with microservices – monoliths are your friend

In some languages, you can enforce boundaries within a monolith nicely using the build system. The key is to break the build up into a hierarchically structured set of libraries somehow where each library only gets to use those libraries it is allowed to depend on architecturally. Independent bits of business logic would need to go into libraries that cannot "see" each other when they are compiled. Everything would still be part of a single build process and still be linked together into a single big program at the end.

The exact method depends on the language. In C/C++, you'd limit the include paths for each library. In C#, you'd have to compile different assemblies. And so on.

yes and no. i totally get what you are saying but this problem has been solved lately in my opinion.

Also deployment is part of code organistaion no? i like to point out the fact that i explicitly mentioned you do not need to decide, you can use both at the same time but i would like to try to answer your point anyway:

Maybe I am just spoiled with go and github, but those deployment pipelines can be directly integrated into your repository. The same way I can counter argue that your build ci and deployment phase will take significantly more time too and if you change a variable from uppercase to lowercase you will wait for minutes too.

I come from a c# background a long time ago and this has been true with it for eons: https://xkcd.com/303/

Another thing that I have noticed is that its easily scriptable too. What I end up doing is to provide a makefile into my repository too. This way i can define the build process amongst other things eaisly.

In the end: We have a predefined spec that will create the desired state on a host of our chosing.

Ansible really does not care if you deploy 1 or 1000 "services" for instance! Tools Like ArgoCD will also deploy stuff when you commit to your master.

There is tooling for everyone available, but what happnes quite often is that the people in charge of the company expected the developers to be all knowing entities that need to define everything end to end. The Kubernetes Space is vast because we are still defining and communication its future.

But recently? I am trying to think of something that would not be completly automateable in 2021

All ideas that are good in principle, become absurd the moment they are elevated to a kind of dogma, applied to every problem, no matter if it makes sense to do so or no.

Microservices are no exception from that rule, and often repeat the same mistake as OOP did with its promise of "reusable code".

Does it sometimes make sense to break some larger services up in smaller ones? Yes.

Does it make sense to "factor out" every minor thing of the implementation into something that can individually be manhandled into a docker container because at some point in the far future, someone may save a few minutes of typing by talking to that service? No.

Why not? Because on the 1:1000 chance that what the service does is actually exactly what that other thing requires, it will probably take more time to implement an interface than it would to simply implement a clone of the functionality.

> What if the product (department) doesn’t give a damn about the underlying system architecture? I mean shall they?

They should not. Either it works correctly, or it doesn't. Even buildings need to be useful, even though people might admire the architecture. No non-technical person will admire your microservice or whatever architecture.

Microservices is kind of a superpower that allows you to choose where you want your complexity to be. You are supposed to start with something simple, so the microservices decision needs to come in later.

Not starting full in with microservices is a good pattern.