Last year, I took a slight departure to discuss the opportunities and challenges that cloud computing presents to the road warrior. Almost a year later, it is time to update the results.
Since my last posting, I have traveled throughout the US and Asia. My rate of travel has continued at a strong pace. You know you are traveling quite a bit when the pilot is sending you handwritten notes thanking you for your patronage. Another common indicator is the hotel front desk recognizing you as you walk up. One of these days, I will add up the number of nights I spend in hotels. However, it may be easier to count the number of nights I was actually home.
During that time, my arsenal of technology has varied. I used to travel with a 15” MacBook Pro and an iPhone 3GS. Just prior to my last missive, I started using an Apple iPad 3G. Today, the MacBook Pro has been replaced with a 13” MacBook Air. Interestingly, the combined weight of the iPad and MacBook Air is still lighter than the 15” MacBook Pro.
Ideally, I would prefer to only travel with the iPad and iPhone. And on several of my trips, that is exactly what I did. Talk about traveling lightly! My only hesitation is when I need to create quite a bit of content. The iPad is a great device for content consumption. Content creation is still a clumsy process on the iPad. The exception is email and text documents.
Over the past 10 months or so, the core challenges noted in my first posting still exist. It is all about data access. Yes, there are ways to store data online securely. Yes, there are ways to access data remotely using the iPad (or laptop). However, the challenge is getting connected wherever I go.
From anecdotal experience, access in hotels, airports and airplanes has not improved much. Until this is resolved, cloud computing will continue to present challenges for road warriors. Here are some examples:
Japan: Last year, I took two trips to Japan. I did my research and found that they had free Internet connectivity throughout the hotel. Great! This would be my opportunity to travel overseas with only my iPad and iPhone. The trip through airport security was a breeze. The iPad does not require removal for security screening like laptops. The long battery life provided more than adequate time for two movies, a ton of emails, some other work and a few games. Nice! I checked into the hotel and immediately found the free Wi-Fi in the hotel lobby. Great! I proceeded up to my room and couldn’t locate the signal. I called down to the front desk and was politely informed that only wired access was available in the room. Wi-Fi is only available in the lobby. This was inconvenient when your device only has Wi-Fi access. Over the course of the two trips, I found quiet places to hang out while connecting, downloading, uploading and conversing via Skype.
Airports: Over the years, I have spent plenty of time in the United Red Carpet Club lounges. It offers a relaxing place much quieter than the hustle and bustle of the airport terminal. It also provides free Wi-Fi access. The challenge is when you are in an airport without a Red Carpet Club. Some airports are moving to free Wi-Fi in the terminals. But many still charge $12-15/day to connect. Alternatively, with the iPad 3G, I pay $25/ month and do not have to worry about where I am or if there is free Wi-Fi. The built-in 3G works for the iPad, but the laptop requires an external 3G card to support wireless everywhere. Plus, the laptop just is not convenient to whip out and use anywhere.
Airplanes: I had hoped that Wi-Fi access on aircraft would have improved since my last posting. Truth be told, I typically only fly United Airlines, so my scope is limited. United does offer Wi-Fi on their P.S. flights between SFO-JFK and LAX-JFK. While some carriers have offered Wi-Fi from the start, United is planning to equip more of its planes with Wi-Fi starting in 2012. In all cases, there is a cost to use the Wi-Fi on aircraft.
Hotels: Many hotels offer free Wi-Fi today. However, the performance can get fairly slow during the evening rush and morning times. During the evenings, I have experienced Hotel Wi-Fi with such poor performance that I had to just work off-line.
Aside from connectivity woes, I still find that cloud presents opportunities for both road warriors and businesses alike. Considering the amount I travel, I still prefer to travel as light as possible. The advent of cloud and tools like the iPad present a glimpse of what is to come. Without cloud-based options, my productivity would be severely limited…unless I had the laptop in tow.
Bottom Line: The back-end options for cloud computing have advanced in many ways over the past year. While the end-user options have not progressed as quickly, one can only expect to see improvements in the near term.
A couple of days ago, I posted some thoughts about the recent Amazon AWS outage. In the passing days, many others have written their own missives collecting their thoughts on what may have happened and the ensuing consequences. The opinions range widely from a typical outage to outrage to a potential cover-up of a larger issue.
The ramifications of the outage are certain to impact the stratospheric velocity of the cloud computing trajectory. Many will consider the impact in a very negative way. They may go so far as to say that an outage at the poster child for cloud (Amazon) demonstrates that the cloud market is still immature for the demand it seeks.
While some place the blame squarely on the provider (Amazon in this case), others point to the short-sided expectations of the clients. Personally, I believe both carry some responsibility in the matter. This is true of all cloud providers and those that leverage the cloud. Further, it is not specific to cloud, but any provider that one uses.
I’ve been on both sides of the coin over the course of my career; both provider and consumer. The objective should be to create a true partnership. But what is a true partnership? And what are the characteristics that differentiate a partnership from a traditional vendor/ customer relationship? We each may have a different set of objectives and characteristics that define a partnership.
A partnership is much like a personal relationship; friends, family, etc. And both parties are responsible for maintaining the partnership over time. Partnerships take work. As such, there are several attributes that characterize a true partnership. Honesty, trust, communication and shared responsibility are just a couple of the core attributes. Without a solid foundation, it is difficult to pinpoint expectations. I could delve into the realm of SLAs and SLOs, but will save that for a future entry.
While it is well and good to talk about what makes a partnership, is it (or should it be) necessary for the cloud market? That depends on the expectations. If the expectations are for basic services with few requirements around confidence, then probably not. If, however, the expectations are more critical to the business or the expectations are higher, a stronger relationship is warranted. And I’m talking about more than just a contract and SLA.
There are many ways to create a partnership. Understanding what is core and important is a good first step. I’m not referring to technology requirements. I’m referring to relationship requirements. What is important to you for that specific service or offering? Thinking ahead, what is expected when things do not work as expected? Do both parties agree to the approach? In some cases, this may be a simple documented communication and action plan. In other cases, it may require a more engaged discussion.
In many ways, this is not too different from a contract. What is a contract? Frankly, it should be something you negotiate at the beginning of the relationship and never have to refer to again. But it really serves as a backstop for when things do not go as planned. SLAs may serve in a similar capacity. When the contract is negotiated, both parties agree to the process, actions and consequences…up front. When something happens, you know what to expect.
But is that really enough? Plenty of providers have written contracts and SLAs available. They provide a basic understanding of expectations, but do not go far enough for critical business processes. In those situations, one needs to look deeper into the organization, the processes, the expectations and the level of relationship to establish. Where there is a gap, correct it. When there is confusion, clarify it.
I was told many years ago that the best business relationships have a senior or executive-level relationship behind it. That is very true to this day. I’m sure this is harder to do with the larger providers. But you may be surprised.
Bottom Line: Look beyond the contract and SLA. What other attributes are in place to ensure a successful relationship?
Today, Amazon suffered a major outage of their EC2 cloud services based out of their Virginia data center. There are plenty of other blogs with more technical details on what specifically took place. Many cloud pundits are pointing to the outage as another example of the immaturity of cloud-based infrastructures. I think this is overblown.
In past missives, I outlined examples of past outages:
- Oct 14, 2009 Microsoft Sidekick Data Loss
- Jun 29, 2009 Rackspace Data Center Outage
- May 14, 2009 Google Outage
- Mar 21, 2009 Carbonite Storage Failure
While the dust-up of Amazon is fresh, outages of infrastructure are something to expect. We expect them in our own data centers. So are we back to expecting a double standard with cloud providers? In the case of Amazon, is the expectation that a higher class of service is delivered for a fraction of the price compared with internally provided data center services? Really?
Outages happen all the time in cloud data centers. Most of those outages are never observed or significantly impact users. Why? In most cases, simple tiers of redundancy are used to lower the statistical probability that an outage will occur. Yes, I said lower the statistical probability…not eliminate it. That’s all that redundancy does.
Then why did these outages happen in such a large and public cloud offering? At some point, one has to make a business decision as to how much redundancy is valuable. It’s easy to take pot shots from the outside of a cloud provider and looking inward. But these same challenges exist within traditional data centers too. And not all redundancy is infrastructure-based. Application architectures must consider the risks too.
I submit that it is time that we need to consider a different approach to how we provide services. I’m not referring to IaaS services. I’m referring to application-level services (SaaS in many ways). Our application architectures have relied on redundant infrastructure at the most basic levels for some time. That includes networks, servers, storage and so on.
This may sound like a pipe dream, but application awareness needs to move much higher in the OSI stack. If you think about it, SaaS applications do this to some degree. Do you know which data center is serving data when visiting
? No. But when you put that in your browser, it works. Why is that? Does that mean that Google doesn’t have infrastructure failures? Do they have applications failures? Of course they do. But they’ve architected their applications and infrastructure to be resilient from failures.
In the case of the Amazon failure today, if the client applications were architected to leverage multiple Amazon data centers, would they have experienced an outage? While it may not have eliminated the entire outage for clients, it most likely would have reduced the impact. From the initial reports, the outage appears to be isolated to Amazon’s Virginia data center.
Some will argue that data sets are the Achilles Heel and prevent this type of redundant application architecture. I would propose that maybe we just haven’t figured out how to deal with it yet.
Bottom line: Failures are a reality in private data centers and in the cloud. We need to stop fearing failure and start expecting it. How we prepare our services and applications to respond to failure is what needs to change.
There has been quite a bit discussion about the topic of Cloud Computing and specifically if interest was starting to wane. In discussions over the past year, I’ve used the term ‘cloud fatigue’ to describe how cloud came on strongly, but without a clear understanding of value, multiple issues are creating confusion. More clarity around direct business value from cloud computing is needed. This includes both top-line and bottom-line impact.
As a current benchmark, I was curious to see how the term ‘cloud computing’ was trending in Google searches. The results were surprising. The charts below were collected April 12, 2011.
Here are the Google search results for the term ‘cloud computing’ since 2004.
It appears that the term has had a steady climb, but is hitting a plateau of late. More on the plateau…or plateaus below. Further details revealed searches originating from India as the top country. The United States came in 7th behind India, Singapore, Hong Kong, Taiwan, Ireland and Malaysia.
It is interesting to see the heavy interest from countries in Asia. The top states (or sub-regions) and cities were fascinating as well. Quincy, MA ranked top in the US well ahead of any other city.
In addition to the surprise in locations that generated the most interest, the data showed another interesting trend. Since 2004, interest has plateaued a few times. Steady growth was observed from 2004 until March 2009. Then growth plateaued for two quarters until October 2009. Afterward, growth continued again until November 2009. However, interest plateaued for another three quarters until June 2010. Then growth resumed again until September 2010. Since then, growth has essentially plateaued yet again.
It’s not clear what is driving these growth spurts followed by plateaus. One could map major announcements against the data. It’s not obvious that the data reveals seasonality either. Overall, normalization of the data does represent overall growth, but suggests a potential slow-down of interest in cloud computing. The slow-down could be attributed to cloud fatigue. Based on past plateaus, the next quarter should tell if growth resumes, continues flat or declines.
Failure…the F-word to some. It is often suggested that we learn from our failures. However, it is often our successes that are celebrated. The question is: Are we truly learning from failure? And do we fear failure too much?
In many cases, the answer is yes…to both questions. While inventing the light bulb, Thomas Edison was famously quoted as saying: “”I have not failed 1,000 times. I have successfully discovered 1,000 ways to NOT make a light bulb.” How do we embrace failure in a positive way as a learning experience?
This month, Harvard Business Review (
) features a series on failure. It provides some good insight on the subject.
HBR: Failing Toward Success (
HBR: Why Leaders Don’t Learn from Success (
Looking back, what have you failed miserably at? Are there examples where you have failed over and over again and eventually got it right?
Hopefully we can push forward to think differently about how to learn from our mistakes, make forward progress and change our paradigm when needed.