The processes overall.Quote:
Originally Posted by GeminiReed
It's vanishingly rare to find a server architecture that isn't 100% virtualized that does not either have a hard cap on resources or that has horrible performance when it gets past where they should've put a hard cap. The former is equivalent to when you hit a website and get a "Too busy, come back later." error page, the latter is equivalent to when you hit a website and it doesn't tell you that it's too busy... it just takes 7 minutes to finish sending you the webpage you asked for.
Architectures that are 100% virtualized avoid some of those problems if well-designed, inasmuch as it can dynamically spin up additional resources as needed, but that does require you to write things such that all the associated "things" it needs to work on don't need to be on the same physical resource... which is oft-overlooked and causes no end of headaches in fully-cloud-hosted systems.
And MMOs are honestly one of the the most complex cases for server ecosystems overall; you have servers dedicated to inventory management, to player recordkeeping, to serving specific in-world zones (or instanced duties), etc., and they're usually all tied together in what looks like the world's most nightmarish subway map.
As an example: it doesn't matter how many copies of a dungeon instance you can spawn, if you still choke some other server responsible for handling inventory. (And if you have the inventory server capable of spinning up new resources, you potentially need a way to be able to pass around the responsibility for a given player's inventory from server to server, to allow load balancing at runtime. And...)
Even if you do hypothetically do that right, it doesn't solve every MMO scalability problem, and it introduces some new and different problems along the way; witness that Star Citizen and New World, both of which run entirely on cloud architecture and can hypothetically scale dynamically, still have issues of their own. (And even New World still limited servers to 2000 players on at a time, due to a variety of reasons. Hence their ridiculous queues at launch.)
So I'm not going to throw too many stones; that FFXIV cannot scale entirely dynamically is less a failure on the part of SQEX and more the reality of the era in which this server architecture originates. (Especially since while we know the client shares no code with 1.x's client, we have every reason to think that the server probably still does... and truthfully, I wouldn't be shocked if 1.x's servers shared code with FFXI's back when they were made.)
We know for a fact that the servers are not virtualized. We also know that they do have a hard cap on resources; if it runs out of instance servers for a duty you need, the roulette just doesn't pop until one is ready, and if too many people are inside houses (and thus the housing servers have hit capacity), you just can't go inside of any houses. (This happened -- quite a bit -- right around Endwalker launch.)
An architecture like that doesn't mean that you're stuck forever, of course, but it does mean that you can't make major changes quickly... and when you do make major changes to a live service, you need to be really careful that you don't break everything else.
If it's something you can have friends visit -- or put more precisely, where you can both be there at the same time -- it's something that has to have a server presence in order to handle your locations and interactions with the shared world. And if that's the case then, yeah, I strongly doubt it'll be straight up instanced housing.Quote:
Originally Posted by GeminiReed
I'd love to be proven wrong, though.
And it's possible; they may have been working very quietly on major changes to the server architecture behind the scenes -- they've certainly needed to do a lot of infrastructure work as it is to support the upcoming datacenter travel! -- and maybe they've got a good way to have a more open-ended number of instanced resources now!
I'm just also not holding my breath.