Ashesh, 

Akka is "*Akka is a toolkit and runtime for building highly concurrent, 
distributed, and resilient message-driven applications on the JVM*". So 
short answer to all your questions is YES you can make Akka do all these 
things. 

Please see inline for my other responses. I'm sure Akka team can provide 
better guidance and correct me when I'm wrong :-)


On Friday, January 16, 2015 at 5:48:10 PM UTC-5, Ashesh Ambasta wrote:
>
> I had a quick question: I'm a lead developer at a small startup and we're 
> working on a solution that depends on the data in our core service to push 
> out periodic updates to other API's (like Facebook, Twitter, etc.) and we 
> want to build a microservices arch. We intend to keep the core service and 
> the data-push service across multiple instances. Is Akka going to be a good 
> choice for a problem like this?
>
> We've built our core API using Scala and the Play Framework and we're 
> happy with the outcomes. And while we were working on the core, we began to 
> look into Akka and it looked quite interesting, given the buzz it has 
> around the web and the success stories.
>
> We will, however, need some convincing about a service like the one I 
> mentioned. What we will definitely need from a system like this is;
>
>
>    - The system should process push requests concurrently: other requests 
>    shouldn't be blocked if the remote API is taking too long to respond.
>
> Akka supports both push and pull. The exact mechanism you are going to use 
to "talk" to your remote API will determine the Akka abstraction/extension 
you are going to use. For example, 
- if it is HTTP then you can use spray.io (or the new akka-http module). 
- if the remote service is akka as well, you can use akka-clustering, 
- if you want low latency you can use akka-zeromq or some other mechanism
...

>
>    - Errors should be logged and reported, and failed requests should be 
>    queued back.
>
>  Akka really shines at handling faults. Fault handling is a first class 
citizen in the Akka world. In fact, it is one of the main selling points of 
Akka when compared to other distributed computing middleware platforms. 
Again, the exact logic of handling faults is business specific and needs be 
engineered for your domain/system. 

>
>    - We're talking about potentially hundreds of requests per minute in 
>    the beginning, we've heard good things about Akka's performance, but we're 
>    yet to come across a similar use case to be sufficiently convinced.
>
> If you *configure Akka properly *you can scale it to *orders of magnitude 
more* than 100s of request per minute.  Throughput and latency are also a 
function of how good your pipeline is. If you avoid/localize blocking and 
keep it asynchronous Akka will give you great performance. It requires some 
effort and engineering to get there though. Since Akka can scale 
horizontally using akka-clustering I would strongly recommend that you 
design your application keeping this in mind. 
You can find examples on TypeSafe's website or just Google for it. 

>
>    - It should be possible for the core service to communicate with a 
>    remotely running Akka service. For example; the Core API runs on some 
>    instance, and the Akka services run on some other instances. A push 
> request 
>    is initiated in an action of the Core service – where a push request is 
>    sent to Akka. The appropriate service for that API should pick that up and 
>    send it to the target API and report back with a confirmation.
>
> As I mentioned before, there are many ways of doing this because Akka is 
so flexible. If both sides are Akka you can just use Akka clustering. If 
you want loose coupling and don't care about extra latency you can use 
Spray/Akka-http and if you want really low latency you use a custom 
transport. 
 

> I'm quite keen on diving into Akka for a project like this, but as I said 
> before, I'll need some convincing.
>
I hope the above has helped. If you have any more specific concerns please 
let us know. I've been working with different parts of Akka for almost 2 
years now. It's amazing how you can write concurrent abstractions that just 
works once you figure out how to play in this new world. 

On the other hand, Akka is not a "silver-bullet" and you can find lots of 
examples where other approaches are either simpler or better than Akka. But 
for the use case you described above I think Akka is a great fit. 

Good luck. 

Cheers,
-Soumya


 

-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to