 Hello, can you all hear me? Can you all see? Is that Finton in the back? Yes, good. What is cloud native and why should I care? I apologize if you've seen this before and you may see a slightly different version of it on Thursday. So what I wanted to do today was make the session just a little bit more interactive and Diane, if you think I need to slow down and focus on just one bit, just please let me know to do that. My job is the CEO of Weaveworks, a company that I hope you've heard of. Please try our product, WeaveCloud. It works with OpenShift. I also am the TOC chairperson for the Cloud Native Computing Foundation, which is an interesting job right now because it's a new foundation doing very, very exciting and amazing things. It's building a toolkit for the next generation of applications or cloud native apps, as we like to call them. Talk a bit about what that means today. Projects like Kubernetes, Prometheus, GRPC are part of this foundation, which is why it's so important. These are the tools that you should use if you want to do cloud native. So just a few standard bits about it, just so that we all know what we're talking about, the same thing. It's a non-profit organization and it's part of the Linux Foundation. The Linux Foundation today is a much bigger beast than when it was founded. It was originally set up to look after Linux, an important thing to do, so important that now Microsoft has joined the Linux Foundation, I think, not too many months ago. It's organized into different sub foundations, each of which focuses on a particular area of functionality. There's another one for blockchain, for example. This one's all about bringing together the tool set for cloud native and promoting it and educating people about how to use it and helping customers and users in that area and developers. As of today, we have seven projects in the cloud native foundation. Here they are. You might recognize some of these. Who here has heard of Kubernetes? Who here has not heard of Kubernetes? There you go. Thank you. You may not know all of the projects. Fluent D is a logging system for log forwarding. Core DNS was originally Sky DNS. It's factoring to work in a number of broader use cases, and it's a standalone modern DNS server. The author wrote 8888, so he knows what he's doing. GRPC is the replacement transport for things like REST and JSON when you're doing my performance cloud native-style scalable architectures originally developed at Google. LinkerD is an iteration for Naegle originally developed at Twitter. It's a tool for more RPC in the case where you need to have a web-facing proxy, and you need to scale that. As you know, Twitter has all kinds of scalability issues. Little Tweety birds holding up whales and things like that. So LinkerD was born out of that need. Open tracing is a toolkit for building tracing libraries in a standard manner because people believe, or we believe in the TOC, that you all want to trace everything pretty soon. So we need a way of helping you to do that. Prometheus, born in Berlin, three chairs for Prometheus, who has not heard of Prometheus? Good. It's a monitoring, alerting, and analytics tool. And there are sponsor members, companies that you've probably heard of. I don't know why Weaveworks is not on here, but it should be. So let's just go on. Okay. It's important to see CloudNative as part of a longer progression of a series of changes in computing. Going right back to when I first got involved in the industry around the year 2000, when it was all about hardware and selling tin, and salespeople selling tin. And now, we've gone through all these different iterations of technology. Who remembers when Heroku appeared in 2008? Okay. They invented a bunch of the stuff that people take for granted today. But the original problem Heroku was trying to solve was Ruby is really great to develop with, but it's a nightmare operationally, and I'm trying to use the cloud. So how do I do that? And they realized that you could automate a bunch of things and give developers a developer-friendly API for operations. And there began this new era of CloudNative from Heroku. There's other sources too that I'll mention. OpenStack is a thing. OpenShift is a thing, apparently. What is OpenShift? OpenShift and actually Cloud Foundry are the iterations from Heroku, showing you the evolutionary path here. Not identical, but in slightly different directions. And then you have containers where you have a company docker, or dockcloud, as it was called, that said, we want to make a pass too. Now, you may be wondering why would somebody make another pass when you've got Heroku and OpenShift and Cloud Foundry. But in those days, it just wasn't obvious which model was correct. And they found they couldn't make that work as a business. But along the side, they'd taken LXC, the container model from Linux, which had become really good by then, and made it into something that they could use for their daily 24-7 deployments of dockcloud as DevOps people. And they thought, wow, what if we just use this? And maybe other people would like to use it, and they decided to talk about it at a conference, and then suddenly everyone went crazy. Here we all are. And then Cloud Native, the Foundation and Kubernetes, and many of the other projects. Now, the projects I've spoken about should also work with OpenShift and containers as it's not directly tied only to Kubernetes. So, in summary, the Cloud Native Computing Foundation is open-source cloud computing for applications, Cloud Native applications, which we believe are what businesses, startups, developers, enterprises want to build in the future in the same way that people in the 1990s got excited about building websites. The key difference, of course, is these are not just static HTML pages. These are richly interactive ways of dealing with potentially multi-million global customer base. And it matters to businesses because they know they need to build these in order to stay ahead of the market. And I'll talk a bit about that. And in the CNCF we are curating and promoting a trusted toolkit for these applications and architectures. So I mentioned Heroku. Another key antecedent is Netflix. Netflix decided they were going to deliver DVDs by post, originally, I believe. And at some point they thought, this Amazon 1999 business model isn't working out too well. We're not very different from a blockbuster at the end of the day. And people always forget to send their DVDs back. And somebody said, well, could we deliver it over the web and get rid of the postage and waiting for things to come back and the plastic CDs and everything else? And they tried it out on the web by then just about as good enough to do this. And they thought, OK, we can send a movie or a TV show over the internet to some people. What if we wanted to do this anywhere in the world at any time and make sure that people could have pretty much guaranteed that when they click the button play, the film will actually show and they will be entertained. Not flickery or you need to install some more software or it pauses as a little wibbly pie chart and things like that. So they wrote the technology team that was tasked with meeting this obvious and simple business requirement. And they wrote down these criteria, which they subsequently talked about. These slides are actually from a much later Amazon Web Services re-invent conference and there's a link there. I recommend you look at them. There's many slides of Netflix on the subject. But the requirements were a web scale, global, highly available consumer facing and they called it, ha, just for short, let's call it cloud native. And cloud native for Netflix was a very practical and important business consideration. There customers had this kind of, what the CEO calls the moment of truth, which basically is a kind of Harvard business person's way of saying, a family sits down on the sofa and are they going to read a fulfilling educational book or talk to each other and build a relationship among themselves or are they going to turn on the TV. And of course Netflix want to win that war. They want you to turn on the TV because it's instantly pleasing. And so to do that, we had to move what they called the curve, which was a ratio of rate of change to the system and availability to end users. Now these are, you know, non-functional properties of an environment that are very important. For Netflix they were business critical. The lowest certain level of availability they couldn't meet that promise to customers. People would not flick on Netflix if they thought it would be unavailable for more than 1,000 of the time. At the same time, the Netflix team realised that in order to give customers what they wanted they were going to have to make a lot of changes to the system very, very frequently, because they didn't really know exactly what customers wanted when they started. They figured that the easier thing to do would be to give them something and listen to what they had to say and then change it very, very quickly. Now this might sound blindingly obvious to you now in 2017, but when they did this in 2009, it was not obvious at all. There were among just a few companies, companies like Facebook and Google and others as well, who really had adopted this idea that you might make several hundred changes a day to your systems in order to make people happy. Whereas previously people had been making changes to their websites once every six months after a lot of meetings. So they wanted to do both of these things at once which is a really difficult thing to do. Do read these slides. And then this worked because everybody wanted to be like this. They wanted to have these rich, instant customer experiences on any device, anywhere in the world and suddenly you have people like this man who you may have seen. I hope you know who this person is. He's a fat American capitalist who invests in startups, Mark Andreason. He also found a Netscape long ago and has been a sort of entrepreneurial hero of Silicon Valley. But he kind of represents this idea that he coined this phrase, software is eating the world. He could only be said after not only Netflix but many other companies had appeared in different areas, not only films but also taxis, hotels, travel, etc. Where suddenly there were new web powered businesses that also worked on your phone and consumers got really excited about because they were so easy to use and they always did that because they could be on anywhere and they could be iterated on very quickly. And then of course people thought we can be on Netflix too. And the answer is we may laugh because we all want to be the unicorn but many of us will end up dreaming in the fields like this fellow on the left. But the reality is that companies that do not create online experiences for their customers just in traditional businesses will struggle to keep up today with companies that do. Unless you're in artisanal bread making and painted coffee mugs or wax pistachios or any of the things that happen in my area of Shoreditch in London you really are having to deal with the largest number of customers which means interacting over the web in a certain way. You can actually measure it. This chart is from a report a couple of years ago Puppet Lab State of DevOps a report I highly recommend reading every year when it comes out of the difference for key metrics between what they call high and low performers which are defined to be people in a certain percentile of the normal distribution and here's an example meantime to recovery in 2015 top performers were 168 times faster than low performers. So think about what that means for availability that's the difference between seconds and minutes and minutes and hours it's huge and it grew between 2014 and 2015 you may not be able to read at the back but on the right it says 48 times in 2014 it went up to 168 times in 2015 so it's getting worse not better for the majority of people so this is need for speed and it's measurable and it's relating to these technologies so what is it about cloud native that helps me go fast so we decided to conduct an experiment on our own company which is the correct place to conduct experiments if you're a startup and build our product in this way so our product I mentioned we're simplified about delivery for cloud native apps with a number of features like monitoring and continuous deployment and here's an old picture of our architecture and you don't need to read all the details the point is it's somewhat complex because it's providing multiple different services to end users through a web screen there's core services, there's visualization data storage and monitoring and management of the thing itself and it's not a 12 factor app who here knows what a 12 factor app is? most of you, great so often people talk about 12 factor apps being cloud native 12 factor is an abstraction of the ideas pioneered by Heroku and followed up on by Cloud Foundry and OpenShift it's essentially taking the best way to build web apps in a 24x7 DevOps environment and incarnating them in practices and in software but this is more complicated than that kind of application so the question becomes how do you enable all of the world's applications to be up all the time and available anywhere and all these things and this is meaningful, you can measure this if you look at the adoption of Amazon it's been wildly successful on some super growth double hockey stick chart and something like Heroku has also been very successful but much more slowly than Amazon which shows you that these 12 factor apps up until now have had a somewhat limited appeal relative to the broader use of the cloud so cloud native in parts aims to broaden the appeal of these more functional frameworks to a larger class of applications and this is kind of a reconfiguration of the Netflix needs but it's worth mentioning at Weaveworks we have the same kinds of needs we want to be up all the time we don't want to write infrastructure we want our app developers our app development have not become experts in reliable storage we also have a business that has multiple parts and they're not used at the same amount by the same people at the same time so we needed to scale components independently now the equivalent over Netflix would be some movies are more popular than others so you need to be able to keep your costs down in parts of your system that are not being used and be able to scale up in parts of your system that are being used and be able to move independently we didn't want to spend lots of money integrating infrastructure either so we used Kubernetes and Prometheus to power our app in fact we've been running Kubernetes in production on Amazon for nearly two years now on multiple zones it's pretty cool but we didn't want to do all the work that we wanted to come out of the open source community there we do also contribute and finally we wanted to be open source not Amazon source now we love Amazon and we're very happy to run on Amazon but we don't want to feel like we're stuck there we want to know that if we have customers who need to be on Google Cloud or need to be on IBM Bluemix or need to be on their own machines that we can do that which means that not only must the infrastructure be portable but all the services around it have to be portable too and they're just not today they're a bit missing so where are those portable multi-cloud open services going to come from somebody's got to bring them together so to summarise our technical needs they're basically automation which leads you down the path of orchestration today orchestrating containers and scheduling them to make apps and CICD which is the automation of deployment abstracting the infrastructure from the app by standard packaging hence containers turn out to be a solution to that problem and cloud-native patterns different patterns for different parts of the app how do you monitor, how do you log how do you stay available, how do you do alerts how do you fix things when they go wrong what is a microservice anyway that kind of stuff a whole collection of these things and so this was really the distillation of our technical needs and it turns out these are exactly the things the cloud-native foundation aims to bring together too so I say that cloud-native you can be described as a set of patterns for using containers automation and microservices and Adrian Cockroft who's spoken an awful lot about this stuff I highly recommend you check out his presentations he's now employed by Amazon so okay if cloud-native is these patterns then we need open source tools to be able to implement them we need to know how to use them they need to come from somewhere somebody needs to look after them they need to move at the pace of modern software and they mustn't lock us in so going back to the list I showed you at the beginning here are some of these tools we now have 7 tools in CNCF I've described them already but I'll just run through them for the people at the back Kubernetes for container orchestration Prometheus for monitoring and analysis Fluent D for log forwarding Open Tracing for introcable tracing Linker D for traffic management and proxies and I wrote on a slightly old slide GRPC and Core DNS are now in the CNCF which are respectively a transport and a DNF and there's more to come in fact there may be more to come this week fingers crossed so it's a layered stack in the CNCF we're focused on the top few layers the runtime orchestration app development we don't build clouds that's OpenStack's job we're very interested in automated pipelines so not only having opinions about what tools to use and how to layer them but also how to deploy them here's an example that we use at Weaveworks it's what I call the ABCD of automation develop using your favorite framework build using your favorite CI system make some containers put them in an imagery pro there's Rocket and Docker container D on the right and deploy them using a deployment tool and run them on your favorite execution environment I made a mistake of putting Kubernetes here but I of course should have had OpenShift in there as well okay just to pause anyone got any questions violent objections desire that I took less or anything like that okay where does OpenShift fit in I described OpenShift earlier as a PAS I know that it now is also Enterprise Kubernetes so it's a bit broader than that there's two kinds of PAS a platform as a service something where you structure everything into one big black box which is really Heroku to run where you like and that's kind of the clown foundry model and plugable PAS which I think OpenShift is striving to get closer to where you get some out of the box functionality but there's more elements of plugability and build it yourself you probably won't be able to read this picture I apologize but it is available on GitHub this is what we call the clown native landscape and the point about this picture is to show you the potential scope and importance and scale of the space so I mentioned we have a layering this is mapped onto here with infrastructure provisioning runtime orchestration and management an app definition and development at the top and the app dev space is richly it's full of wonderful things it's a core new copier of software covering all possible things you can think of languages and frameworks, databases streaming, source code management app dev, registry services, CICD and API servers and the CNCF doesn't aspire to provide you with all of those things but they are there to show you what could be run on top of the right stack we are very focused on the middle layers orchestration and management and the runtime maybe a bit of the provisioning and then also how you monitor and manage all this stuff we've got platforms for management observability and analytics on the right and the tools that I mentioned are all shown here somewhere and this also maps out some of the things that we might want to see in the foundation in the future so I've mentioned the word foundation a lot why do we need a foundation what is it, is it a benevolent technocracy is it like Star Trek is it some kind of karmic Buddhist thing what it's really about is everybody working together yes and dancing together here's the Linux foundation here's the Linux for the long term this is really good for customers because they understand the brand they know it's open source it's a way to collaborate in a trusted manner as we discussed in the panel this morning and it brings them together under one umbrella to do that so last few points coming up this gives you a way to have common open source not single vendor open source but open source that is truly shared and trusted by everybody from end users to vendors, SI's and cloud providers a lot and this is important because I mentioned software is eating the world open source is eating software and cloud is now eating open source so we need a defence against that so the commons provides us a way out of the lock in puzzle created by the huge growth of cloud and its consumption of everything which is of course terrifying if like me you are a small furry animal inside so what steps are we taking to help deal with that we curate open source in a way that everybody can use people like docker, google, IBM, ebay and gullwyn can all play nicely together this is amazingly new and we look for high quality this is the job of the TOC is identify high quality projects and the rules that go with those we don't pick winners we just pick quality and speed we help end users by providing them with education and events like this one upstairs tomorrow and guidance what does it mean to be cloud native a badge of trust and interoperability can we make sure that Kubernetes does work with Prometheus and FluentD we can help to do that all under one big brand trusted commons and then of course we have to help the projects and if you're a developer who's involved in one of these things this is incredibly important to us so we're project first ultimately we believe that good projects get good users make them happy and that makes the project successful and it's a virtuous cycle that we want to support so just to wrap this is something that happened late last year Samson, Gregor Bob Wise really great bloke said I call upon the CNCF to foster a common community container implementation that can be used by Kubernetes, Mesos and Cloud Foundry back by them it's transparent to become the default container implementation for a wide number of open source orchestration systems and he called it an ode to boring infrastructure should be boring and since that time both container D from Docker and RKT from CoreOS have been proposed as container implementations and they are being voted on right now so who knows maybe they will be in the CNCF sometime quite soon so that will be another big step forward for giving you a trusted safe toolkit for cloud applications do we do standards? it's not about standards it's about giving people tools they can trust so here's how we see it evolving right now we're still at the stage of new projects coming in and getting faster and faster Kubernetes is one of the most outstanding successful projects in the market today Docker is also amazing then we're building a cloud native story around that which this presentation is part of that process and finally we hope that as time goes by people will see this as completely standard technology you can use the same way as websites are now what a de facto standard for everybody so to finish up cloud native foundation is open source cloud computing for applications and the job of the foundation is to curate and promote a trusted toolkit for modern architectures thank you very much