Building real applications with Orleans
ฝัง
- เผยแพร่เมื่อ 11 ก.ย. 2024
- Microsoft Orleans is a cross-platform framework for building distributed applications with .NET.
In this episode, Reuben Bond joins Cecil to talk about some of the capabilities of Orleans. They cover application architecture, co-host alongside ASP.NET Core, and more.
[01:10] - What problems does Orleans solve?
[03:15] - Do I have to think different about how I build my application?
[04:44] - The architecture of an Orleans application
[10:56] - Hosting Orleans alongside ASP.NET Core (Demo)
[16:44] - How can Orleans scale out?
[18:50] - Using stateless workers
Links
Orleans Homepage
dotnet.github....
Orleans sample application with Kubernetes hosting
github.com/Reu...
Orleans at Microsoft
• Orleans at Microsoft
#Orleans #AspNetCore #Microservices
Cecil is good in directing the course of discussion. And Reuben is good in explaining the tech. Good job!!
Reuben is awesome :)
i like these but i do feel they dont go quite deep enough, maybe they should be like an hour instead of just 20-30 minutes
Thank you, @aL3891! Yes, it's certainly hard to dive deep in such a short amount of time - it has to be limited to just the main points. We'll do some more of these and go deeper. Let me know what you'd like to see covered (on Twitter).
The talk was quite interesting, but again not nearly scratching the surface. I assume audience is full of developers that wrote data driven applications for the most part of their career - like me.
So this sample of a "CRUD" application using Orleans does not help me at all. What I would like to see is:
How can you use Orleans to write typical ~Entity Framework like applications: Searching through products including paging/sorting, etc.
You see, even such a simple "querying and paging" logic is hard for me to vision in Orleans. Would it be a Grain per page? Would it be a grain per search? Or even one grain per product?
If "one grain per product", how do I get these grains when I query "~ products.Where(p => p.Price > 225).ToList()" ?
Or is that a type of application that is unsuitable for Orleans? Are there any fallacies or scenarios that you should not build using Orleans? (I guess it is not a silver bullet...)
Really interested in knowing the these.
Helpful video. Thank you! I'm a little confused on State Storage vs Data Storage. In the video, I see that we are pulling the data from a sqlite database and loading into the state. When we load it into the state, are we storing it in the Azure Table Storage (State Storage) or are we storing it in memory? Do we have two types of storages in this case?
Reuben great video. Thanks for that
I recently started using the Orleans and I had an issue with the grain persistent. As I noticed that Orleans is storing data in json format and uses reference to point to similar item in the document. My data seems to be updated mistakenly where the referenced variable is coming after the reference pointer. It seems to be an issue so my question here is is that assumption correct? If so where can I find that information so that I can reference to that and fix my data.
Your thoughts would be appreciated !!!
I have always found Orleans very interesting but I never got the chance to use it in production. I wonder, now that microservices are taking over the place, how does Orleans fit in a microservices architecture. Awesome content as usual. Thanks.
Personally I would say no. For practical point of view. Orleans makes scaling for you out of the box and it opens the huge possibility to write highly scalable apps. So, yeah, you could achieve a similar thing with the microservices, sure why not, but you would spend three times more time on building only the infrastructure.
But, personally, I'm curious about the comparison of Orleans and Azure Functions.
Any thoughts about that?
@@sebastianbusek2087 it seems to me that using Orleans to implement a microservices architecture, with all the benefits this brings to the table, is restricting. Some of the benefits of mcsvs arch. are the ability to use different tech stacks, use different architectural and design patterns on every service, etc...
@@trocomerlo Yes, for sure, with all the positives and negatives.
I was thinking the same thing. It could potentially make building microservices much easier. Though I am curious about the performance? In this example, they are saving actors state to azure storage?
@@dule88rs This example uses Redis, but you can use practically any database. Internal users often use Cosmos DB, Azure Tables/Blobs, or SQL Server
Actor-model is solution for concurrency, distribute problem.
Microservice distributed system.
We could think about game server with multiple room. Every room, player, game is one silo... It has a same function, same domain... and it's link to a cluster. It is not like a microservice architecture, where every service has it own logic, domain...
How would i batch my writes to the storage layer? I want to essentially delay my writing to storage, and only write it once every fixed interval (1 hour, maybe even once a day).
i want to use Orleans as a cache, and only persist to a storage once a day, since they may be multiple writes to this grains state, and i dont want to have too many writes to the DB
How I can create a unit test for this example?
Hey @reuben can you clarify the differences between Orleans and SF Virtual Actors and what their strengths are?
can you share your demo? i am studying it
sounds like Scala Akka light-bend framework
Maybe compress the high-level parts more for future talks.
There was close to zero actual content for folks that can.. you know, read the landing page of a project?
If "real applications" is in the title, maybe put a bit more meat onto zhese things.
There's way too much noise in the Microsoft ecosystem. Too many competing libraries, frameworks and tools with no clear winner. Starting a new project becomes a long and arduous journey of evaluations. Too often, a wrong choice can be a dead end leading to technical debt. Going with official Microsoft ones doesn't help either as exhibited by LinqToSql which is no longer supported.
I agree with you on this, kinda of difficult for me to start out a new project
Beans are better than grains
I’m assuming you are talking about Java?
Better learn Erlang or Elixir.
That's indeed a more mature and sophisticated technology, but I wouldn't underestimate Orleans virtual actor system. I think it reduces complexity and for many use cases the features that provides are more than enough.
Of course it would be great if you will learn elixir and erlang. But orleans is a little bit different