Some thoughts on microservices

Edit: in contrast, I don't want anything about a user, except their id in a table for most features. Hearing of free for all's on data makes me question how they protect payment or just general private data.

You don't need a library for that, it's is part of the language. Java can call code from native libraries, C# can export native functions. It can also be another process. [1]

> Yes, the whole point was to come up with a concrete example for the sake of argument, and see how we can accomplish it in practice. We're not writing academic papers here, the fact that this functionality is widely available is a good thing.

The problem is that you moved the goalposts. "I need to interoperate with C# code" is very different from "I need to interoperate with C# code and my company uses microservices and that's the only thing I know".

You can't claim something is automatically worse just because you're ignorant about it.

> Yes, me and 95% of the industry. Again, it's unfortunate but here we are.

Nope. There are exactly zero companies claiming to use microservices when they have exact two services. And it's not about size, by the way, it's about different architectural patterns.

[1] https://www.baeldung.com/jni

Having never done this, I believe you. I am still skeptical of how quickly/effectively you could set up a CI/CD system and the module repos to deploy to a monolith. I wonder how the type interop works there (equivalent of OpenAPI-based code generation).

> The problem is that you moved the goalposts. "I need to interoperate with C# code" is very different from "I need to interoperate with C# code and my company uses microservices and that's the only thing I know".

That's maybe a bit unfair. There are a lot of microservice shops, but I haven't heard many who do this Franken-monolith thing. Remember that infamous microservice dependency graph from Uber? I guess Facebook was famous for doing a monolith but I don't know if it was purely PHP or not.

> You can't claim something is automatically worse just because you're ignorant about it.

I can if the metric is availability/familiarity in the industry, but OK.

> Nope. There are exactly zero companies claiming to use microservices when they have exact two services. And it's not about size, by the way, it's about different architectural patterns.

I don't know, my experience is people like to say they use microservices but they just have a service-oriented architecture. Meanwhile I never ran across an organization that does something like npm modules and goes way crazy with granular services. I don't know, maybe they are out there.

I don't see it as being called out, it's a constructive discussion. The purpose of my example is to see how practical it would be for me to set up a monolith-based CI/CD that could support multi-lingual, multi-repo teams. I have a better idea now, maybe have them publish to a local Maven style server, and kick off a monolith build when there is a new library version? The monolith can then bind them together and rebuild. I'm not sure how the host interfaces would get regenerated still.

Good examples re: libcurl, ImageMagick, etc. How would we deal with very frequent changes there? I know that upgrading a SQL driver is not a task we take lightly, and I would love to see how we could make this easy to do on a daily or hourly basis. Mainly we'd need auto-generated strong types somewhere on the interface, again, like OpenAPI but for libraries.

> You seem to be under the impression that what I'm suggesting is a replacement for real microservices.

This discussion started with several suggestions that monoliths could do just as well as most microservice setups, and I wanted to do an exercise to see how practical this would be.

> I don't understand what's the issue here.

There is no issue. Who said there is an issue? So far so good.

> Sure, but you can't use yourself as a benchmark for the industry if you're that unfamiliar with something that basic.

I know and/or interview enough people across the web-dev and game-dev industry that I feel I have a sizable sample of data points to form an opinion that is not purely a guess of a single person.

> Again, there is a humongous difference between "we're doing microservices" or even "we have a service oriented architecture" and your "I need two things to interoperate".

Sure. The two things example was just a distilled example for the purpose of a thought experiment. We can easily extrapolate to an org with tens of services where maybe most people like to use the default environment like Java/Spring but a few teams maybe prefer or their use case calls for something different like Python or C# or whatever. If anything it would be even more difficult to stand up a monolith there with more and more varied components.