Last year, Johan Janssen started a Lego Internet of Things project. Using Scala, Akka and Raspberry Pi, he controlled a Lego train set. At Voxxed Days Athens, Johan will live demo his project and discuss how to use Akka HTTP and actors. We asked him about the technology.
What is Akka HTTP and what is a remote actor?
Akka HTTP is a toolkit which enables you to provide and consume HTTP services. It’s comparable to Jersey which is often used in Java projects and enables you to quickly create and consume HTTP endpoints.
Akka allows developers to build event driven applications by sending messages around between actors. An actor is used to receive, process and send messages to other actors. If one actor sends a message to another actor in the same JVM then we say that those are local actors. But it’s also possible to send a message from an actor on JVM X to another actor on JVM Y. By the way the two JVM’s can run on two different machines. When we communicate between actors in different JVM’s we say that it’s a remote actor.
In my session I’ll show you how I used remote actors to communicate between my laptop and different Raspberry Pi’s. To communicate between different applications I used remote actors instead of REST calls with Akka HTTP. There are some good reasons to favor remote actors over REST calls with Akka HTTP. One of the reasons is the fact that it’s really easy to change your application from local actors to remote actors, it’s just a matter of configuration. Another good reason is performance, remote actors use the Akka over tcp protocol instead of the HTTP protocol which performs better.
How do they allow you to build the next generation of applications?
Akka’s strength is mainly in highly concurrent systems with low response times that need to be fault tolerant. HTTP isn’t really fast, nor fault tolerant. It takes quite some time for programmers to build REST endpoints in their applications. Using remote actors is really easy and it solves these problems.
There is another good reason why I like local actors and remote actors. Recently there was a lot of discussion about microservices versus monoliths. Some knowledgeable people suggested to start with a monolith and if necessary refactor the monolith into smaller applications (maybe even microservices). Back in the day we often used REST to communicate between the smaller applications. However to go from a monolith to the smaller applications we needed to create REST endpoints and agree on the messages we would send back and forth. That requires quite some work which basically means writing boilerplate technical details instead of building new functionality. So it will be hard to convince someone to invest in such a process. Luckily we now have local actors and remote actors.
When we build a monolith with local actors we already define the messages that are being send between the actors. When we change the monolith into smaller applications we still use the same messages. We only need to configure remote actor support and we need to configure some actors to send their messages to a remote actor instead of a local one.
How did you go about choosing the libraries and technologies for your project?
Actually we first build our project based on Spring applications with an AngularJS backend. Everything was running fine in that setup. Around that time myself and some colleagues at Info Support were investigating Scala and Akka and we followed some courses about those subjects. We really liked it, but wanted to try it in a bit more advanced scenario then “hello world”. Because I quite hate “hello world”! It’s boring and you don’t learn anything while building “hello world”. I mean every tool/framework probably allows you to build “hello world” quite easily. You only encounter the limits if you start building something more advanced.
Scala and Akka
So we decided to rebuild our complete backend in Scala and Akka. For the communication between my laptop and the Raspberry Pi’s we picked remote actors as we wanted to figure out if they worked better than using HTTP calls. We reused our AngularJS frontend with some small modifications. For AngularJS to communicate with our actors we picked Akka HTTP. At that time Akka HTTP was still fairly new and most people were still using Spray. But Akka HTTP was based on Spray and was expected to become the new standard. So we decided to take the more adventurous route and picked Akka HTTP.
To build everything we used SBT instead of Maven as it’s more of a standard when building Scala applications. SBT stands for Simple Build Tool, however from my experience Slow Build Tool would have been a great name as well. I’m still not sure whether SBT or Maven is better to build your Scala projects. Most plugins and documentation for Scala projects is written for SBT. However I wasn’t really convinced that it worked better (faster) then Maven. But that could be partly because I’ve worked with Maven for many years and SBT was new for me.
How did you go about performance testing?
We really liked remote actors as a replacement for REST calls. But we wanted some more objective proof that remote actors are better than REST calls. Not only to convince ourselves that it was a good pick, but also to be able to advice others who doubted between remote actors and REST.
So I came up with the idea of creating a performance test where we compared two almost identical applications. The only difference was that one application made a remote actors call while the other application made a REST call to Akka HTTP. I’ve got quite some experience with JMeter but also heard some great stories about Gatling. As we were already experimenting with lots of new stuff we decided to tryout Gatling. Another good reason was that Gatling uses a Scala DSL and our application was also written in Scala. Gatling proved to be a great pick, it’s really easy to setup and start a performance test, they even provide some nice graphical overview of the performance results.
Why start the project?
Often people are surprised to see that we build something like this. They’re even more surprised when they hear that the hardware was paid by our company. They even let us build part of the project during working hours! I really believe in projects like this.
We learned a lot of things, not only about Scala and Akka, but also about working with IoT setups with Raspberry Pi’s and all the hardware challenges. Next to that we learned quite a lot on other tools such as SBT and Gatling. We were really excited about the toolstack which interested other colleagues and got them excited as well. Later on we started doing projects for customers where we used the same toolstack. We then used our experience and lessons learned from our ‘hobby’ project to get started quickly and avoid some mistakes we learned from before.
For more, see Johan’s talk at Voxxed Athens: