How my company went 100 percent cloud

Last year I wrote about my New Year's resolution to go all-in with the cloud. I expected to do this gradually. Then disaster struck.

My company, Open Software Integrators, is like many small to midsize consulting firms. We do high-end projects that, among other things, provide reliability, disaster recovery, and scalability. But like the shoeless cobbler's kids, we were a bit lacking in our own infrastructure until a few months back.

At the time, we still had a couple of quad-core Dell R200s with far too many VMs running far too many things. The maintenance wasn't too bad on average, and aside from a few services, we could tolerate being down for a while. I mainly wanted to "go cloud" because we were (and are) doubling in size every year and I didn't want to create my own internal IT department.

Then, while I was away on a business trip, I got a wakeup call ... literally. Our office is in downtown Durham, N.C., in a historic district that is now home to hot startups, incubators, and incredible breweries (which have turned the neighborhood into a craft beer watering hole). While we've grown into a multi-million-dollar operation, we're a mom-and-pop consulting shop above a paninotecha (which means "sandwich shop" in Hipster Italian).

One night around 2 a.m., a fellow had a few too many -- and while fleeing a hit-and-run, drove his SUV directly into the beauty shop next to the sandwich shop. He severed the gas line. The fire department showed up, cut the power, and broke down our doors to vent the gas. Scarily enough, one of our staffers was in the building, having forgotten something she needed for a trip to India. Luckily, no one from the cigar bar came to check out the scene with a lit stogie in hand, so she was unscathed.

Our servers were down for eight hours, and various services were intermittent for at least 12 hours. Had things been worse, we could have lost everything. Like our customers, we needed HA and DR. Moreover, we thought, maybe our critical services like email, our website, and Jira should be in a real data center.

This made going all-cloud a top priority for us rather than "when we get to it." Fortunately, we already had a lot of cloud experience. Also, we mainly write custom apps for other people; most of our internal systems are stock.

Our hurry-up migration plan

Some of our systems were already in the cloud. In particular, we were already prolific users of Dropbox for backup and file sharing, Quickbooks Online for accounting and payroll, and Expensify for expense reports.

Ascending to the cloud

This chart shows our company's in-house services and the cloud services that replaced them.

We've been running this way for a few months. Some of these services have been reliable, economical, and easier. Others need revision or are riding a declining satisfaction curve.

Google Apps

Google Apps is central to everything we do. Whether it's Gmail or Calendar or authentication for Sugar or Jira or whatever (via Oauth), this is where it happens. Overall, there have been some minor performance issues on occasion, but Google Apps has been increasingly reliable, especially after we switched to a fiber-optic network.

Google Calendar has been a drastic improvement over Zimbra, particularly with regard to mobile integration. It isn't Zimbra's fault per se, but the CalDAV apps on Android aren't great. Nothing beats Google Calendar's integration with the Android Calendar app. Our mobile division has a number of developers with iPhones, and they seem just as happy.

We were already using Google Apps in our personal Gmail accounts before going Pro. There isn't a great migration path. Instead, we've had to implement some workarounds (sharing from personal accounts to the overall account, copying documents, and so on). In the future, we'll have the security of being able to "take ownership" of all of our new documents, but I really wish there was a path.

I'm not overly enthusiastic about our migration of the wiki to Google Apps. As you might expect, moving free-form wiki docs to word processor documents has not worked out so well. Ironically, I don't think the search works as well as it did before, especially since you can't limit searches to a particular folder. Nonetheless, I hate most of the cloud alternatives. I find Socialtext cumbersome and a bad compromise between a wiki and a word processor. Atlassian's Confluence is nearly as laborious -- almost SharePoint-like. Some may regard that as a compliment, but I assure you that it is not.

QuickBooks Online

The great thing about QuickBooks is its market position: Most credit card companies, banks, and other vendors have integration points.

But frankly, Intuit needs to get its act together. QuickBooks Online catches fire more frequently than a 787; Intuit posts oddly suggestive messages that QuickBooks Online will soon be back to "delight you" or other nonsense. We're probably on the verge of outgrowing it as a service. I have a feeling there aren't a lot of multi-million-dollar tech companies with multistate presences using it (indeed, QuickBooks Online's payroll functions handle the multistate aspect poorly).

Migration to the online edition of QuickBooks was very rocky. It recategorized data in a way that messed up our tax returns and the like. However, it freed us from desktop support, as the installed version seems to rely on the most brittle Windows libraries. Now our finance department only needs a browser.

Dropbox

I admit that I haven't completely weaned all of our applications people off of LibreOffice. They still find it helpful for certain uses, and the Google Apps Spreadsheet program has some irritating bugs -- for example, it doesn't adjust the sheet name reference in formulas when you copy a sheet. However, they use Dropbox to avoid emailing file attachments (I'm known for seriously disliking them) and backup.

We haven't tried the new "for business" function. In general, we'll need to move there or get everything into Google Apps, which seems to be an option. We need to centralize control, so if someone leaves, we can easily recover the documents. We use Dropbox as a mirror, so this is less critical.

Sugar On-Demand

This was a rocky migration. We'd had bad experiences with Sugar's support and service in the past, and initially I wanted to migrate to a different vendor. However, I'm filling in as sales manager until we find someone more qualified, and I love the SugarCRM dashboard and manage my month with it. No one else had a dashboard that came close, although the "reporting" functionality we got in the Enterprise upgrade leaves much to be desired.

Because the dashboard was the deciding factor, can you guess what didn't work when we first migrated? You know it: the dashboard. We filed a support ticket, and after a day or two, I did what anyone would do when they don't get immediate gratification: I Twitter-slapped them. The bug was fixed within a few days.

Since then, my opinion of Sugar both as a product and a company has been rising. We'd never gotten the email integration to work before, but now it does. My salespeople are entranced, and our department is becoming more compliant (that is, we're filling out all the fields we are supposed to) since it's automatic anyhow. I can tell where deals are by looking at the email history. I long for telephony integration that will make logging calls and other tasks equally easy.

Overall performance and reliability have been an improvement, and I've been satisfied since our rocky beginning. Sugar On-Demand is fairly expensive per user, though, so we vastly decreased the number of user accounts.

Expensify

Expensify is perhaps our longest-used cloud service. It was a major productivity boost for our operations people. When we started the company over five years ago, receipts were literally stapled to paper and scanned. Now, most of this happens automatically.

That said, Expensify has been one of our more problematic and increasingly unreliable services. I've said before that PaaS and IaaS are technologies, whereas SaaS is a business model. Expensify isn't based on cloud technology at all, if you read what the company has posted. It's also using very old school master-slave or multimaster replication and a SQL database for what seems on its face like a very easy case for a document database since expense reports and receipts are, like, documents and stuff. I can only imagine the queries necessary to put Humpty back together again.

I'm also pretty skeptical that Expensify's stuff will get better. Each recent release of the software has done weird things like blow away preferences or even ignore them, which has caused problems for our accounting people. It's incredibly disruptive because it happens with low predictability.

The overall setup of Expensify is a lot more "self-serve" than we work as a company. We don't make programmers do very much with regard to expense reports (snap pictures of the receipt with the Expensify app and identify whether it is reimbursable or not). I'd like to say this is because we love our developers and would never make them do such a thing, but the truth is that our accounts people simply do a better job. I kind of think their general target user of Expensify is the independent, self-employed type rather than a company of our size.

Jira

I used to hate Jira when software development was the bulk of my responsibility. When I became more of an operational manager, I grew to love it. Now that I'm more of a strategic manager, I love the integration possibilities. We formerly used Trac and QuickBook's time tracking for billing, but getting developers to do double-entry accounting is not easy. We are now able to use Jira for both.

It's possible that one of the newer tools like Rally would overcome some of Jira's shortcomings with process and workflow, but we were already using Jira on premises and migrating to cloud-based Jira was totally painless. Also, swapping something central like an issue tracker used by both developers and operational people alike would be very disruptive.

Additionally, Jira integrates well with Google Apps for authentication. It also worked well when we used LDAP. Single sign-on has become increasingly important to us as we've grown.

BitBucket

I felt a little dubious about BitBucket at first. Atlassian's related product, FishEye, was terribly slow. On the other hand, BitBucket integrates with Google for authentication and integrates with Jira for history, timeline, and more. It's also cheaper than GitHub, since BitBucket charges per user, while GitHub charges per private repository -- and most of ours are private. (We use GitHub for our public repositories.)

We were overdue to move from Subversion to Git. We waited a good while because the IDE integration wasn't there, and Git's command-line interface is cumbersome, especially when onboarding junior staff. We took the time to do a general reorganization, so this was mostly a manual process. We've been happy with it -- although it does have one really frustrating "feature" that makes you pick a username that's unique to BitBucket and can't be an email address. If you're me, this means you either do acoliver42934 (which I loathe) or you end up with acoliverAndALotOfExpletivesJustFreakingWork.

Synaxis

As Drupal users, our natural cloud choice would seem to be Acquia, the best-known cloud-based Drupal offering. But good grief, Acquia wanted a crap load of money or its pricing was too confusing for us simple software developer folk. I tweeted in protest and the company said that if we were happy with an SLA that was less than what we needed, then the price wasn't so bad.

Synaxis CEO Paul Welty engaged me on Twitter, and for about $9k, we got what we needed. As far as I can tell, this is better than what Acquia offered, but Acquia has weird sliders and stuff that don't tell me whether I can get with some kind of 24/7 SLA. When our engineers tried to get a quote, it was something like $25,000 for our two sites (our DBA Bull City Mobile is used for mobile applications).

We've had outstanding service and performance with Synaxis. The company was also very helpful and supportive when we subsequently relaunched our website.

Fiber

We needed to upgrade our Internet connection. We expect to be at nearly 50 people by the end of the year. It wasn't so much the downlink speed as our uplink speed.

The hidden cost is that we upgraded our Internet to 30-by-30 fiber from 50-by-5 cable. It took a long time for the salesman from Time Warner Cable to convince me that 50-by-5 was slower even on the downlink. True, if you're downloading a gigabyte file, it's debatable, but the ramp-up for most usage is far more latent with cable.