Akka in Action

Raymond Roestenburg, Rob Williams, Robertus Bakker

• Éditeur: Manning
• Année: 2016
• ISBN:
  9781638352938
• Sujet: Ciencia de la computación
• Sous-sujet: Programación

Summary Akka in Action is a comprehensive tutorial on building message-oriented systems using Akka. The book takes a hands-on approach, where each new concept is followed by an example that shows you how it works, how to implement the code, and how to (unit) test it.Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications. About the Technology Akka makes it relatively easy to build applications in the cloud or on devices with many cores that efficiently use the full capacity of the computing power available. It's a toolkit that provides an actor programming model, a runtime, and required support tools for building scalable applications. About the Book Akka in Action shows you how to build message-oriented systems with Akka. This comprehensive, hands-on tutorial introduces each concept with a working example. You'll start with the big picture of how Akka works, and then quickly build and deploy a fully functional REST service out of actors. You'll explore test-driven development and deploying and scaling fault-tolerant systems. After mastering the basics, you'll discover how to model immutable messages, implement domain models, and apply techniques like event sourcing and CQRS. You'l also find a tutorial on building streaming applications using akka-stream and akka-http. Finally, you'l get practical advice on how to customize and extend your Akka system. What's Inside

• Getting concurrency right
• Testing and performance tuning
• Clustered and cloud-based applications
• Covers Akka version 2.4

About the Reader This book assumes that you're comfortable with Java and Scala. No prior experience with Akka required. About the Authors A software craftsman and architect, Raymond Roestenburg is an Akka committer. Rob Bakker specializes in concurrent back-end systems and systems integration. Rob Williams has more than 20 years of product development experience. Table of Contents

• Introducing Akka
• Up and running
• Test-driven development with actors
• Fault tolerance
• Futures
• Your first distributed Akka app
• Configuration, logging, and deployment
• Structural patterns for actors
• Routing messages
• Message channels
• Finite-state machines and agents
• System integration
• Streaming
• Clustering
• Actor persistence
• Performance tips
• Looking ahead

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.

Around the year 2005 when Herb Sutter wrote his excellent article, you’d find companies running applications on clustered multiprocessor servers (often no more than two to three, just in case one of them crashed). Support for concurrency in programming languages was available but limited and considered black magic by many mere mortal programmers. Herb Sutter predicted in his article that “programming languages ... will increasingly be forced to deal well with concurrency.”

Let’s see what changed in the decade since! Fast-forward to today, and you find applications running on large numbers of servers in the cloud, integrating many systems across many data centers. The ever-increasing demands of end users push the requirements of performance and stability of the systems that you build.

So where are those new concurrency features? Support for concurrency in most programming languages, especially on the JVM, has hardly changed. Although the implementation details of concurrency APIs have definitely improved, you still have to work with low-level constructs like threads and locks, which are notoriously difficult to work with.

Next to scaling up (increasing resources; for example, CPUs on existing servers), scaling out refers to dynamically adding more servers to a cluster. Since the ’90s, nothing much has changed in how programming languages support networking, either. Many technologies still essentially use RPC (remote procedure calls) to communicate over the network.

In the meantime, advances in cloud computing services and multicore CPU architecture have made computing resources ever more abundant.

PaaS (Platform as a Service) offerings have simplified provisioning and deployment of very large distributed applications, once the domain of only the largest players in the IT industry. Cloud services like AWS EC2 (Amazon Web Services Elastic Compute Cloud) and Google Compute Engine give you the ability to literally spin up thousands of servers in minutes, while tools like Docker, Puppet, Ansible, and many others make it easier to manage and package applications on virtual servers.

The number of CPU cores in devices is also ever-increasing: even mobile phones and tablets have multiple CPU cores today.

But that doesn’t mean that you can afford to throw any number of resources at any problem. In the end, everything is about cost and efficiency. So it’s all about effectively scaling applications, or in other words, getting bang for your buck. Just as you’d never use a sorting algorithm with exponential time complexity, it makes sense to think about the cost of scaling.

You should have two expectations when scaling your application:

• The ability to handle any increase of demand with finite resources is unrealistic, so ideally you’d want the required increase of resources to be growing slowly when demand grows, linear or better. Figure 1.1 shows the relationship between demand and number of required resources.
• If resources have to be increased, ideally you’d like the complexity of the application to stay the same or increase slowly. (Remember the good ol’ free lunch when no added complexity was required for a faster application!) Figure 1.2 shows the relationship between number of resources and complexity.

Figure 1.1. Demand against resources

Figure 1.2. Complexity against resources

Both the number and complexity of resources contribute to the total cost of scaling.

We’re leaving a lot of factors out of this back-of-the-envelope calculation, but it’s easy to see that both of these rates have a big impact on the total cost of scaling.

One doomsday scenario is where you’d need to pay increasingly more for more underutilized resources. Another nightmare scenario is where the complexity of the application shoots through the roof when more resources are added.

This leads to two goals: complexity has to stay as low as possible, and resources must be used efficiently while you scale the application.

Can you use the common tools of today (threads and RPC) to satisfy these two goals? Scaling out with RPC and scaling up with low-level threading aren’t good ideas. RPC pretends that a call over the network is no different from a local method call. Every RPC call needs to block the current thread and wait for a response from the network for the local method call abstraction to work, which can be costly. This impedes the goal of using resources efficiently.

Another problem with this approach is that you need to know exactly where you scale up or scale out. Multithreaded programming and RPC-based network programming are like apples and pears: they run in different contexts, using different semantics and running on different levels of abstraction. You end up hardcoding which parts of your application are using threads for scaling up and which parts are using RPC for scaling out.

Complexity increases significantly the moment you hardcode methods that work on different levels of abstraction. Quick—what’s simpler, coding with two entangled programming constructs (RPC and threads), or using just one programming construct? This multipronged approach to scaling applications is more complicated than necessary to flexibly adapt to changes in demand.

Spinning up thousands of servers is simple today, but as you’ll see in this first chapter, the same can’t be said for programming them.

1.1. What is Akka?

In this book we’ll show how the Akka toolkit, an open source project built by Lightbend, provides a simpler, single programming model—one way of coding for concurrent and distributed applications—the actor programming model. Actors are (fitting for our industry) nothing new at all, in and of themselves. It’s the way that actors are provided in Akka to scale applications both up and out on the JVM that’s unique. As you’ll see, Akka uses resources efficiently and makes it possible to keep the complexity relatively low while an application scales.

Akka’s primary goal is to make it simpler to build applications that are deployed in the cloud or run on devices w...