Cloud Reliability Showdown

I keep following enterprise cloud technology and services. Ben Kepes is one of the bloggers I follow. He had a recent article analyzing a report from CloudEndure that compares the reliability of Amazon's AWS.to Microsoft's Azure in 2014.

The article is full of graphs and good analysis but his summary hits the nail on the head:

Outages happen - there is no way of avoiding mentioning that fact. But as Netflix has so successfully demonstrated, it is through planning for failure that organizations can achieve the very highest levels of reliability for their applications. Thinking about multiple points of redundancy for every service, every connection and every vendor an application uses is a good start.

See my article on Netflix.

And the he puts a point on it:

Both services are great and both show amazing reliability (as an aside, that reliability is far higher than most on-premises infrastructure) - the key takeaway from this report is that not planning for failure is a huge risk for organizations.

Put that in your pipe and smoke it.

Google Apps vs Office

Business Insider recently had an article on how Google plans to "nab 80% of Microsoft's Office business."

Google's plan is:

1. Make sure that the apps Google offers have "85-90% of the functionality" of Office.
2. Don't worry about the remaining 10-15% of the features required by power users, particularly Excel.
3. Support Office documents as a "first-class citizen."
4. Don't try and convince enterprises to convert from Microsoft Office to Google Apps.
5. Teach them to become power users.
6. Get new customers hooked on products other than Apps.
7. Show them how Google's cloud helps mobile workers.

Yeah, right.

Although I'm a huge proponent and user of Google's office apps for my personal use, there is no alternative to Microsoft Office documents in an enterprise environment. Segregating users into "have's" and "have not's" is going to be extremely difficult.

Apple Cloud Outage

Now we have a new player in the battle of (un)availability in the cloud. On March 11, 2015 Apple's iTunes store was down for 10 plus hours.

But look closer at that web page. First, we could see that web page unlike one of Microsoft's outages. Second, nothing was down but the App Store. iCloud Account & Sign In - Up. iCloud Backup - Up. iTunes in the Cloud - Up. And on and on.

And Apple acknowledged the same day that the downtime was caused by problems with its DNS setup.

The other cloud players could learn something from Apple.

Internet Bandwidth - February 2015

This is an update of my Internet Bandwidth post of June 2014.

The stacked bars are Comcast cable bandwidth. The yellow line is AT&T wireless bandwidth (scale is on right axis). The units are KB so 100,000 represents 100GB. The blue is the difference in what Comcast reports versus what my router reports.

I upgraded my AT&T plan to Mobil Share Value with 10GB in January 2014. AT&T upgraded my Mobil Share Value from 10GB to 15GB for the same price in November 2014. 

I started using CrashPlan Central for backups in December 2014. With CrashPlan Central uploads I've bumped into Comcast's bandwidth cap of 300GB. CrashPlan has good controls to manage its bandwidth usage and the initial upload is complete.

Screen Size Fragmentation

I'm a big user of Pocket Casts and got to following Russell Ivanovic's (one of the developers) blog. He has a couple of interesting posts on screen sizes.

His position is that the various screen sizes aren't a big deal so long as there are relatively few different proportions. You can make different resolution objects that the operating system can select from and present appropriately.

Here's his chart of the various Android screen proportions.

Now who hasn't heard that varying screen sizes are more of a problem on Android than on iOS?

From his follow on blog post here's the equivalent chart for iOS.

Note that the iOS chart was done with guesses of the iPhone 6 screen sizes and the guessed size of the iPhone 6+ was incorrect.

You decide which would be easier to code for.