It should come as no surprise that a geek like myself started with Architecture -- it is a passion of mine and it is also important to start out on the right foot. I wrote many white papers on the architecture required for various solutions espousing on the importance of creating your architecture up front and so that is what I did.

Given that Drupal and, in fact, virtually all CMS systems are simply front-ends to a relational database, the first thing to look at was a DB. As a startup company I knew I didn't want to give Oracle any of my money for their database ... I could go on for a while on this topic but frankly, like many of the software giants, Oracle's DB is overpriced and overhyped ... it is a good DB, for sure, but it is expensive as hell and the support provided is minimal at best. I've often seen implementations of Livelink where the DB costs dominate the equation and wished for an alternative for (at least) the small to medium sized sites. Livelink works with MS-SQL but despite appearances, that too is an expensive decision because of licensing costs (CALs and the like) but more to the point, I don't like Microsoft software and my (technical) dislike certain extends to MS-SQL.

Drupal, of course, supports neither Oracle or MS-SQL and this was one of my first big concerns -- was mysql really up to the task? Could it deal with the load I know I will put on the DB? Will it give me the ability to scale? Will it give me the data integrity assurance I need?

Well, there are scaling issues waiting for me of that I am sure, but I'll have to say that I am quite impressed with MySQL; even though I have deliberately NOT become a DBA I knew I wanted DB replication (for Business Continuity Plan [BCP]) and the ability to scale out to multiple DB servers... The former was absolutely a breeze; creating a Master->Slave replicated DB is well documented and it works pretty much out of the box and made it easy for me to implement our BCP -- problem one solved; data integrity is not a concern. As a managed service we don't have the ability to leave content backups the responsibility of end-users and with replication in place we don't have to.

Next was the computing environment -- while I did spend the majority of my time at OT working on and with MS workstations and servers, I hated nearly every minute working with the forever buggy, expensive, and difficult to work with Microsoft platform. I've been working with it since DOS 2.1 and I can't think of any time at which it hasn't caused me grief. I needed the power of Unix, not just from efficient use of resources (yes you CAN use 4+GB of RAM) but also from a capability and management standpoint. Sure, you can purchase management software to help with MS servers, but with Unix I don't need it! I chose Ubuntu because of cost and accessibility.

There was no real choice vis-a-vis Apache, while there are other web servers available, there seems little reason to look at them.

The real learning curve for me from an architectural standpoint was PHP, with Livelink there were persistent servers that CGI/ISAPI filters / and J2EE Servlets connect to -- scaling of Web was distinct from the application "front-ends" which was distinct from Administration and DB. One of the big advantages to their setup is at the architectural layer where it was/is possible to create multi-networked tiered deployments ... a load-balanced web farm hitting a load-balanced application farm which relied upon horizontally scaled administration and DB services. While such a thing is certainly possible with Drupal, the integrated nature of PHP makes it much more of a challenge.

In the end, what we went with is pretty ordinary: a single DB that is replicated (internally and then offsite) and a set of load-balanced frontend servers that hosts the GATE Village communities. It is clear that a reverse proxy could be used to instill another layer but there is no real value-add to do so.

With the DB setup allowing for tables within a single site to be distributed amongst multiple DBs it is very clear that GATE Village needs to grow by many orders of magnitude before there isn't an obvious and easy to implement growth path.

I have servers dedicated to administration ... they looks like normal front-end servers but are not accessible outside the corporate WAN and thus the backend administrative work (notifications, cache cleaning etc) will not directly affect the performance of the service (it being very difficult for a single application server to overwhelm a DB server).

I also have some spare servers used for "cache creation" but I'll leave that to another page as I talk about Performance.