Clay Tablet Saas: Built to Scale. (Pt. 2)

See part one here.

Built to Scale. In Real Time.
As I mentioned in my previous post, scalability was concern #1 as we started developing the Saas edition of Clay Tablet.

Up until recently, when building out a SaaS offering, your only choice was to do a lot of upfront planning and figure out, or more likely, guess at, how much traffic or load you were going to need to support. From there you’d start buying servers, find somewhere to host them, and then manage them. It took massive investments of both people and time and there were huge risks. If you didn’t get the traffic you needed you were burning money at an insanely fast rate as servers sat idle, not enough servers and you were crashing or ticking off (and probably losing) customers with slow load times.

To address our scalability concerns Clay Tablet Saas has been built to leverage Elastic Cloud Computing (ECC) technologies (a.k.a “Grid Computing“) .

ECC uses the concept of Virtual Servers - there are of course still physical server boxes but these powerful web servers are divided (the processing power, hard drive space, bandwidth, etc.) up into virtual servers within. So for every physical box in the server environment, there are actually several virtual servers hard at work. Large service providers built these server farms and then rent out processor time.

Now, instead of doing intense planning that will definitely be wrong, we simply rent the processing power that we need to handle the load that our clients throw at us.

In the old style of developing Saas applications adding new servers was an involved process. Simply procuring a new server could take days or even a week, then it needed to be configured, tested and finally worked into the server environment. In contrast, Clay Tablet Saas proactively monitors our message queues and turns servers on or off depending on the load. We can literally go from running a couple of servers early in the morning, bump it up to 10 as we get a little burst around lunch time, and then, within minutes, be running 100 server instances when all of our clients spontaneously decide to get all of their content retranslated at once (and then back down to a couple when things cool down again).

This elasticity means we’ll always have the computing power we need at our finger tips, on demand 24 hours a day, seven days a week.

Next: Built to Scale. Simply