Development services in the cloud
To keep development smooth and not have to spend a ton of money on hardware, we moved all our development applications to Contegix, a managed hosting provider that supported the range of commercial and custom products we used. Our team also had access to the boxes so that every change didn't have to go through a trouble-ticket process (unless we wanted it to).
Having our development systems hosted seemed a bit strange to some people. But most got over that when they realized most developers are working off their own code branches, so they would simply merge the local and hosted pieces of code with the trunk that sits online.
We did run into a few hiccups. The integration of our development applications (Confluence, Jira, Bamboo, and custom code) was nonexistent, so there was a fair amount of work necessary for all the systems to interact properly. And somewhere down the line, one of our guys ordered some servers that we really didn't need. We ended up virtualizing them to the max for QA and testing.
Business apps in the cloud
Most of the cloud apps we used supported business needs, from hosting software for users to download to handling customer data. None of these were within our core competence, and we were glad to rely on someone else to manage them.
Web server and downloads. I remember an ugly day at work back in 1996 when someone kicked out the power-supply plug for the servers that ran all the Bell Labs and Lucent Web sites. People were running around the hallways in a panic. After that, I decided I never needed to host my own Web servers or DNS.
At my open source company, we stayed true to that conviction. We put our Web site and intranet at Rackspace because we had to deal with software downloads and needed a dedicated machine and enough bandwidth for things not to choke.
We eventually moved our product downloads to Amazon S3, where we didn't worry about administration, bandwidth, or anything else. And we spent less than $100 per month for 15,000-plus downloads. We did suffer once or twice when Amazon went down, but we were able to easily change our Web site to point to our main Web server to get the same file. If you have the luxury of occasional downtime, S3 can't be beat on price or performance.
We also started running demos of our software on EC2 that would expire based on an allotted time frame.
CRM. We tried SugarCRM first but got stuck early on by the lack of a customer-support portal module (it's since been added), so we chose Salesforce.com.
Salesforce.com is relatively easy to use -- but only after the initial three or so months of painful trial and error. In addition to the base functionality, we created a very simple customer portal and used the Salesforce.com APIs to pull the data into our look and feel. This was great until we learned that we had exceeded the number of API calls and were forced to upgrade to a more expensive package. Nonetheless, in more than two years, we didn't experience any downtime of note, nor did we lose any information.
E-mail. We made the decision from day one that we never wanted to run our own mail server. E-mail is critical to most businesses these days, and it was critical in our case because we had a worldwide development and support team, continuous integration and build servers, forums, blogs, and so on. With all that to handle, we simply didn't want to deal with the possibility of e-mail going down. Letting someone else handle our e-mail sounded great. And it was great -- except when it wasn't.