Preliminary Thinking: Tactical (Reactive) Use Cases

Over the past few days of relative idle time (hooray for the holidays), I’ve had some time to ponder some the details of our infrastructure. I started with some of the glaring omissions in our online presence, including, for instance:

• Still no side-by-side comparison on MerusCase features with the competition (A1 Law, Abacus, Amicus, Tritek Legal, Med-Legal Perfect Filer, ARS CMPro, etc). We seriously kick all of their asses in our sleep at this point and we should sound that off on high from the heavens.
• Still no serious effort into SEO stuff. We rock at this and just need to take the time to do it.
• MerusCase vs MerusWare vs Fuery Solutions vs My Personal Blog. WTF? Excepting, of course, for likely irrelevant historical babble in my blog, we’re all basically the same and have only slightly divergent messages. Our online presence should echo that.
• Fuery Solutions content is a far cry from our core expertise. Yes, it’s all true, but we have some serious in-house expertise on such a wide variety of competencies that the site feels a bit scattered and fails to cover any of them in the depth truly required to demonstrate expertise. For instance, our methodology surrounding JSON-everything, no HTML in an XHR, super-fast client rendering/sorting/drawing of tens of thousands of data points simultaneously is some enterprise-ready jaw dropping goodness. While the future is MerusCase and not growing the consulting business, we should nevertheless brag about this more. We’re doing brilliant stuff in MerusCase that Salesforce.com with its billion engineers isn’t doing.
• A lot of this content is living on different servers. Good for PageRank, bad for centralized management. We also have quite a few client web sites floating around in the ether, some on shared hosting, some on dedicated EC2 boxes (that’s a server hosted in the Amazon cloud for you noobs), and some on our production MerusCase infrastructure (also in The Cloud). While this was convenient in our early days — we just installed another copy of whatever piece of infrastructure we needed in an on-demand fashion — it is confusing and represents a fair amount of infrastructure to maintain.

All of this actually boils down to the last point from a propeller-headed perspective. If we get our infrastructure straight, then the rest will fall into place with relative ease.

Infra-Who? Or, Why it Comes Down to Eating Your Own Dog Food

The promise of cloud computing is simple: All computing resources, including data storage, number crunching cycles, memory to handle said crunching of said data, and bandwidth to move it all around is gathered and used in an on-demand basis. You need to ramp up capacity for a couple of hours to run some insane computational task? Great, launch your own “sandboxed” resource and fire away.
In the last few months, the MerusCase infrastructure has moved from a “dedicated servers running in the cloud” model closer to true cloud computing. Data is no longer stored local to our web server and then backed up after the fact — now it gets moved to the cloud immediately when a user uploads it. Our apache server can literally be offline, crashed, burning from a nuclear holocaust and data files are still safe. Spin up a clone of our baseline web server AMI (Amazon Machine Instance), and voila, 5 minutes of downtime after said nuclear holocaust. Somehow I think we’ll be worried more about how we’re going to harvest enough bugs to eat, but hey, we sell to attorneys, and they are a detail-oriented bunch.
Our web properties, however, have remained in a state of flux. This is a conundrum every enterprise has had to face at some point in their evolution — the web is dynamic, needs to be fluid, should be updated minute-by-minute, needs to allow for user interaction, etc. Yet engineering teams historically are centrally managed institutions — and with good reason. You let a junior fellow who just joined the team release a piece of code without some verification processes in place and you just might have a broken application released to the wild on your hands. (Social-networking derived approaches like GitHub notwithstanding. Someone at some point with a high level of trust, be it a random fellow with a Lead Engineer title or Almighty Linus himself must “bless” software as it is developed.)
And henceforth came the myriad of Content Management packages. Wordpress, Drupal, Joomla round out the open source database-driven list used by the SMB market. Big commerical vendors also come to mind for the enterprise space, with names like Vignette StoryServer (are they still around?), Autonomy, and Oracle in on the action also. On the flip side, contenders like Google Sites and Microsoft Live Whatever-They-Renamed-It-To-This-Week round out the consumer-driven versions. In a sense, really, Facebook and Myspace are personal content management services; they allow users to post customized content about themselves, their interests, and their relationships. And let us not forget wiki — the open source software behind wikipedia has been downloaded millions of times and is in production on hundreds of thousands of web sites for help articles, topic-specific junior wikipedias, and even Collaborative Project Management.
The beauty of these systems is that non-geeks can post information and content in a safe, efficient, and de-centralized fashion. The downfall of managing many such sites like we do is that every instance essentially becomes yet another highly available, always on, mobile phone alerting, uptime requiring, bulletproof infrastructure needing pain in the neck. Even aside from client requirements (which we are presumably being paid sooner or later to worry about), our own content requires at least four databases at this point, not including any redundancy, development environments, or staging servers. For < 100 content pages and a few hundred blog posts? Really?
(True, I’m including the MerusCase infrastructure in that count, but really that’s just one database. And even though the uptime of our premiere SaaS product needs to be orders of magnitude higher than any of the blog posts, from an architectural perspective, the goal of simplifying the mess moves me to approach these as a singular problem first, then debate the intricacies later. Besides, even two approaches is better than the umpteen we actually have in production right now. Four is actually a gross understatement.)
Now then, we’ve based our business on cloud computing. We’re slowly moving our best customers to the cloud because it makes things easier for us to maintain, it often presents a cost savings for our consulting customers (all SMB), and it allows us to cheaply outsource tasks like backing up data (both files and databases) who have commoditized that very task on a global scale — a place where Amazon has taken a distinctive early lead that Microsoft and Google will have a difficulty overtaking. But that is another blog post for another day.
Put another way, our goal as a web software manufacturer is aligned with Google’s understated one — all your data, all the time, anywhere, on any device. We just happen to be doing it in a niche way for attorneys and our custom software clients.
And hosting a bunch of different wordpress blogs and other Content Management Systems (off the shelf or otherwise) all over the place is not aligned with that goal. We should not be monitoring backups and upgrading multiple installations of various packages.
So how do we fix it?

Possible Approaches to Centralizing Management of CMS (Dynamic) Content

1. Multiple Databases be darned. Just put the whole lot into one instance of MySQL Server (Amazon RDS or otherwise) and call it a day. Host everything through one instance of apache. Use the Wordpress Amazon S3 plugin combined with a series of other standardized plugins (Akismet, Gallery, etc) and work out some magical process through a concerted trial-and-error dance that allows themes to be managed by source control, plugins to be managed by Wordpress Admin, and uploads to flow directly up to Amazon. Repeat this dance for other CMS systems (MediaWiki, etc) in our arsenal. Yeah, that sounds readily scalable and easily reproducible. Not.
2. Move all content to hosted versions of the same. In essence, outsource to the cloud at an application/user level, not an infrastructure level. Using blogspot for MerusWare News, MerusCase Help, and the Fuery Solutions blog (this one) seems possible, but we’ll lose flexibility (categories and .htaccess redirects seem a likely sacrifice). We may also be unable to shield the hosted source completely (Blogger Profiles will probably be readily apparent, for instance). Wordpress.com is another possibility, but that will cost $15 a year per domain and we’ll encounter similar losses in flexibility.
3. Host our own MMU (massive multi-user) version of whatever CMS systems we need and add to them as needed. WordPressMU could probably be extended to do whatever we need it to. Then we can scale it as needed. This doesn’t consolidate everything into one place, however, because of the MediaWiki installations floating around out there, not to mention Merus. It would help simplify and be a fun engineering exercise, but this seems like an awful lot of work considering the necessity to still maintain infrastructure for each CMS platform.
4. Throw some stuff away and consolidate around one CMS. Do we really need all of those wiki installations? Ditto with Wordpress?
5. #4 combined with #2. Consolidate AND switch to (free or mostly free) hosted services wherever possible.

My Initial Proposal

1. Move my personal blog to blogspot. Redirect all incoming links to either articles moved to the fuerysolutions.com blog (historic tech articles) or reallysmartguy.com (new personal blog address). Care needs to be taken, because those incoming 2000+ links have a fair amount of value.
2. Move the fuerysolutions.com blog to blogspot. Host as blog.fuery.com. It’s in our email addresses and has been for a long, long time. It should therefore be our primary domain. Create 301s as appropriate (need to verify this is possible on blogspot or come up with a viable workaround).
3. Move the static fuerysolutions.com pages (now fuery.com) to source control and host on the MerusCase infrastructure. Change code accordingly to point to the new blog.fuery.com. While we’re at it, we should do a facelift and unify the MerusCase and FS brands a bit.
4. Literally combine MerusWare News, MerusCase Help, and Fuery Solutions blogs into one content-wise. This is a pain, but the Help articles need editing anyway and it will help unify our message at a detailed level. Differentiate between the siloed content by using Labels (Blogger’s version of Wordpress Categories). Domains should redirect to the appropriate silos — help.meruscase.com, news.meruscase.com, blog.fuery.com (everything).
5. Throw away merusware.com. All live content pages/links should have a home elsewhere now. (Again, 301′ing as appropriate for SEO love.)
6. Ignore MediaWiki for now. It’s a big task; let’s come back to it.