Hacker News new | ask | show | jobs
by yakshaving_jgt 1662 days ago
Given your negative characterisation of the "ball of mud", I'm guessing you haven't actually read the original paper.

> heck even a different language

There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls.

1 comments

> There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls

I mean it's only computers and the only limit to what we can make them do is our imagination.

In this case though for the sake of argument what options would I have if I, say, 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. I'm not sure how I would accomplish this in a monolith.

> I'm not sure how I would accomplish this in a monolith.

With a library.

Depending on what you’re doing (process ran a few times a day?), maybe even spawning a process is enough.

> what options would I have if I, say, 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.

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

> With a library.

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 don't know what that library is right now

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.

> Are you serious? In which language do you program that you don't have to use multiple libraries daily?

I said I don't know which library would let me make C# method calls from a Java Spring runtime, presumably in the same process. Do you? Feel free to share a link.

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

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.

> It's not, you're using the term loosely

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

> I said I don't know which library would let me make C# method calls from a Java Spring runtime, presumably in the same process. Do you? Feel free to share a link.

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