Blog Archives
Smoke-and-mirrors and cloud software
On my more cynical, read-too-many-press-releases days, I wonder if there’s some hapless, tortured PR gnome at Amazon whose job consists solely of vetting one empty cloud fluff piece after another, proclaiming how such-and-such a vendor is now offering deployments on EC2, and how this therefore gives them an on-demand cloud offering (“please think of me as hip and visionary!”), when in reality, the vendor is doing nothing other than packaging up its software as an AMI (an Amazon machine image, basically a disk image of a server with the application installed).
Packaging something up as an AMI doesn’t make it a cloud service. It doesn’t make it massively scalable, automatically scalable, transparently scalable, on-demand, multi-tenant, or any one of a vast number of other terms that get fatuously lavished on anything with a whiff of cloudiness. If a piece of software doesn’t have any cloud traits when it’s deployed in your data center, it won’t have them when it’s deployed on EC2 (or any other cloud infrastructure service), either.
![[the cake is a lie]](https://cloudpundit.com/wp-content/uploads/2009/03/cake_lie.jpg?w=150&h=150)
Cloud infrastructure services today, whether EC2 or from one of Amazon’s competitors, are basically servers in the sky. They are almost always a hypervisor-virtualized server with a normal operating system installation, on top of which you install normal applications. There is no magic cloud pixie dust that settles on these instances and turns them into application faeries of scalability and joy.
Building massively and horizontally scalable, multi-tenant software with elastic economics is hard. It’s even harder if you’re trying to take some legacy software package and re-engineer it. This is why practically no one does that kind of re-engineering, and why software vendors have to resort to puffed-up “yes, we run on EC2!” claims, rather than genuinely delivering on-demand cloud services.
Don’t be fooled.
Marketing and PR folks at software vendors: I forgive you for these releases because I know you’re under pressure to put something out, but every time I read them, I cringe on your behalf, and hope that you’re not genuinely entertaining the belief that releasing an AMI meaningfully moves you forward along the cloud path.
IT folks: When your CEO / CFO / CIO comes to you and asks you why you aren’t taking advantage of your software vendor’s awesome new money-saving cloud service, you can tell him it’s because the PR release is just artfully painting a unicorn — a mythical beast everyone talks about but doesn’t actually exist.
TCO tool for cloud computing
Gartner clients might be interested in my just-published piece of research, which is a TCO toolkit for comparing the cost of internal and cloud infrastructure.
A not-new link, but which I nonetheless want to draw people’s attention to as much as possible: Yahoo’s best practices for speeding up your web site is a superb list of clearly-articulated tips for improving your site performance and the user’s perception of performance (which goes beyond just site performance). Recommended reading for everyone from the serious Web developer to the guy just throwing some HTML up for his personal pages.
On the similarly not-new but still-interesting front, Voxel’s open-source mod_cdn module for Apache is a cool little bit of code that makes it easy to CDN-ify your site — install the module and it’ll automatically transform your links to static content. For those of you who are dealing with CDNs that don’t provide CNAME support (like the Rackspace/Limelight combo), are using Apache for your origin front-end, and who don’t want to fool with mod_rewrite, this might be an interesting alternative.
Billing is hard?
Spreading a little linkage…
A blog post from Reuven Cohen of Enomaly, in the form of musings on billing, metering, and measuring the cloud, and specifically, Amazon’s current inability to offer real-time billing-related reporting for their cloud services.
A blog post from James Hamilton, of the Microsoft Windows Live platform team, provides some brief thoughts on the fact that service billing is hard. The comments thread holds a few things of interest, too.
There’s more to cloud computing than Amazon
In dozens of client conversations, I keep encountering companies — both IT buyers and vendors — who seem to believe that Amazon’s EC2 platform is the be-all and end-all of the state of the art in cloud computing today. In short, they believe that if you can’t get it on EC2, there’s no cloud platform that can offer it to you. (I saw a blog post recently called “Why, right now, is Amazon the only game in town?” that exemplifies this stance.)
For better or for worse, this is simply not the case. While Amazon’s EC2 platform (and the rest of AWS) is a fantastic technical achievement, and it has demonstrated that it scales well and has a vast amount of spare capacity to be used on demand, as it stands, it’s got some showstoppers for many mainstream adopters. But that doesn’t mean that the rest of the market can’t fill those needs, like:
- Not having to make any changes to applications.
- Non-public-Internet connectivity options.
- High-performance, reliable storage with managed off-site backups.
- Hybridization with dedicated or colocated equipment.
- Meeting compliance and audit requirements.
- Real-time visibility into usage and billing.
- Enterprise-class customer support and managed services.
There are tons of providers who would be happy to sell some or all of that to you — newer names to most people, like GoGrid and SoftLayer, as well as familiar enterprise hosting names like AT&T, Savvis, and Terremark. Even your ostensibly stodgy IT outsourcers are starting to get into this game, although the boundaries of what’s a public cloud service and what’s an outsourced private one start to get blurry.
If you’ve got to suddenly turn up four thousand servers to handle a flash crowd, you’re going to need Amazon. But if you’re like most mainstream businesses looking at cloud today, you’ve got a cash crunch you’ve got to get through, you’re deploying at most dozens of servers this year, and you’re not putting up and tearing down servers hour by hour. Don’t get fooled into thinking that Amazon’s the only possible option for you. It’s just one of many. Every cloud infrastructure services platform is better for some needs than others.
(Gartner clients interested in learning more about Amazon’s EC2 platform should read my note “Is Amazon EC2 Right For You?“. Those wanting to know more about S3 should read “A Look at Amazon’s S3 Cloud-Computing Storage Service“, authored by my colleagues Stan Zaffos and Ray Paquet.)
Interesting tidbits for the week
A bit of a link round-up…
My colleague Daryl Plummer has posted his rebuttal in our ongoing debate over cloud infrastructure commoditization. I agree with his assertion that over the long term, the bigger growth stories will be the value-added providers and not the pure-play cloud infrastructure guys, but I also stick to my guns in believing that customer service is a differentiator and we’ll have a lot of pure-plays, not a half-dozen monolithic mega-infrastructure-providers.
Michael Topalovich, of Delivered Innovation, has blogged a post-mortem on Coghead. It’s a well-written and detailed dissection of what went wrong, from the perspective of a former Coghead partner. Anyone who runs or uses a platform as a service would be well served to read it, as there are plenty of excellent lessons to be learned.
Richard Jones, of Last.fm, has put up an annotated short-list of distributed key-value stores (mostly in the form of distributed hash tables). He’s looking for a premise-based rather than cloud-based solution, but his commentary is thoughtful and the comments thread is interesting as well.
Also, I have a new research note out (Gartner clients only), in collaboration with my colleague Ted Chamberlin: evaluation criteria for Web hosting (including cloud infrastructure services in that context), which is the decision framework that supports the the Magic Quadrant that we’re anticipating publishing in April. (Also coming soon, a “how to choose a cloud infrastructure provider” note and accompanying toolkit.)
Single-function clouds are unlikely
GigaOm has an interesting post on HP’s cloud vision, which asserts that HP’s view of the future is that service providers will reducing complexity by delivering only one application (scaling up their own infrastructure in a monolithic way), and that generalized infrastructure-as-a-service (IaaS) providers will not be able to scale up in a profitable manner.
Setting the specifics of what HP does or does not believe aside, I think that it’s highly-unlikely that we’ll see super-specialization in the cloud. There are, of course, software vendors today who make highly specialized components, that in turn are incorporated into the software of vendors further up the stack — today, those are ISVs that sell libraries, Web 2.0 companies with mashable components, and so forth. But as software companies get more ambitious, the scope of their software tends to broaden, too. In the future, they may want to become the masher rather than the mashed, so to speak. And then they start wanting to become diversified.
For an example, look at Oracle. Originally a database company, they now have a hugely diversified base of enterprise software. Why should we believe that a cloud-based software company would be any less ambitious?
Certainly, it is more difficult and more expensive to manage general-purpose compute than it is to manage specific-purpose compute. But there’s a great deal more to driving profitability than keeping costs down. Broader integration has a business value, and the increase in value (and the price the customer is willing to pay) can readily outpace the increased infrastructure cost.
To take another example, Google runs incredibly efficient single-purpose compute in the form of their search farms. Yet, they are trying to broaden their business to other services, both for the potential synergies, and because it is incredibly dangerous for a business to be too narrow, since that limits its growth and vastly increases its vulnerability to any shifts in the market.
I don’t think successful software companies will confine themselves to delivering single applications as a service. And I think that IaaS providers will find cost-effective ways to deliver appropriate infrastructure to those SaaS companies.
Does cloud infrastructure become commoditized?
My colleague Daryl Plummer has mused upon the future of cloud in a blog post titled “Cloud Infrastructure: The Next Fat Dumb and Happy Pipe?” In it, he posits that cloud infrastructure will commoditize, that in 5-7 years the market will only support a handful of huge players, and that value-adds are necessary in order to stay in the game.
I both agree and disagree with him. I believe that cloud infrastructure will not be purely a commodity market, specifically because everyone in this market will offer value-added differentiation, and that even a decade out, we’ll still have lots of vendors, many of them small, in this game. Here’s a quick take on a couple of reasons why:
There are diminishing returns on the cost-efficiency of scale. There is a limit to how cheap a compute cycle can get. The bigger you are, the less you’ll pay for hardware, but in the end, even semiconductor companies have to make a little margin. And the bigger you are, the more you can leverage your engineers, especially your software tools guys — but it’s also possible that a tools vendor will deliver similar cost efficiencies to the smaller players (think about the role of Virtuozzo and cPanel in shared hosting). Broadly, smaller players pay more for things and may not leverage their resources as thoroughly, but they also have less overhead. It’s important to reach sufficient scale, but it’s not necessarily beneficial to be as large as possible.
This is a service. People matter. It’s hard to really commoditize a service, because people are a big wildcard. Buyers will care about customer service. Computing infrastructure is too mission-critical not to. The nuances of account management and customer support will differentiate companies, and smaller, more agile, more service-focused companies will compete successfully with giants.
The infrastructure itself is not the whole of the service. While there will be people out there who just buy server instances with a credit card, they are generally, either implicitly or explicitly, buying a constellation of stuff around that. At the most basic level, that’s customer support, and the management portal and tools, service level agreements, and actual operational quality — all things which can be meaningfully differentiated. And you can obviously go well beyond that point. (Daryl mentions OpSource competing with Amazon/IBM/Microsoft for the same cloud infrastructure dollar — but it doesn’t, really, because those monoliths are not going to learn the specifics of your SaaS app, right down to providing end-user help-desk support, like OpSource does. Cloud infrastructure is a means to an end, not an end unto itself.)
It takes time for technology to mature. Five years from now, we’ll still have stark differences in the way that cloud infrastructure services are implemented, and those differences will manifest themselves in customer-visible ways. And the application platforms will take even longer to mature (and by their nature, promote differentiation and vendor lock-in).
By the way, my latest research note, “Save Money Now With Hosted and ‘Cloud’ Infrastructure” (Gartner clients only) is a tutorial for IT managers, focused on how to choose the right type of cloud service for the application that you want to deploy. All clouds are not created equal, especially now.
Developer-driven cloud adoption?
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.
Self-service shouldn’t mean an information void
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?
Origin story, Amazon EC2
Benjamin Black’s blog has an interesting story: his perspective of how Amazon EC2 came to be.
An interview with Chris Pinkham and Amazon’s Cape Town Development Centre site are interesting reads, too. The latter is focused upon EC2 development.
CloudPundit: Massive-Scale Computing 