Box.net is a cloud-based file sharing service that I used extensively in my last book. Similar to dropbox.com, Box.net allowed my publishers and I to automate our workflow with regard to the publishing process, but more importantly, I was actually able to do much of the review and exchange of files from the iPad, which was really nice given that the book was on iOS. I’ve been working with a few companies over the past few weeks on coming up with various strategies for cloud interoperability, and Box.net has come up a few times in this regard. Looks like I’m not the only one!
NAS (Network Attached Storage) devices are a popular alternative to providing centralized file services to smaller environments. This includes devices such as the Seagate BlackArmor, the DroboShare NAS and the Netgear ReadyNAS Pro. These are inexpensive as compared to an actual server, they require less management and they often come with some pretty compelling features. But one of the primary reasons to buy a NAS can end up being a potential pain point as well: they require less management than a server because they can’t do as much as a server can.
For example, the option to replicate between two of them. Most have NAS to NAS replication built in. However, that replication ends up being dependent on having two of them. But what if you just have a machine on the other side of the replication, want to back it up remotely compressed or want to back up to a cloud environment. Well, if it’s not the same daemon then you’re typically stuck with CIFS, NFS, HTTPS (WebDAV) or FTP. The devices don’t typically give you the option to push directly from it nor to run a daemon that non-proprietary device can connect to directly, so you’d have to use a client to do the offsite sync. One example of how to do this would be to use JungleDisk and an Amazon S3 account. JungleDisk would mount the AmazonS3 storage and the NAS storage (all share points). You would then use a tool such as ChronoSync, Retrospect (Duplicate scripts not backup scripts btw) or even rsync to backup the device over CIFS. It’s not pretty, it’s extra latency and management, but it would work.
The reason you would do synchronization is that if you attempt to backup (a la Retrospect Backup Scripts) then you’d send big, monolithic files over the wire. The smaller increments of data you can send over the wire the better. Another tool that can do that type of sync is File Replication Pro. That would actually do blocks instead of files, pushing an even smaller increment of data over the wire. There are certainly other services. You could even open up the firewall (for just the specific ports/IP addresses requiring connectivity, which is always a potential security risk) and have a remote backup service come in and pull the data sync over FTP, CIFS or WebDAV (if you want to stick with a cloud backup solution), but those types of services are a bit more difficult to find.
The same is pretty much the same for cloud based storage. With the exception that instead of a built-in feature you’re either looking for a built-in feature or an API that allows you to develop your own. The moral of this story, if you use a NAS or a cloud-based solution and you want to back your data up, then your options are limited. Keep this in mind when you decide to purchase a NAS rather than, let’s say, a Mac OS X Server running on a Mac Mini with some Direct Attached Storage (DAS) connected to it.
Microsoft released Service Pack 2 to Microsoft Office 2008 for Mac earlier this week. Once you have installed Service Pack 2 you may notice the new Open from Document Connection File menu item for office applications, or you may notice the new application called Microsoft Document Connection located in your /Applications/Microsoft Office 2008 folder. These are all part of Microsoft’s overall Software+Services strategy: provide a cloud type of environment that is able to sustain the software that you purchase from them. In this case it could be a private document storage “cloud” running on a SharePoint server or it could be a more public environment running in the Office Live environment.
We’ll cover SharePoint integration some other time, but for now, let’s look at the Live environment. Before you setup your computer, first login to your Microsoft Live account at home.live.com. Once you are signed in, click on the More menu and click on Office Live. If you see a button for Get Started for Free, click it; otherwise you should be looking at a screen with an icon in the left column for New Workspace. Click it and then type something that indicates a project or a group of documents you might upload. For example, I’ll just type Mac OS X Security 2nd Edition.
Now that you have a workspace, open up the Microsoft Document Connection application in your Office directory. From here, click on Add Location… and then click on Sign In to an Office Live Workspace… At the dialog box, enter the name and password you use to log into Microsoft Live, clicking Save when you’re done. Now you should see the name of your live account in the Document Connection screen, along with any workspaces you’ve created. You can drag documents into this screen, double-click them to open or control-click them to edit (and you can edit from non-Microsoft applications). At this point you have something similar to Jungle Disk or another application you use to access a cloud service from a Mac.
But Document Connection isn’t just about one user accessing documents. It supports sharing documents between users, commenting on documents and even document check-in and check-out. The portal is where you setup most of the Sharing: use the share button, type the address of who you want to share to, they can then access via the portal or using Document Connection with their own account. Commenting is also available in the portal, much as with a solution like Final Cut Server. Document check-in and check-out seems to require SharePoint and not be a feature of Office Live, but I’ll let you know if I can find a way to do it.
Overall, this is a great addition. Some other products are more mature, but as usual, Microsoft has taken the best from a number of competitors and made an extremely simple to use and intuitive sandbox. The uploads and downloads fail at times. The portal relies on constant communication from Silverlight so sometimes it throws an error. But those are minor issues. This is a great new product that I look forward to integrating into a number of environments. I’ll get to the SharePoint side in the next few days and do a write-up on it as well!
These days it seems like there’s a low-cost or free alternative to everything up on the web/in the clouds. This could be something like gMail for email, OpenDNS for DNS or even one of the many sites that provides users with file storage. Now enter j.otdown.com. Using this service you can type text to your hearts content. When you stop typing a url will be generated and automatically saved. You can then use that URL to revisit your document at a later time.
You can also use the Share button to then email the link to others. For example, this document was created and shared by yours truly. It’s got a lot of useful information in it… 😉
When a large company loses email and other services the help desk is abuzz with calls. But who do you call when an outsourced vendor goes down? I’ve read a number of reports about the Google outage from a few days ago. Having millions of users without service, or with deprecated service, is a lot of potential calls. Just like tens of thousands in an enterprise is lot when those users cannot access email. In the reports I’ve read people were taking a very strong stance on the outage, not necessarily with Google directly, but identifying cloud support options across the board as having “no one to call.” Really? There’s no way to identify a known outage or call someone?
If you have an outage or a problem with Google Apps then you can get support following the steps outlined on this page. Additionally, if you want to check the Google availability for services (both in historical and current contexts) then you can check the google.com/appstatus site. Google also went insofar as to publish a disruption/incident report on the severity and the issues that caused the outage. I love transparency.
IT environments have outages. Google outages, and outages for any cloud-style environment are typically more rare than most organizations I see in production. There is a support line to call and there is also a status page to check, fairly in-line with what you would have for application support for most enterprise organizations. But what gets me is that many of the people writing columns voicing outrage about the outages with Google are the very ones who also write columns about the death of corporate IT and the emergence of the consumerized IT paradigm.
The cloud is not for everyone, but having the option of cloud-based services is a great thing. It’s not right for everyone. However, if you choose to go the route of initiating a large migration towards a cloud-based delivery model for applications then one aspect of keeping that cost at a minimum should be to educate the end users on who to call when it goes down (because at the end of the day, everything goes down every now and then). If it’s a Mac OS X environment maybe you build everyone a widget that displays the availability page or a mash-up of multiple availability pages from vendors on a per-application basis. This would save a lot of wasted time for the service desk (although some users will still call there first).
Overall, there is no substituting an internal solution with one that is cloud-based; this includes both the good and the bad aspects. Internal servers take more resources to manage, there’s always the potential for infighting with the administrator of the application stack that resides on a server and of course, you need to buy the gear that the solution lives on. However, when you outsource that server, which is at the end of the day what you are doing when you employ a SaaS solution, then you end up with diluted ownership, powerlessness when the solution is unavailable, increased bandwidth utilization, feature lock and other negative impacts. There are a lot of arguments to both ends that can be made with regards to moving into any outsourced solution. But complaining about not being able to call a service desk without bothering to check availability nor what the contact information would be for said service desk is ludicrous. If you don’t know how to contact the SaaS vendor then it is more than likely the fault of our organization for not doing the due diligence to document the support scheme ahead of time (or said another way, did you really think Google would never go down, ’cause saying something like that makes ya’ look like a n00b).
I recently read an article in CIO magazine about the cost per gig per month. In the article they quoted Google at about 6 cents per gig per month. I use Amazon for a few projects, which runs at about 12 cents per gig per month. Including labor and hardware I decided to look at about what it would cost per gigabyte per month for Xsan storage. Averaging out 30 installs that we did over the past year turned out a total of about 7.2 cents per gig per month, as opposed to around $2.00 per gig per month which is pretty average for many SAN solutions. Now, Xsan does have its drawbacks compared to a lot of other truly enterprise-class storage solutions (no snapshots, no LUN redundancy, etc), but provided you build it properly, use it for the purposes that it is actually intended and therefore keep labor costs down over a 3 year cycle you can get similar TCO numbers to what you might end up paying for other solutions.
Having said this, the larger Xsans typically require more infrastructure and features, which can lead to around double the cost per month per gig. For example, introducing Cloverleaf or Vmirror into the equation will typically require us to double up storage costs and require bigger and better switches.
I will not say that a cloud storage service such as Google or Amazon doesn’t have its place. It absolutely does: offline storage, web storage, if you have an existing Xsan and need to archive but can’t spring for the tape drive, Final Cut Server archival (see my previous post on using that) if you travel a lot (like me), etc. But before you jump on the Storage as a Service bandwagon run the numbers very carefully. If it makes sense on a per-use basis then absolutely go for it, but try and factor everything in the process (especially the data access speed over your WAN pipe and additional load that will be placed on said pipe).
A few days ago I noticed a post in Tim O’Reilly’s twitter feed asking whether or not it would matter whether people ran a Mac or a PC once everyone had migrated to a cloud. Well, there are a few things about Mac OS X that make it fairly difficult to run in a cloud environment:
EFI – Mac OS X doesn’t use a BIOS like most Operating Systems. This makes the bootup process fairly difficult in a distributed computing environment where the Guest OS would be OS X and the Host OS would be something else.
Lack of Firepower – I love the Xserve. I always have. They’re some of the most beautiful rack mount servers you can get. But even an Octacore is gonna’ choke if you throw too many VMs on it. If I were architecting a large, distributed computing environment I would want some blades, an IBM Shark, etc. Having said this, Xgrid could pose an interesting option if VMware or Parallels were to allow distributed processing through it.
Licensing – The Mac OS X Server software is the only software licensed for a cloud type of environment, if you read your EULA. This has only recently been introduced and has left Mac OS X without Xen or other open source alternatives in the virtualization space.
Having said all of this, Mac OS X is a wonderful system. There is a lot it has to offer and I, as much as anyone would like to see it capable of utilizing services like Amazon S3, but I would be on the lookout for some other strategic moves rather than a full-blown Mac OS X capable of running independently in a cloud environment. For example:
Mac Backups to the Cloud – Time Machine, Bakbone, Atempo, Retrospect, etc. I cannot imagine that one of them will not be able to back up to Google or Amazon S3 at some point in the near future. GUI level support needs to be there for it to gain wide-scale adoption with the Mac user base (like using Backup.app to backup to MobileMe but with enough capacity to back up an Xsan and enough bandwidth to do full backups in less than 72 hours).
Xgrid – There needs to be some kind of port of Xgrid to Amazon EC2 or support from render farm companies for EC2 or some other cloud/grid computing platform.
Apple – The Pro Apps will need to support SaaS, Software + Services, etc. Many Apple users are leveraging Google Apps, but once it comes from Apple it will be legitimate.
So look for it. You’ll notice the companies that are really leveraging trends in IT as they come to market with products that allow the Mac to leverage the cloud. If Apple makes a push towards this then you’ll see more wide-scale adoption, but don’t expect much and you won’t risk getting too let down.