top | item 36679071

(no title)

AndrewPGameDev | 2 years ago

I've had this thought for a long time that if you have a completely functional code base (as in no side-effects), making the decision between a microservice approach and a monolith approach is fundamentally transparent. Any functional code can not only be split onto multiple threads, but multiple servers (at the cost of latency).

discuss

order

dugmartin|2 years ago

Except in the microservice approach with multiple servers you have introduced the possibility of network partitioning where microservice A can't reach microservice B. Unless your language/runtime model can deal with that you have hidden that error case in your abstraction. I think a lot of microservice architectures are implemented with the YOLO model where there is no thought to network errors and all calls are assumed to succeed.

Language/runtimes like Erlang & Elixir on the BEAM/OTP that were built with this in mind work well. They are completely functional with all state contained with lightweight processes and can send messages with timeout handling transparently across nodes in a cluster. With OTP you get a supervision tree for those processes that can automatically restart nodes and child processes of nodes.

dboreham|2 years ago

> Any functional code can not only be split onto multiple threads, but multiple servers (at the cost of latency).

Assuming some simplifying assumptions, yes. But those simplifying assumptions tend not to hold in the real world.

Cthulhu_|2 years ago

This was the Scala / Akka approach, I'm sure there's similar ones in other languages; basically you'd work via communicating, 'pushing' messages to actors instead of calling functions. From a developer's point of view, it then didn't matter if that message went to an actor on the same machine or something halfway across the world. "Don't communicate by sharing memory, share memory by communicating." is the modern adage.

jcparkyn|2 years ago

Any purely functional app still needs a mutable data store _somewhere_. And if that's all owned by one service (the "root" of your functional app, since everything else is pure by definition), then you're hardly doing microservices.

eldenring|2 years ago

Multiple servers adds a pretty hefty layer of networking, orchestration, security, failure handling (even in the datacenter), and serialization - even if the business logic stays mostly the same.