-
-
Notifications
You must be signed in to change notification settings - Fork 138
How did we get here?
We didn't just wake up one day and say, "We need to fork WordPress". Actually, maybe we did. But for Spencer and me it was a two-year journey that began in 2011.
We inherited the care and feeding of a WordPress site with a most unusual workload. Page views were fairly modest at less than one million per month, but the comments were a problem. Posts would see upwards of five hundred comments in as little as two days, multiplied by several posts per day. The current self-hosted solution simply couldn't handle the load. To complicate matters, the hosting company had virtually no experience with WordPress.
So we located another hosting company (with significant WordPress experience) which was able to set us up with load-balanced web servers, dedicated MySQL server, and dedicated cache server. The solution was somewhat effective, if not very elegant. Updating the theme, or WordPress itself, required updating each web server individually. And we still had single points of failure in MySQL and cache.
Unable to find what we considered a viable long-term solution from the average hosting company, we turned to the VIP hosting option from WordPress.com. The end result was simply amazing. The data centers could handle whatever we threw at it. Even posts with more than a thousand comments didn't miss a beat. In short, it was simply the best, and best managed, WordPress hosting option we had seen.
But there was a price to be paid. In order to maintain the level of performance and service we received, the WordPress VIP team demanded much from their customers, and rightfully so. Themes had to be updated and rewritten to meet their coding practices and standards. Direct database calls (which shouldn't be present in the first place) had to be converted to use API calls. Custom database tables were expressly forbidden. Even many of the common plug-ins you have grown accustomed to either were not allowed on the platform or had been updated by the WordPress VIP team to be compliant.
It wasn't long before the restrictions began to hold us back. Management and marketing wanted to push the WordPress site in new and exciting ways, and while we could find some options for working around the VIP rules, the larger and more important initiatives simply were not possible.
While Spencer was dealing with these issues of the WordPress site over the first year, I was involved with migrating other applications to the Azure platform. Those migrations proved so successful that we took a couple of shots at making WordPress run on Azure. But what few tools were available at the time simply were not up to the task.
And then in Summer 2012, Azure announced the preview of Web Sites. A platform intended to solve the problems of running a PHP application on their cloud system. It even included an option to deploy WordPress, complete with a MySQL database provided by a third party.
Azure Web Sites definitely got off to a rough start, when the release approached things were coming together. Though, two problems remained. First, we've learned through testing that the MySQL database offerings are nowhere near as robust (or cost effective) as the native SQL Azure database offerings. Secondly, there is not an Azure-native caching solution available for Web Sites.
The second problem was actually the easy one to overcome (and we released as our Blob Cache platform), but the first is what brought us to this point. For over two years we tested DB abstraction plugins and previous attempts to modify WP core for use with MSSQL. All of them were inefficient and ineffective, but for good reason. Because only with the release of SQL Server 2012 and the corresponding updates for SQL Azure did MSSQL finally have all of the internal support necessary to handle all of the requirements of WordPress.
And that moment, when we realized that SQL Azure now had proper replacements for all required functions, is when we decided to fork WordPress. In a matter of weeks, Project Nami (Not Another MySQL Install) was born.
Forking WordPress core may seem extreme on the surface. But remember that WordPress is itself a fork of b2/cafelog, so this is actually a time-honored tradition. Besides, with the current state of WP Core there isn't another effective option.
Project Nami has a single initial goal, to teach WordPress to natively speak T-SQL while maintaining full compatibility with properly written plugins and themes. This is an important item to note. Any plugin, theme, or function written to access the database via the WordPress API will operate normally. Only those items which attempt fully built MySQL queries will fail. Thanks to our inclusion of a fallback translation layer, many plugins which directly execute MySQL-specific syntax will work. This puts us in the unique position of being able to declare that all WordPress features we have tested are operating as expected. Import, export, paging, multisite; virtually every item which has not functioned in prior SQL Server attempts is operating.
Remember, we built this with the enterprise in mind but Azure allows you to easily scale a site from a low-cost introductory test-bed to a full-scale enterprise operation in just a few clicks.