Weave Gone (Cloud) Native
Today Weaveworks is a founding member of the Cloud Native Computing Foundation (CNCF). In case you wonder why, here is a highly opinionated FAQ, or a “WTF” for the CNCF. Read on to find out what we think this means for Docker, Google,...
Today Weaveworks is a founding member of the Cloud Native Computing Foundation (CNCF).
In case you wonder why, here is a highly opinionated FAQ, or a “WTF” for the CNCF. Read on to find out what we think this means for Docker, Google, and you.
WTF is the CNCF?
Cloud Native represents the future of applications – based on containers and much more efficient and automated than before. The Cloud Native Computing Foundation’s mission is to make this easy. It represents a real breakthrough – a possible “Linux for applications”.
Uniting world class technologies around a mission
There are world class assets coming together in CNCF – from Kubernetes first but also from leading container innovators like Docker, Mesosphere, CoreOS and Weaveworks and Joyent Triton. And from big players like IBM and VMware. All with one mission – to make Cloud Native applications easy.
What does Google say?
From Craig McLuckie’s blog post:
Containers are changing the way that people deploy and manage applications; but we’re in the early days of cloud-native, microservice-based applications. Together with the Linux Foundation and industry partners .. we are creating the Cloud Native Computing Foundation to make container-based computing easier. ….. We are seeding the foundation with Kubernetes…. But Kubernetes is just the beginning….
What does Weaveworks say?
We are joining CNCF as a founder member and contributing code. We could not be more excited about this. CNCF will lead to rapid proliferation of container based applications – good for Weave – which overall extends and enhances our existing commitment to Docker as the leading container platform.
Here’s my quote from the CNCF press release:
With CNCF, container technologies will quickly become ubiquitous in application development, deployment and management. By focusing on the needs of all IT shops and not just an elite, the CNCF will drive rapid developer-led adoption. By enabling standard distributions, the CNCF will remove the need to hire armies of engineers to piece together a mosaic of ever-changing components. And by delivering interoperability, the CNCF simplifies almost any use case from web and data apps to distributed systems.
I’ve included more juicy stuff below. But first – what’s our role?
What are Weaveworks announcing today?
Today we are announcing that:
- we are a founding member of CNCF
- we intend to be a major contributor of code, people, and support.
- we have already submitted a contribution proposal to the CNCF
Does Weaveworks have commercial CNCF plans?
On a future date we will provide commercial support for certain CNCF projects and make concrete interoperability commitments for other CNCF projects. We shall also make public our specific plans around open source collaboration for Weave, Docker, and the Linux Foundation projects involving containers.
How does Weave fit in with other CNCF projects?
Weave is a cloud native fabric, not a platform – and therefore fits really well with the CNCF mission. We see a world where applications use Weave+Docker, Weave+Kubernetes+Docker, Weave+Mesos+CoreOS, and many other combinations.
Weave already works well with Kubernetes – we were the first to create a reliable installation on Azure for example. Weave is already being widely used to provide networking with Mesos and Marathon. Obviously we work well with CoreOS and everyone else because using Weave is magically simple.
What’s in this for Google?
As I see it: Google wants to build a cloud business that can beat Amazon – managing the world’s applications (and information). And the plan is to win the enterprise market before Amazon by doing two things:
- Minimise the gap between enterprise data centres and cloud, by investing in technology that makes modern portable applications much easier – Kubernetes.
- Capture the mindshare of the world’s leading developers, and build a broader Linux for applications – using technologies like Docker, CoreOS, Weave, Mesos – all of which can seamlessly move and scale across clouds and data centers.
Kubernetes has a tantalising value proposition – that enterprises can run software applications with the same speed and efficiency as Google itself. But it has needed broader participation from the container ecosystem in order to be seen as fully trusted and ‘not under Google’s control’. To that end, Google is now aligning innovators like Mesosphere, CoreOS and Weaveworks, with heavyweights like IBM, eBay and Goldman Sachs. And a few weeks ago Google teamed with Docker through the Linux Open Container Project. Finally, last week Google joined OpenStack to further bridge into enterprise data centres.
The prize is clear – to be known and trusted as the best place to deploy the applications of the future.
Why didn’t Google just contribute Kubernetes to Apache and let people have at it?
Cloud Native is about unifying a new generation of tools under a single brand.
The industry will undergo accelerated change if end users and vendors can rally around a simple concept. In the 1990s that concept was “The Web” – remember when every business realised it needed a web site? More recently, “The Cloud” and “Big Data” have played a similar role for changes in on demand compute and data analysis respectively. And so Cloud Native is a way to describe a revolution in which businesses make applications central.
Under a single brand, it is still possible to address largest possible set of use cases. The beauty of CNCF is that it isn’t defining a black box like a typical PaaS – but a much more open platform on which everyone can get involved with.
What will the CNCF deliver?
I see the central mission of the CNCF as being – to lead the industry to an ubiquitous and completely standard suite of tools for Cloud Native applications.
The first set of deliverables is the suite of tools. These absolutely must work very well with Docker containers, and be as simple to get started with. All the tools must be completely portable. We see Weave playing a strong role here as it has those characteristics. We are very committed to open source community and collaboration to move things forward.
The second set of deliverables is all about making it cheap, fast, and safe for companies to create applications using these tools.
- For example at Weaveworks most of our Getting Started Guides have examples showing how easy it is to build applications using Weave; and are working on value added services for monitoring and management, taking advantage of insight into the network.
- We also anticipate companies that bundle the CNCF suite into “stacks” that have a single install and enable applications to be run on them. These are the “platforms”.
How does governance work?
Short answer is that it will be quite lean, given the strong bias that way from the main open source leaders. We expect CNCF to follow the best principles of open source: running code matters more than corporate standards committees and bureaucracy. It won’t be possible to purchase influence with money. What matters is the ability to contribute through code and action. This is why the Linux Foundation is a good home, with simple and open governance that we can all build on.
An important aside: the Foundations that try to write code fail to write good code. The ones that let coherent teams write code and then organise contributions well, can succeed.
How do I spell Kubernetes?
You will be able to use CNCF projects without using Kubernetes. It is not a one size fits all solution. It has grown very fast, but there is some distance yet to travel before it can join the ranks of the most used open source projects of the past.
WTF is Cloud Native?
So you already like Docker – what’s this Cloud Native thing all about?
Why is Cloud Native important for application developers?
Cloud Native ultimately means making your application flexible enough to change at the same speed as your customers’ needs. That may mean: “all the time”. Continuous change requires automated operations for deployment, migration and elastic scale.
How do you do this?
- Container technology is used to make sure that the software runs the same – whether in the cloud, or on your own private enterprise servers. It also simplifies and accelerates adoption for new technology.
- Uncoupling into independent components – in modern architectures this separation may be achieved via containerised microservices.
- Modern higher level abstractions. E.g. software defined networks lead to programmatic management. When combined with dynamic schedulers these can deliver scalable automation to reduce operational overheads.
Taken together we see this as a container fabric that supports applications and rich platforms. This is good news for Weave.
Why is Cloud Native important for end users?
Cloud Native is for companies that understand the significant competitive advantage that software applications can provide. If you want your business to compete with the best products coming out of Silicon Valley, and not be disrupted, then you absolutely have to care about Cloud Native. Stories like Netflix vs Blockbuster and AOL show how important it is to adapt – or die.
Cloud Native provides a single unifying brand for a set of best of breed technologies. It removes the risk of betting your business on piecing together your own mosaic of ever-changing components. It enables you to embrace Silicon Valley code without facing Silicon Valley disruption.
I did a keynote talk about Cloud Native from a user point of view at a recent event – video here.
Why is Cloud Native important for the ecosystem?
Cloud Native provides an open framework for the ecosystem to participate in, adding value in whatever ways can be imagined.
- Software application “platforms” that combine orchestration and/or developer workflow to accelerate production of Cloud Native applications. For example CoreOS.
- Infrastructure, monitoring and management tools. For example Weaveworks.
What about Docker?
Docker are part of the CNCF – what’s in it for them? A better way to reach more users because CNCF+Docker means more portable applications.
Is CNCF different from the Open Container Project?
Where the OCP delivers open containers, CNCF delivers a broader set of standard tools that can work with containers. CNCF delivers an open fabric: production-ready code for cloud-scale infrastructure. Like OCP though, CNCF will focus on running code and not on standards “committees”. In summary – I think they are very well aligned and could possibly be a single project at some future point.
Wondering what OCP is? ICYMI — Docker recently shifted its stance towards containers.
Docker now shares development of the core container technology via the Open Container Project (OCP) that Docker launched at DockerCon last month. OCP is a parallel organisation to CNCF, with similar industry support and that the CNCF will 100% interoperate with. The OCP governs a standard container format called runc, which was formerly Docker’s libcontainer project, as a container spec and reference implementation. UPDATE: the OCP is being renamed the Open Container Initiative – OCI.
How does CNCF accelerate Docker?
Docker can gain the most from Cloud Native. CNCF represents an industry shift to containers as the standard basis for applications. Since Docker is by some margin the leading container, the majority of Cloud Native applications will use Docker. If you believe, as I do, that most applications will ultimately be built in this way, that looks like a huge win for Docker.
But, which Docker will these applications use? The platform or the container runtime?
The CNCF and OCP together form a common set of tools across ALL container-based products that will matter in the next stage of the industry. For example Kubernetes will work with Docker and runc. And for example the CNCF software defined network should work with runc (and therefore with Docker and anything else using runc).
For customers and for Weaveworks, this provides a stable fabric for all Cloud Native apps – something we can bet the business on. And any platform built on this fabric should be able to use Weave. All this will help Docker too.
How could CNCF make life more challenging for Docker?
CNCF will lead to platforms that compete with Docker’s platform. Some of these will be based on Kubernetes, but that really isn’t the main point.
We already talked about Linux. But perhaps the analogy here is Apple iOS vs Android. Two huge platforms with totally different models.
In my view, Docker is becoming an opinionated platform quite a lot like Apple iOS. This means a place to run apps using the Docker user experience from beginning to end. Weaveworks recently collaborated with Docker in developing a way to “plug in” Weave as an extension to this platform.
The way that these plugins currently work is like Apple iOS – they have narrowly constrained APIs and ways of behaving. This is intended to preserve consistency by stopping two plugins from getting into conflict with one another. This makes it easier to promise that all Docker apps will run on the Docker platform plus extensions.
The CNCF will certainly support the Apple approach for platforms that want it. But it will also be possible to be an “Android” style platform. These platforms will compete with the Docker platform and may prevent it from becoming 100% universal.
Unlike Apple iOS, in Android a phone manufacturer can add extensions very freely. This leads to a much wider set of possible types of phone, but it is harder to make promises that conflicts between plugins will not occur and will not impact apps. Speaking as an Android phone owner myself, I haven’t found this to be a big problem.
I am sure Docker will work out ways to do well out of this, however the platforms evolve, and we wish them every success in that – their success helps us too.
And all the other “Linux of the Cloud” projects?
Isn’t CNCF just a silly hipster thing?
No, this is the world leaders in the industry coming together with some of the biggest enterprise and cloud providers – and end users.
How is CNCF different from Cloud Foundry?
Cloud Native is not a new concept or term, having been first defined by Paul Fremantle in 2010. One project that has laid claim to this territory is Cloud Foundry. How is the CNCF different from the Cloud Foundry Foundation? I think one key difference is the breadth of contributors and who they are. But that is quite subjective – there are also some important technical considerations.
First, Cloud Foundry is a PaaS – the kind of thing that you might build on top of Kubernetes, Docker, Weave and other CNCF/OCP software. In this sense it competes with technologies like OpenShift and Deis and Flynn, all of which have traction in their core markets. Cloud Foundry could benefit from using CNCF technologies, to enable stronger focus on its core value to end users.
Second, Cloud Foundry is that it integrates, packages and therefore controls the entire stack so that you don’t have to. A prepackaged stack may be valuable to some, but can create a perception of a “one size fits all” or “black box PaaS”. This leads customers to ask, eg.: what happens if you want to change it, or integrate something new?
CNCF is not a PaaS and does not offer one packaged way to create applications. It is an attempt to open up the platform space to whatever can be imagined. It feels, and in my view clearly is, much less limited. But the market has much room to develop, and Cloud Foundry is clearly moving in this direction too.
How does CNCF help OpenStack?
Google joined OpenStack recently. The idea is to make Kubernetes run well on OpenStack. To the extent that enterprises depend on OpenStack it makes a lot of sense for CNCF technologies to run well on it. This should be very straightforward, and help the missions of both projects.
How is CNCF different from OpenStack?
CNCF has an ambitious and world-changing scope. OpenStack began that way too, and now has some well documented problems. CNCF can avoid these problems by following simple “Unix style” principles:
- Standalone projects – Apache does this very well. Every project must be both useful and usable on its own, with an independent bootstrap
- Easy interoperability between projects – wherever possible.
- Avoid premature integration of projects into a single “stack” – this slows progress
- Projects must be “unopinionated”; this means “not like a PaaS” and not presupposing or implying a specific application architecture such as “web app” or “big data app”
- Don’t invent random stuff – e.g. Use known APIs wherever possible
Plus obviously – keep governance lean, fast and flat. I spoke about this in my Docker OCP blog post.
The war of the platforms – brutal but healthy
Currently most platforms are custom-built by big web companies and some technology hungry enterprises. With CNCF this will shift quickly to being vendors and cloud providers. Customers should think carefully about not getting locked into one vendor here.
The great thing about CNCF+OCP is that by focussing on the common fabric, there is no “one size fits all” where you are at risk of lock in. Yet, it leaves space for vendors to add value via their own stacks – like there are many mobile handsets you can buy, and they can all run apps.
Because the cloud native apps business will be lucrative too, a large number of companies will try to “own the platform” and win it. This includes Docker, with their Apple style approach. And it includes all Kubernetes-based platform vendors, and probably many others. Everyone will be promoting developer friendly components plus commercial “enterprise” bundles.
There is going to be a “war of the platforms” here, with many touting themselves as the one true vendor that CEOs can safely bet the company on. This could get pretty brutal. But there will certainly be safe ways forward and Weave will be one of them 🙂
And so the final phase will see “Cloud Native” become a platform in its own right – probably with Kubernetes and Docker at the core – and a wider ecosystem of applications, cloud services and companies that provide offerings that are based on the platform.
