Kicking off the second day of the Cloud Native Computing Foundation’s European event in Berlin this week was Alexis Richardson, chair of the foundation’s Technical Oversight Committee - which is charged with formally accepting new technologies into the cloud native fold.
Richardson is also the CEO of Weaveworks, a company that focuses on speeding up deployments in cloud native environments.
Taking to the stage, Richardson gave delegates some insight into what the CNCF hopes to achieve in the future, explaining how it will succeed in encouraging development in these open source projects, enabling interoperability and more choice for users.
For those unaware, a cloud native architecture is defined as one that relies on containers, distributed management and orchestration, and the use of micro-services – all of which are specifically designed for cloud environments. It’s the next level of abstraction up from virtualisation and allows for greater utilisation, lower costs and better portability.
The open source technologies that underpin such an architecture – largely driven by the Kubernetes focused CNCF – are growing hugely in popularity and have seen rapid adoption amongst buyers over the past three years.
However, it is still early days, and as we have seen before with these open source communities, it’s not an easy road to future success. However, Richardson was upbeat and said that the Foundation and cloud native as an architecture should be about focusing on three areas. He said:
What is it really about? It’s about these three things: Speed; Freedom; And trust.
Richardson gave some background for those in attendance, and explained that it was companies like Netflix that really began the cloud native revolution, after they realised that typical application deployments weren’t going to cut it for web-scale apps that consistently focused on customer experience and performance.
He added that this cloud native approach focused on two ideas that hadn’t been tackled before in the technology department.
They wanted to do two things. They wanted to make the consumer experience spectacular. To do that they wanted a system that was always on, always there. They also knew they had to change their product continually, to keep in line with consumer needs.
They knew that when they went to market they would need something that would need additional work, but that it would get better and better, faster and faster than their competitors. This pattern of getting better, faster, is key to cloud native.
Going cloud native
As explained above, cloud native focuses on breaking down applications into smaller components, through the use of orchestration, containers and micro-services. In theory this enables companies to build quickly, iterate faster and to recover at speeds that weren’t previously possible.
Richardson said that ten years ago it wasn’t possible for any company to become cloud native, but said that today - because of the CNCF and the technologies on offer - it’s not out of the question. He cited one survey as the perfect example of why it is important for companies to be considering the shift.
Mean time to recovery - in 2015 the gap between the leaders and the laggards was 168X. That’s the difference between recovering in time to make your consumers happy and spending months planning a website change. And it grew between 2014 and 2015. You really do not want to be a laggard here, because that’s what’s going to lead you to becoming Blockbuster, rather than Netflix.
Richardson used his own company, Weaveworks, as an example of how cloud native can work. He said that his team wanted to work on app development as fast as they could, and that they didn’t want to work on integration, infrastructure and plumbing. They wanted to run the application anywhere, not just Amazon, and for it to be made up of independent components that could be scaled. Equally, recovery time was hugely important. He said:
This is a significant application, it’s not a simple application. What we learnt was is that its really important to know you have a system that you can completely blow up, wipe out totally, and then you can recover from that. We found this out ourselves when we had a massive Amazon outage and had to spend 40 minutes rebuilding everything.
What rescued us was simple things like following the rules of cloud native patterns. Using source code control to recover from. Using Kubernetes to rebuild the system from file. Using tools like Prometheus to monitor it. We do all that, we’ve been doing it for two years. That’s what enabled us to recover from this catastrophic failure.
What were some of the technical needs? Automation is really, really important. Even in large companies, it’s really important to know that if one person is on call, they can potentially start fixing things. Automation means orchestration and pipelines. Continuous integration, as well as scheduling, runtime and so on.
The second thing you need is packaging. You need to package your software so you can deploy it anywhere easily. That means Docker containers for us, containerized deployments.
Then there is a set of modern practices, with patterns like micro-services, monitoring. This distills down to patterns that the CNCF thinks are needed in this new era of modern architectures. Containers, orchestration, micro-services.
The future of CNCF
Richardson explained that the CNCF is hoping to make it easier for companies to go cloud native, by doing due diligence on open source technologies that work and then ensuring that they are interoperable, are aligned and have been validated.
However, he said that it’s important that the cloud vendors don’t lock users into specific projects. He said:
Freedom is about lock-in. Freedom from lock-in. For a long time, open source has kind of been eating software. Meanwhile all this free stuff being taken by cloud providers, wrapped up as services that are not mobile between clouds.
This is kind of frustrating, because if you start building an application that works really well on Azure, you don’t necessarily have the ability to move it to Amazon. You may not want to do that, but knowing that you can is pretty comforting.
So we are worried about cloud lock in. Not at the infrastructure layer, but at the app layer. We want to run our app anywhere. We don’t want to be stuck. So what can we do about lock in? It’s very important that anyone, any company, any developer, anywhere, anytime, can use software on any cloud. Not just a scheduler, but also monitoring, routing and other things. It’s got to be commonly held, it doesn’t help if it is one company holding it, it’s got to be shared, in case that company disappears. This means that you’ve got to have a United Nations Federation concept - everybody can work together, even if they have disagreements about certain issues.
Richardson said that the CNCF also has a policy of “no king makers” - meaning that it doesn’t pick one project believing that that one will be the answer for everyone in 10 years time. Instead it tries to pick multiple projects that are good, which it then encourages, helping to move away from proprietary lock in. He added:
We are looking for interoperability. So already, for example, Docker works with Kubernetes, rkt works with Kubernetes, Prometheus works with all of them. You can see the idea. You can expect these tools to work together even if they’re independent. That’s very powerful.
Finally, Richardson said that it’s early days for CNCF and cloud native as an ecosystem of open source technologies. There are dozens of possible projects out there and the CNCF currently only verifies a handful. There is plenty of room for growth. However, Richardson believes that over the coming years this architecture will be desirable for all. He said:
What does the future look like? Right now it’s coming out of stage one, getting some initial tools together that people genuinely care about, that are great tools that you can be excited about the future of. But then interoperability has to come from use. So there are things like networking interfaces, storage interfaces, being worked on. We need these things.
Through that we will have more and more conformance and coherence, strong alignment up and down the stack over time. You will still be able to pick and choose, it won’t be like OpenStack, where it’s all or none. After that we hope that it will have enough credibility and momentum so that everybody wants to be cloud native.