scala.bythebay.io: James Townley, A non-typical introduction to Akka remote actors & Raspberry PI
check okay hello so this is a non-typical introduction to akka remote actors with the Raspberry Pi or binky binky lights if you prefer so if you're here because you want to look and learn about practical applications of the Raspberry Pi with remote actors for akka there's other conferences and other talks over there if you're here because you want to see you know an introduction to what remote actors can do and you want to see you know blinking lights okay stick around right round so there you go so I have a bit of a disclaimer to start off with I'm gonna get some volunteers probably from the front row at some point to come up and press some buttons they have some exposed leads on them so it's 5 volts and 60 milliamps so really low it's hard to hurt yourself with but if you like lick them and hold them across your heart or something it's called evolution in action and nobody's gonna feel sorry for you yeah the Darwin Award exactly yeah so a little bit about me my name is James Townley I'm from Edmonton Alberta and Canada that's just a little bit south of Cold Lake Air Force Base where Wolverine is from from Marvel yeah ok so up north cold right now it's probably - something Celsius so it's a it's yeah it's winter they're full-on I work for a company that is in Ottawa Canada called yah works and yok Works is a light band partner we're also a Hortonworks partner we do training consulting and we tend to think of ourselves as expert in distributed systems and micro services so um that's the stuff I was required to say to be allowed to come so I'm done we can actually get on with the rest of the talk so I want to introduce the characters in this story that I'm going to tell so the first character here is the Raspberry Pi so just a quick show of hands who here has heard of the Raspberry Pi who here has used one who's used one for educational purposes that's what they were designed for so specs and specs are on the screen I don't know anyone who's using for educational purposes mainly for fun spectra on the scene the points that I really want to bring out about the Raspberry Pi is on the back there right at the top of one of these guys is a giant row of pins they're called the it's called a GPIO port or the general-purpose in out port and what that is it's a little tool that's created for software programmers to allow them to pretend to be electrical engineers so they basically you have some options with that you can say turn it on turn it off or listen to what it is if it's either on or off so that's that's what that's for so in my case it allowed me to create a whole bunch of little lights that show up there so we have a couple of other characters in this in this story one is mr. tp-link down there a traffic coordinator I went with the wired network option here because well wireless networks presentation yeah let's make it as a hard as possible right so the other character we have is here is the pretentious mac who will also play a role in this in this in this story we're telling and it has use of USB ports so it's not that pretentious yet so let us begin our story so once upon a time there were four raspberry PI's they lived a simple life operating somewhat independently so I'm going to just go ahead and show you what that what that means so I'm gonna go and find the command and I'm gonna just push some code to them so this script just basically is hey start running this particular Java command so it's gonna just go there and while we do that I'm gonna show you the code for that because it's really simple it doesn't have actors in it yet and you know you can see it on the screen there it spools up a little library called PI 4s which is a wrapper for something called PI for J and it has a while statement in there nobody kill me later please the just loops indefinitely and flashes some lights so in a second here we're gonna see all that network traffic having hit those guys and the compile will complete and they should start blinking any second please oh okay good ha whoo that's a that was the most worrisome part of the whole presentation [Laughter] all right so we've got a really simple system here we got independent operation blinking away at their own random intervals so the only logical course of action for me to take at this point is to kill them all and I'll just do that now okay so they go they all turn back on at this point hopefully as soon as I hit the button so they've all turned back on so for the GPIO port it happens to be holding low when there's no other command telling it so that's why they all turn on at the end is because there's no data being sent to it so it's just going to its default so that's going to bring us to the next part of our story here so one day miss boss the pretentious Mac arrived and decided that she wanted to tell all of these little raspberry PI's what to do so I'm gonna get that code running here this is our part one and just while that's loading up we'll have a look through the code here so we're gonna look at the code that's going to be on the raspberry PI's first so we have created a config factory and loaded some config oh look at that config with you guys in a second we create a simple actor system for each Raspberry Pi and then we create an actor on each each Raspberry Pi of this Raspberry Pi listener actor so I'll show you that and the important thing here is that it has its own PI for s and down here we have this case class blink which takes a color at a time and calls that PI for us with blink for this much time it's pretty simple so we have some stop stuff in there but I'm not gonna go in there yet most people have had that actor conversation about how do you stop an actor and that's another talk that takes a day so by now hopefully all the lights have turned out yeah that means they're ready so we can we'll have a quickly the config and then we'll run that so here's our config so it's pretty simple stuff setting up just like a regular actor Oh Ron configure here we go this is a better config so we set it up just like a regular actor that IP address variable is just the IP address of the local of the local device and you're basically saying use this use this TCP transport from Neddie in this case and here's our hostname and here's our port on the master side which will look at the config first and then we'll go and look at the code there we have a list of all the remotes and their IP addresses DNS works as well and we're just saying yeah use the same transport and here's here's who I am then we can look at that master code so we have a config factor again we have a list of our remote actor addresses from the from the config file we have our own actor system and then we create a bunch of actor refs to that so what we're doing here is we're just mapping the the IP addresses to the actor selection here and we're gonna call this cycle a lot lights thing which should in theory get all the lights on all of the machines to run so let's run this and see what happens now pay very close attention to the beginning of this okay did anyone notice something had happened at the beginning there that was a little different that you weren't quite expecting they did not line up when they turned on in so that's gonna you know introduce a little bit of a topic here which is what type of guarantee we have so with with our delivery guarantee with remote actors by default we're getting a at most once delivery so that means that you don't actually have to get any messages and you really notice that at startup they haven't quite got it in their head what they're meant to do yet or something like that and usually you get a few that miss a message especially with the raspberry pies over a network and it just doesn't work so well so that's just one thing to keep in mind when you're working with these remote actors is you have that at most once guarantee it's important so back to our back to our storybook here so miss boss was really unsatisfied with the work that all of these raspberry pies were doing and she decided that she didn't want to necessarily tell them what to do but she also wanted to tell them how to do it which brings us to our next remote example so I'm going to kill everything again because it's nice just to make sure everything is cleaned up and I'm gonna start pushing this out and I will have a look through the code alright so our next example here is the remote actor now a few of you are thinking what because that's it there's no other libraries here I'm not hiding anything in the imports that's not obvious it's just the config system in the actor system I can prove it that's it and that's our remote actor we're gonna deploy just that to the raspberry PI's and you'll notice something here as well as this time I deployed it and the lights didn't go out and the reason for that is because I haven't actually pushed the library that controls the GPIO port to it yet so we've just set them up now that configs a little bit different here so if we look back at our config there we go you'll see that the only difference really is this little deployment line and it's basically just saying that this is a remote actor that's a deployable remote actor the same same sort of setup their master just happens to be the name of the actor system I realize now that it's probably a bad name a little confusing it's just the name of the actor system it has it doesn't have any connotation other than that so there we have it we have this tiny little thing that's been pushed to all those raspberry PI's hopefully all done by now and let's have a look at our main class a little bit different now we're still loading all of the IP addresses from the master config we're still going through and we're getting the address from from those IP address from those IP addresses getting the full address for the actor this time we're creating this props which is a class of the Raspberry Pi listener actor just the props at this point and then what we do is we iterate through all of our addresses and create a props with deploy and the deploy of a scope of the remote scope of the address that's a mouthful so what that translates into is we're saying hey we're gonna deploy to this remote actor and then run the code and then have it handle all of our messages so we got another thing here which is gonna say okay send send all send all your messages and cycle each of the lights and there we go we're gonna push the code to the Raspberry Pi or run it and watch all the light cycling hopefully spank in oh okay so now they're all cycling and we still have that same problem we had earlier it's the at most once delivery but at this point something else has happened right we've sent all of our code to that so some of the more astute or a more security aware of you at this point are going wait a minute did you just set up your system so that you could have remote code execution really easily it gets better you see when you're using a Raspberry Pi and you want to use the GPIO port the process that needs to access the GPIO port needs to be route so we've just enabled remote code execution as route on our raspberry PI's to make this happen okay so oh that's no good I don't care even if you're in a secure Network that's not a good idea the amount of practical jokes your fellow developers can play on you with this not fun so the people at akka aren't stupid in fact they're quite smart so what they've done is they have created some tools that allow you to secure this stuff this is just right from their example stuff I haven't filled it in or anything but you get the idea so you can set up SSL and protocols and and key stores and trusts and all that good stuff so you can actually lock this down and make it a little bit more secure which you definitely want to do if you're running it over somewhere if you're local you may not want to do it I you have your own internal arguments as to whether or not it's a good idea all right so continuing there a story the remote actors the raspberry PI's got fed up they retired they didn't want to boss any more bosses our boss bosses are lame they're old-school they wanted to work together but not with this overseeing despot machine so that brings us to our last example here and I will start pushing the code all right now you're gonna randomly pick two people maybe yourself this is your button don't like it and maybe yourself this is your button don't like it yeah you can pick up your buttons just just don't push them just yet it's still thinking so let's have a look at this code really quickly here you can stand to the side when you push your button raise your hand when you when you go ahead and do that just so people know who's pushing what alright so here we go we have our code for this now this is only a remote at this point there is no master this is all pushed to each of the individual raspberry PI's so again in the config we've listed all of the raspberry PI's sold every raspberry pi about itself and we do the same thing we did on the master in the second example there where we load all of our actors that exist already on this machine I've introduced another little magical trick here which is listening and that is going to listen to these buttons that these guys are gonna press in a second and until incense and message is based on that press of that button so listener is just very simple it's just do some various things depending on which button gets pressed so it's should be deployed all the lights turn off so go ahead and press your buttons raise your hand when you do yeah have fun press a bunch of times it's cool all right so we've got a different couple of different patterns there and now what we have is a system where all of these remote actors are talking to each other they're talking back and forth and they're operating in a situation where they can each talk to each other so there's no master there's no there's there's no slave relationship anymore it's just each actor has the possibility of sending a message and that can be received by any one of these other actors we're doing it you know somewhat randomly at this point as to which actor it goes to for the for the just button over here and for everybody over there so you have a couple of different possibilities with that so that leads us to our our next step here which is they live happily ever after but of course they didn't really because this is this is you're still dealing with this sort of you know at most once delivery so what's next what's the next topic here what's the next thing I want to do with these raspberry pies and blinky lights well how about a cure cluster which is sort of the evolution of these remote actors where you're changing your delivery specification and you're and you're getting to take these and put them in a large cluster and work independently why raspberry pies well because it's really easy to demonstrate things with and they're small cheap and portable so with that I'd like to say thank you guys all for listening and I hope you've enjoyed yourself and I had a bunch of people who allow me to come here at yah works and and spend some time with you and if you have any questions now is a good time [Applause] sorry if it works with I the question was have I had a chance to try it out with Scala data and Scallon native no I have not tried this out with Matt Scala native but Wow do I ever want to yeah any other questions yeah so the question is is why does it take so long for it to download the programs and start up raspberry PI's you know I haven't spent a lot of time benchmarking that my current theory is the fact that the disk on these things sucks right we're talking about a little SD card running on on a USB 2 port so I think a lot of it is just the you know generating the bytecode is slow once it's up and running it one runs like the boondocks like you know it's a quad-core processor in there and it's one point one megahertz at his arm arm seven right so so it runs really well once it's in memory but running from anything from disk or dealing anything on Raspberry Pi with disk is always slow yeah ah okay so question two questions their first question was is how did I assign the IP addresses well this is just a switch but right beside it is a DHCP server which is also a Raspberry Pi and I just did I just did an assignment on it to reserve the IP addresses for the Macs the second question was okay so the question is was basically why didn't they all start blinking at the same time when why where some message was lost okay the reason for that is is that there is a period of time while the actor is spinning up that if any messages do come in during that period of time it may not get them but that's the guarantee that it has right it's part of the guarantee is is at most once delivery so there there is no way to actually ensure that that message gets there without introducing a lot more code pre-roll or AK type stuff and very quickly you created an active cluster if you go down that path yeah oh my apologies thank you guys again if anyone has a few seconds just to help me grip this off the stage really quickly I'd appreciate it [Applause]