.Net Foundation On .NET, 2 Apr 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Building distributed applications with Akka.NET

Description

In this episode, Aaron Stannard (@Aaronontheweb) comes on to talk about his open source project, Akka.NET. This is a toolkit and runtime for building highly concurrent, distributed, and fault tolerant event-driven applications on .NET and Mono.

01:35 - Implementations and uses of the actor model
03:13 - What is an actor?
10:04 - Actors in the cloud
12:05 - Running Akka .NET on premise or in cloud
14:31 - Use cases for Akka .NET
17:25 - Supported versions of .NET
18:45 - Running Akka .NET in containers

Check out the links below to learn more about the Akka .NET project.

Petabridge: https://petabridge.com/
Akka .NET on GitHub: https://github.com/akkadotnet
Akka .NET Bootcamp: http://learnakka.net/
Akka .NET Code Samples: https://github.com/petabridge/akkadotnet-code-samples

A

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.

A

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.

A

yes,. So you work on akka.net project and at petabridge.

A

yes.. Can you tell us a little bit about both and we'll kind of then get into the main topic.

B

Sure., I'm the lead maintainer.

B

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.

B

Over the years has really been to sort of just.

B

Ensure there's a production grade, quality behind everything you do, and I also maintain most of the code inside the remoting cluster systems..

B

So that's what I do on the project.

B

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.

B

Akka.Net clusters, pretty soon.

B

So that's what we do. our philosophy behind petabridge is basic to make it.

B

Really easy for.net developers to build applications that scale. that's what we do.

B

okay,. That sounds like a good plan.

A

Yes. okay. so, tell us a little bit more about the space.

A

I think there's this actor model.

A

Maybe you can tell us a little bit about other implementations that might be kind of similar or kind of different. sure.

B

Well,, so the akka.net on its implementation of the actor model, right?

B

and the actor model is actually a really old concept been around. Since the early 1970s.

B

Today, in 2018, there's a few different implementations that are available..

B

There were none when we started the akka.net projects..

B

That's a big improvement right there., but you have akka.net itself, which is support of.

B

The really popular scala project called akka.

B

And akka is used to power things like apache spark and a whole bunch of other systems over the hood.

B

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.

B

You also have some sort of, I guess, new interpretations of.

B

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.

B

Large concurrent workloads, somewhat transparently over flexible networks.

B

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.

B

makes sense. so,. Definitely.

A

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?.

A

Sure. well,, when the original actor model white, paper,.

B

From the early 1970s,, the actor model white paper itself is only like a couple years younger than the original relational database white paper..

B

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.

B

Because computer scientists at the time envisioned that.

B

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..

B

And since we didn't have things like multi-threading,.

B

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.

B

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.

B

so,, an actor, has a mailbox which, in darden's space you can think of, is just like a q essentially..

B

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.

B

so, actors really give people sort of a really basic level.

B

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.

A

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?.

B

Yes., the idea behind the actor model is to sort of expose to the software developers who are working on a system,.

B

A tool that has all these sort of safety guarantees out of the box right.

B

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.

B

second,. Is that actors only process their messages in the order which they receive.

B

so,? There's a sort of an ordering guarantee.

B

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.

A

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.

A

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.

A

Another one is seems a little coroutinish as well.

A

Do any of those work for you?

A

I'll? Do the spright one make.

B

Sense but the differences you have like one event, loop thread. That kind drives the render, but in.

B

Actor there can be a unbounded number of threads.

B

I see. so,, the similarity is the fact that.

A

You only ever run on one thread and.

A

You kind of get some amount of time to run, but.

A

The dissimilarity is that there are very many threads and it just.

A

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.

B

So,, if I could visualize this for a second.

B

Okay. so, imagine you have like a 4-core computer.

B

and let's go ahead and just say: there's no hyper threading per second here..

B

That's an idea.

A

So,, it means that I have four things that can.

B

Be executed concurrently at any given microsecond or rate, or for these have executed in parallel,.

B

Rather, if you want to be technical.

B

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.

B

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.

A

I see. so there's kind of a thread pool nature to it.

A

And things like starvation are critical, concerns.

A

Yes. and we have the ability to go and.

B

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.

B

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,.

B

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.

B

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..

B

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.

A

Right kind of vip, status., yes., exactly. so,. We.

B

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,?

B

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,.

B

Something like that. and [overlapping].

A

B

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,.

B

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.

B

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.

A

Yes. one of the things I definitely learned in the iot space is those pins. Don't queue.

A

B

Which is like super annoying.

A

It's like there's just like electricity there, that has to be observed.

A

so,. You talked a bit about azure and cloud.

A

So,, it's funny,. You started by saying,.

A

Actor started out when computers were like completely.

A

Different and had different assumptions than they have now,.

A

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.

A

actually,. It's a really interesting point.

B

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.

B

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.

B

We had a computer shipped with a small number of really fast ones, instead.

A

But,, as the internet became a bigger,.

B

And bigger, and bigger place, the amount of computing power demanded by applications.

B

Grew linearly, along with that,.

B

And now we have cloud computing,, we can go ahead and essentially just provision new course of computing power on demand..

B

The actor model basically, finally got it's sort of day.

B

In the sun here really when.

B

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.

B

running lots of work happening on lots of cheap commodity. Computers was what cloud computing is..

B

It is usually a more economical model,, particularly given that a lot of these workloads people use actors for don't, have predictable shapes.

B

so,. I might be processing a million events, a second,.

B

One day I might be processing 50 million events per second, and then I might drop all the way down to 100,000,.

B

And be able to go ahead and provision.

B

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.

A

Obviously must talk to a bunch of your customers..

A

What do you say is the split between on-prem versus cloud with akka.net?.

B

So,, it varies a lot by industry. The customer is in,.

B

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..

B

So it's a good example.. So we have a lot of major banks like the one's you probably,.

B

Some of the people listening probably definitely have accounts with them, they use akka.net..

B

They have to run everything on-premise because of security, compliance, blah blah, blah,. Maybe they have this policy of,.

B

We don't let anyone who's, not one of our people touch this stuff..

B

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.

B

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.

B

well, during a time of year when there is.

B

Not a lot of hurricanes or wildfires going on,.

B

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.

B

so early stage, companies that don't have a lot of legal risk. I.

B

Think tend to lean on the cloud rule heavily because that operational expenditure of paying a monthly fee,.

B

Is a lot more palatable than a big upfront capital allocation for core and concrete trying to build the data centers.

A

Yet, opex versus capex.

A

for me personally, what akka.net really,.

B

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,.

B

Originally, it was amazon web services, setup,.

B

This is back like, 2013,, so back in the day.

B

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.

B

So just stuff like that can happen.

A

So from what you're saying this isn't.

A

The new way to write a website.

A

You have to have a kind of a little bit of a specific shape.

A

Of application and then you kind of fit into the bull's eye of the actor style framework.

B

So akka.net is.

B

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,.

B

So we actually have people who ship things like xamarin, applications, or wpf,.

B

And I think maybe some unity games, now,.

B

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..

B

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,.

B

This is what gets organizations to really buy in.

B

The akka.net in a major way, are the big distributed server side, cases.

B

and,, to make an investment in something like akka.net,.

B

You probably need to have two different problems that occur at the same time.

B

The first is, you have what I call a soft, real time: processing deadline,.

B

So using the example that might look like..

B

If I am running an analytics, company,.

B

And I have a guarantee that we will produce notifications about these critical events within any number of seconds of them. Happening..

B

That's a software time processing boundary.!

B

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,.

B

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..

B

So that's one criteria.! The second criteria is unpredictable demand..

B

You don't necessarily know how many of those requests that you have the soft real time processing guarantee..

B

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..

B

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..

B

Now what you really have is a stateful application.

B

And what akka.net makes really, is. It makes it really easy to manage state on your own,.

B

It also makes it really easy to linearly increase your ability to process and manipulate state. As you add, more hardware, devices.

B

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.

A

So, a couple kind of more closing questions, one,.

A

Does this run on both.net, core and net framework,.

A

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,.

A

If I'm interested,, where do I go look?

A

sure., so the first thing,.net.

B

Core and.net framework support,, we support both.

B

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..

B

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.

B

and,. We also have a fair number of users on mono as well,.

B

We work on that platform, too., so really, any flavor of.net you want,.

B

As long as, basically, older than.net 4.5. You should be okay.

B

assuming,, newer, than.net, 4.5.

B

Occasionally, we get requests like,, hey guys if we're going to get it back with this,.net 3 or whatever.

B

yeah. containers.

A

So, we actually.

B

Have a new sample by finished last week,.

B

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,.

B

And you can go ahead and scale up and down via just a couple: simple docker, commands.

B

Now it's all running using asp.net core 2.0,.

B

And the most recent beta of the signalr for asp.net core.

B

And then I think we also have containers,.

B

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..

B

I think I sent you a link to that,, so you can go and post that on the show notes..

B

The other thing that I want to throw out there is that.

B

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,.

B

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.

B

And I'll also go ahead, I'll, send you a link to that as well. okay., so it sounds.

A

Like these links are kind of the place to start.

A

What happens if run into issues and need a little bit more help?? We have a gitter chat.

B

That we linked to off of the main akka.net project that has close to 1300 people when last I looked..

B

So there is about eight or nine core contributes at akka.net..

B

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..

B

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.

B

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.

A

Well, thanks., I think, you've shared a lot of great information.

B

Happy to do it, and honestly,.

B

Anything that helps make.net developers more productive is what I care about.

A

You and me, both., thanks for being on the show.

A

This has been another episode of on.net.

A

This time with aaron stannard. thanks.

A