Some thoughts on microservices

I don't know what that library is right now. Meanwhile I could set up the separate repos/microservices by the end of the day.

> That sounds like you need at most two different services, not microservices

It is unfortunate that the "micro" in "microservice" is often misunderstood to expect that these are very small and granular components. In practice by and large it ends up being separate services with separate repo, code review, ownership, deploy or CI/CD etc. pipelines. It doesn't have to mean they are actually very small. I know people like to joke about npm components and the leftpad thing but in my experience microservices have not turned out like that.

I did the full trip on this microservices rollercoaster. Monolith => uServices => Monolith.

I used to vehemently advocate for using microservices because of how easy it would be to segment all the concerns into happy little buckets individuals could own. We used to sell our product to our customers as having a "microservices oriented architecture" as if that was magically going to solve all of our problems or was otherwise some inherent feature that our customers would be expected to care about. All this stuff really did for us is cause all of our current customers to walk away and force a re-evaluation of our desire to do business in this market. All the fun/shiny technology conversations and ideas instantly evaporated into a cloud of reality.

We are back on the right track. Hardcore monorepo/monolith design zealotry has recovered our ship. We are focused on the business and customers again. The sense of relief as we deprecated our final service-to-service JSON API/controllers was immense. No more checking 10 different piles of logs or pulling out wireshark to figure out what the fuck is happening in-between 2 different code piles at arbitrary versions.

Not always. One of the things where I desperately wish people would adopt the "microservices philosophy" is in applications which provide a scripting language.

For example, if I want to "script" OpenOffice, I am stuck with the exact incarnation of Python shipped with OpenOffice. Nothing newer; nothing older; exactly binary compatible. This is a really irritating limitation.

If, however, they simply provided a "microservice interface" that anyone could talk to rather than just the anointed Python, then you could run your own Python or script using a completely different language.

I'm picking on OpenOffice here, but this is not specific to them. Nobody who has a "scripting extension language" as part of their application has demonstrated anything better.

Are you serious? In which language do you program that you don't have to use multiple libraries daily? You just talked about NPM.

In your example, the C# could output DLLs that have functions that can be called by the Java code. This can give the same encapsulation you get with your multiple services example, including separate deployments, different repo, different language, etc.

You could also use different processes. Please tell me you know what an executable is...

> Meanwhile I could set up the separate repos/microservices by the end of the day

That's because someone set it up for you, not because it's faster.

In your hypothetical scenario of "I needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system" you didn't mention that "…but we already have a fast way of setting up micro services".

> It is unfortunate that the "micro" in "microservice" is often misunderstood*

It's not, you're using the term loosely. "Two services" do not make a micro service architecture.

Sorry to be blunt, but I'm getting the feeling you're not talking out of experience, but rather repeating popular talking points.