Highlight/Main differences of Thundernetes vs Agones

[julianxhokaxhiu]

Hello team,

is it possible to have a TL-DR; of what this projects offers compared to https://agones.dev/site/ ?

Looking at the architecture concept I was not able to visualize the differences, other than in how your CRD looks like.

Thank you in advance,
Julian

[dgkanatsios]

Hey @julianxhokaxhiu, thanks for visiting and for the great question!

First, we believe that both projects (as well as carrier) are great evidence that multiplayer game server developers want to use container-based hosting, and more specifically Kubernetes, for their needs. We're excited to be part of this ecosystem and we are doing our best to provide developers with all the tools they need to be successful!

Thundernetes originates from the Azure PlayFab Multiplayer Servers (MPS) team. The team operates a managed service and has experience in running hundreds of titles at scale for many years, including some high-profile AAA games (some examples: 1,2,3,4,5). So, when we originally designed Thundernetes, one of the first requirements was that the game servers should implement PlayFab Game Server SDK (GSDK). The GSDK has been battle-tested by hundreds of titles since it's also required on the MPS service and has been open source for a number of years, supporting a great deal of programming languages and game development environments (Unity, Unreal, C#, C++, Java, Go).  Use of GSDK has also facilitated the enablement of the MPS Local debugging toolkit.

The integration of Thundernetes with GSDK offers the portability of game servers across platforms (currently MPS and Thundernetes). This allows you to move game server workloads from MPS to Thundernetes and vice versa without changing the server itself. Furthermore, the use of a proven SDK simplifies the work of developers and improves the reliability and performance of the server. This functionality unlocks a variety of scenarios, for example:

• starting with Thundernetes when you launch your game and then later decide to transition to MPS (or vice versa)
• using Thundernetes on your CI/CD pipelines before publishing to MPS (we already have some partners doing that)
• use both services at the same time (MPS for the cloud, Thundernetes on on-premises hardware and/or cloud).

To be clear, Thundernetes can perfectly stand on its own on a cloud provider, without MPS. GSDK just makes a potential move easier and more convenient.

 On Thundernetes design and architecture, as you can imagine, it has been heavily influenced by MPS. All the design decisions are based on prior experience to improve reliability, maintainability and performance. For example, we recommend GameServerBuilds to remain immutable with no rolling updates. We also recommend one session per server and that game server lifetime must correlate with the lifetime of the game server process. We further recommend several Node Pools/Groups for better separation of concerns. To promote seamless scalability, auto-scaling is built into the GameServerBuild CRD with the use of standingBy/max properties.

Finally, Thundernetes utilizes controller-runtime library (which is becoming quite popular among Kubernetes operators these days) and uses a DaemonSet for the NodeAgent/heartbeat handler, which allows for the use of hostNetwork, if it is required. Thundernetes also likes to maintain a minimal amount of Watches to the Kubernetes API Server and tries to be as compact as possible, adhering to the original goal: scale GSDK-enabled game servers and enable allocations on them. All other functionality around the project will be provided as add-ons (example, this project about enabling WebGL game servers on Thundernetes).

Again, thanks for dropping by! Hope this helps, please let us know if more clarifications are needed.

[julianxhokaxhiu]

Hello @dgkanatsios,

First of all thank you very much for taking the time to reply, and actually, with a lot of details and documentation links attached. This is really appreciated!

Said that, I went through every link and detail of the explanation, and while actually I can map the concepts around Thundernetes to Agones ( I've been using Agones for the past year so I'm kind of "deep" into it now ), I really have difficulties in finding differences between the two products other than:

• Having high compatibility with Azure MPS ( so you can switch between the two when you prefer )
• Being developed by Microsoft ( or is this a parallel organization? )

Other than this I am really having difficulties in matching differences. For example:

• Game SDK: Yours vs Agones
• Local debugger: Yours vs Agones
• Lifecycle Management: Yours vs Agones

Essentially, I'm really trying to grasp technical differences that would make me pick one or the other, but at the current state all I can find are merely organizational advantages, instead of technical ones. Even carrier shares the same identical way of doing, in both Architecture, SDK and Lifecycle management.

So, what I am currently wondering right now is: does it make sense to spread the effort across three different projects when we can pick one and iron it and make it shine? What if we involve the CNCF and we all start to work one a K8s native solution? Was anything around this considered before starting this project?

Finally, as I understand ( correct me if I am wrong ), is Thundernetes the FOSS version of Azure MPS or is this a new "copy-clone" which eventually will be used in Azure MPS infra? What is the direction you are having for this product?

Thank you in advance again and sorry for the many questions, but being involved directly into this makes me wonder if this is a better solution compared to what I am currently using and what does it offer ( or does not ) compared to what I am using right now.

Best regards,
Julian

[dzmitry-lahoda]

at least if this project will success, i hope it will fix issues which i got with agones and windows, so agones will get good stuff too. i guess playfab was buncho of hacks for windows.