Building distributed applications with Orleans

>>Hey, come check our next show
on Orleans with Sergey, it’s on distributed
computing. Take a look. Welcome to another episode
of the On .NET Show. Today we’re going
to be talking with Sergey about Orleans
and I’m Rich. Okay. Yeah. So, how about you quickly introduce yourself and then we’ll go into the topic.>>Sergey Bykov.
I’ve been working on Orleans for many years now. To the whole story of getting it to open source
and then moving forward. Oh, happy, always
happy talk about it.>>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.>>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. Don’t you think from the backend
it’s just you develop, but in the open that’s what
we’re learning from you guys.>>John, we we’re still doing
it, it’s super successful. Actually, on that note, I know with our
project, .NET Core, that I’m amazed actually at the number of
community developers that are working on the project. Have you had any success with
attracting folks like that?>>Yeah, so, we have
a very great community. So, we have the number
of contributors, both the leisure side
and the pull request. Like, I keep mentioning this guy, Dimitry, we merged over hundred
of his pull requests.>>Oh, my gosh.>>We focus on performance. We counted just through
his pull requests alone, we’d double our [inaudible].>>Okay.>>We count on performance.>>Yeah, that’s super important. We have somewhat similar
things on our part.>>Oh, we have Ben.>>Yeah, we have Ben and presumably Ben’s
performance improvements probably help
you guys in some way.>>Of course.>>So, how about we talk about what Orleans is
somewhat it’s for. Also, I just recently talked
to Aaron at Akka.NET. So, be good at some point to describe any similarities
or differences there.>>Okay. So, how do we explain Orleans in a couple minutes.>>Yeah, couple of minutes.>>That challenging, let’s try. 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, 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. So, the world swished to stateless where you
have frontends, stateless business logic,
they all talk to storage, storages, where everything
is happening really. It’s inefficient
because you need to read data for a request, right? So, you have conflicts, requests come to
different servers. So, at the end of the day, you overload your storage.>>That’s bad.>>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. So, you deal with two storages. So, the Dooley’s model is saying, based on this idea that let’s put stateful middle tier which
is a cluster of service, have this virtual memory space. Essentially, where this objects will leave as if they’re
in the single server. 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.>>Now, does it become
more expensive? The nice thing about the first slide that you
have the stateful model is, although it has
a bunch of drawbacks, the expense of the system
relates almost exactly to the storage on throughput
you need. Is that correct?>>Yes.>>Yeah. So, with this system,
is there like, “Oh, well I need 3x of the cost to maintain this system,”
or is that not fair?>>No, that’s unfair. I
think it’s more expensive because you need to have
communication between no, 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 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, and they talk to
each other still. 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.>>Okay. Makes sense.>>I can really show code, so the grain starts with
the grain interface, which declares what kind
of methods we expose. They will have to be in sync
and because of async away, the TPL benefit from all of that required me
this all coals to grain’s. These objects are asynchronous.>>Right. So, is there
some factory method somewhere, which is like get me
a grain of this type?>>Yeah, that’s
exactly the next thing. So, how do you call a grain. You say give me a grain that implements this interface
with this identity. 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. Let’s say, give me
a reference for this grain, which in fact is
just the proxy object, and you can immediately
make a call to that object.>>Right. So, I see that when you get a new grain that
is a synchronous call. So, that they’re always
immediately available.>>Yes.>>For new grains, and then, the operations are
the things that are async. Are there cases where you let a grain rest, and then get back. Then, that would
be an async call, if it’s like currently residing on one of
those other servers, or that’s the wrong way
of thinking about it?>>I think it all be
clear in the next step. So, implementation is simpler, just the clause that implements the interface everything
is synchronous. The key thing here is that,
it’s single-threaded. You don’t have to protect
this counter that’s an example, you can increment it and
guarantee no conflicts there.>>Make sense. That’s more
like just the way async works.>>What? No, it’s a guarantee. So, they SayHello will
never be invoked on two threads in parallel
for the same object.>>I see. So, even if
you do, test that run, for example in there, will that not run on
another thread or you don’t, you’re not allowed to do
something like test that run?>>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. Within the context
of a single object, single grain there will always be serialized about
one at a time.>>Okay.>>But so, the key here
is that this grain is, it’s a logical construct.
So, it has this identity. So, user email, or phone number, and logically loose forever. 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.” The grain may not be
anywhere in memory. It can be just have
persistence stay in storage. But, the runtime will create
an ounce of it when needed, execute all the calls, wait for it to be unused
for a set period of time, and then remove from
memory because it’s idle.>>I see. So, what I
understand from that is the grain doesn’t really persist over time in the sense
of after it’s unused. 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?>>Yes and no. The state
is the most important part but also the runtime
creates this, 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. So, you have both persistent
state and the memory state, which you can keep there
for a long time and that 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. It’s a very, very
efficient method.>>Okay. Makes sense.>>So, we end up with this cluster that actually handles a sliding
window of grains.>>I see.>>Which you gives you
free resource management. 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, you don’t have to have resources, you don’t have to put
all your state for all your users’ memory.>>I see. So, in
the storage world, we talk about like sparse, sparse allocation of drives. It kind of feels like this is a sparse allocation
in the sense that the entire universe that you might be trying
to represent might have a million grains
or actors in it. But there’s only like 10,000
that are currently active. So, but you still represent the case that this million or the other whatever, 190,000, that they exist, they haven’t been deleted
in any sense. Yeah.>>They all exist the whole time, so that’s why we call them virtual actors, like
virtual memory. It stays is in page file, kind of a calling, but you can always get
inside this memory.>>That’s a good analogy.>>This is actually a difference with you mentioned Akka.NET. So, Akka or Orleans called
traditional actor models. There you explicitly
create every actor. So you would create, say create user actor X and then usually
need to pick a server where 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.>>I see. So more explicit.>>It’s more explicit,
it’s more work, it’s more space to make mistakes because if something failed,
you have to recover. Here, in this model, without any change, if
you say a server dies, 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.”.>>Right. As long as
their state was persisted to a database of some kind, then you’re good to go.>>Yes. The key is that
you don’t need to write 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.>>So, we saw with
that code kind of looked like for a grain, I think it was just her
console right line there but presumably there was reads
and writes to storage. Now, do those go through
some kind of a layer in between the grain and the database or as
the grain developer, I completely own writing to the database and the
consistency model that I need?>>Both choices are available. 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 a provider or Azure Table
or whatever, MongoDB. Then you just say right state, you update his properties
and the property back, call a single method
and it persists. But if that’s not enough for you, if you want to be more advanced, you want a low partial state,
then handle it, you can just write any code
and talk to storage yourself.>>Okay. So, a lot
of flexibility.>>Yeah.>>Okay. So, how about we
talk a little bit about where Orlean’s is
currently used today.>>In terms of space or
in terms of applications?>>Well, I guess you and
I talked about this a little bit earlier which
is in computing today, the main cases are desktop, mobile, server, cloud, and IoT. So, in which ones of
those do you see Orleans? Where’s its sweet spot?>>Well, it’s definitely
the backend server side, cloud. Cloud is the natural place
but anywhere on the backend.>>Yeah. I mean, from
this picture you showed, it’s clear that elasticity
of resources is a key point both from the standpoint
of scaling out but also from the standpoint
of failure and recovery, and pretty much all the
other computing mediums I mentioned don’t have
those characteristics.>>Right. Then from
the beginning, when we started Orleans
back in the research, the goal was the cloud
because it was coming. That’s where you have these
failures at the scale that can guarantee that
you can be elastic.>>It makes sense. So, I know from having talked
to you before that one of the big high profile users of Orlean’s is the Halo service. I think it’s been using
it for like what? Five years or something like
that or maybe even longer.>>Six, more than six.>>Yeah. Okay. Has
that been a success? Are they still happy with it?>>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.>>Right. So, is it the case that or I shouldn’t put
words in your mouth, in a short number of, yeah, how would you describe like why it is that the folks at Halo
are happy with that? What’s the specific problem
it solves for them?>>There are two points. We touched on scalability and that was one of
the two main goals. But the other main goal was
developer productivity. 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. So, you can write try catch
as if things happen locally. As a result, you don’t
need to write code to deliver failures and make
mistakes there and debug. 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->>Somewhere between
three and 10.>>That’s my feeling.
So, that contributes to efficiency of developers work but also
the less code you write, the fewer bugs you introduce.>>Absolutely.>>So, it’s used in
some big services of Microsoft. Has it also been adopted
in the outside world?>>Yes of course. So, we had a public preview
in 2014 I believe, and then we open source
in January 2015. Very wide range of applications, some things I wouldn’t
even think about. One of my favorite
project was this, Energy Management
System in Hawaii, where they have a lot of green power during
the day and then distributed to
these ceramic woody heaters. So, they turn them on and
off on a very short notice, using the system, right? Now, in release to
consume and drive, excess energy and store
it in this forms. 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. Send the signal that, there is a mouse suddenly
in the mouse trap.>>Oh, literally.>>Literally.>>Mouse Traps.>>Yeah.>>What is it though about, I can kind of grasp of
the Mouse Trap one? What is it about or
leans that aligns with the sun energy transfer story?>>The way can I explain it is, 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. 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, “The Ghost Device” we
got what the term is. So, refraction of a device
in the Cloud Memory, has a copy of state. You can leave there
like low latency, very low latency operations.>>Yeah. I don’t think
anyone actually does this, but with those kind of
systems, I always think of, it’s like Bi-power
during the night, and then pump water
behind the dam, with that cheap power and then, run the turbines during
the day and sell hybrid power.>>Kind of the same.>>Yeah. It’s exactly.>>In reversal we did in Hawaii.>>Yeah. For sure. So, if folks are interested
in using Orleans, maybe just to try and
experiment with it, to see what it’s like are
actually adopting it. Where would they go to try
that out? So is it on GitHub?>>Yeah. So, just go to
GitHub and search for Orleans, you’ll find it there. We also have the Gitter chat
and the link is there. That’s where community hands out, and that sort of gives a lot
of energy to my team when they go and talk
with those people in real time and
answer the questions, and hear their ideas
and feedback. So feedback comes in form issues and
comments with initial, at the same time there
is new real time chat, where people just come and say. Oftentimes, they
will come and say, “Thank you for you and
him, we can do better.”>>Yes. It’s very nice.>>It’s kind of
instant gratification.>>To get that. So, I guess
maybe two last questions. One is, what are your aspirations for what you want to do with Orleans next? Then the second one is, just any closing comments.>>So, we just had a big like, first really major release
in March that leads to O. The goal there, was .NET
Core standard compatibility, so people can run
literally anywhere they want. .NET Core has Linux
and docker containers. It was a big deal for us when we restructure than we matured, that could be
much more dependency, injection friendly, and be much more serious about
backward compatibility now. And as part of that, we introduced data
of transactions, which keeps blowing
people’s mind, once they distribute transactions that’s completely impossible. They’re slow and we
are trying to pull that low connection scale
and be efficient. So, that’s the next big
thing we’re finalizing. We have beta working and
we should initiated with internal team that does virtual commerce
to productise it.>>Right. Make sure you take the right amount of money in one account and put in
another kind of thing.>>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. So accounting rules
apply there as well.>>Well, I’d be happy
to spend Gold Coins I don’t have to get
your Cannonballs. No problem there.>>In closing, I would invite everybody to
GitHub, to open source. It’s a great place. GitHub community,
it has some people that sometimes don’t even use Orleans yet in their day job. 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. 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. So, I would advise
everybody to go there and just check out their routines and ask questions very friendly. We’re there, my team is there.>>That sounds like
a wonderful community.>>Yep, we mentioned joints. I had no problem hiring
people on explain what.>>Yes for sure. Yeah that’s where this whole
open source thing is, right? That’s a hiring mechanism.>>No. I mean it sets the bar. 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, it’s not like the first thing
you learn is being defensive and I’m sure you
just went through that.>>Yeah. We’re not doing that. Not being defensive.
Okay, awesome. Well, thanks for coming by. It’s nice to see you were on
Orlean’s is kind of ended up having kind of
worked with you maybe two years ago on this. So take a look on GitHub, I think it’s, right?>>That’s right.>>That’s right. Because
we’re in the same GitHub org. So, take a look, it’s one of, basically, .NET Core’s
sister projects, and give it a try. Thanks for watching another
episode of the On .NET Show.

Leave a Reply

Your email address will not be published. Required fields are marked *