November 2011


With the holiday season upon us, and tablets at the top of many gift lists, it’s all but certain that millions of new users will get exposed to an open source based Android Tablet. By all accounts, Amazon’s Kindle Fire is expected to leapfrog into, at least, number two position in the tablet market. While this would appear to be good news for Android tablets and the Android OS, it may actually be exactly what Apple and Microsoft had asked for Christmas (or any other holiday these companies choose to celebrate).

Great price and Amazon content versus clunky user experience
I’m not going to do a blow by blow review of the Kindle Fire. Glen has a good review of the Kindle Fire versus Apple iPad. I’d also recommend the Kindle Fire review from Instapaper developer Marco Arment from a user experience standpoint.

The first common thread across reviews is the price of a Kindle tablet, at $199, can’t be beat. Some have referred to the Kindle Fire as the people’s tablet.

Second, reviews are virtually unanimous that the Kindle Fire is great when restricted to Amazon’s content, even if some magazines aren’t optimal for a 7 inch screen. The Kindle Fire becomes less attractive as users venture outside of Amazon’s content garden. Even the new Silk browser, touted to speed on device browsing, appears to be a let down.

Finally, many reviews describe a less than delightful user experience while using the Kindle Fire operating system and user interface. The Kindle Fire OS responsiveness is said to lag user input, sometimes forcing users to redo an action only to find that the first input was in fact registered.

The 7 inch form factor, while easier to hold than a 10 inch tablet, presents the added complication of smaller targets for users to press in order to carry out their intended tasks. One of Arment’s issues with the Kindle Fire interface is that: “Many touch targets throughout the interface are too small, and I miss a lot. It’s often hard to distinguish a miss from interface lag.”

Like it or not, iPad is Kindle Fire’s comparison
There are many older users who don’t need a laptop and could benefit from a small and moderately priced tablet for email, browsing and reading. A Kindle Fire seems like a great solution. It’s likely that many of this cohort will receive a Kindle Fire from a well meaning family member or friend. In fact, my wife suggested getting a Kindle Fire for several retired members of our family.

However, the usability issues that Arment brings up, especially surrounding interface lag and smaller touch targets will undoubtedly have an impact on their desire to use the device, or store it away with that interesting looking tie received over the holidays.

It seems that a lack of comfort with new computing devices, fat thumbs and poor eyesight, something we all have to look forward to, aren’t great ingredients for being delighted with the Kindle Fire.

Even younger users, many who own or have used an iPod touch or iPhone are at risk of being annoyed with the lag and user interface roughness of the Kindle Fire.

Some have argued that you can’t compare a $499 iPad with a $199 Kindle Fire. That’s true, on paper. In practice, users are going to compare their Kindle Fire experience with an iPad. There isn’t a tablet market, there’s an iPad market. It’s the reason that most Kindle Fire reviews compare to the leading entry in the market, the iPad, and not other Android or 7 inch based tablet.

A poor Kindle Fire experience reflects on Android
When the Kindle Fire is perceived to deliver a less enjoyable experience than an iPad, the real risk is that the Android tablet market will be viewed in the same light as the Kindle Fire. That may not be fair considering Amazon has forked the Android OS, and Android continues to get better. However, since the Kindle Fire is expected to reach an order of vastly more users than other Android tablets, and considering Amazon’s technical reach, don’t be surprised if typical users generalize their Kindle Fire experience to Android tablets.

Earlier this week Bloomberg BusinessWeek’s Ashlee Vance wrote on his Twitter feed: “Just opened up the old Kindle Fire. Android sure has a Windows 3.0 feel, dunnit?”

That is exactly the type of comment that should make Apple happy and give Microsoft a faint hope in their tablet plans. If Amazon, with its great content and proven track record with Kindle devices, can’t pull off a device users prefer to an iPad, then what’s the likelihood that any Android vendor can?

I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.

While the DevOps movement is centered on reducing the friction between developers and operations teams and the ability for developers to deliver applications faster, neither outcome is possible without standardization. But are developers and operations teams ready to agree on standard environments?

Why developers operations teams are focused on DevOps
A recent post from Matt Asay, now at cloud vendor, Nodeable, links to a survey from Puppet Labs of seven hundred and fifty plus respondents. While DevOps is often considered a developer led movement, nearly 4 times as many operations and administrators responded to the survey as developers. Surprisingly, as Matt points out, operations teams appear to see the same potential benefits from DevOps as developers.

In the survey, Puppet Labs finds that fifty five percent of respondents ranked the automation of configuration and management tasks as the top benefit expected from the DevOps movement. Another thirteen percent, ranked this benefit in their top three benefits expected.

You can’t automate what you can’t standardize
I’ve been spending time learning more about the interaction between developers and operations teams. One thing I’ve come to understand is that these two groups tend to think differently, even if they are using the same words and nodding in agreement.

It’s no surprise that developers want adopt tools and processes that allow them to become more efficient in delivering net new applications and continuous updates to existing applications. Today, these two tasks are hindered, to a degree, by the operations teams who are responsible for production environments. As Matt points out in his post, developers seek automation, which, as an aside, is a reason enterprise developers have been very open to using public clouds.

Operations and administrations teams, as the Puppet Labs survey shows, are also drawn to the automation of manual tasks they must do today, some of which result in the delays that developers experience when they’re waiting on the operations team to provision new resources or promote applications into production.

While both side of the DevOps coin value automation, neither is explicitly calling out the fact that you can’t automate without standardization. Well, maybe can’t is too strong a word. In IT we can do pretty much anything with enough elbow grease.

But ask yourself, could you automate the provisioning of a development environment, or the deployment of a middleware stack, without standardizing what exactly is being automated? No, not really. Operations teams understand this; it’s why operations teams promote enterprise wide standards. In most cases, these enterprise wide standards, whether for things like operating systems, hypervisors, databases or application servers, etc., allow for some limited degree of variability. For instance, may IT shops support Linux and Windows, but if you want Solaris, sorry, you’re outside of the corporate standard.

This is the environment that developers are working in today. You can select amongst enterprise-wide standards. And yet, this is the exact environment that is frustrating developers. Sometimes the corporate standard doesn’t exactly fit the developer’s skills or interests or the project’s needs. Hearing, “tough luck champ”, is what’s driving developers towards DevOps. However, developers automating IT stacks that don’t fit into the corporate standard won’t help bridge the gap between development and operations.

What’s needed is a joint agreement, across development and operations, on the acceptable environments that make up the corporate standard, and which are, in turn, automated.

This isn’t a technical issue. It’s a cultural issue. Before your teams push forward a DevOps initiative, get them beyond the buzzwords and into the nitty gritty around corporate standards, degrees of variability and if or how to allow developers to experiment outside of the corporate standard. If you don’t you’ll have developers and operations expecting different outcomes while using similar words.

I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.

Reading a recent interview with Eucalyptus CEO Marten Mickos, I’m beginning to reconsider my views on Eucalyptus versus OpenStack becoming the dominant open source cloud platform.

OpenStack’s rise
The vendor attention around OpenStack of late has been nothing short of amazing. Once a project controlled by Rackspace, vendors such as Dell, Citrix, and HP have joined the OpenStack open source community. Rackspace has given control of the project to the OpenStack foundation, apparently at the behest of large vendors contributing to the project.

However, as Mickos states, OpenStack is still a work in progress and not production ready – yet.

A tale of two open source projects
Like many, I’d assumed that the community around OpenStack gave it the critical mass required for OpenStack to become the leading open source cloud platform. I’m questioning that assumption now.

To explain why, let’s look back at two leading open source projects, the Linux and Apache HTTP Server. I use “Linux project” in the broadest sense, including the Linux kernel and all the various open source packages that round out a typical Linux distribution.

History has shown us that when an open source project is dealing with a valuable layer of the software stack, that project has tended to be controlled by a single vendor who can directly monetize the project. The term “value” is used to represent differentiation that can be monetized. While multiple implementations or distributions may result from the project, a single vendor becomes the dominant provider in the space. For Linux, that’s Red Hat with its Red Hat Enterprise Linux products. In the open source database space, MySQL would fit this model.

History also shows us that when an open source project is dealing with a commodity layer of the software stack, the project tends to be controlled by a foundation. In these cases, the project is used as a piece of a higher value product which provides differentiated value, and hence can be monetized. Said differently, the opens source project itself is indirectly monetized through the higher value product. The Apache HTTP Server, used within most commercial application server products, or Eclipse, used within many commercial application development products, are two examples.

Eucalyptus and OpenStack’s future:
If history is to repeat itself, then we need to consider whether an open source cloud platform is a valuable and directly monetizable part of the software stack or not. If it is, then a single vendor controlled open source project has a higher potential of success than a foundation-controlled project.

Open source foundations are great and play a valuable role with various open source projects. However, the mixture of ten or one hundred vendor motivations makes it increasingly difficult to meet the needs of the project and the monetization goals of each vendor.

Keep in mind that this only applies if the project is a directly monetizable layer of the software stack. As an outsider looking in, this appears to be the fundamental difference in Eucalyptus and the overall OpenStack community.

The OpenStack community, especially vendors such as Dell, HP and Rackspace, view OpenStack as addressing a part of the software stack that isn’t directly monetizable. These vendors would rather use OpenStack to build a higher value product that can be monetized. For instance, Dell and HP would likely sell “Cloud Platform Ready” hardware systems, rather than selling an OpenStack software product itself.

Clearly Eucalyptus disagrees, and Mickos claims to be growing customers “at an amazing rate”. Eucalyptus has grown from 15 to 70 employees over the past year and added a new headquarters in London to grow in EMEA.

In the end, IT buyers will decide whether Eucalyptus or the OpenStack community made the right bet. I tend to agree with Eucalyptus that a cloud platform is indeed a valuable, and hence directly monetizable, layer of the software stack.

What do you think?

I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.