For question in 51:50, you could scale particular services (which happen to be Actors) without having to scale the entire bounding context (or deployable unit) using a dynamically resizable pool: doc.akka.io/docs/akka/2.5/scala/routing.html#dynamically-resizable-pool
Akka actors are meant as a low-level concurrency abstraction. If someone builds a high-level architecture around a web of actors chatting to each other and hopes that engineers will be able to reason about the system... Well... There is no explicit flow of business input (events/requests) being processed into the desired output.
I would say that Futures are meant as low-level concurrency abstractions; using Actors as your smallest concurrency units is generally not the best choice. You might find several posts discussing this. Personally, I've worked on various enterprise projects for which we use actors for "higher-level" abstractions, so to speak, such as domain services or domain entities, and in my experience they have been a very good fit, specially for building true reactive systems in a distributed microservices fashion. It's true though that there might be a learning curve for engineers for getting the Actor model (motivations, design decisions, etc), probably mainly for those coming from a more traditional MVC background. That being said, I don't think that the fact of using Actors will be a constraint for modeling or reasoning about business flows. In my opinion, all the benefits you get by design using Actors as your main abstractions are worth the ride.
maybe i am missing something, but what problem are microservices trying to solve here? couldn't you just make a monolith using the same interfaces (just internally), skip all the overhead and have identical functionality with less resource requirements?
Why, Raja? I think Play gets too criticized. Yeah, there's the frantic versioning, the breaking changes... and Scala templates and sbt aren't the most user-friendly technologies... but it's still pretty cool.
all the DDD guys (Eric Evans, Vaughn Vernon etc.) need to be played at 1.5x speed
Really enjoy this talk, what is micro service, how big it should be is a really mean thing.
For question in 51:50, you could scale particular services (which happen to be Actors) without having to scale the entire bounding context (or deployable unit) using a dynamically resizable pool: doc.akka.io/docs/akka/2.5/scala/routing.html#dynamically-resizable-pool
I don't get the point of the UDP base registry service. Why dont' use Akka capabilites for that?
Hi, does anyone knows where is the source code for the example that he showed?
Akka actors are meant as a low-level concurrency abstraction. If someone builds a high-level architecture around a web of actors chatting to each other and hopes that engineers will be able to reason about the system... Well... There is no explicit flow of business input (events/requests) being processed into the desired output.
I would say that Futures are meant as low-level concurrency abstractions; using Actors as your smallest concurrency units is generally not the best choice. You might find several posts discussing this. Personally, I've worked on various enterprise projects for which we use actors for "higher-level" abstractions, so to speak, such as domain services or domain entities, and in my experience they have been a very good fit, specially for building true reactive systems in a distributed microservices fashion. It's true though that there might be a learning curve for engineers for getting the Actor model (motivations, design decisions, etc), probably mainly for those coming from a more traditional MVC background. That being said, I don't think that the fact of using Actors will be a constraint for modeling or reasoning about business flows. In my opinion, all the benefits you get by design using Actors as your main abstractions are worth the ride.
maybe i am missing something, but what problem are microservices trying to solve here? couldn't you just make a monolith using the same interfaces (just internally), skip all the overhead and have identical functionality with less resource requirements?
This talk is a real waste of the viewer's time.
i stopped watching when he mentioned "Play"
Why, Raja? I think Play gets too criticized. Yeah, there's the frantic versioning, the breaking changes... and Scala templates and sbt aren't the most user-friendly technologies... but it's still pretty cool.
The title should have been "Play microservices with Scala Akka", so its very misleading.
Yes.
Play is MVC , MVC is tyranny, the exact reason why i quit AspDot Net in 2011
dude just wants to sell his book