Chapter 1. Introducing Akka

 

In this chapter

  • Why scaling is hard
  • Write once, scale anywhere
  • Introduction to the actor programming model
  • Akka actors
  • What is Akka?

Up until the middle of the ’90s, just before the internet revolution, it was completely normal to build applications that would only ever run on a single computer, a single CPU. If an application wasn’t fast enough, the standard response would be to wait for a while for CPUs to get faster; no need to change any code. Problem solved. Programmers around the world were having a free lunch, and life was good.

In 2005 Herb Sutter wrote in Dr. Dobb’s Journal about the need for a fundamental change (link: http://www.gotw.ca/publications/concurrency-ddj.htm). In short: a limit to increasing CPU clock speeds has been reached, and the free lunch is over.

If applications need to perform faster, or if they need to support more users, they will have to be concurrent. (We’ll get to a strict definition later; for now let’s simply define this as not single-threaded. That’s not really correct, but it’s good enough for the moment.)

Scalability is the measure to which a system can adapt to a change in demand for resources, without negatively impacting performance. Concurrency is a means to achieve scalability: the premise is that, if needed, more CPUs can be added to servers, which the application then automatically starts making use of. It’s the next best thing to a free lunch.

1.1. What is Akka?

1.2. Actors: a quick overview

1.3. Two approaches to scaling: setting up our example

1.4. Traditional scaling

1.5. Scaling with Akka

1.6. Actors: one programming model to rule up and out

1.7. Akka actors

1.8. Summary

sitemap