In the sense of "computing power" this is more or less 1-to-1. But what we aim for is flexibility and ease of management.

When I was about to rent the first server for Wikidot I had to wait 2 weeks until it was provisioned. A year later, the next one came in 2 days. Right now with SoftLayer in Dallas we need to wait 4 hours. On top of this comes our work to configure it, which even now to add any new server we need at least 6-8 hours. Plus we pay up-front for the whole month and can cancel any server only by the end of the billing cycle.

With Amazon+Chef we can deploy new servers within one minute and get it automatically configure within the next minute. We pay only for the time we have it (rounded to full hours).

This is great if:
- We have large spikes in traffic: new web servers will be available within minutes, even without our intervention
- Even in 24h periods, we have less traffic at night, more traffic during the day. We can control number of servers and pay only for what we need instead of keeping all the servers all the time
- When a server breaks down - we will ditch it in the ground and start a new one. This is much easier and faster than filling a ticket "Please replace one of our RAM modules because we are getting errors" and waiting for hours.
- If we suddenly decide our search servers need to be upgraded — setting up a new server with better specs is just minutes away.

So what you can expect is that there will be resources on our side for whatever crazy you might want to do with your sites. If you have a million visitors coming suddenly from nowhere — we will have enough servers to handle them. If you trigger recompilation of million pages — we will spin workers that will do the job.

Also you might wonder why we need up to 20 servers. This is critical. Right now we have 5 powerful machines, loaded with multiple CPUs, tons of RAM, SAS and SSD drives. But each of them play multiple roles and run multiple services. So if there is a hardware problem or one of the services starves resources, several other services are impacted. With AWS we can easily separate roles so that one failure does not affect other components.

Moreover, we are distributing critical components into different data centers (Amazon calls them Availability Zones). So e.g. we keep one database server in zone "a", and another with the replicated data in zone "b". We keep half of the web servers in zone "c" and another half in "d". Even if any given zone is down, we loose only some of our servers and the rest should still work and serve Wikidot.com without interruption. We do it for all critical components, spanning servers over 4 different zones.

I cannot guarantee you will see a significant difference immediately, but I am sure in the long term you will. We still will need some time to tune-up the new setup, but we will start it with enough resources to cope with the stress Wikidot generates.

After the transition is complete we will probably publish a whitepaper about it.

Great! Wonderfull collection of modern backoffice.

ROTFL :-)

Brunhilda, right now you do not need to do anything. If you need to touch any piece of cyber-stuff we will email you and make sure you do it right and on time. Right now I am just giving a sneak peek what to expect next week.

Yes that's what I'd hope for as well.

Is it just me, or are page loads significantly quicker now ~!?

I'm seeing the same thing periodically. Some pages hang on wdfiles for a very long time. Pages that were hanging earlier today are now popping right open (and that's from a different PC). I have found that stopping the page load and then refreshing seems to help in most cases.

Overall, things seem to be really fast now. Pages (with ListPages modules displaying form data) that would sometimes take over 20 seconds to load before the migration are now loading in less than 3 seconds!