4 ms·
I'd like to challenge the "I can't imagine a better way of separating" bit. I agree that microservices, if done right, are awesome. Recently, however, I had th
by marcyb5st 6y ago
I'd like to challenge the "I can't imagine a better way of separating" bit. I agree that microservices, if done right, are awesome.
Recently, however, I had the chance to work with a quite extensive codebase that powers a monolith for a fintech company. The code is written in Scala and extensively uses Akka-streams to neatly separate concerns. In my opinion this approach is the the sweet spot as 1) Devops burden is low as you only have one binary to run / deploy 2) Shapes of the various Akka-streams subgraphs are statically typed checked (unless you opt-out by doing stupid things), 3) makes it much easier to reason about the data flow, and 4) testability is really high as you don't have to mock services but only the upstream subgraphs.
The downsides are that 1) the learning curve is very steep at the beginning as Akka in general is very complex to use effectively, and 2) squeezing the maximum performance can be hard as you don't have the ability to horizontally scale only some microservices.
I fell in love with the approach and I'm migrating some personal projects to it.
- 0x445442 6y agoI've seen very few posts here mention horizontal scalability like you did. In my mind, it's the first and foremost reason to consider a distributed rewrite over a monolith. I would bitch long and hard if someone was suggesting the transition from monolith to micro-services without the metrics to prove horizontal scalability was becoming an issue.
- marcyb5st 6y agoFully agree. Another point worth considering is costs. Cloud providers now let you use ephemeral VMs which are amazing in terms of value. If you can identify some parts of your system that use too much in terms of resources you can get quite some nice costs savings by wrapping that around a microservice and deploy it in said cheap VMs.