Comment by staticassertion | Hacker News Reader

Comment by staticassertion | Hacker News Reader

staticassertion

I found this to be surprisingly interesting and novel - usually I expect to see really low quality content when it's a post about microservices, whether for or against the idea. This boils it down to isolation, which I myself have written about in a similar vein[0].

> at this point security people simply don't believe that any of the following (each one the very best technology available at the time) is totally safe

To be fair, we don't think anything is totally safe :) that's the point. Actually a lot of those things listed are why Chrome is so secure. I think this is a bit pessimistic about process isolation, which is actually quite powerful, but I get the point - there's no gap like an air gap.

I prefer to think of monoliths and microservices as being completely unrelated ideas - they aren't on a spectrum of "big to small", they're just two totally different ways of approaching software development. I might put "monoliths" closer to SOA, in that they both describe a very basic approach to a problem, whereas Microservices is not "small services" it's about bounded contexts, patterns, organizations, etc.

Anyways, I appreciated this post.

[0] https://www.graplsecurity.com/post/architecting-for-performa...

There is a subtle link between monoliths and microservices: co-routines. You can emulate a service oriented architecture inside a monolithically linked application. That way if you ever do decide you need to break for further isolation and/or to be able to parallelize the execution for more performance it down you at least can limit that to cutting on the dotted lines.

I personally like microservices a lot because they allow you to do one more thing (a variation on the isolation theme, sure), to limit the scope of what you, the programmer have to deal with at any given time. Your specifications, tests and mental activity all focus on a much smaller chunk of code, which is much easier to deal with.

I don't think I've ever built a bug-free monolith, but I'm fairly sure I've been able to repeatedly produce bug-free (or nearly bug free, you can never be 100% sure) microservices. And that to me is the bigger advantage, the scope limitation from the programmers perspective.

Coroutines can have shared memory though and the lack of shared memory is perhaps one of the defining features of microservices.

Yes, it is an in-between step, which is why I used it as an illustration. You get roughly the same architecture but without the process isolation. In fact: co-routines will share some memory, whether you like it or not, they are in the same executable.

> You get roughly the same architecture but without the process isolation.

I think that's only true for very specific kinds of architecture which are only tangentially related to coroutines: stateless data transformations or actor-inspired architectures. Things like shared atomic data structures or mutexes translate pretty poorly to microservice architectures (they're doable, but really painful, bug-prone, and you give up a ton of performance).

EDIT: Hmmmm... on reflection, I suppose if you think of the actual stateful set of yield and continuation operations of coroutines they are one particular possible microservice architecture, but it strikes me as a bit messy? Although I guess you can retrofit the usual set of other concurrency operators on top.

It's a hack for sure, you are essentially creating a new little operating system within one binary. But it is an architecture that works remarkably well for quite a few applications: message switches, games and so on. And it even works on architectures where you only get one thread of execution.

Ah I see, you perhaps mean a slightly more general concept of coroutines than I was thinking about? Closer to something that fits a thread-like interface on top of actual threads regardless of whether it's being done through direct yields or intermediated by some sort of scheduler?

Basically the crucial point being getting concurrency without the need for actual parallelism?

Yes. And you can simulate that perfectly using the co-routine mechanism.

You can have same-process memory isolation in any programming environment that support isolates/actors, like JavaScript (via web workers[1]), Dart[2], Pony[3], and if done carefully, Rust[4] (probably many others too but I am not familiar with others that I can remember now).

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

[2] https://medium.com/dartlang/dart-asynchronous-programming-is...

[3] https://patterns.ponylang.io/data-sharing.html

[4] https://doc.rust-lang.org/book/ch16-02-message-passing.html

But Redis....

Seriously, I've seen a monolith broken up into a microservice using Redis as shared memory. Didn't know it was an anti-pattern.

> Didn't know it was an anti-pattern.

You really just have to be clear whether you are building a distributed monolith vs a set of microservices. In the former case, you are optimizing entirely for performance and scalability concerns. It just so happens if you have things that require scaling of the underlying hardware, our current state-of-the-art tooling handles scaling hardware resources (number of cores and memory) better when you have separate services rather than bundling it all in a single program.

However, you get none of the operational/human-level process changes of microservices. Teams are still coupled to the changes in the shared state. Anything that changes the shared state cannot be deployed independently. In fact from a process perspective things are probably even harder to coordinate now since the coupling is still there, but not explicitly expressed in code anymore. And from a site reliability perspective, you still have a single point of failure: the shared memory. Any mitigation strategies you use for that you could've used for a monolith as well.

I find the most common outcome of adopting microservices is a buggy system made of bug-free microservices, via misunderstood specifications or surprising interactions.

Yes. Also something I see in messaging oriented architectures, often seen with microservices for async communication, since synchronous calls usually make the whole as reliable as its least reliable element.

Message orientation, in isolation for each message handler, is wonderful, easy to test, decoupled etc. But the overall flow is harder to understand and coupling at the business level still exists. You still need to remove stock from inventory after a sale even if the two parts don't communicate directly. Messages are COMEFROM.

The other thing is reliability. Monoliths can usually rely on the ambient availability of resources - a synchronous in-process call will have a CPU available because that's how in-process calls work - but services across the network might not have resources to respond for some time. It cuts the other way too, though; when the monolith is down, everything is down. There's tradeoffs everywhere.

Every bit of complexity that you add has a price tag, before adding it you need to look at that tag and decide whether or not the price is worth it in this particular case. More often than not the answer is 'no' but people will go ahead and do it anyway.

Yes, what will typically happen is that people go overboard, and instead of 5 or so big functional blocks they explode the monolith into 50 (I've seen 200!) microservices and then end up with a huge overhead in terms of IPC and complexity in the IPC protocol that is worse than it ever was before. Bonus points if all it does is synchronous calls between services leading to a deadlocks and other hard to debug issues.

Good software architecture is hard.

Reply on news.ycombinator.com