|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
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
|
Service |
Existing |
Service provider |
|
Website |
Drupal |
Synaptix |
|
|
Zimbra |
Gmail |
|
Calendar |
Zimbra |
Google Calendar |
|
Bug/issue/time tracking |
Self-hosted Jira |
Atlassian-hosted Jira |
|
Security |
OpenDJ |
Google Apps |
|
CRM |
Self-hosted SugarCRM (community) |
Sugar On-Demand |
|
Wiki |
MediaWiki |
Google Docs |
|
DNS |
Bind |
Godaddy |
|
VPN |
OpenVPN |
No longer needed |
|
Revision Control |
Subversion |
BitBucket |
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.