When I have a presentation to give, I’m increasingly writing out my spiel (after drawing up the slides), which was the case with the talk I gave this morning at the Linux Foundation’s Collaboration Summit on Cloud Computing and Linux. Thing means for you, dear readers, there’s some meaty text to skim through instead of just boney slides. Also, this time I recorded a practice read-through of the talk which you could watch as well, below. I’m one of those people who never gives the same presentation twice, but you can get an idea of this mornings talk from one or both of the below:
Cloud computing is one of the bigger tech-world hypes at the moment. As with all these things, there was a disruptive innovator who didn’t so much invent something mind-bogglingly new, but managed to do what in retrospect seemed the obvious thing and make it look simple – “a lot of effort went into making this look effortless,” as one of my favorite old quotes goes.
Let’s set some expectations for this next 30 to 35 minutes – I’ll leave some room for questions at the end. First, there’s lots of “how many angels can dance on the head of pin” talk going on about cloud computing now. Like SOA before it, “cloud computing” has become a sort of silly-putty that can fit into whatever hold a stakeholder brings to the table. It’s all over the map. Here, we’re not interested in getting low-level enough to make those debates any fun to get into.
And yet, we need some definition to go off of. So I’ll pull out, what seems to me, the most common one, and we’ll run with it in the interests of not debating it.
Being in Linux-land here, we’ll spend the bulk of the talk going over the goods and the bads for Linux in the possible cloud computing future.
The 3 *aaS’s of Cloud Computing
I can’t resist a chance to pun-curse. It’s just in my nature. Before cloud computing was all the rage, if you recall, we were all nuts about Software-as-a-Service, one of the funner tech initializations – “SaaS”! Once Amazon introduced EC2, SalesForce Force.com, and others followed, we needed some more categorization to differentiate and understand these things. “We” being industry pundits & vendors. Thus, we arrive at the 3 *aaS’s of cloud computing.
What I’m leaving out is a tall stack of every other technology suffixed with “aaS”: storage, identity, networking, security, whatever you have that you care about. Like I said in the beginning, I’m not interested in defending the 3 *aaS’s as the only ontology of cloud computing, it’s just a nice, simple one to work with.
What are they?
To over-simplify again, it breaks down to:
- applications – what someone is actually using to do some task, business goal, or shoot zombies in. Whether you’re gaming or hustling up sales, you’re using a “service,” which is subtly semantically different from “software.”
- middle-ware – developers, or people who write software if you prefer, need a comfy bed to lay all their code in. We’ve had “stacks” forever: LAMP, Java application servers, .Net CLRs, you know. This is a “platform.”
- servers – throw together some hardware and an operating system, perhaps a hyper-visor, and you’ve got “infrastructure.”
Clearly, you can see that Linux creeps in from the bottom of this stack. Of course, Linux people might sort the opposite in order of important.
Key to all this stuff is that it’s provided over a network and in the classic definition, an organization using it doesn’t actually own or manage any of it: they just use it. All of this thinking was really crystallized by Nick Carr in The Big Switch, which seemed pretty overly optimistic when it came out, but has been a sturdy metaphor and explanation for this cloud stuff.
You can also see that these are Russan-doll concepts: SaaS depends on PaaS, depends on IaaS. Kinda. GMail is a SaaS, but there isn’t really a “GMail PaaS,” right? Kinda. There’s IMAP and POP – but wait, those are old, so surely they’re not cloud.
The Russian doll point is one more of market visibility & important: the wider world probably cares more about actually doing something – SaaS – than having middleware to build something – PaaS – and care more about those two things than having a bunch of instances with that annoyingly calm blinking command like cursor – IaaS.
Why Cloud Computing?
So what motivations do people have on both sides of the fence – user and vendor – for cloud computing?
For users, it comes down to 3 things:
- Cost – Amazon is renowned for being dirt cheap for storage and burst-y processing.
- Flexibility – or “ease of use.” Instead of having to wrangle all your own *aaS’s, you let someone else manage them for you.
- Elasticity – this is great for public web companies, but not so much of a holy grail for the rest of the world.
For vendors, there are a few things, chief among them:
- New Business Models – you always need something new to sell, and here it is. Also, the as-a-Service model creates whole new markets to sell to and even, theoretically, flattens out market segmentation allowing vendors to sell to every segment instead of picking Small, Medium, or Enterprise.
- New Features – if everything is running on the Internet, with the potential of hyper-connectedness there’s all sorts of new things to offer. New features mean new reasons for customers to give vendors money.
- Operation Expenses – while a vendor has to own and manage hardware, in theory the ability to put out new versions, patches, and control everything is a better way, long term, to run software. In an *aaS world you can have “featureless” architecture-releases – though, as a developer, I’ve always consider “works better” and “higher quality” to be a pretty damn nice feature. Seemed to work for Japanese cars.
You can’t go around saying something is at the apex of height without some skepticism. What are some concerns when it comes to cloud computing?
First, though I’ve dubiously tried to avoid a definitional quagmire, that’s the major concern: what exactly cloud computing means to different sets of users. Most cloud computing thought now appeals to public web companies and startups, ISVs at the best. What cloud computing means for “enterprise” users is not so clear-cut and wide-open to vendor manipulation. This is the “public” vs. “private” cloud debate: “private cloud” means running a cloud behind your firewall.
I tend to question the idea of a private cloud – owning and managing the cloud seems to miss the point of cloud computing in the first place. That said, much of the “private cloud” talk results in tools that simplify the automation and provisioning of big time IT. Now, businesses using the public cloud – sure – but running their own, I’m not sure calling whatever we’re talking about here “cloud” helps.
There are other concerns:
- Retraining developers and operations people to deal with cloud computing
- Ending up paying more for *aaS’s – I talked with one non-tech company who had been hounded to sign up for a $100k+ a year SaaS when the TCO for their on-premise stuff just cost them about $20k a year to run.
- Lock-in – there really is no standard for the goop you’re running in the cloud now-a-days.
- Legacy concrete – so far, it’s not really straight-forward to just move your stuff into the cloud, leaving the IT department with two problems now: on-premise and cloud.
- Finally, all this cloud stuff could just be a distraction from virtualization in general. Today’s “cheap” virtualization is what makes cloud computing possible, and there is a conceptual risk that cloud computing narrows down virtualization too much.
Things to point to
Cloud computing is still very new. It’s still, though barely, at the stage where you can point to vendors and implementations for a definition rather than have to start with an idea.
Here are the outfits that come to my mind:
- Amazon is, of course, the prime mover here. Whatever they do in this space is cloud computing. They haven’t biffed yet and they’re up and running.
- SalesForce’s Force.com Microsoft Azure is a PaaS in the works.
- There are other interesting folks: 3Tera, Sun’s Cloud, Rackspace, and many reborn hosters, people like EngineYard as well. You hear a lot about Slicehost (now with Rackspace).
- I keep an eye on people like Puppet who do automation software.
Now we’ll get into the SWOT breakout. Starting with existing Linux strengths:
In a cloud environment, everything is driven by cost (like mainframes). The fact that Linux can be had for free is thus a core strength.
Clearly, Linux is known to work, be reliable, and scale well. It has breadth of supported hardware devices, and so on. People no longer doubt if Linux will work for them.
Like most open source, Linux is very transparent and malleable. Not only can you peer into it and see how it ticks, but you can muck around with it. It’s like an old VW Bug or Van: it’s great to tinker with. This is vital for cloud people who need to bend all the software to their needs.
In general, Linux is easier to build IT management tools for. Having done this kind of work myself, I can tell you that it’s easier to write software to manage Linux than just about anything else. Closed and low-volume operating systems are always crap-work in this area. Cloud computing relies on good management tooling to work – to defeat the so called “meat cloud.”
Linux is best friends with virtualization, and that’s table steaks for cloud computing.
Finally, the wide variety of applications that already work on Linux means that the re-writing isn’t as terrible as it could be. Sure, there’s bound to be changes, but it at least works on a single node cloud.
In the world of cloud computing, Linux’s primary weaknesses are mirrors of it’s strengths.
To me, cloud computing is largely about the upper layers of the 3 *aaS’s: applications and middlware. Linux finds its strength at the bottom layer, with infrastructure. The emphasis of the Linux community tends to be equally aligned. There are “Linux applications,” but it’s not as dominate a concept as “Java applications.” The point is: if cloud computing is largely about applications, services, Linux is a small part of that. More in the threats section.
Related is the weak allegiance that developers have to operating systems. Developers tend to align with platforms, with stacks, rather than an operating system. Sure, there’s Microsoft and everyone else, but many of those “everyone elses” still run on Windows, they just run Java, PHP, or whatever.
Next up, there’s fragmentation with different distributions and hyper-visors. From a cloud stand-point, ideally, there’d be as few of those as possible. To explain this point through an example: RedMonk often talks with cloud vendors who support “Linux.” What they mean is that they usually mean is that they support RedHat Linux, sometimes Suse.
Finally, there’s the SaaS GPL killer: the trade-off between “free,” open source Linux and non-paying customers is gets jacked around by Linux. More importantly, there’s some concern over the role of open source if no software distribution actually occurs: if a user only sees a front-end, did the code get distributed?
What are some new, positive things Linux could see in a cloudy world?
My bias towards SaaS should be pretty clear by now. If you look at the iPhone, it’s all about being the internet in your pocket. While the iPhone is no friend to Linux, the general concept it brings paired with Netbooks are a hugh opportunity for Linux. AT&T has started selling [TK see if they sell Ubuntu on there] Netbooks as if they were phones (with equally onerous contracts). The “Net” in Netbooks could just as well be “cloud”: they’re a way for people to access and use the cloud.
Very much in the early stages now, an idea of model-driven IT management is emerging for behind-the-firewall management. Frameworks like Puppet are driving much of this thinking, and the white-boxness of Linux makes it a great underlying layer for this kind of IT. What’s this model-driven stuff? Well, think of autonomics and other big name IT ideas from the past decade, inject them with open source and pragmatism, and you’ve pointed in the right direction.
The most low-hanging fruit is simply people wanting to setup their own clouds and using Linux for it. Whether it’s free, support-paid, custom made, whatever. Very few people – read: Microsoft and Sun, maybe IBM – are going to use anything but Linux for clouds they build.
Finally, as a small note: with cloud computing it’s now easier than ever for an individual to simply try out Linux. While it’s been very easy to get live CDs and whatnot recently, piddling around with your own instance that you can mess up and blow away at will in the cloud is amazing.
Threats often manifest themselves as methods of exploiting weaknesses. Here, by “threat” we mean an external force that could harm the Linux world, clearly, in relation to cloud computing:
- “The Operating System Doesn’t Matter” – looking at the top two *aaS’s in cloud computing, operating systems find little purchase. Obviously, an OS is needed to run the middleware and the applications, but it’s further distanced from the users. The threat here is Linux loosing intimacy with end-users, which means less “brand power,” to put it one way, that can be called on when needed to prove the worth and import of Linux. This has been tried many times over – recall the Java VM, the .Net CLR, and more – with various effects. In the currently, environment, operating systems still “matter” a great deal. The question in the cloud computing world is how much further down into Morlock land SaaS and PaaS can push Linux.
- Closed Clouds – cloud computing offers vendors/providers the chance to create closed source worlds where, in contemporary, on-premise environments, open source dominates. End-users and decision makers may not care about open source – or, put another way, worry about relying on a closed source stack – if it’s simple and “just works,” e.g., Google Apps. Here, the threat is erosion of the progress that open source and, thus, Linux has made to forward it’s philosophy of openness.
- Distro Madness – the other side of the opportunity of “fragmented air-space,” is an over proliferation of Linux-based clouds. While multiple technology choices are absolutely welcome over single-technology ecosystems, too many choices can become a hassle in its own right. For example, the early proliferation of open source licenses caused much confusion and has been, largely, thankfully consolidated.
All of these weaknesses and threats aside, Linux seems perfectly positioned in relation to cloud computing. In the worse case scenario – cloud computing ends up being vapor-ware and a colossal waste of attention-time – Linux is ineffective. The Linux world’s health isn’t connected to cloud computing that tightly. In the best case scenario – cloud computing explodes – Linux instances will blossom. (As has been pointed out, not all clouds will be Linux based, but many are and, most likely, will.)
For a technology ecosystem, that’s the best case to be in: no risk, and potential gain from an external trend.
Finally, in the hear and now, those interested in cloud computing would do well to start thinking about and working on transitioning “brown field” applications to the cloud. Starting “green field” applications (brand new applications) on any new technology platform is simple enough: you just do it, from scratch. However, the bulk of software and IT out there is old, legacy technology. They’re “brown field” applications. To my knowledge, there are not readily available practices or tools for easily transitioning these applications to the cloud. Some applications may be simple enough to run in the cloud, while others will require re-tooling and re-process engineering in IT. Cloud computing will only be wildly and widely successful if it “cares” about these brown field applications and not just the fresh and lush green field applications.
Disclosure: The Linux Foundation, Reductive Labs, Microsoft, and others mentioned are clients.