World of Warcraft is a massively popular 16 years old game, and maybe one of the most popular games ever. Since its launch in 2004 it’s been changing and evolving into what it is today, which is something completely different to what it was in its inception. Given that a large number of people would like to play the Vanilla WoW, that is, the first version of the game before any expansion was released, Blizzard has decided to roll out a “classic” version with all the content prior to the first expansion. This expansion was released in late 2006, and since there have been many more. Before the company’s official announcement that they would be releasing this classic version, many requests were made for it by fans but they were turned down by Blizzard citing several arguments such as: “the vanilla wow doesn’t exist anymore since the codebase has continued to evolve” and “Vanilla wow would be looking back and we want to move forward”. However, a vanilla WoW paid server named Nostalrius, maintained by fans for fans gained such popularity that during its peak it had more than 100k players on it. Sadly, it had to be closed in 2016 after Blizzard sent them a cease and desist order. It would seem that from the whole episode the company realized that there was actually a market for a classic WoW and they eventually changed their mind.
World of Warcraft is a popular commercial subscription-based cloud-hosted enterprise legacy app featuring a low grade CRM system married to a highly complex logistics system in a standard 3 tier architecture deployed in a fully sharded configuration. Like many legacy systems, it has undergone significant schema mutation over the course of its deployed lifecycle in response to customer demand. Notably, it started out with a mostly-denormalized schema and, with the advent of improved database performance, a better understanding of the customer base’s requirement envelope, and feature creep, it has moved towards Codd’s 3rd normal form.
As with many legacy apps, some customers’ business needs mandate that they stay pinned to older versions of the app. Interestingly, customers have here asked that an earlier version of a cloud-provided app be made available 12 years later, which poses some interesting issues having to do with incompatible schema migration. Given that the app is also written in a mix of obscure legacy languages, the traditional approach of simply migrating the queries and schema together is technically formidable.
One established practice here is to create a proxy facade layer. In this pattern, you keep the interface to the legacy client application exactly the way it is, but create an intermediate layer which translates the db calls to and from the normalized format. This incurs round trip cost and bugs are common in edge cases, especially in frequently-undocumented minor shifts in API and field meaning, and especially given the expected low coverage of unit and functional tests in a 12 year old codebase. This technique is frequently overused owing to underestimation of the cost and time complexity of ferreting out the edge cases.
The other established practice is to perform a one-time wholesale schema migration, normally done either through an ETL toolchain like Informatica, or more commonly through hand-written scripts. This approach frequently takes more developer time than the facade approach, owing to needing to “get it right” essentially all-at-once, and having a very long development loop.
Whatever the technique used, schema migration programs of this scope need a crisp definition of what success looks like that’s clearly understood by all the involved developers, project managers, data specialists, and product leaders. Too frequently, these types of programs fail owing to incomplete specification and lack of clearly defined ownership boundaries and deliverable dependencies. The industry sector in which this legacy app resides is at greater than average risk for failure of high-scope projects due to fundamental and persistent organizational immaturity and improperly managed program scopes.
Also, they better not nerf fear, because rogues were super OP in vanilla and getting the full 40 down the chain to rag with portals was tough enough.
As someone who levelled through Stranglethorn Vale via painstaking underwater+Unending Breath grinds in order to escape OP rogue stunlock love, I say to you: Bravo Sir!. Also, f**k the debuf cap.
For someone who knows absolutely nothing about gaming, World of Warcraft, or this thing in particular… what is this? Can someone explain?
World of Warcraft is a massively popular 16 years old game, and maybe one of the most popular games ever. Since its launch in 2004 it’s been changing and evolving into what it is today, which is something completely different to what it was in its inception. Given that a large number of people would like to play the Vanilla WoW, that is, the first version of the game before any expansion was released, Blizzard has decided to roll out a “classic” version with all the content prior to the first expansion. This expansion was released in late 2006, and since there have been many more. Before the company’s official announcement that they would be releasing this classic version, many requests were made for it by fans but they were turned down by Blizzard citing several arguments such as: “the vanilla wow doesn’t exist anymore since the codebase has continued to evolve” and “Vanilla wow would be looking back and we want to move forward”. However, a vanilla WoW paid server named Nostalrius, maintained by fans for fans gained such popularity that during its peak it had more than 100k players on it. Sadly, it had to be closed in 2016 after Blizzard sent them a cease and desist order. It would seem that from the whole episode the company realized that there was actually a market for a classic WoW and they eventually changed their mind.
World of Warcraft is a popular commercial subscription-based cloud-hosted enterprise legacy app featuring a low grade CRM system married to a highly complex logistics system in a standard 3 tier architecture deployed in a fully sharded configuration. Like many legacy systems, it has undergone significant schema mutation over the course of its deployed lifecycle in response to customer demand. Notably, it started out with a mostly-denormalized schema and, with the advent of improved database performance, a better understanding of the customer base’s requirement envelope, and feature creep, it has moved towards Codd’s 3rd normal form.
As with many legacy apps, some customers’ business needs mandate that they stay pinned to older versions of the app. Interestingly, customers have here asked that an earlier version of a cloud-provided app be made available 12 years later, which poses some interesting issues having to do with incompatible schema migration. Given that the app is also written in a mix of obscure legacy languages, the traditional approach of simply migrating the queries and schema together is technically formidable.
One established practice here is to create a proxy facade layer. In this pattern, you keep the interface to the legacy client application exactly the way it is, but create an intermediate layer which translates the db calls to and from the normalized format. This incurs round trip cost and bugs are common in edge cases, especially in frequently-undocumented minor shifts in API and field meaning, and especially given the expected low coverage of unit and functional tests in a 12 year old codebase. This technique is frequently overused owing to underestimation of the cost and time complexity of ferreting out the edge cases.
The other established practice is to perform a one-time wholesale schema migration, normally done either through an ETL toolchain like Informatica, or more commonly through hand-written scripts. This approach frequently takes more developer time than the facade approach, owing to needing to “get it right” essentially all-at-once, and having a very long development loop.
Whatever the technique used, schema migration programs of this scope need a crisp definition of what success looks like that’s clearly understood by all the involved developers, project managers, data specialists, and product leaders. Too frequently, these types of programs fail owing to incomplete specification and lack of clearly defined ownership boundaries and deliverable dependencies. The industry sector in which this legacy app resides is at greater than average risk for failure of high-scope projects due to fundamental and persistent organizational immaturity and improperly managed program scopes.
Also, they better not nerf fear, because rogues were super OP in vanilla and getting the full 40 down the chain to rag with portals was tough enough.
As someone who levelled through Stranglethorn Vale via painstaking underwater+Unending Breath grinds in order to escape OP rogue stunlock love, I say to you: Bravo Sir!. Also, f**k the debuf cap.