 Live from Boston, Massachusetts, it's theCUBE, covering Red Hat Summit 2017, brought to you by Red Hat. Welcome back to theCUBE'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. I really appreciate it. It's too 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 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, right? 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, right? There's layers of technology architecture. In fact, you could think of it as technology archeology, as I mentioned in the keynote, right? We don't want to create a new genre of people called programmer archeologists, right? Who have to go digging. I'm picturing them just chipping away. I don't think it'll be as exciting as Indiana Jones. Digging through the layers of the stack is not really what people want to be doing at their time. Temple of the Lost Colonel. I love it. Yeah, so Sam, you know, it's interesting to kind of see, you know, I was at the Google Cloud event, you know, 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, you know, everybody has their cloud. Come on, you want to lock everybody and you've got the best technology. Therefore, you know, why isn't it just, you know, being open because it's great to say open and people will trust you. You know, I'll explain that. You know. Yeah, you know, puppies, freedom, apple pie. Exactly, right? Yeah, yeah. So there's a couple sides to that. So one, we think the cloud is just a spectacular opportunity, we think, you know, about $1.2 trillion 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, right? It's sort of exponential versus logarithmic. It's kind of 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. Like, 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, right? 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 finance community, you 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 debt. We didn't fund it, right? We kind of got these ideas baked and then kind of moved on. There's another OCI now. So 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, right? Can't build yourself. Second, we said it'll have open access. There'll be no barriers to enter or exit, right? 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 because 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, right? 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. It's great. So we did an event with MIT a little while back. We had Marshall and Ben Olstein, Professor at BU, I know you know, he's an advisor to Cloud Foundry, and he talked about those platforms and it was interesting to watch. 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 the adoption, but less revenue. So not sure it's just, yeah. And interestingly, we run those curves and you kind of see that same logarithmic versus exponential shift happening in Android, right? So we've seen some, I don't have the latest numbers in 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 in public cloud. Thank you. Apologize. Sorry, I'm on a little bit of a jab here where I'm trying to tell people the collective noun for technologists is not guys. It could be people, it could be folks. Internally, we use squirrels from time to time just to remind people. So when I touch the cloud squirrels, Microsoft has embraced open source. Amazon has an interesting relationship and 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 and we say, okay, if I want to be able to live across many clouds or in my own data centers, Kubernetes is later 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 in choice effectively is a spectrum of effort, right? If it's incredibly difficult, it's the same as not having 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 Plurry. I don't want to lose you in WordSoup, LinkerD, ContainerD, 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 distant clouds that you can have other applications, other capabilities layered on top of it. So this permissionless innovation idea is getting reborn in the cloud era. Not on top of TCPIP would take that for granted, but on top of Kubernetes, right, and all of the linked projects. So yeah, that's a big part of it. I want to continue on with that idea of permissionless 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 are synonymous with engineers. 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 I think 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 in the same project, you would overwhelm your competition, right? 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 had a single company. 10,000 people, 10,000 engineers share the copyright to the Linux kernel. At no point have they worked at the same company and no point could a company have afforded to get all of them together. So this economic imperative that kind of marks what I think was the first half of the 30 years of open source that we've been in. The second half has been sort of more us all waking up and realizing open source has got to be inclusive, right? 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, right? If we get turned off of building our great ideas into software because the community has, 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 like I'm not going to be there. And it's a cutthroat industry, 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, we can have cutthroat competition in corporations. But we don't have to make that personal because 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 like 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. I'm curious how you look at the spectrum of with this complexity out there, how much will your average customer and you could 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 you 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 and you have 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 it, 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 kind of in clouds more than outsourcing these days. The old outsourcing was you're a mess for less and this should be somewhat more transformational and hopefully more business value, right? There's Horsley who's our SVP of technical infrastructure says the cloud is not a co-location facility, right? It is different. It is not your server that you shipped up and 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 DevOps. 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, right? There's kind of a shift because you don't want to break a lot of people's experience. How do you do that? While making sure that you have higher liability. 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's a deeply data intensive business and we've taken that to 11 basically with machine learning, which is why it was so important to explain TensorFlow, 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. Yes. A lot of, 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 kudos. We've talked on theCUBE 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. Thank you. What's your learnings that you've had as you've been involved in some of these various initiatives? Couple of foundations, we interviewed you back when you were 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, right? You've seen a lot of changes in open source startups, dot coms that are also at 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 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, because 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. 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, and in which case you'll create a different class of foundation. Great, well, Sam Rajee, thank you so much for being with us here on theCUBE. I'm Rebecca Knight, and for your host, Stu Miniman, please join us back in a bit.