When I was a kid I was always that nerd who was pushing the limits of my hardware, and over-clocking CPU’s, mainly because I didn’t have the money to buy the good stuff. I had more time than money, so it was easier for me to develop half-baked strategies like “poor man’s RAID”, where you just write a program to automate the copying of files onto multiple drives instead of buying an actual RAID controller to sync it properly. As I advanced in my career and found myself with more money than time, I started building complex redundant networks. It was expensive, but the redundancy made the cost worth it – that is, until cloud computing came into the mainstream and changed the way I looked at hosting websites.
In 2008 when I began developing the Cartooga platform, “cloud computing” was still a buzz word and I hadn’t really seen any company do it well yet. I had a problem with putting my faith in someone else’s hardware – I survived the first dotcom crash 11 years ago and remember when entire data centers shut their doors, causing a lot of small companies to lose their websites because the data center they were using maintained their server(s) and backups. The thought of developing a fairly complex application to service thousands of ecommerce customers on hardware I didn’t own was still a scary prospect for me. When it came time to design Cartooga’s network I had 25 MB of fiber run to my building, built out a climate controlled server room, and bought a rack’s worth of servers, firewalls, disk array’s, and backup power supplies. I doubled up on everything to make sure there was no single point of failure.
Except I forgot one thing – the physical location of the hardware itself was a single point of failure. What if Cartooga’s growth continues and this network is no longer adequate? What if there is a fire or a major hurricane hits my part of Florida? What if ninjas infiltrate my building and steal my servers? As more and more customers started moving their e-commerce sites to Cartooga, I started thinking about all of these things. Well, not so much the ninja part, but I knew needed a better long-term solution. Something scalable, that would never go down, but still worked like a stand-alone Windows 2003 server.
Enter cloud servers. The image to the right (courtesy of Rackspace) illustrates how cloud servers work. Imagine multiple servers working together as one and “your server” is not a physical machine, but an instance among many servers sharing the same resources. As your application grows in CPU/memory requirements and disk space, you can request more resources from the cloud and they’ll be allocated to you automatically. If a physical machine within the cloud dies, the remaining servers pick up the work-load until it’s replaced.
The short version: it works like a regular stand-alone server that never goes down and can instantly grow in size, CPU, and memory when you need it. It’s the closest you can get to a 100% up-time guarantee, and frankly any web hosting company that isn’t hosting your site this way is putting your business at risk. The temporary inconvenience of changing IP addresses is worth the added value.
With most of the data we’re hosting now moved off-site, the network I built leaves Primordium with one heck of a development environment. And as for my fear of the data center going out of business, well, I still back up all of our data on those cloud servers to that local network. It probably isn’t necessary, but old habits die hard.
hello there, outstanding website, and an excellent understanding! at last one for my favorites.
Great article, ninjas are real.
On and off since the 90′s, just mostly through forums and not really developing a “personal brand”.
Truth be told though, I’ve been running my mouth my whole life.