WEBVTT - How IBM and Red Hat Are Transforming IT 0:00:04.240 --> 0:00:07.240 Welcome to tech Stuff, a production of I Heart Radios, 0:00:07.320 --> 0:00:14.280 How Stuff Works. Hey there, and welcome to this special 0:00:14.520 --> 0:00:18.680 Bonus sponsored episode of tech Stuff. I'm Jonathan Strickland. I'm 0:00:18.680 --> 0:00:20.760 an executive producer with How Stuff Works and I Heart 0:00:20.840 --> 0:00:23.479 Radio and I love all things tech and back in 0:00:23.640 --> 0:00:28.240 July two thousand nineteen, IBM completed it's acquisition of the 0:00:28.280 --> 0:00:32.560 company red Hat, famed for its work in open source software. 0:00:32.840 --> 0:00:36.200 The company's invited me out to red Hat headquarters, which 0:00:36.880 --> 0:00:40.120 does in fact have a big red hat on it, 0:00:40.520 --> 0:00:43.160 to talk about why the company has made this move, 0:00:43.479 --> 0:00:46.600 how they plan to work together, and ultimately what does 0:00:46.640 --> 0:00:50.560 this mean for all of us? And so in this episode, 0:00:50.560 --> 0:00:52.960 you're going to hear sections of an interview I did 0:00:53.000 --> 0:00:56.640 with IBMS Steve Robinson and red hats a Chesh Badani, 0:00:57.000 --> 0:00:59.160 and I'll be popping in and out to give a 0:00:59.200 --> 0:01:02.360 bit more content text and explanation. But first I want 0:01:02.400 --> 0:01:05.440 to set the stage a bit. Now. We're mainly going 0:01:05.480 --> 0:01:09.520 to talk about cloud computing and open source software in 0:01:09.560 --> 0:01:12.479 this conversation, and the reason that this is a big 0:01:12.520 --> 0:01:15.560 deal is that more companies are putting more of their 0:01:15.600 --> 0:01:18.240 operations on the cloud, and there are a lot of 0:01:18.280 --> 0:01:21.000 different reasons to do this. One is to make sure 0:01:21.160 --> 0:01:25.800 that the services they provide are available whenever and wherever 0:01:25.959 --> 0:01:28.520 the end user needs them, whether the end user is 0:01:28.520 --> 0:01:31.360 someone else in the company, a different company, or a 0:01:31.360 --> 0:01:36.319 consumer like you or me. Another reason is to maximize resources, 0:01:36.360 --> 0:01:40.280 and there are tons of other reasons besides those that 0:01:40.400 --> 0:01:44.440 companies do this. What about the average user? You know, 0:01:44.480 --> 0:01:48.080 I don't run a global company with worldwide service, so 0:01:48.280 --> 0:01:51.320 why do I care about all this? Well, for me, 0:01:51.680 --> 0:01:55.440 it's about the utility and availability of the apps I 0:01:55.600 --> 0:01:58.360 run on all these different devices, whether it's a computer 0:01:58.640 --> 0:02:01.720 or a mobile phone, a tablet, whatever it might be. 0:02:02.240 --> 0:02:05.520 More of those apps are tapping into lots of different 0:02:05.560 --> 0:02:09.480 aspects that a company is involved with. So a bank, 0:02:09.600 --> 0:02:11.920 for example, could have an app that allows you to 0:02:11.960 --> 0:02:14.960 access your bank account. You can make transfers, you can 0:02:15.000 --> 0:02:17.639 pay bills, you can check your reward status on any 0:02:17.680 --> 0:02:19.360 credit cards you might have, You might be able to 0:02:19.400 --> 0:02:22.760 apply for loans, and more. To the end user, it 0:02:22.840 --> 0:02:25.239 might seem like all that stuff just sort of lives 0:02:25.560 --> 0:02:29.120 in the brick and mortar building that the bank we 0:02:29.280 --> 0:02:32.320 use happens to be located in, But in reality, those 0:02:32.320 --> 0:02:36.240 services might be spread across numerous computer systems all over 0:02:36.280 --> 0:02:39.040 the place. Some of them might be on premises at 0:02:39.040 --> 0:02:41.880 the bank itself, some might be in a privately managed 0:02:41.960 --> 0:02:45.080 data center off site. Some might depend upon large cloud 0:02:45.160 --> 0:02:49.000 computing services run by big companies. So there's a whole 0:02:49.080 --> 0:02:52.600 variety out there now. As an end user, I just 0:02:52.680 --> 0:02:56.560 expect that stuff to work. I expect all those services 0:02:56.600 --> 0:03:00.680 to be integrated into the app seamlessly, and it's frustrating 0:03:00.680 --> 0:03:03.080 when that's not the case, right like when you try 0:03:03.120 --> 0:03:06.040 to do something and either there's a long wait time 0:03:06.240 --> 0:03:08.680 or it doesn't work the way you expected. But the 0:03:08.720 --> 0:03:11.720 cloud computer landscape it's a complicated one for reasons that 0:03:11.760 --> 0:03:13.960 we're going to get into in the discussions I had 0:03:13.960 --> 0:03:18.359 with Steve in a chef. So making this happen all 0:03:18.400 --> 0:03:22.320 the stuff working together isn't as easy as just inserting 0:03:22.360 --> 0:03:26.840 a few links between services. So let's get started. I 0:03:26.919 --> 0:03:30.400 began with what seems like a simple question but is 0:03:30.680 --> 0:03:36.360 actually fairly complicated. So I'm very pleased that I get 0:03:36.400 --> 0:03:40.400 to speak to two experts on this subject because about 0:03:40.440 --> 0:03:44.080 a decade ago I wrote more than a dozen articles 0:03:44.160 --> 0:03:49.400 all about the concept of cloud computing. Back then, cloud computing, 0:03:49.440 --> 0:03:52.720 at least for the mainstream, was just creeping into the 0:03:52.760 --> 0:03:55.960 public consciousness and there was a lot of confusion about it. 0:03:56.520 --> 0:03:59.800 And I think over the years everyone has a better 0:03:59.800 --> 0:04:02.080 and standing of what cloud computing is. But the problem 0:04:02.120 --> 0:04:05.360 is everyone has a different understanding of what cloud computing is. 0:04:05.680 --> 0:04:09.240 So can we talk about the definition of cloud computing 0:04:09.240 --> 0:04:13.120 and how that has actually evolved over time? Be happy 0:04:13.160 --> 0:04:15.400 to and I think you you again, you hit the 0:04:15.440 --> 0:04:18.360 nail on the head with regards to I think it's 0:04:18.360 --> 0:04:22.000 one of the most amorphous definitions out there. You ask anybody, 0:04:22.080 --> 0:04:24.480 I think they've got a different view. And I think 0:04:24.480 --> 0:04:27.240 around a period of time, at least in an IBM's view, 0:04:27.440 --> 0:04:31.160 is is that it's one that's continually redefining, and it's 0:04:31.200 --> 0:04:34.600 probably in a phase right now where it's being redefined 0:04:34.760 --> 0:04:38.000 as well. I think in most cases people originally assumed 0:04:38.120 --> 0:04:42.160 an associated cloud with the large public clouds, you know, 0:04:42.279 --> 0:04:47.159 the multi tenant hyper scalers and UH And it reminds 0:04:47.160 --> 0:04:49.800 me a little bit like the early days of the Internet. 0:04:49.880 --> 0:04:52.120 You know, if you if you go back to UH 0:04:52.400 --> 0:04:55.680 the Internet, you had extra net, you had internet, you 0:04:55.720 --> 0:05:00.240 had public Internet, you had private Internet, and before long 0:05:00.320 --> 0:05:02.120 you started to see most of the vendors start to 0:05:02.240 --> 0:05:05.080 rally around a small set of standards T C P 0:05:05.200 --> 0:05:07.880 I P H, T M L, and before long it 0:05:08.000 --> 0:05:10.800 just became the Internet. You know, you would serve up 0:05:10.800 --> 0:05:12.800 a U R L and you really didn't care where 0:05:12.800 --> 0:05:16.120 the server was that was serving up the content behind it. 0:05:16.240 --> 0:05:17.919 It could be in your data center, could be on 0:05:18.000 --> 0:05:21.160 go Daddy, could be wherever that uh, it could be 0:05:21.200 --> 0:05:24.159 in one country versus another. It just became the Internet. 0:05:24.400 --> 0:05:26.120 And I think that the cloud we're kind of ad 0:05:26.160 --> 0:05:28.240 that position to. I think the cloud is going to 0:05:28.960 --> 0:05:31.719 start to expand to be almost anywhere that I've got 0:05:31.760 --> 0:05:35.359 compute and data capabilities. And we've seen this this whole 0:05:35.440 --> 0:05:39.800 rally around a certain set of standards really driving that 0:05:39.920 --> 0:05:42.760 and driving that at a speed that's just unbelievable. Right now, 0:05:43.160 --> 0:05:45.440 I think, you know, the adoption of lenox, I think 0:05:45.480 --> 0:05:49.960 the whole history of containers and the maturity of containers, 0:05:50.000 --> 0:05:52.760 which are you know, kind of you know, finer grained 0:05:52.839 --> 0:05:56.040 virtualization that allows me to to have code and move 0:05:56.080 --> 0:05:58.880 it around and pack the middlewhere into it, etcetera. And 0:05:58.920 --> 0:06:01.360 then finally kubernet ease that gives me the ability to 0:06:01.480 --> 0:06:04.880 orchestrate and manage those containers. Are kind of that becoming 0:06:04.880 --> 0:06:07.640 that Lingua franco. You know, I think we all of 0:06:07.680 --> 0:06:11.760 the major vendors are now kind of embracing those three standards. 0:06:12.040 --> 0:06:15.159 I think there's probably over forty to fifty different distros 0:06:15.200 --> 0:06:18.279 of coube today and that's now I think kind of 0:06:18.279 --> 0:06:20.480 turning it into cloud. I Can I do cloud in 0:06:20.480 --> 0:06:22.640 my data center? Sure, there's a lot of things I 0:06:22.680 --> 0:06:25.080 can do. I can run containers, I can run Kubernetes, 0:06:25.120 --> 0:06:27.279 I can build a p I S, I can have 0:06:27.360 --> 0:06:29.360 always on, I can do a lot of cloud native 0:06:29.360 --> 0:06:32.320 concepts right in the data center. Can I do a 0:06:32.400 --> 0:06:35.440 dedicated cloud that may be set up and assigned to 0:06:35.680 --> 0:06:38.640 a single client or a single customer. Yep. You now 0:06:38.680 --> 0:06:40.640 have been able to to do cloud concepts and put 0:06:40.640 --> 0:06:43.320 a single customer boundary around it as well. And then 0:06:43.360 --> 0:06:45.120 you've got the hyper scale ers that can do that 0:06:45.200 --> 0:06:48.039 for a wide range and never know where. You know, 0:06:48.080 --> 0:06:51.560 my my my machine, maybe in one data center one day, 0:06:51.560 --> 0:06:53.640 in one data center the next day. So I think 0:06:53.760 --> 0:06:57.479 all of this is becoming the cloud, and uh, I 0:06:57.480 --> 0:07:00.080 think within the next couple of years, cloud will be 0:07:00.160 --> 0:07:04.520 anywhere that I'm doing kind of cloud native properties independent 0:07:04.560 --> 0:07:07.280 of its its final locality here. And this has kind 0:07:07.279 --> 0:07:09.800 of been the real basis of some of the work 0:07:09.840 --> 0:07:12.800 you guys have been doing the red house strategy the right. Yeah, yeah, 0:07:12.840 --> 0:07:17.120 And you're write about the definition of cloud search changing, right, 0:07:17.160 --> 0:07:21.120 So from this notion of cloud computing is when it 0:07:21.320 --> 0:07:26.280 just happened on somebody else's computer, right or somewhere else. 0:07:26.480 --> 0:07:28.440 And you know, if we go back, right, if you 0:07:28.480 --> 0:07:32.760 can ask yourself, look, where were people's expectations of this frame, right? 0:07:33.360 --> 0:07:36.280 Were they in the P two P sharing? You know, 0:07:36.320 --> 0:07:38.720 if anyone remembers that, right, So there's notion of kind 0:07:38.760 --> 0:07:43.520 of you know, music sharing or streaming um or or 0:07:43.520 --> 0:07:45.800 even this notion that you had with regard to well 0:07:45.840 --> 0:07:48.080 I can get my email and that's being served over 0:07:48.080 --> 0:07:50.480 the internet. And then you know, people to equate the 0:07:50.480 --> 0:07:54.040 Internet to the cloud. And so I'll sort of taking 0:07:54.080 --> 0:07:55.960 people the different sort of you know, aspect of that 0:07:57.080 --> 0:08:00.960 from you, Steve, because I think people expectations for cloud 0:08:00.960 --> 0:08:04.200 competing we're also computing. We're also sort of shaped around 0:08:04.760 --> 0:08:07.880 being able to access software from anywhere they were, right, 0:08:07.920 --> 0:08:09.600 So in the past, WHEA was Hey, I'm locked down 0:08:09.600 --> 0:08:12.960 to particular desktop or particular laptop or machine write a 0:08:12.960 --> 0:08:15.000 physical location. And now you can say, well, I'm free 0:08:15.040 --> 0:08:17.200 now right now, I can you know, get my information 0:08:17.200 --> 0:08:19.160 wherever and you know, the same data I could get 0:08:19.200 --> 0:08:20.960 from a laptop. You know, I can be on the go, 0:08:21.600 --> 0:08:24.080 you know, hiking in Peru, and I can access at 0:08:24.080 --> 0:08:27.080 the same time too. Having said all that, I think 0:08:27.160 --> 0:08:30.920 also the definition of cloud or the sort of expectation 0:08:30.960 --> 0:08:33.440 cloud or sort of shifting to new areas right and 0:08:33.480 --> 0:08:37.960 to all call out around security and privacy. Increasingly we're finding, 0:08:38.360 --> 0:08:40.520 especially red hat, we're seeing customers sort of you know, 0:08:40.600 --> 0:08:43.880 talking about you know, inasmuch as a fine value from 0:08:43.880 --> 0:08:47.240 being able to take advantage of you know, deploying applications, 0:08:47.320 --> 0:08:50.319 running them, thinking avoute, all the new technologies you talked about. 0:08:50.720 --> 0:08:53.920 It's also about, you know, is this secure? You know, 0:08:54.080 --> 0:08:56.079 is this something you know, if I'm audited that I 0:08:56.120 --> 0:08:58.800 can kind of stand behind u, you know, is this 0:08:58.920 --> 0:09:01.400 complying with the regular lation and the governance of the 0:09:01.400 --> 0:09:04.640 particular region that I'm working with? And then ultimately, right 0:09:04.679 --> 0:09:06.400 are we making sure I think maybe you know you've 0:09:06.400 --> 0:09:09.080 talked about this before. Stay around gdp R or privacy 0:09:09.160 --> 0:09:11.840 or regulations that are put in place to ensure that 0:09:11.960 --> 0:09:14.880 when customers and you know, be the individual consumers, are 0:09:15.000 --> 0:09:18.200 actual enterprises, we're meeting the requirements that they've put in 0:09:18.280 --> 0:09:22.280 place to us as providers. This is a good spot 0:09:22.480 --> 0:09:24.880 for me to jump back in here and explain some 0:09:24.960 --> 0:09:29.880 basic concepts like containers and kuberneties. You may remember I 0:09:29.920 --> 0:09:33.400 did an episode not long ago about virtualization, and the 0:09:33.400 --> 0:09:36.920 concept of virtualization is to use software to create a 0:09:37.000 --> 0:09:41.960 virtual machine on top of an actual, real physical machine. 0:09:42.040 --> 0:09:44.400 And when I say machine, I'm really talking about computers. 0:09:44.840 --> 0:09:46.640 And there are lots of different reasons that you would 0:09:46.679 --> 0:09:48.960 want to build a virtual computer on top of a 0:09:49.000 --> 0:09:52.280 physical computer. You might want to have a virtual machine 0:09:52.280 --> 0:09:56.120 dedicated to running a specific application, for example, and you 0:09:56.160 --> 0:10:00.480 want it completely separated from any other process running on 0:10:00.520 --> 0:10:04.440 the physical hardware itself, and the application might not be 0:10:04.520 --> 0:10:07.000 so demanding that would take up all, or maybe even 0:10:07.000 --> 0:10:11.480 a significant amount of a physical machine's resources. So if 0:10:11.520 --> 0:10:14.400 you did decide I'm just going to buy a server 0:10:14.800 --> 0:10:17.440 and that server is just going to run this one app, 0:10:17.760 --> 0:10:21.160 even though the app only relies on maybe five percent 0:10:21.280 --> 0:10:24.640 of the server's processing power and storage, you would have 0:10:24.679 --> 0:10:28.640 a ton of computing power just sitting idle, essentially going 0:10:28.720 --> 0:10:32.040 to waste. Virtual machines give you the chance to run 0:10:32.160 --> 0:10:35.600 data centers more efficiently with less idle time. On computers, 0:10:35.640 --> 0:10:39.280 you could have multiple virtual machines on the same physical device, 0:10:39.920 --> 0:10:43.080 and that way you're maximizing the use of that physical 0:10:43.160 --> 0:10:48.360 hardware and you're minimizing downtime. This is increased efficiency, better savings. 0:10:48.400 --> 0:10:52.960 It just makes more sense. Containers are similar to virtualization 0:10:53.040 --> 0:10:56.319 in many ways. A container sits on top of an 0:10:56.360 --> 0:11:00.320 operating system on a computer, and containers hold all the 0:11:00.360 --> 0:11:05.760 components necessary to run some bit of code in isolation 0:11:05.880 --> 0:11:09.040 of everything else. And you can have multiple containers on 0:11:09.080 --> 0:11:12.360 the same machine, each in its own protected environment, on 0:11:12.440 --> 0:11:15.240 the same operating system, so you don't need a bunch 0:11:15.320 --> 0:11:18.400 of virtual machines on the same physical hardware. You could 0:11:18.520 --> 0:11:21.280 run containers on virtual machines, but you could also run 0:11:21.280 --> 0:11:25.719 containers just on a computer without the virtual machine and 0:11:25.800 --> 0:11:29.240 hypervisor layers, so there's no need to allocate resources to 0:11:29.320 --> 0:11:33.199 apps dynamically because the containers quote unquote contain everything needed 0:11:33.240 --> 0:11:37.120 to run that code. Moreover, it's easy to move those 0:11:37.160 --> 0:11:42.360 containers from environment to environment, so a developer builds the 0:11:42.679 --> 0:11:46.480 some app and puts it into a few containers. The 0:11:46.800 --> 0:11:50.959 different containers are specific parts of what that app does, 0:11:51.440 --> 0:11:53.640 and then it's very easy for the developer to move 0:11:53.720 --> 0:11:57.280 those containers over to a test environment and from there 0:11:57.280 --> 0:12:00.280 to a production environment or deployment to the cloud. You 0:12:00.320 --> 0:12:03.360 can think of containers as keeping things efficient and tidy, 0:12:03.480 --> 0:12:06.000 and they're called that because it's very much like the 0:12:06.040 --> 0:12:08.680 containers you would have in shipping. The whole idea is 0:12:08.679 --> 0:12:12.320 that you've standardized this and it's really easy to move 0:12:12.320 --> 0:12:15.120 it around to wherever it needs to go. Okay, but 0:12:15.200 --> 0:12:18.560 what is Kubernetes. Well, that's a system that's designed to 0:12:18.720 --> 0:12:24.200 manage the deployment, scaling, and management of containerized applications. It's 0:12:24.240 --> 0:12:27.720 not the only one out there. There are other strategies 0:12:27.720 --> 0:12:30.720 for doing this, but it's one that has become incredibly 0:12:30.760 --> 0:12:33.920 popular over the last few years. So an application might 0:12:33.960 --> 0:12:38.600 require the use of several containers. Kubernetes organizes containers for 0:12:38.640 --> 0:12:43.600 applications into groups called pods, nodes, and name spaces. That's 0:12:43.640 --> 0:12:47.120 going from the smallest to largest. So containers your basic unit. 0:12:47.240 --> 0:12:50.280 Then you have pods, the nodes, the name spaces. I'm 0:12:50.280 --> 0:12:52.040 not going to get too much into the weeds here, 0:12:52.200 --> 0:12:55.240 because we get really kind of bogged down. But think 0:12:55.240 --> 0:12:57.760 of this as a way to coordinate all of these 0:12:57.920 --> 0:13:01.240 different containers so that the apps work the way they 0:13:01.280 --> 0:13:03.800 need to and you can easily poured it over to 0:13:03.880 --> 0:13:07.599 whatever environment you need to use. And the use of 0:13:07.640 --> 0:13:11.199 containers and orchestration strategies like Kubernetes is making it easier 0:13:11.240 --> 0:13:13.720 for developers to build and deploy apps that will work 0:13:13.760 --> 0:13:16.920 on any computing environment. All right, now, let's get back 0:13:16.960 --> 0:13:20.880 to my discussion with Stephen a chef. So for the 0:13:20.920 --> 0:13:24.440 average person, I think most people, if they hear about 0:13:24.480 --> 0:13:27.280 cloud computing, they're mostly thinking of public cloud applications. You 0:13:27.440 --> 0:13:31.319 think about cloud storage is probably the number one application 0:13:31.360 --> 0:13:35.199 that they think of us exactly. And then and then 0:13:35.320 --> 0:13:37.640 if they're thinking about the apps that they're running, they 0:13:37.720 --> 0:13:40.840 might have a little bit of appreciation about that as well. 0:13:41.840 --> 0:13:45.840 But I think a lot of people who aren't in 0:13:46.200 --> 0:13:51.120 that world, they hear terms like public cloud and private cloud, 0:13:51.440 --> 0:13:54.560 and that already starts to get a little confusing to them. 0:13:54.559 --> 0:13:57.160 So could you just for a moment kind of talk 0:13:57.240 --> 0:14:00.679 about the difference is what what are those entities and 0:14:00.760 --> 0:14:03.319 what would you use public cloud for versus private cloud. 0:14:03.360 --> 0:14:07.520 If you're let's say, I don't know a global corporation 0:14:07.559 --> 0:14:13.440 that has locations in the EU, for example, Yeah, let 0:14:13.480 --> 0:14:15.840 me do that. So and we'll try to break it 0:14:15.880 --> 0:14:19.840 down whereby we don't get so caught up in definitions 0:14:19.880 --> 0:14:22.320 that we miss the point of where we're trying to 0:14:22.360 --> 0:14:27.760 get to, right, which is um Historically, you know, we 0:14:27.840 --> 0:14:30.000 always dealt with this right. So we we've talked about, 0:14:30.040 --> 0:14:33.560 for example, data centers, and it could be your own 0:14:33.640 --> 0:14:35.800 data center that you managed, could be a third party 0:14:35.800 --> 0:14:37.880 that sort of managed it on your behalf. You might 0:14:37.920 --> 0:14:40.320 deploy some applications on your own, you might have someone 0:14:40.360 --> 0:14:42.720 else deploying on your behalf, and then you should go 0:14:42.760 --> 0:14:46.440 back and forth across them. Now, if you extend that 0:14:46.480 --> 0:14:48.720 out and then you say, well, you know what if 0:14:48.760 --> 0:14:50.560 we started having and I'm going to sort of take 0:14:50.600 --> 0:14:54.240 this if this sort of analogy to its logical conclusion. 0:14:54.760 --> 0:14:58.440 What if we now had a vast pool of compute, 0:14:58.480 --> 0:15:01.760 network and storage, right, and then we dev that up 0:15:01.760 --> 0:15:04.440 to say, some of it lives physically in a certain area, 0:15:04.800 --> 0:15:08.160 managed by a certain party, some live somewhere else managed 0:15:08.200 --> 0:15:11.360 by someone else. You can take advantage of economics. Because 0:15:11.400 --> 0:15:14.720 it shared, multiple parties can use it and then be 0:15:14.800 --> 0:15:17.600 able to say, well, I'll deploy now those applications that 0:15:17.640 --> 0:15:20.480 I have based on policies right now, those policies might 0:15:20.480 --> 0:15:23.440 be cost they might be based on latency, they could 0:15:23.440 --> 0:15:26.680 be based on performance, they might be based on you know, 0:15:26.960 --> 0:15:29.760 we talked about regulation, privacy and governance and so on, 0:15:30.240 --> 0:15:33.320 right and then in that sense, it doesn't really matter 0:15:33.720 --> 0:15:36.240 what we've called it. And this is why I think 0:15:36.320 --> 0:15:38.840 between a red hat and IBM and I think we 0:15:38.920 --> 0:15:41.040 share this vision. And I'm sure Steve you'd agree with 0:15:41.080 --> 0:15:44.040 this right that, you know, the hybrid cloud notion is, 0:15:44.080 --> 0:15:46.760 you know, really the abstraction that we can put in 0:15:46.880 --> 0:15:50.400 front of resources that can be made widely available to 0:15:50.520 --> 0:15:52.960 customers around the world, and then for us to now 0:15:53.000 --> 0:15:55.840 think about what productive things can they do on top 0:15:55.880 --> 0:15:58.760 of that, What new applications can they build? How can 0:15:58.800 --> 0:16:01.520 they integrate both exists stinging around as they have the 0:16:01.760 --> 0:16:03.800 new ones they wanted to build out, How can they 0:16:03.800 --> 0:16:07.600 create great agility and great innovation in vols? Jumping back 0:16:07.600 --> 0:16:10.440 in here again just to clear up a couple more things. So, 0:16:10.520 --> 0:16:13.280 why would a company want to keep some stuff on premises? 0:16:13.640 --> 0:16:17.600 Some in a private cloud and some on a public cloud. Well, 0:16:17.600 --> 0:16:19.280 it has to do with a lot of different stuff, 0:16:19.360 --> 0:16:23.880 including security, governance, and cost. All this data has to 0:16:23.960 --> 0:16:28.920 ultimately live on physical machines somewhere, and it costs money 0:16:28.960 --> 0:16:32.160 to buy and maintain those machines, and they take up 0:16:32.160 --> 0:16:37.600 physical space. So there are limiting factors, mostly money in space. 0:16:37.680 --> 0:16:39.760 The restrict how many computers are going to have in 0:16:39.800 --> 0:16:43.360 your physical location. Now, some stuff you're gonna want to 0:16:43.400 --> 0:16:46.960 keep close to you. Maybe you have some trade secrets 0:16:47.040 --> 0:16:51.119 that you're protecting. Maybe you have private data on customers 0:16:51.160 --> 0:16:54.600 that you don't want leaked out to anybody else. Maybe 0:16:54.680 --> 0:16:57.400 there are specific laws in place that state you have 0:16:57.600 --> 0:17:02.240 to keep certain information under your control and you alone 0:17:02.360 --> 0:17:04.920 are allowed to have access to it. Whatever the motivation. 0:17:05.400 --> 0:17:07.760 You may want some of your data and services running 0:17:07.760 --> 0:17:11.080 on equipment that your team directly manages, so you keep 0:17:11.080 --> 0:17:14.840 all that stuff on premises or on prem We talk 0:17:14.920 --> 0:17:17.399 a lot about the EU and this discussion, because the 0:17:17.440 --> 0:17:20.720 EU has strict rules about what data can and can't 0:17:20.800 --> 0:17:24.040 leave the continent, and in those cases, you have to 0:17:24.080 --> 0:17:27.240 make sure your system respects those restrictions. If you're doing 0:17:27.280 --> 0:17:30.560 business inside the EU, now, you might hire a third 0:17:30.600 --> 0:17:35.200 party to oversee servers running your apps, and that's all 0:17:35.240 --> 0:17:38.480 those particular servers are doing, right you. They aren't running 0:17:38.520 --> 0:17:43.120 any applications for any other client on those particular servers. 0:17:43.400 --> 0:17:46.520 They might all exist in a similar data center, but 0:17:46.640 --> 0:17:50.200 the machines you're using are quote unquote yours alone. You're 0:17:50.280 --> 0:17:54.439 essentially renting them. Your stuff is completely separated from anyone else's. 0:17:55.240 --> 0:17:57.320 Or maybe you've got some services you want to move 0:17:57.359 --> 0:18:01.160 to big public cloud providers, and those solutions might cost 0:18:01.440 --> 0:18:05.760 much less than running the machinery yourself, and the services 0:18:05.800 --> 0:18:09.680 guarantee redundancy. They have multiple machines holding onto your data, 0:18:10.080 --> 0:18:13.000 so if one set of servers go down, other servers 0:18:13.080 --> 0:18:17.200 with the same information can take their place, and this 0:18:17.400 --> 0:18:21.400 takes a lot of the management of that information off 0:18:21.480 --> 0:18:23.920 of your plate. So there are a lot of big 0:18:23.960 --> 0:18:27.720 companies that are using multiple cloud and on premises solutions 0:18:28.000 --> 0:18:31.280 to host their services and their data, and as you 0:18:31.320 --> 0:18:35.320 can imagine, that gets really complicated. Just knowing where stuff 0:18:35.520 --> 0:18:39.320 is is complicated, getting stuff to work together with each 0:18:39.359 --> 0:18:43.200 other on these different platforms is even more so, And 0:18:43.320 --> 0:18:45.760 so you have to figure out how to make all 0:18:45.800 --> 0:18:49.080 this data living in these different environments to play nice together, 0:18:49.480 --> 0:18:52.560 and that's where the concept of the hybrid cloud comes 0:18:52.560 --> 0:18:56.199 into play. Let's get back to Stephen Asches. So this 0:18:56.280 --> 0:18:59.280 kind of gets us into this concept of the hybrid 0:18:59.440 --> 0:19:03.160 cloud strategy. Can you talk a bit more about what 0:19:03.240 --> 0:19:06.800 that is and how that's going to benefit companies? That's 0:19:06.800 --> 0:19:11.119 sactly right. So the part that we sometimes skip over, 0:19:11.160 --> 0:19:12.680 and I think this is kind of you know, where 0:19:12.840 --> 0:19:17.280 hybrid really really shines is far that you know, Steve 0:19:17.320 --> 0:19:19.199 started talking about, right, And I think Steve, you're describing 0:19:19.280 --> 0:19:21.119 this as sort of the two phases, right, you know 0:19:21.200 --> 0:19:24.280 about you know, we're about of our way into the journey. 0:19:24.320 --> 0:19:27.560 We've got any percent to go? Why is that really important? 0:19:27.560 --> 0:19:30.440 It's almost like an iceberg, right, We've got so much 0:19:30.520 --> 0:19:32.600 more to do, and yet we only see the tip 0:19:32.920 --> 0:19:35.720 of what we've done now. If you don't think of 0:19:35.760 --> 0:19:37.720 the world, you know, in a hybrid fashion, when as 0:19:37.720 --> 0:19:39.360 a hybrid you know, I'm sort of gonna call out 0:19:39.359 --> 0:19:41.919 your right at uses a terminology call four footprints, right, 0:19:42.760 --> 0:19:44.840 running something in a physical environment, running something in the 0:19:44.920 --> 0:19:47.960 virtual environment virch your life environment, running it in a 0:19:47.960 --> 0:19:50.680 private cloud, running in a public cloud. If you don't 0:19:50.720 --> 0:19:53.679 have something that stands the four footprints? What are you 0:19:53.720 --> 0:19:59.320 doing right? You are potentially choosing to disregard that any 0:19:59.359 --> 0:20:02.000 percent that you haven't moved over where you can make 0:20:02.000 --> 0:20:06.359 it most productive. Why is it important? Most enterprises of 0:20:06.480 --> 0:20:15.040 any size have large investments in applications, services, processes, people's 0:20:15.040 --> 0:20:18.560 skills that they've made over decades. What happens to all 0:20:18.600 --> 0:20:22.280 of those? Right? And if we aren't able to unlock 0:20:22.320 --> 0:20:25.600 all of that, right, how can we truly deliver innovation 0:20:26.080 --> 0:20:28.760 and the scale that we want while leaving all that 0:20:28.840 --> 0:20:31.600 moroon on the side. Right, So the opportunity to able 0:20:31.640 --> 0:20:33.679 to say, look, I am going to be able to 0:20:33.760 --> 0:20:36.080 bridge you know, existing investments that I've made and I 0:20:36.400 --> 0:20:39.840 obviously worked with the clients you know for decades around this, 0:20:40.400 --> 0:20:42.600 but at the same time expose them to what we 0:20:42.800 --> 0:20:45.800 call you know, cloud native, you know ways of working. Right. 0:20:45.840 --> 0:20:48.840 There's notion of micro services. Right. Let me not build 0:20:48.840 --> 0:20:51.520 out massive applications. Let me build them in smaller and 0:20:51.560 --> 0:20:53.600 more actual fashion. Steeve talked about you and having a 0:20:53.720 --> 0:20:56.439 PI is available right to make it just easier for 0:20:56.440 --> 0:20:59.000 different applications to to interact each other and be able 0:20:59.040 --> 0:21:01.800 to share information data across them, but to be able 0:21:01.840 --> 0:21:04.199 to realize all that promise, and we've got to be 0:21:04.280 --> 0:21:07.760 able to provide a hybrid cloud platform that spans both 0:21:08.080 --> 0:21:10.359 the new environments that we're all trying to go towards 0:21:10.760 --> 0:21:13.960 as well as the existing applications and environment that we 0:21:13.960 --> 0:21:17.120 have running today. And I think it's an interesting case 0:21:17.119 --> 0:21:20.280 in point. Right when we announced the acquisition intent of 0:21:20.600 --> 0:21:23.720 red Hat, I had a ce IO executive VP of 0:21:23.720 --> 0:21:27.560 a large fast food restaurant chain called me up and 0:21:27.560 --> 0:21:29.760 he says, okay, Steve, give me the scoop. Why did 0:21:29.800 --> 0:21:32.239 you do it? And I had to tell him. I said, well, 0:21:32.320 --> 0:21:34.679 let's just take a look at what we're doing with you. 0:21:34.840 --> 0:21:37.720 And at that point in time, um, we were putting 0:21:37.720 --> 0:21:40.719 a server in every single one of those restaurants, were 0:21:40.720 --> 0:21:44.040 putting a private cloud in every single one of his restaurants, 0:21:44.280 --> 0:21:46.159 and what we were attaching that we were attaching our 0:21:46.160 --> 0:21:48.760 Watson services to do the ordering so that you just 0:21:48.800 --> 0:21:51.840 speak in but automatically handle it, etcetera, saving the labor 0:21:51.920 --> 0:21:54.439 on that, etcetera. We had also outfitted every one of 0:21:54.480 --> 0:21:56.920 his stores with IoT cameras, so all of a sudden, 0:21:56.920 --> 0:21:59.480 you see the bustload of high school students start to 0:21:59.520 --> 0:22:01.760 come in. He felt that if he had just a 0:22:02.040 --> 0:22:05.560