.Net Foundation On .NET, 18 Jun 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Building distributed applications with Orleans

Description

Orleans is a framework for building high-scale distributed applications, without the need to learn and apply complex concurrency or other scaling patterns.

In this episode, Sergey Bykov (@sergeybykov) joins us to talk about how Orleans works, and what are some of the use cases of the framework.

02:07 - What is Orleans and what problem does it solve?
03:58 - How does this architecture impact characteristics of the system?
05:18 - How do you implement a Grain in Orleans?
09:25 - How does Orleans manage resource allocation?
13:02 - What types of applications is Orleans used for?
18:35 - Where can you go to learn more about Orleans?
19:28 - What's up next for Orleans?

Check out the links below to learn more about Orleans.
Orleans documentation and tutorials: http://dotnet.github.io/orleans
Orleans on GitHub: https://github.com/dotnet/orleans
Orleans Gitter Chat: https://gitter.im/dotnet/orleans
Orleans on Twitter: https://twitter.com/MSFTOrleans

A

Hey, come check. Our next show on orleans with sergey,.

A

It's on distributed computing., take a look.

A

Welcome to another episode of the on .net show.

A

Today, we're going to be talking with sergey about orleans and I'm rich.

A

Okay. yeah. so,. How about you.

A

Quickly, introduce yourself and then we'll go into the topic.

B

Sergey bykov. I've been working on orleans for many years, now.

B

to the whole story.

B

Of getting it to open source and then moving forward.

B

oh, happy, always happy talk about it.

A

Yeah, and we actually worked on that, the open sourcing, a little bit together. yeah.. We have learned a lot from you, guys. yeah,. We went a little bit before and yeah, that was fun.

B

Always one of the fun because when we started talking, I was shocked like all this energy is kind of let people glowing out, we're open source..

B

Don't you think from the backend? It's just you develop,.

B

But in the open, that's what we're learning from you! Guys.

A

John, we we're still doing it,. It's super successful.

A

Actually, on that note,, I know with our project, .net core,.

A

That I'm amazed actually at.

A

The number of community developers that are working on the project. have you had any success with attracting folks like that?.

B

Yeah, so,, we have a very great community.

B

So, we have the number of contributors,.

B

Both the leisure side and the pull request.

B

Like, I keep mentioning this guy, dimitry, we merged over hundred of his pull requests.

B

A

We focus on performance.

B

We counted just through his pull requests, alone,.

B

We'd double our [inaudible].

A

B

We count on performance.

A

Yeah,, that's super important..

A

We have somewhat similar things on our part.

B

Oh, we have ben. yeah,, we have ben and.

A

Presumably ben's performance improvements.

A

Probably help you guys in some way. of course. so,. How about we talk about what orleans is somewhat? It's for.

A

Also, I just recently talked to aaron at akka.net.

A

So, be good at some point to describe any similarities or differences. There.

B

Okay. so,, how do we explain orleans in a couple minutes. yeah, couple of minutes. that challenging,, let's try.

B

so,? It all starts with good old days where there was client server, server that was holding a bunch of objects to a state and everything was consistent, easy to manage. Locks.. This whole model fell apart many years, ago,.

B

Probably 20 years ago, when the web started., because the moment you had the second server,, you have two copies of the world and they have nothing in common,. There's no coordination.

B

So, the world swished to stateless, where you have frontends, stateless business logic,. They all talk to storage, storages,, where everything is happening. Really.

B

it's inefficient because you need to read data for a request, right?

B

so,. You have conflicts, requests come to different servers. so,. At the end of the day,. You overload your storage.

A

B

Yeah, and of course, we threw in cache say, "yay, we're going to read from cache, write directly,", and then you inherited this problem of cache and validation, and everything.

B

so,. You deal with two storages. so,. The dooley's model is saying,.

B

Based on this idea that let's put stateful middle tier, which is a cluster of service,, have this virtual memory, space.

B

essentially,, where this objects will leave as if they're in the single server.

B

so,, the coldest limitations of a single server machine were limit. Memory, doesn't scale, they'll go away. If we move to the cluster model., if something fails, that's handled, automatically.

A

Now,, does it become more expensive?? The nice thing about the first slide that you have the stateful model is,.

A

Although it has a bunch of drawbacks,, the expense of the system relates almost exactly.

A

To the storage on throughput, you need. is that correct?.

A

Yes. yeah. so, with this system, is there like, "oh,.

A

Well, I need 3x of the cost to maintain this system,", or is that not fair??.

B

No,, that's unfair.. I think it's more expensive because you need to have communication between no,.

B

It's all you and your civilization, and overhead of messaging,, but you don't have to multiply.. You can still have 10 times the throughput.

B

If you have 10 servers or double the service., I see. that's the idea. so,. The picture we arrive to is like this. so,. You have a cluster where you have many, many. These independent objects, we've called them grains in orleans that leave they isolated,.

B

And they talk to each other still.

B

but,, because they're isolated,. Now we don't care if they live on the same server or in different servers. so, from the users, developer, perspective,, it's the same. so,. We have this illusion of a single machine,, but you program against the cluster.

A

Okay. makes sense., I can really show code,.

B

So the grain starts with the grain interface,, which declares what kind of methods we expose.

B

They will have to be in sync and because of async away,, the tpl benefit from all of.

B

That required me this all coals to grain's.

B

These objects are asynchronous.

A

Right. so, is there some factory method, somewhere,.

A

Which is like get me a grain of this type?.

A

Yeah,, that's exactly the next thing.

B

So,, how do you call a grain.? You say give me a grain that implements this interface with this identity.

B

then, to use meant to be application specific and stable like for user,. It could be e-mail,, it could be social security, number, or phone number..

B

Let's say, give me a reference for this grain,.

B

Which, in fact, is just the proxy object, and you can immediately make a call to that object.

B

right. so,. I see that when you.

A

Get a new grain that is a synchronous, call.

A

So, that they're always immediately available.

A

yes. for new grains, and then,. The operations are the things that are async.

A

Are there cases where you let a grain rest, and then get back.

A

then,? That would be an async call,.

A

If it's like, currently residing on one of those other servers, or that's the wrong way of thinking about it?,.

B

I think it all be clear in the next step.

B

So, implementation is simpler,, just the clause that implements the interface. Everything is synchronous.. The key thing here is that,. It's single-threaded..

B

You don't have to protect this counter. That's an example,.

B

You can increment it and guarantee no conflicts. There.

B

make sense., that's more like just the way async works.

A

What? no,, it's a guarantee.

B

So, they sayhello will never be invoked on two threads in parallel for the same object.

A

I see. so,, even if you do, test that run,.

A

For example, in there,, will that not run on another thread or you don't,.

A

You're not allowed to do something like test that run?.

B

You can do different. Test. test is always an exception.. It doesn't respect- okay. but,. There is a way to run multiple tasks., the key is,. They will never run on real threats.

B

within the context of a single object, single grain. There will always be serialized about one at a time.

B

Okay. but so,. The key here is that this grain is, it's a logical, construct. so,. It has this identity.

B

so, user, email, or phone number, and logically loose forever.

B

so,. You can always call at any point.. You don't need to create.. You don't need to delete. you just say, "give me a reference, make a call.".

B

The grain may not be anywhere in memory..

B

It can be just have persistence, stay in storage.

B

but,. The runtime will create an ounce of it when needed,.

B

Execute all the calls, wait for it to be unused for a set period of time,.

B

And then remove from memory because it's idle.

A

I see. so,. What I understand from that is.

A

The grain doesn't really persist.

A

Over time, in the sense of after it's unused.

A

The fact that you might get the same one again is not super meaningful,. It's the data that it represents. That is the more meaningful part. is that fair?.

B

Yes and no. the state is the most important part.

B

But also the runtime creates this,.

B

We call them activation, instance in-memory in the cluster somewhere., like a single instance in the route of a request for the single usable grain to the same physical object..

B

So,, you have both persistent state and the memory state,.

B

Which you can keep there for a long time and that.

B

Contributes to low latency high throughput because you don't have to go to storage for a request. Anymore. okay.! You get more for that, because this grain can talk to another grain,, which is a memory,. You don't have to go to storage.

B

It's a very,, very efficient, method.

B

Okay. makes sense. so,. We end up with this cluster that actually.

B

Handles a sliding window of grains.

A

B

Which you gives you free resource management.?

B

You only have memory used for these grains that are used right now or were used recently.. You want to keep them kind of warm in-memory but other than that,.

B

You don't have to have resources,. You don't have to put all your state for all your users' memory.

A

I see. so, in the storage world,.

A

We talk about like sparse,.

A

Sparse allocation of drives.

A

It kind of feels like this is a sparse allocation in the sense that.

A

The entire universe that.

A

You might be trying to represent, might have a million grains or actors in it.

A

But there's only like 10,000 that are currently active.

A

So,, but you still represent the case that this million or the other whatever, 190,000,, that they exist,.

A

They haven't been deleted in any sense. yeah.

B

They all exist the whole time,. So that's why we call them virtual actors,, like virtual memory..

B

It stays is in page file, kind of a calling,, but you can always get inside this memory.

A

That's a good analogy.

B

This is actually a difference with you mentioned: akka.net. so,, akka or orleans called traditional actor models.

B

There you explicitly create every actor., so you would create, say, create user actor x and then usually need to pick a server where.

B

It needs to leave and then that the actor may create another actor and then you to remove them from memory. so,. This whole resource management is on use to a developer.

A

I see. so more explicit.

B

It's more explicit,, it's more work,, it's more space to make mistakes, because if something failed, you have to recover.

B

here, in this model, without any change,, if you say a server dies,.

B

Right in this picture, then it's only normal event, because the runtime knows, "oh,, we lost actors that are there,. We can immediately recreate them with another server.".

B

right., as long as their state was persisted.

A

To a database of some kind,, then you're good to go. yes.. The key is that you don't need to write.

B

Any application code to recover or to react to the server failure event,, you just write the code for this class that gets activated, can persistent state, can do some actions, and that's it..

B

So, we saw with that code kind of.

A

Looked like for a grain,, I think it was just her console right line there, but presumably there was reads and writes to storage.

A

Now,, do those go through some kind of a layer in.

A

Between the grain and the database or as the grain developer,, I completely own writing to.

A

The database and the consistency model that I need?.

B

Both choices are available.

B

so,. You can go through this kind of simplistic, ecological persistence. Where you say this is the property backlogs, and this is the state of my grain.. Then we have a notion of providers. Persistence, providers,, you declared you're associate., so a user grain class with say cosmos db as.

B

A provider or azure table or whatever, mongodb.

B

Then you just say: right: state,, you update his properties and the property. Back, call a single method and it persists.

B

But if that's not enough for you,, if you want to be more advanced,, you want a low partial state,, then handle it,.

B

You can just write any code and talk to storage, yourself., okay. so,, a lot of flexibility.

A

Yeah. okay. so,. How about we talk a little bit about.

A

Where orlean's is currently used, today.

B

In terms of space or in terms of applications?.

A

Well,, I guess you and I talked about this- a.

A

Little bit earlier, which is in computing, today,,.

A

The main cases are desktop,.

A

Mobile, server, cloud, and iot.

A

so,, in which ones of those do you see orleans?.

A

Where's, its sweet spot?.

B

Well,, it's definitely the backend server side, cloud.

B

Cloud is the natural place, but anywhere on the backend.

A

Yeah. I mean, from this picture. You showed, it's clear that elasticity of resources is a key point.

A

Both from the standpoint of scaling out, but also from the standpoint of failure and recovery,.

A

And pretty much all the other computing mediums.

A

I mentioned: don't have those characteristics.

A

right., then from the beginning,.

B

When we started orleans back in the research,, the goal was the cloud because it was coming.

B

That's where you have these failures at the scale that can guarantee that you can be elastic.

A

It makes sense. so,. I know from having talked to you before that one of the big high profile users.

A

Of orlean's is the halo service.

A

I think it's been using it for like what?

A

five years or something like that or maybe even longer.

A

six, more than six.

A

yeah. okay. has that been a success?.

A

Are they still happy with it?.

B

Absolutely happy. they infected other people, because if it works for halo,, which is a bigger scale, then than mine,, then I should be fine with it.. So it was a huge kind of proof. Point for us.

A

Right. so,, is it the case that, or I shouldn't put words in your mouth,.

A

In a short number, of, yeah,.

A

How would you describe like why it is.

A

That the folks at halo are happy with that?.

A

What's the specific problem, it solves for them?.

B

There are two points.

B

we touched on scalability, and that was one of the two main goals., but the other main goal was developer productivity.

B

so,, because you don't have to write code to do a lot of these things like handle failures or, for example, we propagate exceptions through distributed, call chain.

B

so,. You can write, try catch as if things happen, locally.

B

As a result,, you don't need to write code to deliver failures and make mistakes there and debug.

B

So, developer productivity is much higher and some people say they write three times less code,. Some people claim that 10 times less code.. I don't know what the true metric is in even-.

A

Somewhere between three and 10.

B

That's my feeling. so, that contributes.

B

To efficiency of developers work but also the less code, you write, the fewer bugs you introduce. absolutely.

A

So,, it's used in some big services of microsoft.

A

Has it also been adopted in the outside world?.

B

Yes of course. so,, we had a public preview in 2014 I believe,, and then we open source in january 2015.

B

Very wide range of applications,.

B

Some things I wouldn't even think about., one of my favorite project was this,.

B

Energy management system in hawaii,.

B

Where they have a lot of green power during the day and then distributed to these ceramic woody heaters.

B

So, they turn them on and off on a very short notice,.

B

Using the system, right? now, in release to consume and drive, excess energy and store it in this forms..

B

Everyone thinks that we need the battery. While you have the heat out of it, and then you heat water for free., that's fascinating, project.. I know what it was: like, a couple million mouse traps, iot.

B

Send the signal that,: there is a mouse suddenly in the mouse trap.

A

Oh, literally. literally. mouse, traps. yeah.. What is it, though? About, I can kind of grasp of the mouse trap. One?.

A

What is it about or leans that aligns with.

A

The sun energy transfer story?.

B

The way can I explain it: is,.

B

A leans shines when you have lots of contexts and the context. Maybe like, use a recession. Device. so, you have this water heaters that spread around..

B

They have their own properties.. I see.. Then you send requests to that specific context and say, "turn on," "turn, off," "give me your state.", because it's in memory, you have an iot. They call,.

B

"The ghost device", we got what the term is.

B

So, refraction of a device in the cloud memory,.

B

Has a copy of state., you can leave there like low latency,, very low latency operations.

A

Yeah., I don't think anyone actually does this,, but with those kind of systems, I always think of,.

A

It's like bi-power during the night,.

A

And then pump water behind the dam, with that cheap power and then,.

A

Run the turbines during the day and sell hybrid power.

B

Kind of the same. yeah. it's exactly. in reversal. We did in hawaii. yeah. for sure.

A

So,, if folks are interested in using orleans,.

A

Maybe just to try and experiment with it, to see what it's like are actually adopting it..

A

Where would they go to try that out?? So is it on github?.

A

Yeah. so, just go to github and search for.

B

Orleans, you'll find it there.

B

We also have the gitter chat and the link is there..

B

That's where community hands out, and that sort of gives a lot of energy to my team when.

B

They go and talk with those people in real time and answer the questions, and hear their ideas and feedback..

B

So feedback comes in form, issues and comments with initial,. At the same time, there is new real time, chat,.

B

Where people just come and say.

B

oftentimes,, they will come and say, "thank you for you and him,. We can do better." yes.. It's very nice.

A

It's kind of instant gratification. to get that. so,. I guess maybe two last questions.

A

One is,: what are.

A

Your aspirations for what you want to do with orleans next?, then the second one is, just any closing comments.

B

So, we just had a big like, first, really major release in march. That leads to o.

B

The goal there, was .net core standard compatibility,.

B

So people can run literally anywhere they want. .net core. Has linux and docker containers.

B

It was a big deal for us when we restructure than we matured,. That could be much more dependency,.

B

Injection friendly, and be much more serious about backward compatibility, now.

B

And as part of that,, we introduced data of transactions, which keeps blowing people's mind, once they distribute transactions, that's completely impossible.

B

they're slow and we are trying to pull that low connection scale and be efficient.

B

so,. That's the next big thing: we're finalizing.

B

We have beta working and we should initiated with.

B

Internal team that does virtual commerce to productise it.

A

Right. make sure you take the right amount of money in one account and put in another kind of thing.

B

Yeah. they have a funny sides like exchanging gold coins for cannonballs, and you don't want to spend gold coins that you don't have..

B

So accounting rules apply there as well.

A

Well, I'd be happy to spend gold coins. I don't have to get your cannonballs. no problem. There.

B

In closing,, I.

B

Would invite everybody to github, to open source.

B

It's a great place., github community,. It has some people that sometimes don't even use orleans yet in their day, job..

B

Just like the crowd of people because you didn't tracked seems like, in my opinion, track people direct an experience, they're passionate., so you don't get people that, just do like lazy job,. That would not go there.

B

So, you have this whole selection of people that really know whether you're really passionate and very good to each other, helping and exchanging the ideas.

B

so,. I would advise everybody to go there and just check out their routines and ask questions very friendly..

B

We're there,. My team is there.

A

That sounds like a wonderful community.

B

Yep, we mentioned joints.. I had no problem hiring people on explain, what.

B

A

Yeah, that's where this whole open source thing: is,, right?, that's a hiring mechanism.

B

No. I mean it sets the bar.

B

So it's like, there's the code and everyone can see it, so you can now do your sloppy job or you try to do as best as you can, and you learn to accept feedback,.

B

It's not like the first thing you learn is being defensive and I'm sure you just went through that.

A

Yeah. we're not doing that.

A

Not being defensive. okay,, awesome.

A

well,, thanks for coming by., it's nice to see you were on orlean's is kind of ended.

A

Up having kind of worked with you, maybe two years ago on this., so take a look on github,. I think it's github.com/dotnet/orleans, right?.

A

B

That's right. because we're in the same github, org.

A

So, take a look,, it's one, of, basically, .net core's sister projects, and give it a try.

A

thanks for watching another episode of the on .net show.