Monthly Archives: February 2009
James Governor’s thoughtful blog post on finding the REST of cloud prompted me to think about developer-driven versus sysadmin-driven adoption of cloud. This is a fulcrum that’s separate from GUI vs. CLI vs. API tug-of-war, which in many ways is a sysadmin-driven debate.
The immediacy of cloud provisioning has instinctive appeal to developers who just want to get something up and running. Amazon’s choice to initially do API-based provisioning was a clear choice to favor developer thinking, and developers at vast numbers of start-ups rewarded them by adopting the platform. At Web 2.0 start-ups, the founders, who usually come out of some sort of dev background, get to hire the ops people and call the shots. And thus, direct appeal to developers has been very important to cloud success, up until this point.
But my observation from client interactions is that cloud adoption in established, larger organizations (my typical client is $100m+ in revenue) is, and will be, driven by Operations, and not by Development. The developers may be the business stakeholders, and they might be the engineers who first experiment with the cloud (in a “rogue” or ad-hoc way), but Operations has the budget and Operations is going to be managing the actual cloud deployment, and therefore Operations makes the decision about what cloud to go with in the end.
That assumes, of course, that the developers haven’t tied their code to a non-portable API. If the developers have, unbeknownst to the Ops folks, gone and tightly integrated their application with, say, Amazon S3 in a way that doesn’t readily allow portability between different cloud storage APIs, or built on top of Google App Engine, then Ops isn’t going to have much in the way of options.
Another way to think about this: Developer-driven adoption is bottom-up adoption, rather than top-down adoption. The early stages of cloud adoption have been bottom-up. But because of the economic climate, larger organizations are experiencing a radical acceleration of interest in cloud computing, and thus, the next stage of cloud infrastructure adoption is more likely to be driven top-down.
A client recently asked me what my Clifton Strengths are. I couldn’t remember at the time, but I’ve dug out old 1.0 results from back in 2006…
- Ideation. People strong in the Ideation theme are fascinated by ideas. They are able to find connections between seemingly disparate phenomena.
- Strategic. People strong in the Strategic theme create alternative ways to proceed. Faced with any given scenario, they can quickly spot the relevant patterns and issues.
- Input. People strong in the Input theme have a craving to know more. Often they like to collect and archive all kinds of information.
- Learner. People strong in the Learner theme have a great desire to learn and want to continuously improve. In particular, the process of learning, rather than the outcome, excites them.
- Intellection. People strong in the Intellection theme are characterized by their intellectual activity. They are introspective and appreciate intellectual discussions.
Back in 2005, my colleague Monica Basso and I wrote a research note titled, “Wide Array of Communications Overwhelms Users“. In it, we pointed out that the proliferation of communication mechanisms and the complex intermixing of personal and business communications would become increasingly unmanageable.
Until a few months ago, Gartner had a policy that disallowed analysts from participating in most forms of social media. So, up until recently, I’ve had relatively clean distinctions in my communications — a personal instant messaging account, del.icio.us, Facebook, Twitter, and so on, used strictly to communicate with friends. LinkedIn was the face of my business profile.
Now that my employer is actually encouraging use of social media, I’m finding myself facing a problem of converging business and personal identities. I am happy to build big social networks, but categorization and compartmentalization are a big problem. For instance, how do I deal with the fact that my vendor contacts see my high school acquaintances scribbling random things on my Facebook Wall? Should my blog followers who want to see my interesting technology links also have to endure my MMORPG links on del.icio.us? What do I tweet to my various accounts? (On Twitter, I have a business identity, a private friends-only identity, and a public personal identity, but ironically, I find Twitter almost impossibly distracting to deal with, so I tweet and read tweets very seldomly.) How much do I really want to federate of myself on FriendFeed?
I feel like social networking, whether targeted at personal or business use, really needs strong tagging and categorizations. Here are the people who happened to work at the same company as me, that I’ve spoken to a few times; here are my immediate co-workers; here are the people I’ve worked closely with and think are awesome. Here are business contacts at other companies that I want to stay in touch with but don’t have a personal relationship with. Here are vague past acquaintances, current friends, and my inner circle of close buddies. And I desperately want tools on all social networking sites that let me limit the flow of me-related content: public, all connections, just these specific groups.
But more broadly, we are still missing really elegant ways to manage the incredible flow of communication and information that’s coming our way. There’s a commercial opportunity there that’s still not been taken.
I’ve recently discovered TripIt through LinkedIn, which has an app to link in TripIt travel plans.
I’ve got to say, it’s pretty awesome. Forward your confirmation emails to it, and it will automatically build them into travel plans. I normally get PDFs via American Express. But my trips are a multi-email jumbled mess of multiple cities, one-way airline tickets, hotel reservations, and whatnot. With every trip, I generally spend a tedious, hair-pulling amount of time gathering up all the scattered emails and manually creating a document that has all the information. Then I have to go track down things like driving directions, time to destinations, and weather so I know what to pack.
No more. TripIt is smart. It can take all those zillion confirmation emails and consolidate them into one unified trip plan, complete with weather, driving directions, and links to online check-in and flight status. It produces a full schedule of your day, although it has the key problem that it doesn’t know that you need to be at the airport at least an hour in advance of your flight.
Plus, TripIt has a social-networking element, similar to Dopplr, so you can privately share your trip information with others. (This helps my spouse, who has to ask questions like, “What city are you in now?”)
This is what useful applications should be — automating away tedium.
Joel Spolsky has two UI design principles:
- Users don’t have the manual, and if they did, they wouldn’t read it.
- In fact, users can’t read anything, and if they could, they wouldn’t want to.
These ought to be core principles of cloud UI design, and, in fact, most cloud infrastructure providers do seem to earnestly be trying to hide complexity between simple, colorful UIs. (Although ostensibly simple things are often not as easy as they look. Appliance-builders and application-stack builders, for instance, usually turn out to be vastly more involved than the GUI, or even the demo, indicate.)
The bright shiny buttons are certainly inviting, and encourage a certain amount of try it and see if you like it, but for a business which is trying to figure out what cloud to go with, understanding the swathe of possible options can be a shockingly difficult exercise. What cloud providers often don’t do a very good job of explaining is what the heck it really means to use their cloud. The in-a-nutshell “this is exactly what is and isn’t going to be different from the systems and network administration you do today” explanation is simply missing.
That’s important, because it means that lots of cloud providers are missing out on the chance to differentiate themselves. Cloud infrastructure is not a commoditized service, yet, and won’t be for several years, while the technology is still immature, and features and the quality of implementation still distinguish providers from one another.
Of course, there’s the challenge: How do you do that without making people read more than a handful of words?
There are other Akamai resellers out there, but Distribution Cloud posts its prices publicly, starting at 50 GB for $150 per month ($3/GB), and going up to 1 TB for $2,200/month ($2.20/GB), with storage at $15/GB. That’s 10x the cost of Limelight with a Rackspace Cloud Files origin ($0.22/GB, no commit) — definitely not a commodity price, so it’s really the low commit that makes this interesting.
But the blog post got me wondering: Who is Distribution Cloud, anyway? Their website lists a phone number and the fact they’re in Cambridge, MA, but no address or anything else that indicates who the company is. A search on the phone number turns up that it’s registered to a David Reisfeld at 94 Rice St, phone service courtesy of Level 3. LinkedIn and Naymz have listings for a person who seems to match: a senior director, product management, CDN streaming services, at Level 3 — formerly a senior product manager at Akamai.
But that only deepens the mystery. Did Reisfeld run a reseller (since 2002, the site claims) while employed at Akamai, with the blessing of his employer? Is he fronting for a buddy? Is he still doing it while employed at a competitor, or is the name for the phone listing not current? If it’s not his company, whose is it?
We’re in the midst of a fascinating discontinuity in IT purchasing patterns. Even the dot-com crash didn’t cause this kind of disruption. Practically everyone is scrambling to save money immediately, and some organizations are looking at long-term belt-tightening.
The most obvious immediate impact is that buyer tolerance for paying a premium is rapidly diminishing. Quality is suddenly being eyed with greater objectivity, as businesses stop feeling like they need to have “the best” and start actively considering what services and service levels they really need and can cost-justify. It doesn’t matter (enough) if they love their current vendor and feel they’re getting excellent value for the money. It’s about absolute dollar amounts and aligning spend with needs rather than want-to-haves. Risks are being taken in the name of the bottom line.
Gartner is hiring! Here’s the formal job posting: Research Director, Emerging Enterprise Network Services, Europe. (Or you can go to Gartner Careers and search for req 7705BR.)
Informally, here’s the scoop:
My team is looking for a European counterpart for me — someone who will be European-based, European-focused, and cover Internet infrastructure services and other emerging network services. That means following hosting, colocation, content delivery networks, cloud computing, the Internet bandwidth market, and so on. There’s a global element to this position, too, and this analyst will also deal with non-region-specific issues.
The right candidate is probably currently a senior product manager; a senior manager or director in a technical operations, product engineering, or sales engineering organization; or a senior technical evangelist. (Or they’re an analyst at one of our competitors.) They almost certainly have a background working for an ISP, carrier, Web hoster, data center outsourcer, IT consultancy with a specialization in data centers or networks, CDN, or other Internet-centric company.
This is your chance to influence the evolution of an entire industry, at a critical juncture in time. You’ll get to work with smart, self-motivated people across a wide variety of topic areas, advise executives at vendors as well as end-user organizations, and really dive into the things that interest you and our clients.
Feel free to drop me a line if you want to hear more.
January was a crazy, crazy month, and February looks to be shaping up to be just as intensive, if not more so.
During January, in the fifteen available working days (the days not completely consumed by travel or by our research planning process), I had one hundred interactions — one hundred individual client/prospect inquiries or visits.
This first week of February alone, in four working days, I’m going to have thirty-four interactions. The only reason there aren’t more is that I’m physically out of schedulable hours.
What do all of these people want to talk about? Mostly cloud computing in the form of public cloud infrastructure services (40%), colocation (20%), and CDN services (20%). (Percentages are for this week.)
It’s pretty much all about cost savings, right now.