> How exactly? It's not magic, you still have to apply them, and now it requires more strategies and effort to accomplish.
Yes, we have tons of tooling for process isolation. Splitting a service into two services means you can isolate two processes instead of one, which means you break up the capabilities unique to each.
I used the word "apply" so I don't know why you're saying "you still have to apply them"... it's literally what I just said.
For all the repetition you have on this thread, can you summarize it with the actual benefit that you have gained in a serious production use?
I very much disagree.
> For all the repetition you have on this thread, can you summarize it with the actual benefit that you have gained in a serious production use?
I already have summarized it. All I've done since is correct people being incorrect with regards to my summary.
If you want a specific example, here's a blog post I wrote a long time ago (the dates are incorrect since we moved websites): https://www.graplsecurity.com/post/architecting-for-performa...
Nothing in that article explained a clear need or benefit of microservices.
Nothing in the article has to do with the product or the fact that it's security related, other than to provide a motivating use case.
> The only potential benefit there was for security
And performance.
> even that was just relying on the ephemeral nature of lambdas
I think you've failed to understand the article, which may be my fault, I haven't read it in a long time. The key is isolation. Ephemerality gives you a sort of temporal isolation. Splitting your messaging from your data storage gives you a capability based isolation. And so on.
It also means we can scale to the limits of S3/SQS - each service is itself stateless, the majority of state is managed in SQS, which could be quite loose about its consistency since every service is idempotent - arguably a form of temporal isolation.
What I've described in this article is effectively the actor model. I feel like I don't have to really justify the benefits of the actor model with regards to scale?
What part of microservices (split functionality with completely separate runtime artifact deployed to separate servers) is needed for actors? You can have actors in a monolith.
> "Further, a call between functions can cause mutated shared state - not the case across a boundary, they physically do not share mutable state."
This is false as state is not tied to your process nor does it require a network leap to add isolation.
> "now you can apply least privilege as you desire."
How exactly? It's not magic, you still have to apply them, and now it requires more strategies and effort to accomplish.