EQEmu in the cloud

[Vonguru]

Hey all,

I'd love to get a thread going about an "R&D" effort to see what we could do to run EQEmu as a more micro-service architecture rather than monolithic. There are some options as to providers, but I do not want to get wrapped around the axle on that right now.

What I would be really interested in is a couple quick wins to see what it is we could do to alleviate the burden of server operators having to maintain their own infrastructure.

I think a good example would be using a managed database service such as RDS from AWS or Azure Database for MySQL.

Other efforts are somewhat ongoing that I know of including nats.io integration which uses event hubs. Kafka could be another discussion which is more widely supported by major cloud services.

As a project, what would be interesting to you? This "R&D" would be to see how we continue to move the project forward with new technologies that are out there! I realize that AWS/Azure cost money. Let's worry about that later and just get a discussion going around general thoughts.

Thanks,
Von

[l0stmancd]

Why?

What reasonable benefit could be achieved by expending the large effort it would take to move this to a micro service based architecture? There needs to be more benefit than "monolith bad ook ook microservice good ook ook".

Re using RDS from AWS - why do you think you can't do that? I mean, sure - its probably a bad idea since it moves the database further away from the application that needs it and thus brings in round trip latency issues for _literally_ no benefit, but sure - you could do it. Better you than me.

Kafka - Are you even listening to yourself? What benefit do you think you would receive by re-architecting a known good working product to include, for some unknown reason, queues... and then pushing these queues to a third party service provider bringing in additional lag.

You asked for thoughts so here are mine:

* This is a worthless discussion - you have decided that you want microservices without determining if there is a problem in the existing code space that is not well served by its existing architecture and would be better served by stopping all new development instead to shoe horn in technology that is unnecessary.
* Suppose you succeed and now there is a VM Image on Azure/AWS that you can use to spin up "RandomKakfaServer04" - this would be taken down immediately by the providers in question.
* Stop thinking about the cool new technology and how bad monoliths are (because - most of the time - they are not) and instead try to figure out what some of the hard problems are. Spend your time, then, finding a solution to a hard problem that has no solution or a bad solution. If that necessitates bringing in different architecture then sure... but why, for gods sake, would you start this in the opposite direction?

[Vonguru]

Hello there,

I feel honored that I could bring you back to the boards after a 7+ year hiatus. You must really feel passionate about this subject.

Thanks for your feedback. While very aggressive, I suppose everyone is welcome to provide opinions as that is what I said though I am not sure why you would care so much.

I suppose you aren't familiar with the nats.io transition that some members of the community have been working on. Would you like to attack their efforts as well?

TL;DR; - if you aren't interested in trying new things with the project, that is not a problem. If that is the case, maybe save your time and frustration for something else. If you ARE interested in trying new technologies and see what we can come up with, this may be an interesting place for others who want to try new things like me for a game I love.

Let's keep this positive ...

Thanks,
VG

[Uleat]

I'd like to see some specific examples of what you're recommending and an explanation of how they will benefit from such a change.

[Speedz]

eqemu is open source for a reason.
Make your own setup, make it work, provide a working proof of concept...end of story.

[demonstar55]

How do you envision this architecture?

We are also limited by what the client wants. That mainly means we need a single world server, can't really do anything about that.

Zones can already be split up already (hell, you could limit the DB too, at least for zone specific data, but that might be a pain to maintain global NPCs [pets etc])

I guess the main thing is how would you want to handle the DB. We need at least a single authoritative source for player data.

Most people don't really see a benefit since they can generally fire up hundreds of zones and server hundreds of players on a single beefy enough machine. And if it's not beefy enough they can just run less zones.

P99 last I knew had at least 2 servers to spread the zone load across.

[haynar]

Totally doable.

All db queries need to be asyncronous with appropriate checks when waiting for stuff to finish.

Group zone servers with most of db info. Like shared mem. Load all char db info thru world. All NPC info for spawns, etc., would be self contained in zone servers. So only thing hitting main char db (thru world), is player info.

Coordinating thru world is the key.

But really need all the world/zones in same data center for best performance.

Just my opinion.

H

[GRUMPY]

The only MMO I found "trying" to work it's way into microservice architecture
is Eve Online, but nothing to claim they have yet. (don't ask me, haha) Just
mentions something about having moved the game chat to being seperate making
it "one step closer" to the microservice architecture.
When you look at big data like Netflix, Amazon and Ebay using microservice
architecture, it may benefit them, but for this particular project, I can't
see any benefit at all for the work that would be involved for the devs just
to go in that direction. Are we even dealing with the kind of traffic volume
that would benefit from this ? I did a little reading on the pros, cons and
drawbacks involved. Doesn't seem worth it. Don't fix what's not broken ?
Would that kind of crossover involve discord and these forums being flooded
with support questions from "technical newbies" (past and future) ? <GRIN>
EQEmu Support Desk

[Uleat]

I do recall seeing

...to see what we could do...

in his first sentence.

Maybe he's willing to take the reins?

[Vonguru]

Apparently nobody thinks it's worth it. Thanks!

EoT

[Uleat]

Worth it as a 'proof of concept' or 'shits-and-giggles' style coding - no.

No volunteer here has the want or desire to re-code the entire project on a whim.


I asked you to provide examples of changes and how the systems affected would benefit from said changes..but, you failed to do so.

So, to agree with you, "Apparently nobody thinks it's worth it."

[Vonguru]

Why is everyone so aggressive in their discussion? This was intended to be just that, a discussion, not a design meeting to rehaul the project.

I hope this isn't how you all function in your professional lives.

End of thread.

[Auxie]

If you want to get to the bottom of the "aggression", look at it from the developers and maintainers point of view.

I'm sure your intentions were wholesome as you've likely read about some benefits migrating monoliths to microservices, maybe even been a part of a migration yourself! You wanted to contribute to the benefit of EQEmu and you had a good idea to see if this kind of idea could work on this project.

Then you poked the beast. Always keep in mind that the maintainers and developers on the eqemu source code don't directly earn a dime for the code they write for this open sourced project. So really what the members have invested into the project is their time, time that is likely quite costly per hour on the open market.

I've worked as a developer and with many developers and I can tell you, the number one way to get someone to support your idea, is to provide a proof of concept. It does a few things for your cause:

1. Shows that you generally understand what you're talking about
2. Are willing to put in some leg work to help others better understand your ideas
3. Are ready for the criticism that is to follow from the core team

The proof wouldn't need to be huge in scope, maybe a small script that you could contribute to the documentation that would provision a server / db, config them, pull the code, and start the server. This is a softer more gradual change that others can opt in that is not threatening the existing status quo that others are maintaining.

Now let's get to how I personally interpreted your post. It read as if you were claiming something was broken that needed fixing and you had the answer to it. It's not crazy to think that maintainers of EQEmu would interpret that as a threat or criticism. But then it contained no backing points... you openly just said you wanted to start the discussion - as if the maintainers weren't capable of already knowing how to have this discussion, either internally or publicly.

I don't think anyone wants you to die in a car crash, but it's not absurd to feel like you may have called someone's baby ugly and were surprised when they were offended.

I wouldn't consider this the end of the thread. Keep working on efforts to run EQEmu how you want to. Then publicly share your tools you build. That's how you'll see EQEmu running in the cloud. Create the thing you want, and give it back.

That's exactly what the EQEmu devs do.

[image]

Originally Posted by Auxie

If you want to get to the bottom of the "aggression", look at it from the developers and maintainers point of view.

I'm sure your intentions were wholesome as you've likely read about some benefits migrating monoliths to microservices, maybe even been a part of a migration yourself! You wanted to contribute to the benefit of EQEmu and you had a good idea to see if this kind of idea could work on this project.

Then you poked the beast. Always keep in mind that the maintainers and developers on the eqemu source code don't directly earn a dime for the code they write for this open sourced project. So really what the members have invested into the project is their time, time that is likely quite costly per hour on the open market.

I've worked as a developer and with many developers and I can tell you, the number one way to get someone to support your idea, is to provide a proof of concept. It does a few things for your cause:

1. Shows that you generally understand what you're talking about
2. Are willing to put in some leg work to help others better understand your ideas
3. Are ready for the criticism that is to follow from the core team

The proof wouldn't need to be huge in scope, maybe a small script that you could contribute to the documentation that would provision a server / db, config them, pull the code, and start the server. This is a softer more gradual change that others can opt in that is not threatening the existing status quo that others are maintaining.

Now let's get to how I personally interpreted your post. It read as if you were claiming something was broken that needed fixing and you had the answer to it. It's not crazy to think that maintainers of EQEmu would interpret that as a threat or criticism. But then it contained no backing points... you openly just said you wanted to start the discussion - as if the maintainers weren't capable of already knowing how to have this discussion, either internally or publicly.

I don't think anyone wants you to die in a car crash, but it's not absurd to feel like you may have called someone's baby ugly and were surprised when they were offended.

I wouldn't consider this the end of the thread. Keep working on efforts to run EQEmu how you want to. Then publicly share your tools you build. That's how you'll see EQEmu running in the cloud. Create the thing you want, and give it back.

That's exactly what the EQEmu devs do.

Nicely put. +1