OpenStack has emerged as the consensus forum for open source private cloud software. That of course makes it a big and complex community, with complex governance and arguably even more complex politics, but it has survived several rounds of competition and is now settling down as THE place to get diverse vendors to work together on a IAAS that anybody can deploy for themselves. It is a big enough forum with sufficient independent leadership that no one vendor will ever control it (despite some fantastically impressive efforts to do so!). In short, OpenStack is what you want if you are trying to figure out how to build yourself a cloud.

And by quite a large majority, most of the people who have actually chosen to deploy OpenStack in production, have done so on Ubuntu.

At the latest OpenStack summit, an official survey of production OpenStack deployments found 55% of them on Ubuntu, a stark contrast with the 10% of OpenStack deployments on RHEL.

Canonical and Ubuntu play an interesting role in OpenStack. We do not seek to control any particular part of the project, although some of our competitors clearly think that would be useful for them to achieve, we think OpenStack would be greatly diminished in importance if it was perceived to be controlled by a single vendor, and we think there are enough contributors and experts around the table to ensure that the end result cannot actually be controlled by a single party. To a certain extent, the battle for notional control of key aspects of OpenStack just holds the project back; it’s a distraction from the real task at hand, which is to deliver a high quality, high performance open cloud story. So our focus is on supporting the development of OpenStack, supporting the broadest range of vendors who want to offer OpenStack solutions, components and services, and enabling a large ecosystem to accelerate the adoption of OpenStack in their markets.

It’s a point of pride for us that you can get an OpenStack cloud built on Ubuntu from just about every participant in the OpenStack ecosystem – Dell, HP, Mirantis, and many more – we think the healthiest approach is for us to ensure that people have great choices when it comes to their cloud solution.

We were founding members and are platinum sponsors of the OpenStack Foundation. But what’s more important to us, is that most OpenStack development happens on Ubuntu. We take the needs of OpenStack developers very seriously – for 14.04 LTS, our upcoming bi-annual enterprise release, a significant part of our product requirements were driven by the goal of supporting large-scale enterprise deployments of OpenStack with high availability as a baseline. Our partners like HP, who run one of the largest OpenStack public cloud offerings, invest heavily in OpenStack’s CI and test capabilities, ensuring that OpenStack on Ubuntu is of high quality for anybody who chooses the same base platform.

We publish stable, maintained archives of each OpenStack release for the LTS releases of Ubuntu. That means you can ALWAYS deploy the latest version of OpenStack on the current LTS of Ubuntu, and there is a clear upgrade path as new versions of both OpenStack and Ubuntu are released. And the fact that the OpenStack release cadence and the Ubuntu release cadence are perfectly aligned is no accident – it ensures that the OpenStack developers can always deliver their latest code straight to a very large audience of developers and operators. That’s important because of the extraordinary pace of innovation inside OpenStack; there are significant and valuable improvements in each six-month release, so customers, even enterprise customers, find themselves wanting a more aggressive upgrade schedule for OpenStack than is normal for them in platform environments. We support that and have committed to continue doing so, though we do expect the urgency of those upgrades to diminish as OpenStack matures over the next three years.

For commercial support of OpenStack, we are happy for industry to engage either with our partners who can provide local talent combined with an escalation path to Canonical for L3 support of the whole solution, or directly with Canonical if the circumstances warrant it. That means building on Ubuntu opens up a wide range of solution providers who can make the same high commitment to SLAs and upgrades.

For Canonical itself, our focus is on scale and quality. Our direct customers run the very largest production deployments of OpenStack, both private and public, and we enjoy collaborating with their architects to push the limits of the stack as it stands today. That gives us a lot of insight into the approaches being taken by a wide range of architects in telco, finance and media. We ourselves invest very heavily in testing, continuous integration, and interoperability, with the largest OpenStack interop program (OIL) that gives us the ability to speak with confidence about what combinations of vendor offerings will actually work, and in many cases, how they will perform together for different applications.

The fact that the traditional enterprise Linux vendors have now joined OpenStack is a tremendous validation of the role that OpenStack has assumed in industry: THE open cloud forum. But for all the reasons outlined above, most of the actual production deployments of OpenStack are not on traditional, legacy enterprise Linux. This mirrors the public cloud, where even the largest and most mission-critical deployments tend not to be on proprietary Linux offerings; the economics of HA single-node solutions just don’t apply in a scale-out environment. So just as Ubuntu is by far the most widely used platform for public cloud guests, it is also on track to be the enterprise choice for scale-out infrastructure like IAAS, storage, and big data. Even if you have always done Linux a particular way, the transition to scale-out thinking is an opportunity to reset expectations about your base OS; and for the fastest-moving players in telco, media and finance, Ubuntu turns out to be a great way to get more done, more efficiently.

In a series of 12 posts, I’ll make the case for Ubuntu as the platform of choice for public clouds, enterprise clouds and related scale-out initiatives.

Cloud computing is largely being defined on public clouds today. There are a range of initiatives for private cloud computing – some proprietary, some open – but for sheer scale and traction, the game today is all about public cloud services. Azure, AWS, a range of offerings from telco’s and service providers together with innovative takes on the concept from hardware OEMs have been the leading edge of the cloud market for the past five years. We do expect private clouds to flourish around OpenStack, but we expect the gene pool of innovation to stay on the public clouds for some time.

And what do people run on public clouds? By substantial majority, most of that innovation, most of that practical experience and most of the insights being generated are on Ubuntu.

Digital Ocean, the fastest growing new challenger in the US public cloud market, published definitive statistics on the share of operating systems that customers choose on their cloud:

Ubuntu has 67% share of the Digital Ocean public cloud

Ubuntu is the most popular OS on public clouds, by far.

AWS hasn’t spoken publicly on the topic but there are a number of measurements by third parties that provide some insight. For example,  SCALR offer a management service that is used by enterprises looking for more institutional management control of the way their teams use Amazon. One might think that an enterprise management perspective would be skewed away from Ubuntu towards traditional, legacy enterprise Linux, but in fact they find that Ubuntu is more than 70% of all the images they see, three times as popular as CentOS.

There is no true safety in numbers, but there is certainly reassurance. Using a platform that is being used by most other people means that the majority of the content you find about how to get things done efficiently is immediately relevant to you. Version skew – subtle differences in the versions of components that are available by default on your platform of choice – is much less of an issue if the guidebook you are reading assumes you’re on the same platform they used.

There is also the question of talent – finding people to get amazing things done on the cloud is a lot easier if you let them use the platforms they have already grown comfortable with. They can be more productive, and there are many more of them around to hire. Talking to companies about cloud computing today it’s clear their biggest constraint is knowledge acquisition; the time it takes to grow own internal skills or to hire in the necessary skills to get the job done. Building on Ubuntu gives you a much broader talent and knowledge base to work with. Training your own team to use Ubuntu if they are familiar with another Linux is a relatively minor switch compared to the fundamental challenge of adopting a IAAS-based architecture. Switching to Ubuntu is the fastest way to tame that dragon, and the economics are great, too.

That’s why we see many companies that have been doing Linux one way for a decade switching to Ubuntu when they switch to the cloud. Even if what they are doing on the cloud is essentially the same as something they already do on another platform, it’s “easier with Ubuntu on the cloud”, so they switch.

Building clouds for fun and profit

Monday, September 19th, 2011

So you’d like to spin up an internal cloud for hadoop or general development, shifting workloads from AWS to your own infrastructure or prototyping some new cloud services?

Call Canonical’s cloud infrastructure design and consulting team.

There are a couple of scenarios that we’re focused on at the moment, where we can offer standardised engagements:

  • Telco’s building out cloud infrastructures for public cloud services. These are aiming for specific markets based on geography or network topology – they have existing customers and existing networks and a competitive advantage in handling outsourced infrastructure for companies that are well connected to them, as well as a jurisdictional advantage over the global public cloud providers.
  • Cloud infrastructure prototypes at a division or department level. These are mostly folk who want the elasticity and dynamic provisioning of AWS in a private environment, often to work on products that will go public on Rackspace or AWS in due course, or to demonstrate and evaluate the benefits of this sort of architecture internally.
  • Cloud-style legacy deployments. These are folk building out HPC-type clusters running dedicated workloads that are horizontally scaled but not elastic. Big Hadoop deployments, or Condor deployments, fall into this category.

Cloud has become something of a unifying theme in many of our enterprise and server-oriented conversations in the past six months. While not everyone is necessarily ready to shift their workloads to a dynamic substrate like Ubuntu Cloud Infrastructure (powered by OpenStack) it seems that most large-scale IT deployments are embracing cloud-style design and service architectures, even when they are deploying on the metal. So we’ve put some work into tools which can be used in both cloud and large-scale-metal environments, for provisioning and coordination.

With 12.04 LTS on the horizon, OpenStack exploding into the wider consciousness of cloud-savvy admins, and projects like Ceph and CloudFoundry growing in stature and capability, it’s proving to be a very dynamic time for IT managers and architects. Much as the early days of the web presented a great deal of hype and complexity and options, only to settle down into a few key standard practices and platforms, cloud infrastructure today presents a wealth of options and a paucity of clarity; from NoSQL choices, through IAAS choices, through PAAS choices. Over the next couple of months I’ll outline how we think the cloud stack will shape up. Our goal is to make that “clean, crisp, obvious” deployment Just Work, bringing simplicity to the cloud much as we strive to bring it on the desktop.

For the moment, though, it’s necessary to roll up sleeves and get hands a little dirty, so the team I mentioned previously has been busy bringing some distilled wisdom to customers embarking on their cloud adventures in a hurry. Most of these engagements started out as custom consulting and contract efforts, but there are now sufficient patterns that the team has identified a set of common practices and templates that help to accelerate the build-out for those typical scenarios, and packaged those up as a range of standard cloud building offerings.

 

Innovation and OpenStack: Lessons from HTTP

Thursday, September 8th, 2011

OpenStack is facing an important choice: does define a new set of API’s, one of many such efforts in cloud infrastructure, or does it build around the existing AWS API’s?  So far, OpenStack has had it both ways, with some new API work and also some AWS-based effort. I’m writing to make the case for a tighter definition of mission around the de facto standard infrastructure API’s of EC2, S3 and a few other elements of AWS.

What prompted this blog was my overhearing (or, seeing an email on a list) the statement that cloud infrastructure projects like OpenStack, Eucalyptus and others should “innovate at the level of the API and infrastructure concepts”. I’m of the view that any projects which try to do so will fail and are not worth spending your or my time on. They are going to be about as successful as projects that try to reinvent HTTP to make it better/faster/cleaner/whatever. Which is to say – not successful at all, because no new protocol with the same conceptual goals will match the ecosystem that exists today around HTTP. There will of course be protocol innovation, the last word is never written, but for the web, it’s a done deal. All the proprietary and ad-hoc things that preceded HTTP have died, and good riddance. Similarly, cloud infrastructure will converge around a standard API which will be imperfect but real. Innovation is all about how that API is implemented, not which API it is.

Nobody would say the web server market lacks innovation. There are many, many different companies and communities that make and market web server solutions. And each of those is innovating in some way – focusing on a different audience, or trying a different approach. Yet that entire market is constrained by a public standard: HTTP, which evolves far more slowly than the products that implement it.

There are also a huge number of things that wrap themselves around HTTP, from cache accelerators to 3G content compressors; the standardisation of that thin layer has created a massive ecosystem and driven fantastic innovation, even as many of the core concepts that drove HTTP’s initial design have eroded or softened. For example, HTTP was relentlessly stateless, but we’ve added cookies and cacheing to address issues caused by that (at the time radical) design constraint.

Today, cloud infrastructure is looking for its HTTP. I think that standard already exists in de facto form today at AWS, with EC2, S3 and some of the credential mechanisms being essentially the core primitives of cloud infrastructure management. There is enormous room for innovation in cloud infrastructure *implementations*, even within the constraints of that minimalist API. The hackers and funders and leaders and advocates of OpenStack, and any number of other cloud infrastructure projects both open source and proprietary, would be better off figuring out how to leverage that standardisation than trying to compete with it, simply because no other API is likely to gain the sort of ecosystem we see around AWS today.

It’s true that those API’s would better be defined in a clean, independent forum analogous to the W3C than inside the boiler-room of development at any single cloud provider, but that’s a secondary issue. And over time, it can be engineered to work that way.

More importantly for the moment, those who make an authentic effort to fit into the AWS protocol standard immediately gain access to chunks of the AWS gene pool, effectively gratis. From services like RightScale to tools like ElasticFox, your cloud is going to be more familiar, more effective and more potent if it can ease the barriers to porting from AWS. No two implementations will magically Just Work, but the rough edges and gotchas can get ironed out much more easily if there is a clear standard and reference implementations. So the cost of “porting” will always be lower between clouds that have commonality by design or heritage.

For OpenStack itself, until that standard is codified, I would describe the most successful mission statement as “to be the reference public cloud provider scale implementation of cloud infrastructure compatible with AWS core API’s”. That’s going to give all the public cloud providers who want to compete with Amazon the best result: they’ll be able to compete on service terms, while convincing early adopters that the move to their offering will be relatively painless. All it takes, really, is some humility and the wisdom to recognise the right place to innovate.

There will be many implementations of those core API’s. One or other will be the Apache, the “just start here” option. But it doesn’t matter so much which one that is, frankly. I think OpenStack has the best possible chance to be that, but only if they stick to this crisp mission and don’t allow themselves to be drawn into front-end differentiation for the sake of it. Should that happen, OpenStack will be vulnerable to another open source project which credibly aims to achieve the goals outlined here. Very vulnerable. Witness the ways in which Eucalyptus is rightly pointing out its superior AWS compatibility in comparison with OpenStack.

For the public cloud providers that hope to build on OpenStack, API differentiation is poison in a juicy steak. It looks tasty, but it’s going to cost you the race prematurely. There were lots of technical reasons why alternatives to Windows were *better*, they just failed to become de facto standards. As long as Amazon doesn’t package up AWS as an on-premise solution, it’s possible to establish a de facto standard around something else, but that something else (perhaps OpenStack) needs to be AWS-compatible in some meaningful way to get enough momentum to matter. That means there’s a window of opportunity to get this right, which is not going to stay open indefinitely. Either Amazon, or another open source project, could close that window on OpenStack’s fingers. And that would be a pity, since the community around OpenStack has tons of energy and goodwill. In order to succeed, it will need to channel that energy into innovation on the implementation, not on trying to redefine an existing standard.

Of course, all this would be much easier if there were a real HTTP-like standard defining those API’s. The web had the enormous advantage of being founded by Tim Berners-Lee, in an institution like CERN, with the vision to setup the W3C. In the case of today’s cloud infrastructure, there isn’t the same dynamic or set of motivations. Amazon’s position of vagueness on the AWS API’s is tactically perfect for them right now, and I would expect them to maintain that line while knowing full well there is no real proprietary claim in a public network API, and no real advantage to be had from claiming otherwise. What’s needed is simply to start codifying existing practice as a draft standard in a credible forum of experts, with a roadmap and the prospect of support from multiple vendors. I think that would be relatively easy to arrange, if we could get Rackspace, IBM and HP to sit down and commit to doing it. We already have HP and Rackspace at the OpenStack table, so the signs are encouraging.

A good standard would:

* be pragmatic about the fact that Amazon has already made a bunch of decisions we’ll live with for ever.
* have a commitment from folk like OpenStack and Eucalyptus to aim for compliance
* include a real automated functional test suite that becomes the interop benchmark of choice over time
* be open to participation by Amazon, though that will not likely come for some time
* be well documented and well managed, like HTTP and CSS and HTML
* not be run but the ITU or ISO

I’m quite willing to contribute resources to getting such a standard off the ground. Forget big consortiums or working groups or processes or lobbying forums, what’s needed are a few savvy folk who know AWS, Eucalyptus and OpenStack, together with a very few technical writers. Let me know if you’re interested.

Now, I started out by saying that I was writing to make the case for OpenStack to be focused on a particular area. It’s a bit cheeky for me to write anything of the sort, of course, because OpenStack is a well run project that has an excellent steering group, which recently held a poll of contributors to appoint some new members, none of which was me. I’ve every confidence in the leadership of the project, despite the tremendous pressure they are under to realise the hopes of so many diverse users and companies. I’m optimistic for the potential OpenStack has to accelerate cloud technology, and in Canonical we put a considerable amount of effort into making OpenStack deployment a smooth experience for Ubuntu users and Canonical customers. Ubuntu Cloud Infrastructure depends now on OpenStack. And I have a few old friends who are also leaders in the OpenStack community, so for all those reasons I thought it worth making this perspective public.