> You don't get to change the constraints ("I already know how to setup X") after an answer just to say the answer is wrong/worse and expect not to be called out on it...
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.
Updating SQL drivers, etc, is not trivial because you don't have control over the code, but if you have enough integration tests (or at least proper failure handling) for your separate library then you can update with the same frequency as microservices.
I think it's fine to do this thought exercise, but you're massively discounting the difficulties of microservices, while making up obstacles and mocking ("Franken-monolith") every other suggestion. Any company that doesn't already use microservices (and doesn't also have people with experience building infrastructure for them, rather than just using) is gonna have a harder time with a microservice solution than you currently do. It is perfectly fine to extrapolate from your own experience, but you're discount things without any research whatsoever and saying "nobody knows about it" or "nobody uses it" in a very disrespectful way. Another post of this discussion about code ownership is exactly the same: it takes literally seconds to write a simple codeowners file in GitHub, while you make it seem like it would be an Sisyphean task ("an uphill battle") compared with microservices just because you're not aware of it. Some things are not hard, maybe you just didn't heard of them yet.
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.