Building distributed applications with Akka.NET

Just another WordPress site

Building distributed applications with Akka.NET

>> Welcome to another episode of the ON.NET Show We’re going to talk to Aaron Stannard about the Akka.NET Actor model. You won’t want to miss it Hey, welcome to another episode of the ON.NET Show Today, we’ve got Aaron Stannard and he’s going to be talking to us about Akka.NET Thanks for being on the show Aaron >> Thanks Rich. Much appreciated >> Yes, so you work on Akka.Net project and at Petabridge >> Yes >> Can you tell us a little bit about both and we’ll kind of then get into the main topic >> Sure. I’m the Lead Maintainer of the Akka.NET project and I’m one of the founders I did it back to the very beginning And my roles sort of in the open source projects over the years has really been to sort of just ensure there’s a production grade quality behind everything you do, and I also maintain most of the code inside the remoting cluster systems So that’s what I do on the project Petabridge, my company has been around for a little over three years now We provide commercial support, training, and actually we pretty soon, we’re going to be launching a proprietary DevOps suite for managing large Akka.NET clusters pretty soon So that’s what we do Our philosophy behind Petabridge is basic to make it really easy for.NET developers to build applications that scale. That’s what we do >> Okay, that sounds like a good plan >> Yes >> Okay. So, tell us a little bit more about the space I think there’s this Actor model maybe you can tell us a little bit about other implementations that might be kind of similar or kind of different >> Sure Well, so the Akka.NET on its implementation of the Actor model, right? And the Actor model is actually a really old concept been around since the early 1970s Today, in 2018, there’s a few different implementations that are available There were none when we started the Akka.NET projects That’s a big improvement right there But you have Akka.NET itself which is support of the really popular scala project called Akka And Akka is used to power things like Apache Spark and a whole bunch of other systems over the hood So, you have Akka.NET which is a quarter of balance, operates in a very simpler manner to Erlang and some of the other sort of traditional Actor model imitations You also have some sort of I guess new interpretations of that design like Microsoft or Orleans’s and Service Fabric actors, which both implement this virtual Actor model Which has some semantic differences in terms of how Actor life cycle works and everything else But really they’re trying to accomplish the same goal which is making it really easy for developers to build applications that can distribute large concurrent workloads somewhat transparently over flexible networks So you can go ahead add and remove, appears on demand using something like a Windows Azure scaling set, and get a linear increase in the amount of computing capacity that you have >> Makes sense. So, definitely heard this term Actor before, can you give us some more of a sense of what the nature of it is and if it’s similar to anything else? >> Sure. Well, when the original Actor model white paper, from the early 1970s, the Actor model white paper itself is only like a couple years younger than the original relational database white paper Just to give you a sense of how old these ideas are The Actor model was actually developed as a means of doing really high concurrency programming Because computer scientists at the time envisioned that the way major networks and server side applications would be built, would be these big computers that would take up a massive amount of space and have thousands of really small cores And since we didn’t have things like multi-threading, and stuff like that at the time, we needed some way of describing how concurrent processing would happen in that environment So, they came up with this idea of an Actor being a sort of virtual process that would be able to go and communicate with other Actors They’re all logically the same part of the application, but each one behaves at their own little independent micro-process And that’s really the right way to think about Actors is that they’re fundamental units of work So, an Actor has a mailbox which in Darden’s space you can think of is just like a Q essentially That Actor only does work when messages are pushed into its Q, and everything the Actor does was processing that message all occurs in a single thread Which means that everything an Actor does to its own state, like its internal variables and fields, is always guaranteed to be thread safe So, Actors really give people sort of a really basic level If you’re using Actor like just totally inside a single process is a way of doing concurrent programming that doesn’t require a locks or critical regions or any of

the other really nasty sort of synchronization mechanism stuff >> Yes. I’ve definitely been in those situations where it’s like you look at some piece of coding, can I guarantee that the next set of lines are either going to be on the same thread such that I don’t really have to worry about much or there is a potentially a thread transition in the middle and that’s where you kind of get bitten? >> Yes The idea behind the Actor model is to sort of expose to the software developers who are working on a system, a tool that has all these sort of safety guarantees out of the box right So, first guarantees is that your Actor really does one thing at a time There serial nodes So, that means that anything an Actor does its own variables in its own state is always safe Second, is that Actors only process their messages in the order which they receive So, there’s a sort of an ordering guarantee On the order in which the Actors operations are going to be processed The other guarantee is that an Actor states always private No one else can go and modify it from the outside >> I see So, I’m a big fan of bad analogies And so when you were talking, couple of things came to mind Some of that sounds a little bit like Sprite’s in gaming If you’re familiar with that, because there’s very many of them There is a game loop that runs on I kind of get modified and dealt with Another one is seems a little coroutinish as well Do any of those work for you? >> I’ll do the spright one make sense but the differences you have like one event loop thread that kind drives the render but in Actor there can be a unbounded number of threads >> I see. So, the similarity is the fact that you only ever run on one thread and you kind of get some amount of time to run but the dissimilarity is that there are very many threads and it just So is it, a one to one relationship between Actors and threads or there can be multiple Actors on each thread? >> There can be multiple Actors on each thread So, if I could visualize this for a second >> Okay >> So, imagine you have like a 4-core computer And let’s go ahead and just say there’s no hyper threading per second here >> That’s an idea >> So, it means that I have four things that can be executed concurrently at any given microsecond or rate or for these have executed in parallel, rather if you want to be technical What the Actor Akka.NET does to this dispatching system is you might actually have a million Actors that all have messages sitting in their mailbox, and our dispatching system essentially guarantees that those four threads will go in service, all one million Actors in kind of a fair way, based on when the Actor had data pushed into it And each Actor will get the process maybe up to 30 messages by default Four has to go back of the line again, and wait to process the next round of messages in its mailbox >> I see. So there’s kind of a thread pool nature to it And things like starvation are critical concerns >> Yes. And we have the ability to go and configure the dispatching system because there are some cases, so for instance, Akka.Remote for instance is that are the module in the Akka.NET framework to use for letting Actors communicate across process boundaries So, when you start building a distributed system across like Windows Azure, or Docker, or something, Akka.Remotes like the infrastructure that delivers messages from one Actor, one process to another In that set up, the system Actors built into Akka.NET that actually deal with the message serialization and transmission, have these soft real time deadlines they have to adhere to So, we actually go and use a technique called exclusive scheduling, where they get their own thread pool separate from everyone else, so the work here is always really short for those Actors That way if there’s a million Actors on the general thread pool trying to process stuff, these actors can kind of jump to the front line >> Right kind of VIP status >> Yes. Exactly. So, we have some customers who do a lot of IoT with Windows Azure And in some cases, depending on the type of device you’re working with, they might have a scenario where it’s like we have to pull this buffer from this device 400 times a second or we lose frames, something like that. And [OVERLAPPING] >> Yes >> And it’s like the developer doesn’t really have any choice over it It’s like the OEM built it that way Right? And so what they’ll do in those cases, is they’ll put the Actors that pull those frames off of that device on what’s called a pin dispatcher, where the Actor always runs on the same thread over and over again Now, by and large, Akka.NET does a really good job of managing all this for you out of the box So you should probably shouldn’t mess with it, unless you have like an edge case like that, like the IoT example But for most part, we do a pretty good job with fair scheduling and everything else >> Yes. One of the things I definitely learned in the IoT space is those pins don’t queue >> No >> Which is like super annoying It’s like there’s just like electricity

there that has to be observed So, you talked a bit about Azure and Cloud So, it’s funny, you started by saying, Actor started out when computers were like completely different and had different assumptions than they have now, but you know have things come full circle and now all of a sudden the Cloud is like the perfect use case because that would be super odd >> Actually, it’s a really interesting point So the reason why the Actor model was originally designed like the early 70’s and wasn’t actually implemented in a commercially accessible or meaningful way until the late 1980’s when Erlang was originally developed The reason why there was that huge gap there is because Moore’s Law eliminated the need for these, let’s say, living room sized computers with thousands of really slow CPUs in it We had a computer shipped with a small number of really fast ones instead But, as the Internet became a bigger, and bigger, and bigger place, the amount of computing power demanded by applications grew linearly along with that, and now we have Cloud Computing, we can go ahead and essentially just provision new course of computing power on demand The Actor model basically finally got it’s sort of day in the sun here really when the internet started becoming a much larger place where it wasn’t safe or productive to try to run everything on a small number of really high end computers Running lots of work happening on lots of cheap commodity computers was what Cloud Computing is It is usually a more economical model, particularly given that a lot of these workloads people use Actors for don’t have predictable shapes So, I might be processing a million events a second, one day I might be processing 50 million events per second, and then I might drop all the way down to 100,000, and be able to go ahead and provision a deep progression computers to go and do that is a really good technique for trying to keep that so cost effective >> Right. So, you obviously must talk to a bunch of your customers What do you say is the split between on-prem versus cloud with Akka.NET? >> So, it varies a lot by industry the customer is in, and the maturity of the company This is going to sound bad but a lot of the decisions around on-prem or cloud have a lot more to do with political stuff than they do with dollars and cents usually So it’s a good example So we have a lot of major banks like the one’s you probably, some of the people listening probably definitely have accounts with them, they use Akka.NET They have to run everything on-premise because of security, compliance, blah blah, blah, maybe they have this policy of, we don’t let anyone who’s not one of our people touch this stuff We have some large health care customers that use Akka.NET too, same exact story But then we have a lot of startups that go and do interesting things, like there was a startup I talked to that does real time risk modeling for insurance essentially Trying to predict what are the total maximum amount of claims a natural disaster that has these parameters might generate? So the risk using Akka.NET for trying to like run risks simulations and that sort of thing Well, during a time of year when there is not a lot of hurricanes or wildfires going on, their capacity might be a lot lower than normally is, so they might go ahead and spin down the amount of computing power with it So early stage companies that don’t have a lot of legal risk I think tend to lean on the Cloud rule heavily because that operational expenditure of paying a monthly fee, is a lot more palatable than a big upfront capital allocation for core and concrete trying to build the data centers >> Yet, OPEX versus CAPEX >> For me personally, what Akka.NET really, its first real production use case was I built a real time marketing automation analytics for Windows Phone and Windows desktop applications And we ran everything on, originally it was Amazon Web services setup, this is back like, 2013, so back in the day And that made a lot more sense for us just because we couldn’t predict what our load was going to be We had one period of growth where our total network traffic during peak hours grew by 600 percent for six consecutive days So just stuff like that can happen >> So from what you’re saying this isn’t the new way to write a website You have to have a kind of a little bit of a specific shape of application and then you kind of fit into the bull’s eye of the Actor style framework >> So Akka.NET is a little bit different than things like Orleans, or Service Fabric Actors in the sense that it can scale down to run inside a single process, so we actually have people who ship things

like Xamarin applications, or WPF, and I think maybe some Unity games now, where they’re using the Actors to manage concurrent state inside the client app itself So if you’re building a Unity game, you might use the Akka.NET Actors and the client to go ahead and drive NPC behavior, or something like that So there are some use cases that are sort of strictly related to this like local concurrency type stuff At this cases, most people want to talk about, this is what gets organizations to really buy in the Akka.NET in a major way are the big distributed server side cases And, to make an investment in something like Akka.NET, you probably need to have two different problems that occur at the same time The first is, you have what I call a soft real time processing deadline, so using the example that might look like If I am running an analytics company, and I have a guarantee that we will produce notifications about these critical events within any number of seconds of them happening That’s a software time processing boundary If you’re building a trading system, you’re going to guarantee that trades get posted within a certain deadline, for doing E-commerce, you’ve got to guarantee that word it sent So you can see like, it was like a functional structure, I kind of defines what those look like As actually, more and more the case these days, that more and more services have like this sort of real time processing deadlines So that’s one criteria The second criteria is unpredictable demand You don’t necessarily know how many of those requests that you have the soft real time processing guarantee You don’t also know how many of them are going to be at any given time, but you know you have to honor that guarantee for all of them regardless of what the volume is So when those two requests appear simultaneously, typically means you’re going to need to do two things differently than you’d normally do So it’s not about site anymore Now what you really have is a stateful application And what Akka.NET makes really, is it makes it really easy to manage state on your own, it also makes it really easy to linearly increase your ability to process and manipulate state as you add more hardware devices So it really what gives you that linear hardware scalability that makes it easier to predict how many servers do I need to handle this amount of traffic >> Makes sense So, a couple kind of more closing questions, one, does this run on both.NET Core and NET framework, and the other one is, do you know there’s some other trends happening in industry right now? Containerization will probably be top of the list and so I’m curious how this relates, and I guess the last one is, if I’m interested, where do I go look? >> Sure. So the first thing,.NET Core and.NET framework support, we support both We’ve targeted.NET 4.5 since forever when we first started the project, we still do that We have a pretty decent number of users who still on that runtime, but we also target.NET Standard 1.6 So that means that if you’re running.NET core 1.0, or 2.0, or 1.1, or whatever, you can really use Akka.NET And, we also have a fair number of users on Mono as well, we work on that platform too So really, any flavor of.NET you want, as long as, basically, older than.NET 4.5 you should be okay Assuming, newer than.NET 4.5 Occasionally, we get requests like, hey guys if we’re going to get it back with this,.NET 3 or whatever >> Yeah. Containers >> So, we actually have a new sample by finished last week, it’s our web crawler sample that we use for teaching Akka.cluster If you want to build really large distributed systems, Akka.cluster is kind of the foundational tool for doing that So our Akka.cluster demo now uses Docker Compose, and you can go ahead and scale up and down via just a couple simple Docker commands Now it’s all running using ASP.NET Core 2.0, and the most recent beta of the SignalR for ASP.NET Core And then I think we also have containers, which I think running on.NET Core 1.1 which is the out of the box service discovery engine that we use for Akka.cluster I think I sent you a link to that, so you can go and post that on the show notes The other thing that I want to throw out there is that we have a do-it-yourself sort of learned by coding exercise, or teaching yourself the Akka.NET syntax and the Actor model, and it’s called the Akka.NET Bootcamp, it’s been around for a few years, we’ve had about 25,000 people do it, and it is available, go to this URL, learnakka.net, it’s all onboard but it will take you to the bootcamp

And I’ll also go ahead, I’ll send you a link to that as well >> Okay. So it sounds like these links are kind of the place to start What happens if run into issues and need a little bit more help? >> We have a Gitter chat that we linked to off of the main Akka.NET project that has close to 1300 people when last I looked So there is about eight or nine Core contributes at Akka.NET They hang out in there and answer questions periodically, so me included So I usually try to spend ideally about half an hour every day answering questions in there So if you need help with that, you can always go do that We also do check Stack Overflow for Akka.NET questions and we answer those And then worst case scenario, if you want to have someone help you figure out how to architect an Akka.NET application, you can always contact Petabridge, we’ll be happy to do that >> Exactly Well, thanks I think you’ve shared a lot of great information >> Happy to do it, and honestly, anything that helps make.NET developers more productive is what I care about >> You and me, both. Thanks for being on the show This has been another episode of ON.NET This time with Aaron Stannard. Thanks >> Thank you