There was legitimate debate at one point whether the style of cloud computing often called Platform-as-a-Service (PaaS) was really going to take off in a big way.
The aim of PaaS is to supply developers with a set of services that they can use to build scalable applications without doing all the underlying grunt work themselves.
Such a platform might automatically add additional capacity in response to increased load. Or it could offer various middleware services, such as databases and application servers. (The National Institute of Standards and Technology has a definition document that I and many others use to help make sure we're all on the same page when it comes to the types and characteristics of cloud computing.)
As is always the case with such things, the lines between what is a platform and what is just infrastructure and what is end-user hosted software blur a bit. But, in the main, platforms are a higher level of abstraction than infrastructure but don't offer something that's directly useful for end-users out of the box.
The questions about PaaS were at least two-fold.
For one thing, while cloud infrastructure has a fairly clean correspondence to physical and virtual infrastructure in a data center and Software-as-a-Service is just hosted software in many respects, PaaS doesn't map especially well to familiar concepts. It's partially related to middleware but also includes forms of background automation that haven't historically existed.
There's also the lock-in concern. Cloud infrastructure services like Amazon EC2 and S3 aren't standardized in a formal way. But their interfaces are straightforward enough that a third-party like RightScale can map them across different providers. Alternatively, others can treat them as effectively a de facto standard and mimic them for their own implementations as Eucalyptus is doing.
But PaaS is more vendor specific and the more layers of specialized function, the more specific it becomes. But this doesn't concern everyone. For example, Tobias Klauder of digital advertising agency Razorfish told me that he generally endorsed the idea of vendors competing on the basis of unique differentiation that users need. As he put it: "I don't see benefit to getting the exact thing from three different providers; then you're just competing on price, not features." And the reality is that moving from one vendor's middleware and other supporting application infrastructure to another's has never been an easy and transparent process.
However, upon reading a recent post by fellow CNET Blog Network writer James Urquhart, it's becoming clear to me that PaaS is an important component of cloud computing.
Microsoft's commercial launch of Azure at its Professional Developer Conference was, by all appearances, a big hit. I've personally viewed Azure as a major bellwether for PaaS, given the large Microsoft development community. If Azure clicks with .Net developers, it bodes well for the PaaS concept.
James also notes that "Ruby on Rails platform service vendor Heroku reportedly hosts more than 40,000 applications now. At its Dreamforce conference in San Francisco, Salesforce.com mentioned it had approximately 135,000 applications running on its Force.com platform" and that "anecdotal evidence suggests there is a large body of Web application developers running on both the Java and Python instances" of Google App Engine.
Google App Engine's relatively low profile was one reason to be somewhat skeptical of PaaS a year ago. Today, I'm still unconvinced App Engine is living up to some of the early expectations that surrounded it. Nonetheless, in the context of clear PaaS advances elsewhere, it's another data point for an at least moderately popular offering.
To these, I'd add that cloud infrastructure is expanding and morphing into something that looks more like a platform. Newer Amazon services such as Elastic MapReduce and Relational Database Service blur the line between what is infrastructure and what is something more. Arguably, Simple Queue Service already did this from the early days but the new services can increasingly handle the mechanics of scaling an application transparently to a developer.
In fact, given such this apparent demand for more abstraction and higher-level services, I wonder if we're starting to see cloud infrastructure essentially morph into a platform.
Last week's virtual version of the roaming CloudCamp conference was a good opportunity to check the pulse of cloud computing's evolution.
It struck me that we continue to see two very different groups of attendees at events such as this.
One is the "clouderati," the vendors involved with cloud computing in some form or another, and sophisticated users who grok cloud computing and its implications for their organization. This crowd is so past definitional debates and analogies to the electrical grid. They just want to get on with specific issues--such as dealing with audit requirements in a world where you increasingly can't just walk into a datacenter and point to the physical server where an application is running.
The other group is still a bit fuzzy on the general concept. Does cloud computing just mean Amazon Web Services? Where does software as a service fit? Is it just a load of hype? Is it safe?
It's not hard to understand why there is a fair bit of confusion. Cloud computing has become a sort of blanket term for where computing is going. Think of it as a synonym for "computing.next." It represents a shift to an operational model in which applications don't live out their lives on a specific piece of hardware and in which resources are more flexibly deployed than was the historical norm.
Cloud computing is therefore not a single technology or even a single approach but rather a collection of technologies and approaches that collectively represent the direction that computing is headed. I see nothing wrong with this. Many of the benefits espoused for these new approaches to computing are genuine. To the degree that "cloud computing" offers a convenient rallying point to get users headed there, that seems for the good.
But specific things are easier to grapple with than general paradigms. And cloud computing started life as something fairly narrow as articulated in author Nick Carr's The Big Switch. (The irony is that, not only is the cloud computing concept bigger than the Big Switch concept of a few, huge mega-service providers, it now seems unlikely that the degree of centralization and fundamental change in economic model envisioned by Carr will happen any time soon.) Whereas today, we see cloud computing used sometimes to mean computing.next and sometimes to mean a specific technology approach that someone is either promoting or denigrating.
Cloud computing incorporates and makes use of many individual sharply-defined techs of course. But, increasingly, think of the broad term as applying to a way of thinking about computing rather than the specifics of how it's done.
NEW YORK--It was a larger and cheerier crowd that attended this year's Red Hat's analyst day at the New York Stock Exchange on Tuesday.
That shouldn't be surprising. At last year's meeting on October 7, Red Hat management had the dubious honor of ringing the closing bell on a day that saw the Dow Jones Industrial Average drop over 500 points.
This meeting took place in a time of what's probably best described as cautious optimism about the state of the economy. And in the context of Red Hat financial results that have continued to show growth at a time when so many companies in IT industry and elsewhere have not.
For the quarter ending August 31, its profit jumped 37 percent relative to the year-ago quarter, besting analyst estimates.
The day included a fair bit of discussion related to financial minutiae, as you'd expect for an event pitched primarily for financial analysts. However, it also included an overview of Red Hat's strategy and its technical direction. Here are a few things that caught my eye.
Jim Whitehurst, Red Hat's CEO, spent a fair bit of time talking about what boils down to fine-tuning of its go-to-market execution such as:
- Value of subscription. This includes what he called "education and compliance," essentially a euphemism for getting people using Red Hat Enterprise Linux (RHEL) without paying for it to purchase a subscription. It also encompasses improving renewal rates for those cases where RHEL has been preloaded by a system builder and bringing a greater focus to articulating the value of RHEL relative to free substitutes such as CentOS.
- Routes to market. This refers to a continued build-out of the channel so that system integrators and others who recommend and install systems for less sophisticated customers will specify Red Hat as part of their solution. This stands in contrast to how, historically, Red Hat was mostly pulled into accounts by technically-savvy users and IT departments.
The message I took away from this is that Whitehurst isn't looking to change Red Hat's direction in any major way but sees a fair number of areas where more focused execution could lead to financial improvements. Later in the day, we also heard that Red Hat is taking a more systematic approach to which products it allocates development dollars for work such as internationalization.
For his part, Paul Cormier, executive vice president of products and technologies, reiterated Red Hat's belief that virtualization (which should be taken as hypervisor in this context) belongs in the operating system. This argument has been in evidence for a while as my fellow analyst Stephen O'Grady discussed after last year's event.
It stands in stark contrast to VMware's desire to make the operating system irrelevant. Or, to put it another way, VMware's ambition to make the VMware ESX and ESXi hypervisors the model for a new type of operating system. This is too fraught a debate to tackle here; I largely agree with Stephen's take in his post.
However, one of the interesting outcomes of this battle is that Red Hat has been cozying up to Microsoft, the other big gun on the "hypervisors belong in the OS" side. This includes Red Hat's announcement Wednesday "that customers can now deploy fully supported virtualization environments that combine Microsoft Windows Server and Red Hat Enterprise Linux."
This sort of interoperability is certainly a customer desire and both Red Hat and Microsoft can legitimately present it in those terms without anyone smirking. However, the enemy of my enemy is also my friend, at least up to a point.
I also took note that Red Hat finally seems to be making some progress on the management front.
The product in question is RHEV Manager (RHEV-M); it's covered in detail in this video from the Red Hat Summit in September and is currently being tested by customers.
One reason I think it's important is that Red Hat apparently, if belatedly, recognizes that it is. CTO Brian Stevens admitted that RHEV-M "has been a huge missing ingredient."
The one customer speaker at the analyst day was Dave Costakos of Qualcomm and he focused on his company's experiences with testing RHEL-based virtualization and the associated RHEV Manager which he describes as "hits the mark."
I caught up with Dave at a break to get a bit more detail. He told me that they wanted a Web-based interface, which RHEV Manager has. He also liked the integration with Active Directory and other directory systems, and the role-based access controls. He said that it could perform the provisioning operations that Qualcomm requires and otherwise meets their needs.
Management has historically been a relatively weak part of Red Hat's offering that was mostly focused on updating packages. This is really a reflection of the broader Linux and open-source ecosystem in general. Projects like Nagios and, more recently, GroundWork notwithstanding, management doesn't play well to the strengths of open source. It touches too many parts of an IT infrastructure and requires too much cooperative work with the vendors making the things that need to be managed.
It's reasonable to ask whether Red Hat is too late to win big with RHEV Manager and its associated KVM-based virtualization play. But it had to attack management from some angle unless it was prepared to just cede that area of differentiation and potential point of control to system makers and others.
Finally, no technology discussion today would be complete without at least a mention of cloud computing. Brian Stevens jokingly called it a "shiny thing that people are looking at how to monetize."
The cloud discussion covered several angles, not least of which was standardization efforts such as Deltacloud. Like most other standardization efforts, this focuses on what is often called Infrastructure-as-a-Service; Amazon EC2 and S3 are perhaps the best known examples. Stevens admitted that it's going to be much harder to define a standard set of higher-level services (platform as a service in the vein of Microsoft Azure) that are portable.
Red Hat's distinctive play in the infrastructure cloud essentially circles back to its approach to virtualization. In cloud infrastructure as imagined by Red Hat, the operating system matters in important ways.
That's because applications matter; indeed, applications are ultimately what matter most. And in on-premise computing, one of Red Hat's greatest values and differentiators is the vast number of certified applications that it runs. This certification matters to users because, if they encounter a problem, it means that they can call the application vendor to get support. Otherwise, they'd get a "sorry, that's not a supported configuration."
One can argue whether the software layering of which the historical operating system is a part is the most appropriate choice for cloud computing. Fellow CNET blogger James Urquhart dives deeply into this topic in a pair of recent posts.
However, whether it's the way it should be or not, it is for now. And for Red Hat to be able to enable users to carry the certification of applications into a cloud model is a significant differentiation.
I started following and writing about topics like Amazon Web Services and mashups even before they were corralled under the "cloud computing" moniker. But today, cloud computing is one of the hottest topics in IT.
Much of what I write about the cloud drills down on particular aspects or is a reaction to some vendor's announcement. Here I'm going to take a different approach and take a broader look at where things stand today and some of the challenges ahead.
1. Let's get one thing out of the way first. Cloud computing is real. Yes, there's a lot of hype and a lot of "cloud-washing" (applying the cloud term to only peripherally-related things). But cloud computing legitimately refers to a convergence of technologies and trends that are starting to make IT infrastructures and applications more dynamic, more modular, and more network-centric.
2. The industry has reached a rough consensus on a basic taxonomy for public clouds. We have infrastructure as a service (e.g. Amazon Web Services), platform as a service (Microsoft's Azure), and software as a service (Salesforce.com). People may quibble about some of the details and about how to characterize standalone Web services and such but IaaS, PaaS, and SaaS have developed into a convenient shorthand for describing the basic levels of abstraction for network-based computing.
3. Private clouds exist and will continue to exist. I'm not a huge fan of the term, but many enterprises simultaneously want to take advantage of the technologies and approaches associated with public clouds while continuing to operate their own IT infrastructure (or, at least, to maintain dedicated hardware at a third-party provider). Some of this is doubtless "server hugging" and some is giving IT-as-usual a trendy new name. However, there are lots of reasons why enterprises can't just move to a multi-tenant public cloud provider and it's not even clear that it makes economic sense for many to do so.
4. Security and compliance are high on the list of those reasons. I often see such concerns essentially trivialized as a matter of attaining a comfort level or a level of knowledge--sort of an enterprise version of consumer worries about the safety of online banking. However, as I noted after CloudCamp Boston, we're now getting into very real and very thorny questions such as how right-to-audit clauses can be satisfied in a cloud computing environment.
5. Closely related are legal matters. I hear a lot of generalized concern that the requirements for law enforcement to obtain data from a service provider may well be, at least in practice, lower than those needed to obtain a warrant for a company's own servers. Furthermore, we've already seen a case where the FBI confiscated servers from a hosting provider above and beyond those related to the specific company under investigation. Borders, especially national ones, also carry--not always well understood--legal implications.
6. There is no "Big Switch." Nick Carr's The Big Switch argued that computing is on a similar trajectory to what we saw with electrical power generation and distribution. If so, that would make cloud computing a fundamentally disruptive economic model rather than a mostly gradual shift toward software being delivered as a service and IT being incrementally outsourced to larger IT organizations. However, so far, there is scant evidence that, once you reach the size of industrialized data center operations (call it a couple of data centers to take care of redundancy), the operational economics associated with an order of magnitude greater scale are compelling. Specialization, such as to meet industry-specific compliance and regulatory requirements, will also tend to mitigate cloud computing concentration.
7. Data portability is a must. Interoperability less so. Although data portability isn't a panacea--even if you can extract your information in a documented format that doesn't mean you can transparently make use of it somewhere else--it's a base-level requirement. Interoperability is trickier. We're seeing some standardization activity at the IaaS level through a combination of de facto standards, consortia, and third-party brokers that translate among services. However, as we move further up the software stack, there are significant trade-offs between standardization and useful differentiation.
8. Cloud computing and virtualization intersect in interesting ways, but they're not the same thing. The flexibility and mobility provided by server virtualization is a great match for cloud platforms in general. And certain types of cloud computing largely define themselves in terms of the virtual machine containers that virtualization creates. However, companies such as Google have demonstrated that large-scale distributed infrastructures don't require server virtualization; they architect their infrastructures using other techniques and provide higher-level abstractions and services to users.
9. Location-based applications will reach their potential through cloud computing. People have been talking about the potential of apps that understand place almost since cell phones went mainstream. However, it's the intersection of more precise sensors on the client (GPS augmenting cell signal triangulation) and easily-consumable cloud-based applications that can mash up that data with geographical databases and the data from other users of a service that are moving apps about "place" into the mainstream.
10. The cloud will change the client. There often seems to be an implicit assumption that, over time, computing moves into the cloud and mobile devices become interchangeable display and input devices. The reality is more complicated. Copies of our devices' "state," whether data or personal customizations, will indeed migrate into the network. However, both user experience and the reality of sometimes-connected networks suggest that there's a lot of reason to push many computing tasks and working data sets out to the client device. The client will change but it won't become just a portable version of a "dumb tube."
As human beings we like analogies. Admittedly, we sometimes overextend them and end up obfuscating rather than clarifying. Such is arguably the case with cloud computing and the electric grid. However, a good analogy can not only make the new and unfamiliar more comprehensible but can even bring fresh insights based on history and past patterns.
Many of you are probably familiar with the computing-in-shipping-containers theme that Sun most popularized but that a variety of vendors has picked up on in various forms. The idea is that a shipping container is the largest thing that can be easily transported around the world and therefore it's the largest unit of computing that can be practically prebuilt at the factory.
Thus, in this storyline, the shipping container represents the new increment for large-scale computing infrastructures.
At one level, this shouldn't be taken too literally. Even if an increasing number of high performance computing and high-scale Web sites add servers in this kind of quantity, most aren't buying them actually installed in shipping containers; they're putting them in data centers a rack at a time. And vendors are designing new server form factors to reflect this shift.
However, a discussion with HP in the context of their ProLiant SL launch got me to thinking: Literal shipping containers aside, the evolution of containerization has a lot of interesting lessons for how technologies evolve more broadly.
Existing infrastructure matters. The size of container ships is largely constrained by the width and depth of the Panama and Suez Canals. A "Panamax" container ship is the maximum size that can go through the Panama Canal; a "Suezmax" the largest that can go through the Suez Canal. "Malaccamax" ships have the maximum draught that can traverse the Strait of Malacca. (Currently, there are bulk carriers and supertankers this large but not container ships.) In a totally different context, there's a good argument that the Segway failed, not so much because of price or poor design, but because it wasn't a good fit with either existing sidewalks or roads.
Standards matter. Containers have been around in various forms since at least the 1800s, beginning with the railroads. In the U.S., the container shipping industry's genesis is usually dated to Malcom McLean in 1956. However, for about the next twenty years, many shipping companies used incompatible container sizes and corner fittings. This in turn required different equipment to load and unload and otherwise made it hard for a complete logistics system to develop. This changed around 1970 when standard size and fittings and reinforcement norms were developed (with all the political jostling between the incumbents that you'd expect).
Process matters. At least as important as standards was changes to the labor agreements at major ports. When containers were first introduced, existing labor contracts negated much of their economic benefit by requiring excess dockworkers or otherwise requiring processes that involved more handling than was actually necessary. (For reason of both labor negotiations and infrastructure, containerization allowed the Port Newark-Elizabeth Marine Terminal to largely eclipse the New York and Brooklyn commercial port.)
Marc Levinson's "The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger" has lots of detail on the labor and other aspects of shipping containers.
Cloud computing is one area where the story of the shipping container has particular relevance. Like the container, the basic concepts aren't new but they are being made more relevant to a wider audience by things like network infrastructure.
Standards will matter--at least to get to the point of interoperable clouds (which admittedly may not be as pressing a need as in the case of the electrical grid and the world's logistics system).
And the business processes are, as always, highly relevant to the computing resources that are ultimately there simply to support them. Processes that are rooted in manual approaches that have lots of human back and forth won't see much benefit from new technology no matter how virtualized, service-oriented, or self-service.
CAMBRIDGE, Mass.--Cloud-computing events are in vogue these days. Wednesday's CloudCamp Boston (actually held across the river at Microsoft's Research and Development facility in Cambridge, Mass.) was a good one.
To be sure, I read a few online commentators who were of the opinion that the material in the formal part of the event--CloudCamp is organized as a combination of pre-organized talks and an unconference format--was far too basic. However, a lot of the questions I heard and conversations I had at the event suggest to me that a lot of people are still trying to get their heads around the basic concept of cloud computing. As a result, it behooves those of us who work with this stuff on a daily basis to remember that not everyone is quite so immersed.
Any event of this sort inevitably has lots of different simultaneous threads going on. However, here are a few that I think are worth highlighting:
Is security really an issue? The security aspects of cloud computing are often presented as a matter of trust in service providers and getting comfortable with the loss of direct hands-on control. Those are part of it certainly. But a number of discussions made it clear to me that the situation is a lot more complicated than developing a "comfort level" with the technology. It also goes beyond point products such as data encryption.
Christofer Hoff (who was in one of the unconference sessions I participated in) wrote a post a few days ago that gives a nice window into some of the complexities here. This isn't to say that security control and compliance concerns are stumbling blocks for moving all applications into a cloud, but they do have to be taken into account (in all their myriad complexity) for many core business applications.
What is cloud interoperability? Interoperability seems to be emerging as a bit of a contentious topic in cloud computing. This is partly because interoperability, like cloud computing itself, means different things to different people. Just about everyone agrees that base-level data portability (download your customer records from a CRM system in a readable format) is a must and that a nirvana of totally transparent computing delivery across providers is years away.
The confusion and argument comes in the vast middle ground.
A couple of things that people at the event seemed to generally agree with:
The higher you go up the stack from Infrastructure-as-a-Service (a la Amazon Web Services), the less interoperability you can or should expect. (And, indeed, the less interoperability IT folks are even necessarily looking for.) In other words, don't expect to transparently switch from one business intelligence application to another even if you can move and transform your data relatively easily.
A lot of interoperability will be provided not by the service providers themselves (who after all don't have a particular incentive to make switching away from their service easy) but by third-party "service brokers." We see a good early example of this sort of thing is RightScale who is essentially mapping the APIs from different IaaS (infrastructure as a service) vendors like Amazon and Rackspace to common interfaces in their management software.
Where's the business opportunity? Finally, in a session led by fellow analyst Judith Hurwitz, we discussed the opportunities for start-ups in cloud computing. One way to look at the opportunity is to break it down into two broad categories: companies and products such as development or management tooling that make clouds work better and those that are enabled by clouds. The latter includes software as a service broadly, but it could also refer to things like distributed testing that make use of geographically distributed public cloud providers.
As is the case with the software industry more broadly, there was general agreement that industry-specific products and services often offer better opportunities than big horizontal plays. For example, offerings that deal with data governance issues related to a specific vertical such as the pharmaceutical industry.
One thing there was consensus about is that setting up capital-intensive cloud infrastructure is not typically going to be a good start-up play. (In general, I conclude that far more start-ups are going to be enabled by cloud computing--vis the explosion of mobile applications--than will be involved in creating the platforms that support it.)
Cloud computing covers a lot of territory and there are still enormous differences in how familiar different people and organizations are with the particulars. However, one of my takeaways from this event is that we're seeing reasonable consensus on the basic taxonomy of cloud computing (even if we argue about terminology like "private cloud"). But, like peeling an onion, now that we're winding down some definitional and basic value debates, we're starting to get into more detailed and thornier questions about the particulars.
Standards evolve in a lot of different ways. However, broadly speaking, they fall into two main buckets: de jure and de facto (to use the Latin-derived legalese). By law and by fact.
In high tech as elsewhere, it's often a matter of historical accident and political maneuvering that determines which approach wins out in a particular area of technology. And it can be a high-stakes game for the companies involved, with big players often seeking to position their approach as a "standard" even if it's only standard in the sense of being ubiquitous (think Microsoft Windows) while the smaller guys tend to favor approaches blessed by standards bodies or at least industry corsortia.
In cloud computing, we're seeing almost all the forms of standards-making coming into play with the primary goal of promoting interoperability among different cloud service providers and between private and public clouds.
On the de jure side, the most significant standards-making effort is taking place under the auspices of the Distributed Management Task Force (DMTF), an established organization in the management standards space. AMD, Cisco, Citrix, EMC, HP, IBM, Intel, Microsoft, Novell, Red Hat, Savvis, Sun Microsystems, and VMware announced in April 2009 (PDF) that they would comprise the board for an Open Cloud Standards Incubator within the DMTF.
If you were to observe that none of those companies currently have a big play in public cloud infrastructure, you would be correct. Microsoft has its Platform-as-a-Service Windows Azure play, and a number of those companies are very active in working with enterprises to build internal cloud-style IT, but none have an Infrastructure-as-a-Service (IaaS) offering in the vein of the conspicuously absent Amazon.
And it's Amazon Web Services (AWS) that has clearly emerged as the de facto standard for IaaS. The fact that Amazon is one of the first vendors that comes to mind in just about any discussion of public clouds is one indication. Another is the growing ecosystem of companies like RightScale that add additional features to AWS--not uniquely, but first and foremost. We now even have an open-source project and company, Eucalyptus, that lets organizations implement their own clouds that are compatible with many AWS services.
Now one of Amazon's competitors, Rackspace, is taking yet another approach to promoting its implementation as a standard. It's open-sourcing the specifications for its Cloud Servers and Cloud Files API under the Creative Commons 3.0 Attribution License. It also has made available its Cloud Files language bindings for Java, PHP, Python, C#, and Ruby under the MIT license.
The Creative Commons license that Rackspace is using lets users both share and change the work so long as they provide attribution to the creator, in this case Rackspace. The MIT license is a very permissive license in the vein of BSD that allows essentially any use of the code including its use within proprietary software.
Rackspace has emerged as a major player in public cloud infrastructure. Cloud Servers competes with Amazon EC2 and Cloud Files with S3. It also has a product called Cloud Sites, based in part on technology from its Mosso acquisition, that is more of a PaaS offering with dynamic scalability (but that's not part of this announcement).
This announcement doesn't fundamentally change the landscape. However, it does give an already well-established IaaS vendor a point of clear differentiation from its biggest competitor.
We've been hearing a lot about thinner client devices of late. Netbooks are a hot topic, whether or not they're really a distinct category of device. I've wondered if there might not be a role for a sort of ebook-on-steroids. And Google's Chrome OS, pitched for a browser-centric world, had the digerati all in a flutter a few weeks back.
A lot of this activity reflects a general move away from software that is locally installed and run on a traditional PC to software and services housed on servers out on the network--in the cloud, to use the lingo du jour. It's enabled in no small part by increasingly pervasive networks including wireless ones of various kinds.
However, although cloud computing tracks improvements in networks, it doesn't necessarily sync up so cleanly with the parallel improvements going on in computers themselves. As a commenter put it in a recent post of mine: "The thing that I don't understand about the move to "cloud-based services" is that it seems at odds with Moore's Law. Specifically, devices are going to have more & more processing power, disk space & memory - why would you want to offload processing to the cloud?"
This is a deceptively deep comment and one that touches a lot of basic architectural questions about how we will run software and where we will run it.
One thought is that we're not really running counter to Moore's Law. Rather, we're moving the increased number of transistors that Moore's Law gives us from the client to the server. We're making clients thinner (and therefore more portable, cooler, and so forth) and the servers fatter.
There's some truth in that with mobile phones perhaps offering the clearest illustration.
But, for more notebook-like clients there's a lot of processor and graphics horsepower on the local computer that's going to waste much of the time. And, in any case, telecommunications infrastructure places hard limits on bandwidth for a given time of place, but we can dial up and down our local compute horsepower by selecting devices with different characteristics. So it makes more sense to favor local processing much of the time.
In fact, the fundamental thing that thinner clients and cloud computing tackle isn't really the movement of computing off the client but rather the movement of "state" off the client--which is to say data, applications, and customizations specific to a given user.
As a practical matter, most clients still store some amount of state. In the days of old, terminals didn't store anything locally. Sun's Sun Ray line comes closest to replicating this experience in modern thin clients. However, even browsers store cookies and can be configured with extensions and plug-ins that will vary from one installation to the next.
And, for most purposes, this is probably a reasonable enough state of affairs. Our personal devices are personal anyway; we just want to get away from having to load and manage custom software for each individual task that we want to do. Shared, public clients are a different matter, of course. However, in this case, a lowest-common-denominator software load (such as a browser) is typically sufficient.
There is clearly a lot of work left to do and battles, both technical and political, left to fight to arrive at the best architectural models and programming practices for this new generation of client-server computing. For example, do "rich Internet applications" live in the browser a la Microsoft's Silverlight or is a separate framework such as Adobe's AIR a better approach? Where do .NET and Java fit in?
These (and many others) are not small questions. Application writers need to understand at a very granular level the environment for which they're writing. And there is very much a tension between richness of the client experience and the degree to which we can standardize and simplify that client.
At the conceptual level, there isn't a huge amount of disagreement among technologists about the fundamentals of cloud computing--its forms, its characteristics, its potential benefits, and its limitations.
That said, individual vendors come at cloud computing from particular perspectives that often reflect the character and needs of an existing customer base. Nowhere is this truer than in the case of IBM. I attended an IBM event at their new Littleton, Mass., location a couple of weeks ago, and I was struck by the degree to which its latest cloud computing announcements and the strategy of its cloud computing organization mirror the focus and strategy of IBM in other areas.
Several related threads collectively define IBM's primary approach to cloud computing.
The first is "private clouds."
By "private," IBM means one of three things: 1) infrastructure within a customer's data center, 2) infrastructure operated by IBM for a customer within an IBM data center, or 3) IBM infrastructure dedicated to the use of a single customer.
In other words, private pretty much covers the gamut of everything that is not a shared, multi-tenant public cloud.
However, that shouldn't be read as IBM just using the term "cloud" here as a marketing buzzword to cover just about all computing. It's easy to draw that conclusion given IBM's focus on dedicated infrastructure. But while IBM uses the term broadly and very pragmatically, it does associate it with certain specific characteristics.
For example, one IBM exec at the event spoke of an existing virtual desktop infrastructure (VDI) deployment and noted that it was not, yet, a cloud because it is the operations analysis, the service orchestration, and self-service that make a cloud. (In this context, operations analysis refers to identifying and modifying workflows and interactions between people--such as eliminating "ad hoc chatter" that duplicates effort or adds latency.)
A second thread is IBM's main target for this phase of its cloud rollout. That would be development and test--mostly for the reason that IBM sees this as the low-hanging fruit. It's an area of enterprise IT where change happens all the time and resources are often not easily reclaimed even when they're no longer being used.
If this sounds like a familiar storyline, it should. This is where virtualization got its start and for many of the same reasons. At the same time, what IBM is doing here goes beyond test/dev virtualization.
And this brings us to the third thread, the precise nature of the audience for these products.
What's different here from just loading up VMware on a blade server and even adding a VMware product like Lab Manager is the other IBM tooling in place. Rational development toolsets and Tivoli service management are integral parts of these integrated packages. (Tivoli plays a central role in IBM's approach to cloud in general.)
You might think that this is a heavyweight and heavy-duty enterprise-centric approach to cloud computing. You would be right. I made this observation to one of their senior cloud executives and he didn't disagree.
The exec's response: "Our natural constituencies are the enterprise developers and we have to cater to the enterprise developer and enterprise developer teams. Within them, we have the subset who write enterprise transactional software. These are the apps who decide over life or death of a CIO and we have to cater to them. They are also the majority still of the central development organization."
This is not to say that IBM isn't also doing things related to lighter-weight, such as RESTful, development approaches. There's an IBM Mashup Center, for example, and cloud resources on IBM developerWorks. However, this style of cloud computing is not at the forefront of Erich Clementi's cloud computing organization.
But IBM is putting the wood of the arrow behind cloud computing for the core mission-critical applications in an enterprise, its primary target outside of the cloud as well.
Coming from a technical background, when I hear the word "standards," I tend to think of things that usually go by strings of numbers (802.11), inscrutable abbreviations (USB), or at best a slightly more melodious moniker dreamed up by a marketing department (WiMAX).
They may be codified by a standards body as part of a formal de jure process. They may evolve through the efforts of one or several companies and gain wide enough usage to be considered a de facto standard. Or, as with PDF, they may start life as a de facto standard that is later ratified by a standards body.
Whatever the particulars, such technical standards allow equipment or software from a variety of different sources to work together in predictable ways.
When people talk about cloud computing, these are the sorts of standards that they're usually talking about. The main issue being addressed is portability--the canonical example being moving an application developed for Amazon Web Services to some other vendor's service.
In the Amazon case, a subset of AWS has indeed become a sort of de facto standard. Eucalyptus is one example of implementing a subset of AWS outside of Amazon. Another approach is epitomized by RightScale, which has emerged as a dominant management platform for AWS; it has efforts under way to mask the differences between different cloud infrastructure providers at the management level.
Well-established Web standards of various types also play key roles in creating and accessing cloud-computing services.
So technical standards for cloud computing are indeed moving forward. However, I find that when I talk to consumers of cloud computing, they don't really care much at this point. I noted this previously after I interviewed Tobias Klauder at Razorfish.
That's not to say that people don't care about standards in cloud computing. I led a session at the Massachusetts Technology Council unconference on The Future of Software and the Internet last week to address the question of whether we need standards for cloud computing.
The participants argued that we do indeed need standards. But they had a different sort of standards in mind--something more akin to these definitions:
- an average or normal requirement, quality, quantity, level, grade, etc.
- those morals, ethics, habits, etc., established by authority, custom, or an individual as acceptable
They were looking for more transparency in understanding data protection schemes--backup procedures, recovery point objectives, and recovery time objectives. They wanted to understand what is private and what is not and how data is secured and exported. They wanted this to be communicated in a straightforward manner and, ideally, audited by a trusted third-party in some way.
The issues raised in my session were less about finely tuned service level agreements (SLAs) and more about simply understanding the characteristics of a service. One size does not fit all. Thus, an online backup service such as EMC's Mozy has to offer a variety of options--including whether a user supplies their own encryption key (which itself must be kept secure and protected) or let the service provide one. An organization with specific archive requirements would need other types of guarantees and capabilities.
These are all standards. Some may become true standards over time in the sense of codified best practices and metrics. However, it's clear to me that what users most want in the near-term is to better understand, in plain English, some of the basic practices followed by cloud-service providers.
