On the new discipline of dev ops
Sam Ramji: The most advanced companies are creating this blended discipline of dev ops, where the application development and the IT operations people drive the business forward at the speed that's required by their market.
Quentin Hardy: How is cloud computing affecting that?
Ramji: Cloud computing started out as sort of a shadow IT. It was the developer's best friend. With a credit card and an API call, you could get a server. Now cloud development is starting to show up, and the buyer is actually the VP of infrastructure, who's the same person who's accountable for all the capital expenses and the operations people. So, the decisions are getting more complex. It's blurring the line between the resilient systems that power the business mainframes, which you can't really outsource, and the new capabilities in cloud to have elastic capability — new forms of analytics and machine learning — and manage it all, creating a single discipline, and starting to blend the teams, and be able to create that bridge, so that you understand, on both sides, what the struggles are.
Hardy: So ideally you create an IT side of people who are totally attuned to what the resource needs are and don't have to get into the wire pulling, and rack maintenance, and security patch hassles, because that's all been automated. But they're still doing IT stuff.
Hardy: Just in different context.
Hardy: On the developer side, what's happening?
Ramji: Ten years ago we were in the middle of the biggest wave of outsourcing of developers in IT because it was considered a cost center. Now we've started to realize, "No, this is actually the nervous system of a business."
Hardy: They speak to the company's comparative advantage and try and express it, as fully as possible, by using AI tool sets, or fast mobile development, or global reach of databases — whatever you want to call it.
Ramji: If you take an airline, it has particular concepts. An airline has concept of a flight, has a concept of a passenger. It has the distinction of a missed flight or a late flight. Every single business has its own system of cognition, and developers in a company aren't just working with IT ops to make sure the infrastructure works. They're mapping these core business problems, these constructs that are unique to that company, into ways that its customers, and its partners, and its employees can interact with. Right? This is this distributed cognition system.
Hardy: How does this change the way one should manage developers?
Ramji: Number one, in-source development as fast as possible. Hire those developers, make them full-time employees.
Hardy: Hold them close.
Ramji: Get them committed to the company. Second, mix them up. Embed developers directly into the business, so that they are learning the business concepts. If you're a 50- or 100-year-old company, you've got some deep thoughts about tractors and fertilizers and, you know, satellite radar and what all these things mean. That needs to become second nature to your developers, because those thoughts that your business has, are thoughts that your marketers, and your product managers, and your support people have. Those thoughts need to be shared by the developers so they can be put directly into code.
On open cloud and keeping up
Ramji: The fascinating thing about open source — it's a little bit like Thomas Jefferson said: "The power of knowledge is that if I light my candle to yours, I've lost nothing by it."
Ramji: Right, but your candle's now lit. So there's a positive sum game, and we see network effects in open source with the ability to learn collectively tens or hundreds or thousands or hundreds of thousands or millions of people who are using this particular software. Subset of that knowledge is getting in and improving each of those pieces of software.
Hardy: Let's say I'm the head of a medium-sized company in Memphis or Oklahoma City...
Hardy: Or Denver. How do I really stay on top of all this and should I?
Ramji: You should stay on top of it in the sense that hiring developers is a competitive advantage. Do you need to know exactly how Cassandra replicates its information? Absolutely not. Should you have a sense of, you know, what are the top ten new application development infrastructures? You probably should. People who are putting that on their resume are signaling to you, "I've got some experience. I'm effective. And I'm continuing to learn new things." You want those people in your company.
Hardy: And how would you recommend a typical viewer of this video to stay on top of what's happening in software development technologies?
Ramji: You know, there's various ways to read the world. Right, there are very good journals. There are very good blogs to be able to follow. I tend to curate my Twitter feed and just kind of keep an eye on that every few days and look for people who are talking about dev ops. I read things like "The New Stack." Pay attention if you want to get kind of a bite-sized chunk. The RedMonk folks in particular blog pretty common — pretty constantly. And keep trying to put their thoughts into sort of useful, purposeful form. I think the other thing, though, is you want to be able to make this knowledge yours. So make sure you've identified two or three people in the company who will make it part of their job to really be looking at new stuff. Make it part of the job of some of the management and make sure that you enable and encourage that by having people come present to you.
Hardy: Developers are like everybody else. They yearn to be inspired.
Ramji: Yes, if you have outsourced all your development, you've communicated that it's overhead that has cost reduction impact. If you want to reverse that course, you need to be genuinely curious about developers, things that developers are curious to explore. And you can demonstrate that by having this process light up by questions. During my time at Microsoft, as the Linux and open source team grew and tried to understand our mission and how we can help Microsoft succeed, we learned that Bill had a series of quarterly demos, and it was a huge honor to sit, to spend half an hour with Bill to demonstrate what you were building, or even for us, what we hadn't built, but we were showcasing things from the open source community. Every company has a culture of rewards. What are the social rewards that you can pay to your development teams, to your IT Ops teams to get them to come out and show you what they're doing.
Hardy: You've recently been talking about something called open cloud. How do you describe that?
Open cloud is a view of the long-
term structure for computing.
Ramji: We're really thinking about three things — friendliness to open source. We're thinking about open access, right — open to bring things into this cloud that you want to put there, open to taking things out of this cloud when you want to move them out, which could include your whole estate.
And then finally, open ecosystem. And this is where we have an opportunity to transform businesses and IT as an industry. If the cloud ecosystems evolve in an open and operable and portable way, it forms a single large economy that can continue to grow, again, based on positive sum games.
On Google as a business model
Hardy: You are in charge of the products that go into Google Cloud that enable software developers to build great products for their companies.
Ramji: Yeah, that's right. So, one of the things that inspires me about Google and what our standing is, what we can offer to the world is we've learned this the hard way, right? There's 1,000 steps from a developer needing to write code, to something scaling in production for the nth release.
Every other company doesn't have
to be Google, but they have to be
the best digital version of
themselves. So, we have really an
opportunity and a responsibility
to the industry to help transform
We've had to beat our head on each one in order to make our seven different, billion-user businesses successful. Everybody knows Google is the most extraordinary digital business model in the world.
Hardy: Yeah, we have all this fantastic learning, but we do have to tune it up and make it coherent in a new way.
Ramji: We do. What we've learned is unifying these disciplines and building a coherent system where that workflow actually flows — that's the prize.
So, that's what we're trying to bring to bear.
Hardy: But what are we doing that you find particularly special?
On new applications
Ramji: If you are an application developer, or you're in IT operations, you care about the packaging, standardization, and scale of your workload. For a long time, that was physical servers and that was the old days, very difficult, very complicated. Then it became virtual servers. Now, we've bridged into a new abstraction layer called containers. Containers are a wonderful mechanism for packaging an application or a workload. It's specifies: Here's the application, here are the core dependencies.
Hardy: And by keeping it constrained in just the thing you want to do.
Hardy: Not the thing you have to do.
Hardy: You can deploy and manage essentially at any point in the globe.
On container management and standardization
Ramji: One of the things that makes computing so difficult is for any application you want to build and deploy, tends to have cascading dependencies. Imagining dependencies like roots, right; they keep you stuck in place. Containers clip the roots back down at the pot, and you say, "Well, we can just move this potted plant anywhere we need." So, it's dependency reduction, so that you can copy them a million times, scale them out a million servers, or scale them back down to a hundred servers when the load decreases. So, this is something that's bringing in this era of elasticity. Now, given our expertise there and our contribution to Linux, we've also built a great amount of capability and containers in Google and in Google Cloud. In fact, we created the number one container management project in the world called Kubernetes. So, Kubernetes is open source, and it's proliferating madly everywhere. It's on premises, it's in people's data centers, it's multiple clouds.
Hardy: Open source is smart strategy, because it puts you in a lot of places and a lot of people pulled on, so it has a kind of appeal of a standard.
Ramji: Exactly right. Open source is standardization for the software development community. Industrialization of the construction industry occurred when you started to standardize the tooling you were using. Did you — could you talk about a 2x4? Or did everybody have to mill their own planks? Once you have 2x4s, you have an open supply and you can start to say, well, now we have standardized languages and patterns about which we can build a house. Software developers are really cognitive construction workers, right? They're cognitive carpenters. The more that they can standardize the tools that they're using, and modify them a bit to meet their own needs, the better of a house they can build, the better apps they can build. Sometimes we talk about open source and a CIO says, "Oh, my God, if I use open source does that mean that all the software I have in my company has to be given away?"
Hardy: I'm exposing everything.
Ramji: No, right? What we're saying is, here is a piece of industrialized goods that your developers can use, that they can modify as they see fit.
On quantum computing
Ramji: One thing that is on the very near horizon is quantum computing. So, this year we should see a quantum supremacy event. And what does that mean? That means that in one compute moment, right, in basically less than a second, we will have a quantum computer that can beat the world's fastest supercomputer. We haven't even begun to see what's next. This is what we're going to do in the next few years. What does ten years from now look like? What does 20 years from now look like? And taking it back to developers, how does a developer program a quantum computer? So, there's a whole bunch of cognition that's got to be layered up until we have frameworks to make it easy to program, and then understand, what do we do?
Hardy: But for a standard developer who's a smart guy, the front end won't change; there'll just a be a lot more computation for a lot less cost.
On delivery and statistics
Ramji: Or, you know, or a smart gal. Right? We see increasingly our diversity in who's coming to work and program. I think it will shift, because there's some new thinking that we need to do, and this is similar to the shift in machine learning. And I would actually put it in the same category. Most developers haven't had to deal a great deal with statistics, right? But most ML effectively is statistical regression. We have to understand the statistical toolkit. How is it that we say "this is like that"? Well, there's a statistical correlation. How do we identify out of all the things we could solve, what's the optimal choice in balance of all these variables, right? What's the cost of the material? How hot can it withstand? Right? What does it cost to maintain? How available is it? Quantum can actually interact with this statistical systems, because it can represent all these statistical states simultaneously. So, part of the developer's experience, their toolbox, in the next decade, must expand, and they're going to need to really build statistical competence. It's absolutely crucial that it becomes a cross-functional discipline, because in a modern company, everybody's job should be to think and innovate. So, if your domain is, "I'm a person who understands this domain and I'm thinking," then you should somehow be connected with a software developer, and if you're a software developer, trying to figure out how to build value, you should be looking for thoughts that need to be automated or turned into some screen-based experience, so then people can interact with. And you're not going to come up with those by yourself, sitting in a group of 100 people just like you, right? So, it is really this diversity that's gonna cause companies to benefit from the industrialization of software.
Hardy: At times, this can all feel a little futuristic. How do you advise companies to get started?
Ramji: You should establish a small group with a mission to experiment with ML right now. Three to five people; enough so that you have critical mass. And measure them on a quarterly basis. Say, "What are you discovering, and what business problems are you finding to solve?" And as long as you're solving business problems, the group will stay together.
Hardy: And grow that.
Ramji: The second thing is, we need to radically demystify machine learning. You said it best in the beginning: we tend to make this all look so super futuristic. It's not futuristic at all. This is basic statistics. So, you could say, "Where statistically in my business do I seem to have high error rates?" That's a great place to deploy an ML team that could be a detection that kicks off an alert to a person more efficiently. Reduce the meantime to discovery for the fault. It could be slightly better call routing in your call center. When these calls come in, are we able to dynamically combine a few pieces of data to make a 5% better allocation to a level two versus level 1 tech right away? What does that do to reduce our load and prove our customer stats?