>> Hello, everyone. I'm Khalil Ahmad, Senior Director, Architecture at S&P Global. I have been working with S&P Global for six years now. Previously, I worked for Citigroup and Prudential. Overall, I have been part of IT industry for 30 years, and most of my professional career has been within financial sector in New York City metro area. I live in New Jersey with my wife and son, Daniel Khalil. I have a Master degree in software engineering from the University of Scranton, and Master in mathematics University of Punjab, Lahore. And currently I am pursuing TRIUM global Executive MBA. A joint program from the NYU Stern, LSE and HEC Paris. So today, I'm going to talk about building multi-cluster scalable container platform, supporting on-prem hybrid and multicloud use cases, how we leverage that with an S&P Global and what was our best story. As far as the agenda is concerned, I will go over, quickly the problem statement. Then I will mention the work of our core requirements, how we get solutioning, how Docker Enterprise helped us. And at the end, I will go over the pilot deployment for a proof of concept which we leverage. So, as far as the problem statement is concerned. Containers, as you all know, in the enterprise are becoming mainstream but expertise remains limited and challenges are mounting as containers enter production. Some companies are building skills internally and someone looking for partners that can help catalyze success, and choosing more integrated solutions that accelerate deployments and simplify the container environment. To overcome the challenges, we at S&P Global started our journey a few years back, taking advantage of both options. So, first of all, we met with all the stakeholder, application team, Product Manager and we define our core requirements. What we want out of this container platform, which supports multicloud and hybrid supporting on-prem as well. So, as you see my core requirements, we decided that we need first of all a roadmap or container strategy, providing guidelines on standards and specification. Secondly, with an S&P Global, we decided to introduce Platform as a Service approach, where we bring the container platform and provide that as a service internally to our all application team and all the Product Managers. Hosting multiple application on-prem as well as in multicloud. Third requirement was that we need Linux and Windows container support. In addition to that, we would also require hosted secure image registry with role based access control and image security scanning. In addition to that, we also started DevOps journey, so we want to have a full support of CI/CD pipeline. Whatever the solution we recommend from the architecture group, it should be easily integrated to the developer workstation. And developer workstation could be Windows, Mac or Linux. Orchestration, performance and control were few other parameter which we'll want to keep in mind. And the most important, dynamic scaling of container clusters. That was something we were also want to achieve, when we introduce this Platform as a Service. So, as far as the standard specification are concerned, we turn to the Open Container Initiative, the OCI. OCI was established in June 2015 by Docker and other leaders in the technology industry. And OCI operates under Linux Foundation, and currently contains two specification, runtime specification and image specification. So, at that time, it was a no brainer, other than to just stick with OCI. So, we are following the industry standard and specifications. Now the next step was, okay, the container platform. But what would be our runtime engine? What would be orchestration? And how we support, in our on-prem as well as in the multicloud infrastructure? So, when it comes to runtime engine, we decided to go with the Docker. Which is by default, runtime engine and Kubernetes. And if I may mention, DataDog in one of their public report, they say Docker is probably the most talked about infrastructure technology for the past few years. So, sticking to Docker runtime engine was another win-win game and we saw in future not bringing any challenge or issues. When it comes to orchestration. We prefer Kubernetes but that time there was a challenge, Kubernetes did not support Windows container. So, we wanted something which worked with a Linux container, and also has the ability or to orchestrate Windows containers. So, even though long term we want to stick to Kubernetes, but we also wanted to have a Docker swarm. When it comes to on-prem and multicloud, technically you could only support as of now, technology may change in future, but as of now, you can only support if you bring your own orchestration too. So, in our case, if we have control over orchestration control and not locked in with one cloud provider, that was the ideal situation. So, with all that, research, R&D and finding, we found Docker Enterprise. Which is securely built, share and run modern applications anywhere. So, when we come across Docker Enterprise, we were pleased to see that it meets our most of the core requirements. Whether it is coming on the developer machine, to integrating their workstation, building the application. Whether it comes to sharing those application, in a secure way and collaborating with our pipeline. And the lastly, when it comes to the running. If we run in hybrid or multicloud or edge, in Kubernetes, Docker Enterprise have the support all the way. So, three area one I just call up all the Docker Enterprise, choice, flexibility and security. I'm sure there's a lot more features in Docker Enterprise as a suite. But, when we looked at these three words very quickly, simplified hybrid orchestration. Define application centric policies and boundaries. Once you define, you're all set. Then you just maintain those policies. Manage diverse application across mixed infrastructure, with secure segmentation. Then it comes to secure software supply chain. Provenance across the entire lifecycle of apps and infrastructure through enforceable policy. Consistently manage all apps and infrastructure. And lastly, when it comes to infrastructure independence. It was easily forever lift and shift, because same time, our cloud journey was in the flight. We were moving from on-prem to the cloud. So, support for lift and shift application was one of our wishlist. And Docker Enterprise did not disappoint us. It also supported both traditional and micro services apps on any infrastructure. So, here we are, Docker Enterprise. Why Docker Enterprise? Some of the items in previous slides I mentioned. But in addition to those industry-leading platform, simplifying the IT operations, for running modern application at scale, anywhere. Docker Enterprise also has developer tools. So, the integration, as I mentioned earlier was smooth. In addition to all these tools, the main two components, the Universal Control Plane and the Docker Trusted Registry, solve lot of our problems. When it comes to the orchestration, we have our own Universal Control Plane. Which under the hood, manages Kubernetes and Docker swarm both clusters. So, guess what? We have a Windows support, through Docker swarm and we have a Linux support through Kubernetes. Now that paradigm has changed, as of today, Kubernetes support Windows container. So, guess what? We are well after the UCP, because we have our own orchestration tool, and we start managing Kubernetes cluster in Linux and introduce now, Windows as well. Then comes to the Docker Trusted Registry. Integrated Security and role based access control, made a very smooth transition from our RT storage to DTR. In addition to that, binary level scanning was another good feature from the security point of view. So that, these all options and our R&D landed the Docker Enterprise is the way to go. And if we go over the Docker Enterprise, we can spin up multiple clusters on-prem and in the cloud. And we have a one centralized location to manage those clusters. >> Khalil: So, with all that, now let's talk about how what was our pilot deployment, for proof of concept. In this diagram, you can see we, on the left side is our on-prem Data Center, on the right side is AWS, US East Coast. We picked up one region three zones. And on-prem, we picked up our Data Center, one of the Data Center in the United States of America, and we started the POC. So, our Universal Control Plane had a five nodes cluster. Docker Trusted Registry, also has a five node cluster. And the both, but in our on-prem Data Center. When it comes to the worker nodes, we have started with 18 node cluster, on the Linux side and the four node cluster on the Windows side. Because the major footprint which we have was on the Linux side, and the Windows use cases were pretty small. Also, this is just a proof of concept. And in AWS, we mimic the same web worker nodes, virtual to what we have on-prem. We have a 13 nodes cluster on Linux. And we started with four node cluster of Windows container. And having the direct connect from our Data Center to AWS, which was previously existing, so we did not have any connectivity or latency issue. Now, if you see in this diagram, you have a centralized, Universal Control Plane and your trusted registry. And we were able to spin up a cluster, on-prem as well as in the cloud. And we made this happen, end to end in record time. So later, when we deploy this in production, we also added another cloud provider. So, what you see the box on the right side, we just duplicate test that box in another cloud platform. So, now other orchestration tool, managing on-prem and multicloud clusters. Now, in your use case, you may find this little, you know, more in favor of on-prem. But that fit in our use case. Later, we did have expanded the cluster of Universal Control Plane and DTR in the cloud as well. And the clusters have gone and hundreds and thousands of worker nodes span over two cloud providers, third being discussed. And this solution has been working so far, very good. We did not see any downtime, not a single instance. And we were able to provide multicloud platform, container Platform as a Service for our S&P Global. Thank you for your time. If any questions, I have put my LinkedIn and Twitter account holder, you're welcome to ask any question

(electronic music) >> Announcer: From Boston, Massachusetts, it's theCUBE, covering Cloud Foundry Summit 2018. Brought to you by the Cloud Foundry Foundation. >> Welcome back, I'm Stu Miniman, and this is theCUBE's coverage of Cloud Foundry Summit 2018, here in Boston. Happy to welcome back to the program, Chen Goldberg, who's the Engineering Director at Google. Chen, thanks for joining me. >> Thank you, it's always a pleasure. >> So Chen, what are the big questions coming in? We talked to you at the KubeCon Show before. You know, Kubernetes, you know, Cloud Foundry, containers, serverless, all these things mashing up. You've been here at the show for about a day, what have you learned so far? How do all these kind of fit together in your mind? >> So actually, it was great being here for the last day, 24 hours so far, and just seeing how Cloud Foundry Community is really opening and welcoming influence from other communities in the cloud native space. And we see it in different ways. We see work that is being done on building some open standards, for example, and so working with the Cloud Foundry on things like OCI, the Open Container Initiative, and the CSI, which is the Container Storage Interface. But not only that, for example, we in Google have been working, last year, building Kubo, which then became the Cloud Foundry Container Runtime, and really bringing things together. And I think that's awesome because like any other technology, we need to know how we can take the best out of everything. And this is what really, user wants to know. They want to know that when they are making a decision or a choice of a technology, that technology can move with them forward. The last thing that we also see all of interest about the Open Service Broker and how you can really mesh things together with different platforms. >> Chen, I'm wondering if you can help us squint through this a little bit. And we've heard Google talking for a while about Open Cloud, and that means it doesn't beam all one source in the public cloud portability between clouds, public and private. Google's had many partnerships over the years with there. How do these pieces fit together in your mind? >> I think it all starts with what user wants. Okay, I always talk about the customer and what is their pain? And the pain, in reality is that they have a very complex environment, okay? They have on-prem. They want to use some of the cloud services. Sometimes they have some places, like we hear it from retail, they have some warehouses, that they don't have actually good connectivity, but they still want to serve, they still want to have the guild transformation. And, I think, that's the main thing that what we hear from users, that they want to have that flexibility over to run their business. Okay, because this is what they really have to do and they want to compete more effectively. So, think about that. The other piece which we hear about users is that they want to make sure like we talked about Cloud Foundry before. They want to make sure that the infrastructure they choose though, that the tools will allow them to evolve, and that can be in different ways. It can be about maybe having flexibility to choose different tools, but also not to be locked in to a specific vendor because that happened to them before, right? So, they want to make sure that they can continue and move forward because the technology we know today maybe, probably will change in the future. So, by having all of that together, that leads us to some of the pieces I've talked about in the keynote. And the first one is portability. We achieve it by open source. We believe in open source because it does bring the community together. We learn about users, partners. We have an amazing ecosystem. So that's one. The second piece is about its sensibility and this is where you can see how Cloud Foundry can actually integrate into Kubernetes. It's because of those extension points. We don't know where innovation will come from. What will be the next cool thing? And back in KubeCon, I talked about some serverless framework we see on top of Kubernetes. All of that is possible through those extensions. Open Service Broker is actually a combination of two. So Open Service Broker is an open standard. It allows you to consume services from different platforms. We saw, in the keynote, so Google is announcing, now in beta, the Google Managed Service Broker, supporting the Open Service Broker API. And you consume it out from any Kubernetes cluster that are using a catalog, service catalog. And it is available also through those extensions. So when we think about Open Hybrid Cloud, we think about that you can run it anywhere. And either you have interopabilities, so you can consume different tools and you can extend it and innovate on top of it. So that's our way of thinking. >> Yeah, I mean, we know the only thing that's constant in this industry today is change. >> Yes. >> One of the things we've been tracking is if I look at an application, it used to be I deploy an application, it takes me 12-18 months at least, and then, once I'm running it, gosh. Yeah, sure, were going to run it for three to five years but, no, no, actually, we're going to run it for 10-12 years. We're going to keep it longer. How does this kind of decomposability of applications and having things and more components? We talk about things like flexibility and speed but, you know, how do you hear from customers, really, from the application side of things? >> This is all about microservices? >> Yeah. >> Right? Just making sure that your application is architected in a way that allows you to change things. I think also that developers are now used to that cycle which is really fast. I'm talking about agility and how quickly you can deploy changes. You know, I keep talking with my engineering team, like don't get too attached (laughs) to anything because things do change and requirements change all the time, and if you're building your application right, you can do those changes. For example, again, going back to the Open Service Broker, you can use a service. First of all, maybe your own service, like your own SQL. But then you can use through a managed service like if you are running on G Key or having Cloud Foundry running on GCP, then you can use one of the managed services offered by Google. >> Okay, anything new you're hearing from users? What are some of their biggest challenges? What's exciting them these days? >> So it depends which user and also who you talk in that audience. Yeah, I think developers are still very excited about the opportunity and the different tools and open source and how quickly the technology is moving forward. When we talk with enterprise, they are very excited about consistency because it's hard. That complexity and managing all of it is really hard to train your operational teams and the developers on different tools. So they are very much concerned about that, their TCO. So they care about, of course, the cost of the infrastructure, but also the people. Right, we don't talk about how hard it is to train and change technology, technologies, all during a cultural change within an organization. So, they care about consistency and this is something that is really in the heart of the thing that we are building. So starting with Kubernetes, we talk about flexibility without compromising consistency. And you do it by building obstructions and letting everyone own a different piece. And there's always some excitement about Istio, in that sense, because what it allows you is to create an obstruction for managing services which is separated from the code that you build. So, let's say you want to, for example, deploy a new policy of access control to your services, you can do it through Istio, because you have proxies in front of all your services, regardless of what they run, by the way. You can have services on VMs, on Cloud Foundry, on a Google Kubernetes engine, or anything, anywhere else you actually would like to have them. And you have that consistent layer in front of all of them. You can do troubleshooting easier because you will have the same matrix and data and telometry on top of it. And so, moving into that direction, creating more obstructions that are creating less friction for the end-user, while still allowing just the platform to evolve, right? If you have this platform on top of it, you can still move services from running from one platform to another, but that person that is using the data, actually, their experience won't change. >> Alright, Chen, what should we be looking for from Google and Eureka's system for the rest of 2018? >> So, of course, we continue and invest a lot in Kubernetes and its ecosystem, and you can see it all the time. All the time, we are bringing more and more tools in open source, showing some of our best practices of how we manage development and production into the community. Some of it is in, like project, like developer experience project, like scaffold, and others that were announced in the last few months. So we will see more of those coming. And in some ways, it's also around the best practices. So, we have been delivering messages of how you should run your clusters or application more secured. And, of course, some of those offerings will be on GCP. But that's another area where we are heavily investing. We have a lot of experience and we are happy to share that. >> Well okay, last question I have for you, is the world becoming more Googly? Or is Google becoming more like the rest of the world? (Stu and Chen laugh) >> I want to say that the world becoming more Googly. (laughs) Being Googly means many things for people here in the, that maybe don't know what means. To me, being Googly is being nice and being kind, and also, being open to more ideas and that's what I would hope to see the world moving towards. But yes, but definitely Google, as part of it being Googly, is working, continuing to work with the community and get feedback, and that's great. >> Okay, well, Chen Goldberg, it's a pleasure to catch up with you again. We will have lots more Google content (Chen laughs) and Googly guests, not only here at the Cloud Foundry Summmit, we're going to be at KubeCon, Copenhagen, as well as KubeCon, Seattle, at the end of the year, and really excited to say that we will be at the Google Cloud Next Show >> Aww. >> this summer, so, look for lots more of theCUBE. >> Thank you, Chen, for joining me. >> That's exciting. >> I'm Stu Miniman. Thanks for watching theCUBE. (electronic music)

(Upbeat Music) >> Announcer: Live from Los Angeles, it's theCUBE, covering Open Source Summit, North America, 2017, brought to you by the Linux Foundation and The Red Hat. >> Hey, welcome back everyone, live here in Los Angeles, California for theCUBE's exclusive coverage of Open Source Summit in North America. I'm John Furrrier, with my co-star Stu Miniman, Our next guest is Patrick Chanezan, who is a member of the technical docker, also on the governing board of the Cloud Native Compute Foundation, also known as CNCF, which is the hottest part of the open-source community right now. It's very fast, we're very trendy, a lot of people are on the bandwagon, a lot of contribution going on. Welcome back to theCUBE. Great to see you. >> Hey, thanks, John and Stu, it's very good to be back on theCUBE. >> Docker's been just a great company to follow since the beginning, the birth of Docker to the transformation from Dark Cloud to Docker. It's just a great team. We have a lot of respect for you guys. Congratulations. But the CNCF right now is the hottest thing, there's more platinum sponsors than I think maybe members. It seems to be very hot. Industry loves it, developer is going crazy about it, why is CNCF so hot? What's your perspective on that? >> What we're seeing right now is really the realization of adoption of containers, we talked about it two years ago. It was very early, and people were starting to use Docker and just covering containers. Today they're really putting them into production, and what we see at Docker with our customer base is that they are using it more and more to modernize traditional applications. So we see tremendous use of containers everywhere in enterprises, and the rise of CNCF is tied to that, I think. We're seeing more and more developers joining the bandwagon, more and more systems being built based on containers. And at Docker, we're playing a big role into that. >> Patrick, for a couple years, the chant was Docker, Docker, Docker, and sometimes people say, "Cubernetti's is where the hotness is." Well underneath that, there's containers. And a lot of those containers, Docker's involved there. Maybe you can help us understand the nuance a little bit as the Cubernetti's wave has grown, sure there was the Mezos, Docker Swarm, Cubernetti's war, if you will there, but what does this mean for Docker? What are you seeing from your customers? Give us the update on Docker itself. We'll probably need to get into the Mobi stuff, too, as we get into the interview. >> Sure, definitely. That's a big question, so let's start with the beginning. When enterprises adopt containers, what happens is that usually it starts with the wrappers who are adopting containers with Docker. So they download Docker for their Windows machine, or for their Mac, or on Linux, they start modernizing their applications. What we see is more and more enterprising wrappers, modernizing existing applications by Dockerizing them, and then the next step is that they want to put that into production. For that, you need the whole system. So at Docker, we have two systems. We have Docker C and Docker E, our enterprise version that has role-based controlled sequencing and all that good stuff. There are lots of different components that you need in order to have a production container system, and so Cuberneris, the orchestration engine is one piece of that. At Docker, we have swarm kits. But there are lots of other different components and lots of different layers to that system. So you have the infrastructure layer that you are using to deploy that inside the firewall or in different cloud providers. Many different solutions there. At Docker, we have one that's called infrakit, that we're using in our additions, to deploy it everywhere. Then on top of that, you need some version of Linux. At Docker Con in April, we released a project called Linuxkit, which helps you do that. On top of that, you need a container run-time. Traditionally, it's been Docker. Right now, we re-factored the Docker codebase to extract a core run-time component that's called container G, which we donated to CNCF. Container G is nearing one or better, so it would be one of them pretty soon. Then, on top of that, you need an orchestration engine. Docker E comes with its own orchestration based on swarm, Cuberneris is another orchestration engine that people like. Cuberneris, behind the scenes, is using Docker, and right now we are working very closely with theCUBE rneris community to implement CRI container G. So CRI is the container run-time interface in Cuberneris that lets you plug in different engines to plug container G in the place of Docker in there. >> Stu: There's a lot of pieces in here. We had too many interviews yesterday talking about the Open Container Initiative, or OCI, which really made sure we've got the 1.0 version of that done. What container format, seems like we're in agreement. We're not fighting over that kind of piece anymore. From the Cubernetti's community, I heard loud and clear, they're like, we've got container D. We've kind of got what we want. We're happy it's open-sourced. We're going. We were at Docker Con when you annouced Mobi, which is kind of open-source, and it felt like we were still trying to figure out all those pieces. Give us the update as to Mobi, you're talking at the open source show, you talk a little bit about CE and EE being the productized versions, but part of it is what we used to think of as Docker is now Mobi, and the company Docker versus the project. You kind of teased those apart a little bit, right? >> Yes. Exactly. And actually, that's what I came here at the Open Summit to talk about, to give people an update on the Mobi project. So what we announced back in April was the launch of the Mobi project, which is the end of a two year re-factoring of the Docker codebase into different components. So all these components on the stack that I told you about, we just tease them out from the Docker codebase so that it's a modular set of components that you can assemble together. Mobi is three things. It's an open source project where people can collaborate in container-based systems. It's also a tool that we're using to assemble our components into Mobi Corp, which is the upstream of Docker products. Then it's also a set of lots of components, like container G, Linux, Infrakit, Notary, and all the projects I talked about. One other thing we've started doing since April as well is we started proposing to donate some of these container projects to CNCF. So container G is already part of CNCF now. Recently, this summer, we proposed Infrakit, and they think it's a little bit too early for donation, because they want to see other, different projects in there. Right now we're in the process of donating and proposing Notary, so there's an active discussion in there, and I hope that the vote will happen probably next week or something like that. So Notary is the component that we're using for Docker, and we think that this could be used in lots of different Cloud Native systems, so it really has its place in the CNCF. >> So identity component for the container management, or what specifically is that going to address? >> So Notary is the piece that we're using in Docker Con Contrast to make sure that you can trust the images that you've built. A signed signature should be able to revoke all the signatures, all the kind of features that our customers love in Docker E. >> John: It's kind of like Stu and me on Twitter, he's verified, I'm not. But this is important, because now, this is a stamp of approval, if you will, that the community can look to. >> Yeah, definitely. So it's something that we implement in Docker, and now people building other containment systems who will be able to use it. And so Mobi saw a lot of traction for its different projects, some of them are going to CNCF, some of them are growing by themselves. On the Docker side, we made some progress prioritizing all that with Docker C and Docker E. We had a 1706 launch of Docker E recently, with lots of new role-based axis control, controls for enterprises, who are adopting it essentially to modernize their traditional apps. >> Take us through a kind of personal question. You were just at a board meeting with the CNCF. Did everyone show up or are people calling in? >> I think Alexi Richardson was the only one, maybe two people on the phone. >> John: Was Sam Redjay there? >> Sam was not there either, but Epona was standing for him. So the room was full, and to me it's really an impressive achievement, two years after we helped start the CNCF. The first meetings were 10, 15 people at Google deciding to create this foundation, and today, maybe we're twenty or thirty people around the table. An\d everybody-- >> Even before that Google meeting, we were covering theCUBE Con Cubernettis' movement early on from your event. So I think, out of Docker Con and some of the Linux Foundation events, the early momentum, we were there, Stu. Then it became the CNCF, and they decided, hey, let's get the Cloud Native Foundation. So it's interesting to me, seeing the growth from the beginning. And it's unique to have that opportunity to be in the front lines of an organically developing group. It wasn't really build the table and come, this was a realization. >> It was a realization and also a concerted effort to build something together to show customers where the containment systems were going in terms of architecture-- >> What were the factors beside, I mean Docker was big driver. Notably, you should get the credit for pioneering the space. But what were the drivers for this coalescing, this call to arms, if you will, or this organic formation of CNCF. What were the key drivers in your mind. Obviously, containers is one. What are the other ones? >> Yeah, to me, containers is a big one, because when you are starting to design your system with containers in mind, you need to change lots of things, how you're building them and things like that. And how you are architecting things together. There were lots of questions about how you do the balancing in that kind of system, how do you do monitoring, how do you do tracing. The CNCF was assembled so that all these components have a place where we can show our inter-repairability between them. So Docker is part of that, Mezos is part of that, as well as Cuberneris. There's a big inter-repairability work that's happening in there. We had a report in the board meeting today about the new CI Initiative that tests different CNCF projects together. >> John: What CI? >> Sorry, continuous integration. >> John: Got it, yeah. >> So there's the continuous integration-- >> John: Not conversion infrastructure. >> Oh, you're right, yeah. >> We always get acronym-ed up. But Chris Anazik was talking yesterday about the graduation path, still waiting to see something graduate from the process. What's going to graduate first? Any bets, what's the betting, what betting is going on? Do you guys actually make bets? Is there a fantasy drafting going on? >> I don't think that really matters, what matters is really adoption of the components. >> Okay, so what's happening on the graduation scale? What's coming out of the woodworks? What's next? What's going to graduate first? >> So one thing I'm curious about is whether Container G will graduate, because it's kind of mature now, it's reaching 1-0 with the CRI and soon integration in Docker, it may be a good candidate for graduation. For the others, I don't know which ones would be first into the graduation process. >> Well, we know it's a high bar, for sure. >> Patrick, the stuff that's getting mature. What about some of the roadmap there? From Docker and CNCF, something like serverless containers, first generation, are going to be important. We had too many interviews this week talking about, today, many of the containers we'll see in the future where serverless and open Faz and things like that go. So how does that all fit in? Can you give us a Docker and a CNCF view on that? >> Let's talk about the CNCF view first. CNCF is working on lots of different areas where there needs to be more definition about what Cloud Native means for storage, for example, with the CSI Initiative, container storage interface, CNI, container networking interface, and then there's the working group for CI, which is about integrating all these projects together, but the working group I'm most interested in is the serverless one. So we have a Docker rep at the serverless working group, and there we're trying to define what a portable, serverless stack looks like. And at Docker, we're naturally interested in this -- >> Of course, Serverless is a beautiful thing. >> Most of these projects are running on top of Docker, so open Faz for people-- >> I got to ask you, Patrick, because we love serverless, I have a love/hate relationship with the word serverless because technically it's a beautiful thing, but there's servers involved. I'm an old-school, so I kind of look at it differently. The younger generation, they want infrastructure as code. This is a clear obvious thing. It was once a dream, but now it's become a reality. What's your position on that? Where is it on the progress bar? How close are we to serverless? >> I'd say there's an initial adoption of serverless on one of the few stacks that exist out there today. So you have the hosted services, the Faz services, from Amazon, Microsoft, and Google, where I'm more interested, and I think customers are kind of looking for that, is a portable way of doing that. For example, in studying that on top of Docker platforms, so that's what projects like Open Faz is doing. Right now, I think we're really in the stage of discussions with CNCF of what a portable service layer would look like so that you could focus on your code, but be able to deploy on Prim, on top of Docker, or in different cloud providers. So that portability aspect to me is very important there. And I think it's important for customers as well. To me, also, I'm an old timer as well, I used to pitch a platform as a service at the beginning of it, Google App Engine, many years ago. To me, it's kind of a feeling of deja vu. We're kind of re-inventing that, but with containers and in a much more portable way. >> The beautiful thing about being an old-timer is we get to look back and, not so much to the young kids, get off my lawn, we had to walk to school with bare feet in the snow, build our own libraries. I was just talking to Eilene, she's like, "Oh, my low-level class was C and my high-level class was Python." I'm like, "Our low-level class was machine code "and high-level wasn't even C yet." >> Yesterday, at the party, I was discussing with one of the IBM engineers, who's working on Linux and containers on mainframe, and we were talking about GCL, and that's the type of feeling that we got. Like we're getting higher up in the stack, and I think for modern developers, it really helped them-- >> It's a beautiful thing right now. Just think about the young guns that are coming up. This is a beautiful library of options now. 90% of the code is leverage-able. That's like unbelievable. So it really allows the creativity of the developer to be a lot more about structural engineering code-base rather than just being very creative on the 10-20% of real intellectual property that they can bring to the table. >> I would add something, it's really about creating value, as opposed to building infrastructure. When we're getting up the stack, and serverless is an example of that, it's really about creating value for enterprises, and that's what these wrappers are about. >> When you start dreaming in code, you know you're doing good. Patrick, thanks so much for coming on theCUBE, and congratulations on all the success with CNCF, and certainty Docker. You guys continue to impress and do a great job. I know there's some changes over there we're looking for, some of the cool stuff graduating out of CNCF, more Docker container goodness from you guys. Thanks for coming on theCUBE. We appreciate it. I'm John Furrier, we're live in Los Angeles, California, for the Open Source Summit North America coverage with theCUBE. I'm John Furrier, Stu Miniman back with more after this short break.

(gentle music) >> Announcer: Live, from Los Angeles, it's theCUBE, covering Open Source Summit, North America, 2017, brought to you by the Linux Foundation and Red Hat. >> Okay welcome back, and we're live here in Los Angeles, this is theCUBE's exclusive coverage of the Linux Foundation's Open Source Summit North America. I'm John Furrier, your host with my co-host Stu Miniman. Our next guest is Chris Aniszczyk, who's the COO, Chief Operating Officer of the CNCF, the Cloud Native Compute Foundation, formerly Cube-Con, Cloud Native Foundation, all rolled into the most popular Linux Foundation project right now, very fashionable, cloud native, running on native clouds, Chris welcome back to theCUBE, good to see you. >> Awesome, it's been a while, great to be back. >> So you are the Chief Operating Officer of the hottest project, to me at least, in the Foundation. Not the most important, because there's a lot of really important, everything's important, you don't pick a favorite child, but, if one's trending, the CNCF is certainly trending, it's got the most sponsors, it's got the most participants, there's so much action going on, there's so much change and opportunity, around Kubernetes, around containers, around writing cloud-native applications. You've guys have really put together a nice foundation around that, nice group, congratulations. >> Thank you. >> Take a step back and explain to us, what the hell is the CNCF? We know what it is, we were there present at creation, but it's super-important, it's growing in relevance every day. Take a minute to explain. >> So I mean, you know, CNCF is all about providing a neutral home for cloud-native technology, and it's been about almost two years since our first board meeting and the idea was, there's a certain set of technology out there that are essentially micro-service-based, that live in containers that are centrally orchestrated by some process, right, that's essentially what we mean when we say cloud-native, right, and CNCF was seeded with Kubernetes as its first project, and as we've seen over the last couple of years, Kubernetes has grown quite well, they have a large community, diverse contributor base, and have done kind of extremely well. They're one of actually the fastest, highest velocity open source projects out there, maybe only, compared to the kernel is maybe a little bit faster but it's just great to kind of see it growing. >> Why is it so hot right now? What's the catalyst? >> So I think if we kind of step back and we look at the trends in industry, right, more and more companies are becoming software companies, you know, folks like John Deere, building IoT platforms. You need some type of infrastructure to run this stuff, and especially at scale. You know, imagine sensors in every tractor, farm or in every vehicle, you're going to need serious infrastructure and cloud native really is a way to scale those type of infrastructure needs and so this is kind of I think why you're seeing a lot of interest being piqued in CNCF-related technology. >> A lot of prototypes too. >> Chris, see you know, it's interesting, I look back you know, a year or two ago, and it was like, oh, it was like the orchestration wars, it was Swarm versus Mesos, and now I look at it in the last year it's like, wait, Mesos fully embracing it, MesosCon they're going to be talking about how Mesos is the best place to you know, Kubernetes on DCOS, containerd now part of the container wars, so the container wars, we're going to talk about OCI, you know, Amazon, Microsoft, of course Google, out there at the beginning. Is there anybody that's not on board that Kubernetes... >> I mean we really have the top five cloud providers in the world, depending on what metrics you look at, part of CNCF, you know there's some others out there that still aren't fully part of the family. Hopefully if you stay tuned over the next week or so you may hear some announcements coming from CNCF of other large cloudy-type companies joining the family. >> Every week there's a new platinum sponsor (Chris laughs) and you guys are getting a check every week it seems. >> To me it's great to see companies stepping up to the play and actually sustaining open source foundations that are critical to the actual business, and I think that it's great to see this involvement. So to me I'm personally thrilled, 'cause otherwise we'd be in a situation where if the top five cloud providers in the world weren't part of CNCF, maybe they'd be trying to do their own initiative, so it's great that we have these companies at the table, and all trying to build, you know, find their own pathway to cloud-native. >> You guys are hyper-growth right now, and you're new too, you're still kind of you know, >> Chris: Less than two years old! >> I mean it's amazing. So I want to put a little Jim Zemlin test to you, (Chris laughs) which is, in his keynote today he talked about, this is the big kind of event for the whole community of open source to come together, and again, you're talking 64 million libraries out there now. He projected by 2026, 400 million, it literally is a hockey stick growth, so you got growth there, so he talked about four things, my summary. Project health, so healthiness, sustainability, secure code, training, new members. What's your strategy re those four things? Keeping the CNCF healthy, you don't eat too much and choke on all of that growth... >> Yeah, so in terms of projects, we have a very unique governance structure in place when we designed CNCF. So we kind of have this independent technical operating committee, we kind of jokingly refer to them as a technical supreme court, but they are made up of people from, kind of luminaries in the container cloud-native space, they're from competing companies too, but they try to really wear an independent hat and make sure that we're, projects that we're accepting are high quality, are a good fit for the foundation, and so it's actually fairly hard to get a project in CNCF, 'cause it really requires the blessing of this TOC. So, even though we have 10 projects now in about two years, I think that's about a project every two months, which is an okay pace. The other unique thing that we're doing is we have different levels of projects, we have inception, incubation and graduation. Right now, we have no graduated projects in CNCF, believe it or not, Kubernetes has not graduated yet because they're still finalizing their governance for the project and they're almost there. Once they do that, they'll most likely graduate. >> They'll walk cap and gown all nine yards, eh? >> Exactly, it'll be great. December we'll have the cap and gown ceremony. But the other unique thing is we're not, we do annual kind of reviews for some of our projects, certain levels will be annually reviewed, and if they're not longer healthy or a good fit, we're okay archiving them, or telling, you know, telling them you know, maybe you're not a good fit anymore for the foundation, or you know. And so I think you have to have a process in place where sometimes you do have to move things to the attic. >> Do you have a high bar on the projects >> The initial bar is extremely, extremely high, and I think over time, we may see some projects that get recycled or moved to the attic, or maybe they maybe merged together, we'll see, so we're thinking about this already, so... >> John: Okay, security? >> Security, so we, all projects in CNCF that graduate have to partake in the core infrastructures best practices badging program, so if the CII has this great effort that is basically helping to ensure projects meet a minimal level of best practices that make their projects secure. You know, it doesn't give you like full-blown guarantee, but these are good practices. >> So you were leveraging pre-existing work, classic, open-source ethos. >> Exactly, and they have like a set of domain experts completely focused on security building out these practices and you'll notice Kubernetes recently merged in the CII Best Practices badge, so if you go to the readme, you'll actually see it, and you'll click through and you'll see all the things that they've had to sign off and check on that they participate in, and so all of our projects are kind of going >> Training. >> Training, yeah, we just recently announced couple things. One is we have a >> Looking good so far, you get an A plus. >> Yeah, so as of today we've launched the Certified Kubernetes Administrator Program or CKA for short. So we have folks that are getting trained on, and are having official stamps that they are certified Kubernetes administrators, and to me that's huge, given like how hot the space is, having some stamp of approval that they are really certified in the space is huge. So we also offer free training through edX, so we launched some training courses earlier, and to be honest, if you look at our member companies, lots of great folks out there providing training material. >> So one of the keynotes that Christine Corbett Moran was talking about in her keynote was, more inclusion so there's no ruling class. Now I know you really have a ruling class going on with your high bar, I get that. How are you getting new members in, what's the strategy, who are the new members, how are you going to manage the perception possibly that a few people control the swing votes at potentially big projects? >> So here what's interesting is, people joining CNCF, like I mentioned before, we have a TOC, right? So there's kind of this separation of, I don't say church and state, but like, so the governing board, people who pay to join CNCF, they pay to sustain our open source projects, and so essentially they help with, they pay for marketing, staff, events and so on. They actually don't have technical influence over the projects. You don't have to be a member to have technical influence over our projects. People join CNCF because they want to have a say in the overall budget of how marketing, events and stuff, and just overall support the organization. But on the technical side, there's this kind of firewall, there's an independent TOC, they make the technical decisions. You can't really pay to join that at all, you have to actually be heavily participating in that community. >> John: How does someone get in that group? Is there a code? >> They have to just be like a luminary, we have a kind of election process that happens every two or three years, depending on how things are structured, and it's independently elected by the CNCF member community, essentially, is the simplest way I can explain it. >> The other announcement you talked about, kind of the individual certification, but the KCSP sort of programs >> Correct, exactly. >> Maybe you can tell us a little bit about that. >> Yes, so we had a program set up so it's Kubernetes Certified Service Provider, KCSP, that basically >> rolls right off the tongue >> I know, right, exactly. Herbal space program, whatever, I think of sometimes video games when we say it, but essentially, the program was put in place that a lot of end users out there in companies that are new to cloud native, and they're new to Kubernetes, essentially want to find a trusted set of partners that they can rely on, services and other things, so we created KCSP as a way to vet a certain set of companies that have at least a minimum of three people that have passed the Kubernetes certification exam that I talked about, and are essentially participating upstream in some way actively in the Kubernetes community. So we got a couple handfuls of companies that have launched, which is great, and so now, given that we're growing so fast, companies out there that are early end users that are exploring the space now have a trusted set of companies that go look at, and we're hoping to grow that program over time too. So this is just phase one. >> All right, so Chris, the other thing that I want to make sure we talk about, the Open Container Initiative, so I think it was originally OCP, which of course is, >> Open Container Project which when OCP was announced, it was like, okay, the cold war of Docker versus CoreOS versus everybody else, (Chris laughs) trying to figure out what that container format was, we all shook hands, I took a nice selfie with Ben who was CEO at the time, and everybody. So 1.0 is out. So, container's fully mature, ready to be rolled out right? But what does it mean? >> So I mean it's funny 'cause I basically joined the Linux Foundation, to help both start CNCF and OCI around the same time, right, and OCI was very narrowly scoped to only care about a small set of container-specific issues. One around how do you actually really run containers, start, stop, all that kind of life cycle bit, and how are containers laid out on disk, we call that the image specification. So you have the runtime spec and the image spec, and those are just very limited core pieces, like that OCI was not opinionated on networking or storage or any of, those are all left to other initiatives. And so after almost two years, we shipped 1.0, we got basically all the major container players to agree that this is 1.0 and we're going to build off from this, and so if you look at Docker with it's containerd project, or you know, fully adopting OCI, the Mesos community is, Cloud Foundry, even AWS announced their container register's supporting OCI, so we got the 1.0 out there, now we're going to see an abundance of people building tools and other things. I think you'll see more end users out there exploring containers. I've talked to a lot of companies that I can't necessarily name, but there's a lot of folks out there that may not dive into container technology until there is actually a mature standard and they feel like this technology is just not going to go away or they're going to get locked into some specific platforms. So, with 1.0 out the door, you'll see over the next six to 12 months, more tools being built. We're actually working to roll out a certification program so you get that nice little, you know, hey, this product is OCI-certified and supports the spec, so you'll see that happen over the next... >> Okay, so you've got the runtime spec and the image format spec, >> Yep, those are the two big ones. >> All 1.0, we're ready to roll, what's the roadmap >> Yeah, what's next. So there are early discussions about what other mature areas are out there kind of in container land right now. There are some discussions around distribution, so having a standard API to basically fetch and push container images out there. If you look at it, each container registry has basically a different set of APIs, and wouldn't it be nice if we could all kind of easily work together and have maybe one set, a way to kind of distribute these things. So there are some early discussions around potentially building out a distribution specification, but that's something that the technical community has to decide within OCI to do, and so over the next couple of months we're having some meetings, we're doing a bigger meeting at DockerCon Europe coming up in October to basically try to figure out what's really next. So I think after we shipped 1.0 a lot of people took a little bit of a breather, a break, and say like, congratulate themselves, take some vacation over the summer, and now we're going to get back into the full swing of things over the next couple of months. >> Say, what's the big conversation here, obviously at your event in Austin, it's got a plug for, theCUBE will be live covering it as well. >> I know, I'm excited. >> What's the uptake, what's the conversation in the hallways, any meetings, give us some >> Yeah, so we're doing >> I know there's some big announcement coming on Wednesday, there's some stuff happening >> Yeah, so, you know, first coming Wednesday, so like I mentioned, we have 10 projects right now in CNCF. We have two projects currently out for vote. So one of them is Envoy. There's a company you've probably heard of, Lyft, ride-sharing company, but Envoy essentially is their fancy service mesh that powers the Lyft platform, and many other companies out there are actually taking advantage of Envoy. Google's playing around with it, integrating into the Istio project, which is pretty powerful, but Envoy is currently, it was invited by the TOC for a formal vote, the voting period started last week, so we're collecting votes from the nine TOC members, and once that voting period is hopefully we can announce whether the project was accepted or not. The other project in the pipeline is a project called Jaeger, which is from Uber, you know, nice to have Uber >> John: Jaegermeister. >> Yeah, Jaegermeister, a bit like it. It's nice to have a product from Uber, another product from Lyft, kind of it's nice to see >> And if you have too much Jaeger, you have to take the Lyft to get home, right? >> Exactly, correct. So you know, just like Envoy, Jaeger is, you know, was formally invited by the TOC, it's out for vote, and hopefully we'll count the votes soon and figure out if it gets accepted or not. So Jaeger is focused on distributed tracing, so one problem in micro-services land is once you kind of like refactor your application to kind of be micro-services-based, actually tracing and figuring out what happens when things go wrong is hard, and you need a really good set of distributed tracing tools, 'cause otherwise it's like the worst murder mystery, you have like no idea what's happened, so having solid distributed tracing solution like Jaeger is great, 'cause in CNCF we're going to have a project called OpenTracing, but that's just kind of like the spec of how you do things, there's no full-blown client-server distributed >> For instance you usually need it for manageability >> Exactly, and that's what Jaeger provides, and I'm excited to kind of have these two projects under consideration in CNCF. >> Is manageability the hottest thing going on right now in terms of conversations? (Chris sighs) Or is it more stability and getting projects graduating? >> Yeah, so like our big focus is like, we want to see projects graduate, kind of meet the minimum bar that the TOC set up for graduated projects. In terms of other hot areas that are under discussion in CNCF are storage, so for example we have a storage working group that's been working hard to kind of bring in all the vendors and different storage folks together, and there's some early work called the container storage interface, we call it CSI for short, and so you know there's another project at CNCF called CNI, which basically tried to build a standard around how networking is done in container land. CSI is doing the same thing because, you know, it's no fun rewriting your storage drivers for all the different orchestration systems out there, and so why not get together and build out a standard that is used by Kubernetes, by Mesos, by Cloud Foundry, by Docker, and just have it so they all work across these things. So that's what's happening, and it's still early days, but there's a lot of excitement in that. >> Okay, the event in Austin, what can people expect? Cube-Con. >> You're literally going to have the biggest gathering of Kubernetes and cloud-native talent. It's actually going to be one of our biggest events probably for the Linux Foundation at all. We're probably going to get 3-4,000 people minimum out there, and I'm stoked, we're going to have some... Schedule's not fully announced yet. I do secretly know some of the keynotes potentially, but just wait for that announcement, I promise you it's going to be great. >> And one question I get, just I thought I'd bring it up since you're here in the hot seat, lot of people coming in with, supporting you guys on the governing side, not even cyclical. How are you going to service them, how are you going to scale up, do you have confidence that you have the ability to execute against those sponsorships, support the members, what's your plan, can you share some insights, clarify that? >> You know, pressure makes diamonds, right? We have a lot of people at the right table, and we are doing some hiring, so we have a couple spots open for developer advocacy, technical writing, you know additive things that help our project overall. We're also trying to hire a head of marketing. So like, we are in the process of expanding the organization. >> Do you feel comfortable... >> I feel comfortable, like things are growing, things are moving at a fast clip, but we're doing the best we can to hire and don't be surprised if you hear some announcements soon about some fun hires. >> Well it's been great for us covering, we've been present and creating, if you will, this movement, which has been kind of cool, because it kind of a confluence of a couple of things coming together. >> Chris: Yeah, absolutely. >> It's just been really fun to watch, just the momentum from the cloud really early days, 2009 timeframe to now, it's been a real nice ride and congratulations to the entire community. >> Thank you, like for me it's just exciting to have all these companies sitting together at the same table, having Amazon join, and the other top fighters, all basically committing to saying, we are in the cloud-native, we may have different ways of getting there, but we're all committed working together at some level. So I'm stoked. >> Great momentum, and you guys doing some great work, congratulations. >> Thank you very much. >> And you know it's working when I get focused, hey can you, so and so, I'm like, oh yeah, no problem, oh wow, they're big time now, you guys are big time. Congratulations. >> Thank you, it's in phase one now, like we have the right people at the table >> Don't screw it up! (John and Chris laugh) As they say. It's on yours. Chris Aniszczyk, who's the COO of the Cloud Native Compute Foundation, the hottest area of Linux Foundation right now, a lot of action on cloud, cloud-native developers where DevOps is meeting, lot of progress in application development. Still, they're really only two years old, get involved, more inclusion the better. It's theCUBE, Cube coverage of CNCF. We'll be in Austin in December. >> Chris: Yep, six to eight. >> December 6 to 8, we'll be there live. More live coverage coming back in Los Angeles here for the Open Source Summit North America after this short break.

>> Announcer: Live, from Boston, Massachusetts, it's the Cube. Covering Red Hat Summit 2017. Brought to you by Red Hat. (futuristic tone) >> Welcome back to the Cube's coverage of the Red Hat Summit here in Boston, Massachusetts. I'm your host, Rebecca Knight, along with my co-host Stu Miniman. We are welcoming right now Sam Ramji. He is the Vice President of Product Management Google Cloud Platforms. Thanks so much for joining us. >> Thank you, Rebecca, really appreciate it. And Stu good to see you again. >> So in your keynote, you talked about how this is the age of the developer. You said this is the best time in history to be a developer. We have more veneration, more cred in the industry. People get us, people respect us. And yet you also talked about how it is also the most challenging time to be a developer. Can you unpack that a little bit for our viewers? >> Yeah, absolutely. So I think there's two parts that make it really difficult. One is just the velocity of all the different pieces, how fast they're moving, right? How do you stay on top of all the different latest technology, right? How do you unpack all of the new buzzwords? How do you say this is a cloud, that's not a cloud? So you're constantly racing to keep up, but you're also maintaining all of your old systems, which is the other part that makes it so complex. Many old systems weren't built for modernization. They were just kind of like hey, this is a really cool thing, and they were built without any sense of the history, or the future that they'd be used in. So imagine the modern enterprise developer who's got a ship software at high rates of speed, support new business initiatives, they've got to deliver innovation, and they have to bridge the very new with the very old. Because if your mobile app doesn't talk to your mainframe, you are not going to move money. It's that simple. There's layers of technology architecture. In fact, you could think of it as technology archeology, as I mentioned in the keynote, right, this we don't want to create a new genre of people called programmer archeologists, who have to go-- >> I'm picturing them just chipping away. >> Sam: I don't think it'll be as exciting as Indiana Jones. >> No. >> Digging through layers of the stack is not really what people want to be doing with their time. >> Sam: Temple of the lost kernel. >> I love it. >> So Sam, it's interesting to kind of see, I was at the Google Cloud event a couple months ago, and here you bring up the term open cloud, which part of me wants to poke a hole in that and be like, come on, everybody has their cloud. Come on, you want to lock everybody in, you've got the best technology, therefore why isn't it just being open because it's great to say open and maybe people will trust you. Help explain that. >> Puppies, freedom, apple pie, motherhood, right. >> Stu: Yeah, yeah. (laughs) >> So there's a couple sides to that. One, we think the cloud is just a spectacular opportunity. We think about 1.2 trillion dollars in current spend will end up in cloud. And the cloud market depending on how you measure it is in the mid 20 billions today. So there's just unbounded upside. So we don't have to be a aspirational monopolist in order to be a successful business. And in fact, if you wind the clock forward, you will see that every market ends up breaking down into a closed system and a closed company, and an open platform. And the open platforms tend to grow more slowly, sort of exponential versus logarithmic, is how we think about it. So it's a pragmatic business strategy. Think about Linux in '97. Think about Linux in 2002. Think about Linux in 2007. Think about Linux in 2012. Think about Linux today. Look at that rate. It's the only thing that you're going to use. So open is very pragmatic that way. It's pragmatic in another direction which is customer choice. Customers are going to come for things that give them more options. Because your job is to future proof your business, to create what in the financial community call optionality. So how do you get that? In 2011, about eight other people and I created a nonprofit called the Open Cloud Initiative. And the Initiative is long since dead, we didn't fund it right, we kind of got these ideas baked, and then moved on. >> Stu: There's another OCI now. >> That's right, it's the Open Container Initiative. But we had three really crisp concepts there. We said number one, an open cloud will be based on open source. There won't be stuff that you can't get, can't replicate, can't build yourself. Second, we said, it'll have open access. There'll be no barriers to entry or exit. There won't be any discrimination on which users can or can't come in, and there won't be any blockers to being able to take your stuff out. 'Cause we felt that without open access, the cloud would be unsafe at any speed, to borrow a quote from Ralph Nader. And then third, built on an open ecosystem. So if you are assuming that you have to be able to be open to tens of thousands of different ideas, tens of thousands of different software applications, which are maybe database infrastructure, things that as a cloud provider, you might want to be a first party provider of. Well those things have to compete, or trade off or enrich each other in a consistent way, in a way that's fair, which is kind of what we mean when we say open ecosystem, but being able to be pulled through is going to give you that rate of change that you need to be exponential rather than logarithmic. So it's based on some fairly durable concepts, but I welcome you to poke holes in it. >> So we did an event with MIT a little while back. We had Marshall Van Alstyne, professor at BU who I know you know. He's an advisor at Cloud Foundry, and he talked about those platforms and it was interesting, you know, with the phone system you had Apple who got lots of the money, smaller market share as opposed to Android, which of course comes out of Google, has all of the adoption but less revenue. So, not sure it's this, yeah. >> Interestingly, we've run those curves, and you kind of see that same logarithmic versus exponential shift happening in Android. So we've seen, I don't have the latest numbers on the top of my head, but that is generating billions of dollars of third party revenue now. So share does shift over time in favor of openness and faster innovation. >> So let's bring it back to Red Hat here, because if I talk to all the big public cloud guys, Microsoft has embraced open source. >> And they're not just guys, actually, there's lots of women. >> Rebecca: Yes, thank you. >> Stu: I apologize. >> Sorry, I'm in a little bit of a jam here, where I'm trying to tell people the collective noun for technologists is not guys. >> Stu: Okay. >> It could be people, it could be folks, internally we use squirrels from time to time, just to invite people in. >> So, when I talk to the cloud squirrels, Microsoft has embraced open source. Amazon has an interesting relationship. >> I was there when that happened. >> You and I both know the people that they've brought in who have very good credibility in the open source community that are helping out Amazon there. Is it Kubernetes that makes you open because I look at what Red Hat's doing, we say okay, if I want to be able to live across many clouds or in my own data centers, Kubernetes is a layer to do that. It comes back to some of the things like Cloud Foundry. Is that what makes it open because I have choice, or is there more to it that you want to cover from an open cloud standpoint, from a Google standpoint? >> Open and choice effectively is a spectrum of effort. If it's incredibly difficult, it's the same as not having a choice. If it's incredibly easy, then you're saying actually, you really are free to come and go. So Kubernetes is kind of the brightest star in the solar system of open cloud. There's a lot of other technologies, new things that are coming out, like istio and pluri. I don't want to lose you in word soup. Linker D, container D, a lot of other things, because this is a whole new field, a whole fabric that has to come to bear, that just like the internet, can layer on top of your existing data centers or your existing clouds, that you can have other applications or other capabilities layered on top of it. So this permission-less innovation idea is getting reborn in the cloud era, not on top of TCP/IP, we take that for granted, but on top of Kubernetes and all of the linked projects. So yeah, that's a big part of it. >> I want to continue on with that idea of permission-less innovation and talk about the culture of open source, particularly because of what you were saying in the keynote about how it's not about the code, it's about the community. And you were using words like empathy and trust, and things that we don't necessarily think of as synonymous with engineers. >> Sam: Isn't it? >> So, can you just talk a little bit about how you've seen the culture change, particularly since your days at Microsoft, and now being at Google, in terms of how people are working together? >> Absolutely, so the first thing is why did it change? It became an economic imperative. Let's look at software industry competition back in the 90s. In general, the biggest got the mostest. If you could assemble the largest number of very intelligent engineers, and put them all on the same project, you would overwhelm your competition. So we saw that play out again and again. Then this new form of collaboration came around, not just birthed by Linux, but also Apache and a number of other things, where it's like oh, we don't have to work for the same company in order to collaborate. And all of a sudden we started seeing those masses grow as big as the number of engineers who went a single company. Ten thousand people, ten thousand engineers, share the copyright to the Linux kernel. At no point have they worked at the same company. At no point could a company have afforded to get all of them together. So this economic imperative that marks what I think of as the first half of the thirty years of open source that we've been in. The second half has been more us all waking up, and realizing open source has got to be inclusive. A diverse world needs diverse solutions built by diverse people. How do we increase our empathy? How do we increase our understanding so that we can collaborate? Because if we think each other is a jerk, if we get turned off of building our great ideas into software because some community member has said something that's just fundamentally not cool, or deeply hurtful, we are human beings and we do take our toys away, and say I'm not going to be there. >> That's the crux of it too. >> It's absolutely a cutthroat industry, but I think one of the things I'm seeing, I've been in Silicon Valley for 22 years, less three years for a stint at Microsoft, I've actually started to see the community become more self-reflective and like, if we can have cutthroat competition in corporations, we don't have to make that personal. 'Cause every likelihood of open source projects is you're employed as a professional engineer at a company, and that employment agreement might change. Especially in containers, right? Great container developers you'll see they move from one company to another, whether it's a giant company like Google, or whether it's a big startup like Docker, or any range of companies. Or Red Hat. So, this sort of general sense that there is a community is starting to help us make better open source, and you can't be effective in a community if you don't have empathy and you don't start focusing on understanding code of conduct community norms. >> Sam, I'm curious how you look at this spectrum of with this complexity out there, how much will your average customer, and you can segment it anywhere you want, but they say, okay I'm going to engage with this, do open source, get involved, and what spectrum of customers are going to be like, well, let me just run it on Google because you've got a great platform, I'm not going to have Google engineers and you guys have lots of smart people that can do that in any of the platform. How do you see that spectrum of customer, is it by what their business IT needs are, is it the size of the customer, is there a decision tree that you guys have worked out yet to try to help end users with what do they own, what do they outsource? It's in clouds more than outsourcing these days. The deal of outsourcing was your mess for less, and this should be somewhat more transformational and hopefully more business value, right? >> Yeah, Urs Hölzle, who's our SVP of Technical Infrastructure, says, the cloud is not a co-location facility. It is different, it is not your server that you shipped up and you know, ran. It's an integrated set of services that should make it incredibly easy to do computing. And we have tons of very intelligent women and men operating our cloud. We think about things like how do you balance velocity and reliability? We have a discipline called site reliability engineering. We've published a book on it, a community is growing up around that, it's sort of the mainstream version of dev ops. So there are a bunch of components that any company at any size can adopt, as long as you need both velocity and reliability. This has always been the tyranny of the or. If I can move fast I can break things, but even Mark Zuckerberg recently said you know, move fast and break fewer things. Kind of a shift, 'cause you don't want to break a lot of people's experience. How do you do that, while making sure that you have high reliability? It really defies simple classification. We have seen companies from startups to mom and pop shops, all the way to giant enterprises adopting cloud, adopting Google cloud platform. One of the big draws is of course, data analytics. Google is a deeply data intensive business, and we've taken that to eleven basically with machine learning, which is why it was so important to explain tense or flow, offer that as open source, and be able to move AI forward. Any company, at any size that wants to do high speed, high scale data analytics, is coming to GCP. We've seen it basically break down into, what's the business value, how close is it to the decision maker, and how motivated is an engineer to learn something different and give cloud a try. >> Because the engineer has to get better at working with the data, understanding the data, and deriving the right insights from the data. >> You're exactly right. Engineers are people, and people need to learn, and they need to be motivated to change. >> Sam, last question I have for you is, you've been involved in many different projects. We look at from the outside and say, okay, how much should be company driven, how much does a foundation get involved? We've seen certain foundations that have done very well, and others that have struggled. It's very interesting to watch Google. We'd give you good as we've talked on the Cube so far. Kubernetes seems to be going well. Great adoption. Google participates, but not too much, and Red Hat I think would agree with that. So congratulations on that piece. >> Sam: Thank you. >> What's your learnings that you've had as you've been involved in some of these various initiatives, couple foundations. We interviewed you when you were back at the Cloud Foundry, and things like that, so, what have you learned that you might want to say, hey, here's some guidelines. >> Yeah, so I think the first guideline is the core of a foundation is, the core purpose of a foundation is bootstrapping trust. So where trust is missing, then you will need that in order to create better contribution and higher velocity in the project. If there's trust there, if there's a benevolent dictator and everyone says that person's fine or that company's fine, then you won't necessarily need a foundation. You've seen a lot of changes in open source startups, dot coms that are also a dot org, shifting to models where you say well, this thing is actually so big it needs to not be owned by any one company. And therefore, to get the next level of contribution, we need to be able to bring in giant companies, then we create trust at that next level. So foundations are really there for trust. It's really important to be strong enough to get something off the ground, and this is the challenge we had at Cloud Foundry, it was a VMware project and then a Pivotal project, and many people believe this is great open source, but it's not an open community, but the technology had to keep working really well. So we how do we have a majority contributor, and start opening up, in a thoughtful process and bringing people in, until you can say what our target is to have the main contributor be less than 50% of the code commits. 'Cause then the majority is really coming from the community. Other projects that have been around for longer, maybe they started out with no majority. Those organizations, those projects tend to be self-organizing, and what they need is just a foundation to build a place that people can contribute money to, so the community can have events. So there's two very different types of organizations. One's almost like a charity, to say I really care about this popular open source project, and I want to be able to give something back, and others are more like a trade association, which is like, we need to enable very complex coordination between big companies that have a lot at stake, in which case you'll create a different class of foundation. >> Great, well Sam Ramji, thank you so much for being with us here on the Cube. I'm Rebecca Knight, and for your host Stu Miniman, please join us back in a bit. (futuristic tone)