Cloudonomics: The Economics of Cloud Computing

CloudClub PaaS. As an add-on to the main conference, on Tuesday night a CloudClub meeting was held. CloudClub is a monthly event held in the Bay Area for people involved in cloud computing companies. This month's event focused on PaaS (Platform-as-a-Service). Several of the presenters asserted that, long-term, PaaS is how people will use cloud computing. The first presenter, Mitch Garnaat, showed a number of forum postings from AWS from people who it was clear assumed that AWS would offer transparent application scaling with no effort required from the application developer. Just to be clear, AWS provides the resources to scale an application, but expects the application to arrange for the new resources to join the application. Consequently, according to these presenters, people will turn to PaaS providers, which do arrange for transparent scaling for applications written to their framework. The flip side to depending upon the platform provider for scalability is, of course, lock-in. As to the question about naive users expecting IaaS vendors to provide more services than they really do, there's no doubt. We recently interacted with a company that thought their admin costs would fall through the floor because AWS would take complete application responsibility for only 8.5 cents per hour. They were disappointed when they found out that AWS explicitly abjures that responsibility. I'm not 100 percent convinced on the "inevitable PaaS" question, though; however, I think MicrosoftMicrosoft offers a pretty interesting play in this regard and deserves some respect for what it's delivering. We'll see. Alles zu Microsoft auf CIO.de

10 Cloud Computing Companies to Watch

Standards. The most emotional session at the entire event was focused on standards. Unfortunately, I missed it while attending a session on government cloud computing. Charlie Babcock covered the session in his blog on InformationWeek. Apparently, the discussion got rather heated with a lot of heckling from the audience, with one attendee noting that Amazon was not represented on the panel and that the panelists were the "losers in the market." In discussions on the topic elsewhere I've heard people assert that standards are necessary to prevent fragmentation to the detriment of cloud computing adoption. My own position is that it's far too early to be discussing cloud computing standards - standards are appropriate when the innovation in an area has been wrung out and a platform for innovation in other areas needs to be put into place via a standard. Cloud computing is changing so rapidly that it's impossible to know what it's going to look like in a year, much less being able to maintain that the true innovation needs to be in some other part of the ecosystem. I won't go so far as to characterize the vendors calling for standards as "losers," but I will say that their position on the subject is likely to change as their offerings get into the marketplace and start getting traction. The one exception to my "too early for standards" position is OVF. This standard will be incredibly important as we move to a world in which data center boundaries are porous and workloads are migrated according to load and robustness needs.

Death of the Sysadmin Redux. My post last week on "The Death of the Sysadmin" got a lot of attention. It was tweeted a bunch and even made "top news of the week" on CompTIA's resource site. What was really interesting on this subject at the conference was kicked off by a session on "orchestration." Orchestration refers to the coordinated delivery of disparate resources like processors, storage, and network to provide an integrated provisioning process, which can be delivered in minutes rather than days or weeks. One often hears vendors discuss how their products support orchestration as being the path forward for enterprises to "move to the cloud."

The session quickly outstripped this topic, however, and moved on to the administration/operations of large-scale cloud applications. Essentially, in the world of these types of apps, there are no separate efforts called "development" and "operations." The applications must be written to be dynamically scalable, and the operations characteristics needed to support that scalability must be built into the application from the beginning. Trying to retrofit those characteristics - or worse, trying to address operations manually - is impossible. The meme for this integration is "devops" (#devops is the twitter tag) and I predict this will become a much more prominent topic in the future. One hears so much about the "consumerization" of enterprise applications and the rise of big data; it's critical to understand the other items that accompany this transition in enterprise software applications. The biggest question about this is to what extent this transition will affect enterprise apps - that is, what percentage of enterprise apps in the future will be of such scale and load variability that devops will be necessary for them. Obviously, it won't be 100 percent - but it won't be 0 percent either. And if it's even 5 percent, that means that, as an enterprise, this new integrated discipline needs to become part of the future.