You seem to be applying different rules to MMOs and Github, and I don't understand why. I'd say that there are many ways of looking at this; there exist complex MMOs; and one could look at Github from the point of view of an average user.
E.g., a bit tongue in cheek:
> An MMO is a very simple system, in that there's only one Service Level Indicator (SLI) that devs, shareholders, and players all agree on. That SLI is "can a player connect to the server, and perform regular gameplay actions, without a ridiculous amount of per-action latency."
Wouldn't you say that in an MMO of sufficient scale there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once?
> In systems of sufficient scale, there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once. Never has been, never will be.
Couldn't we redefine SLIs as "can the user connect to the server and perform regular user actions without a ridiculous amount of per-action latency"?
> and one could look at Github from the point of view of an average user.
My point was that Github has no "average user." Github is like Microsoft Word: each user only uses 10% of the features, but it's a different 10% for every user. Yes, there are some features that are in the critical path for all users (loading the toplevel repo view in the website might be one); but for any given particular user, there will be plenty of other features that are also in their critical path.
An MMO, meanwhile, does have an "average user"; in fact, MMOs have ideal users. An MMO's goal is to induce every user (player) to play the game a certain way, so that the company can concentrate their resources on making that particular play experience as polished as possible. There is, per se, an idiomatic "rut" in the road that players can "click into", ending up doing exactly the same short-term game loops that every other player before and after them has also done when playing the game.
MMOs can be reduced to a single SLO: can the ideal player have fun playing the game at the moment?
GitHub cannot be reduced to a single SLO, because there is no ideal user of GitHub. There are probably two or three thousand separate "ideal users" (= critical, non-universal user stories) for GitHub.
> Wouldn't you say that in an MMO of sufficient scale there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once?
No, not really; MMOs have a complexity ceiling by operational necessity. They aren't composed of a ridiculous sprawling array of components. They might use Service-Oriented Architecture, but in the end, you don't scale an MMO vertically by making more and more complex clustered systems with master-to-master replication and so forth. You scale MMOs by either pure-vertical hardware scaling, or by horizontal shared-nothing sharding.
(The key thing to realize about MMO servers is that they're OLTP servers — they need to track a whole bunch of users doing a whole bunch of simple actions at once; and therefore they can't really be doing overly-much computation on those actions, lest they lose shared-realtime verisimilitude.)
I think you underestimate the complexity of MMOs. They can host truly massive events, e.g. https://en.m.wikipedia.org/wiki/Battle_of_B-R5RB . With so many different play styles and optional components (guilds, pvp, official forums, paid content, user made content, etc), I’d say defining an ideal MMO gamer is just as easy as defining an ideal SaaS user.
Not sure if any MMO reaches Github level, most likely not. But I don’t think there is a ceiling or any sort of hard distinction; i.e. I think 5 years from now we could have a MMO with complexity of today’s Github. Maybe it will be called a metaverse though.
I should mention that I've worked as an infrastructure engineer on both MMOs and GitHub-like enterprise-y services.
EVE is literally the only exception to "MMOs scale by horizontal shared-nothing sharding"; and that's why I mentioned the option EVE uses instead — namely, "vertical scaling of hardware" (i.e. having a really honking powerful single-master multi-read-replica DB cluster.)
In neither case is anything "clever" (i.e. inefficient for the sake of developer productivity / enterprise integration / etc.) happening. There's no CQRS message queues, no async batch writes, no third-party services halfway around the world being called into, no external regulatory systems doing per-action authorization, no separate "normalized data warehouse for OLAP, denormalized data for runtime" forking writes, no low-level cross-replicated integration between a central multitenant cloud system and individual enterprise-hosted tenant silos, etc etc.
> With so many different play styles and optional components (guilds, pvp, official forums, paid content, user made content, etc)
I think you misunderstood me when I said that there's a rut that users are guided into. The thing about MMOs is that the ideal user uses all the features (because the game incentivizes doing so, and because the more deeply and broadly users engage with the game's systems, the higher their retention / lower their churn will predictably be.) The ideal player is in both a party (or constantly switching parties) and a guild; has paid for all the DLC and regularly buys cash-shop items; plays every piece of PVE content you build; engages in PVP content and co-op UGC content all the time; etc.
Which is to say, for the ideal user, "the game" either works or it doesn't, because "the game" is the whole thing. Every feature needs to work, in order for the game to work. Because the ideal user engages with every feature. The SLO is, essentially, "can you do a completionist run through every bit of content we have." (If you're clever, and can make your server deterministic, you can create a completionist run as a backend-event demo file and run it in CI!)
And this is, in part, why MMOs are kept architecturally simple. Everything needs to work!
(And I don't just mean "simple" in terms of the backend not being a sprawling enterprise-y mess, but rather usually a single monolithic binary that can keep a lot of state in memory. I also mean "simple" in terms of as much of the game as possible being pushed to local, mostly-ephemeral-state client-side logic. MMOs are, often, a lot less "online" than one might think. It's very hard to "break" an MMO with a content update, because most content updates are to zonal scripts whose state doesn't persist past the lifetime of the in-memory load of that zone in a particular interacting device.)
With GitHub, their ideal users — of which there are many — can be individually satisfied by very small subsets of the system, such that they're still satisfying almost all their users even if one system is horribly breaking. That's what an SLO is "for", in the end: to tell you whether different subpopulations of users with different needs are happy or not. If you only have one "core" subpopulation, one ideal user, then you only need one SLO, to track that one ideal user's satisfaction. If you have more, you need more.
I understand and I had a similar understanding with your earlier comment. I still disagree with: "The thing about MMOs is that the ideal user uses all the features". This seems not a property of MMOs, this seems just a way of working with MMOs.
E.g., a bit tongue in cheek:
> An MMO is a very simple system, in that there's only one Service Level Indicator (SLI) that devs, shareholders, and players all agree on. That SLI is "can a player connect to the server, and perform regular gameplay actions, without a ridiculous amount of per-action latency."
Wouldn't you say that in an MMO of sufficient scale there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once?
> In systems of sufficient scale, there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once. Never has been, never will be.
Couldn't we redefine SLIs as "can the user connect to the server and perform regular user actions without a ridiculous amount of per-action latency"?