 Well, hello and welcome everyone to this, what I would consider a special edition of in the clouds with Red Hat, because I am your guest host. So my name is Andrew Sullivan, I'm a technical marketing manager with Red Hat, and a close friend and peer of Chris Short, your normal host. So Chris is unable to join us today, so I am filling in and I am very honored to have our guest, Marco Bill Peter join us today. Marco, if you would please introduce yourself. What is your role here at Red Hat? Sure. Well, first of all, hello everybody. It's great to have you listening in here and I'm very honored to be in the in the clouds with you, Andrew. My role at Red Hat is I'm the Senior Vice President of Customer Experience and Operation. Now you probably ask, what the heck is that? And there is an element in there, but it's basically all like customer facing, but not in the sales role. So I'm lining up to the products and technologies of our engineering functions in my team. I have basically support, customer success, technical account managers, and we go into documentation, again, part of customer experience, this security, I think we'll probably hit them security, product security a little bit. That's in my area, there is quality engineering. And I also run like some of the IT for our engineering, like release engineering is in my team. The idea is always like, you want to know how our products work before actually customer hit it. So that's what I do. I've been here a few years, but a few years, I was looking at your profile, your internal profile. I think you are two months less than Matt Hicks. I think it was, he was late, late 2005, you were early 2006. Yeah, you catch that, well, 15 years, I'm 15 years and two months or something like that. Congratulations. That's an impressive span. So you mentioned, like that's a big breath, right? That's a huge organization with a lot of different things going on inside of there. And in my head, I kind of lumped that as, well, we have the field organization, the sales organization who is ultimately responsible for exactly that, right? Getting products to our customers. You kind of take over after the sale is done. And your team, the group of people that work for you are responsible for, as you said, things like support and documentation. How do I actually get this thing deployed and implemented? And how can I help customers use it? And what stuck out to me as a former customer, as somebody who used Red Hat products for a long time before coming to the company, was that you have a team of people who are using our own products. The common phrase is eating your own dog food, but I'm going to use the much more optimistic drinking our own champagne. So I know we have a list of things that we want to talk about. I kind of wanted to diverge a little bit and ask you about how much impact does that have? How meaningful is that practice been inside of your organization? Yeah, I'll give you a very specific example that I think we can share. We run a huge, huge environment that basically is for our engineering team, be it release engineering, be it actually development, be it a specific testing, be it some other stuff. It all runs on a open stack and open shift on top clusters. So literally what a lot of customers do that, right? And for us, it's been like, what's the difficult in setting it up? Oh, we got to change documentation like that. That's unclear. It is basically an applied quality assurance and like a funny anecdote, right? I mean, this is really a large environment. And sometimes we have issues as well, right? And so it's always funny when you point out, oh, yeah, we had this issue. It was down and it turned out to be an open stack. But what do you do engineering to actually fix it? So it actually brings the teams quite a bit together, right? It's not the usual IT. Oh, IT got to do this. IT screwed up. It's more like, oh, this is our product. What do we do? And so I think that's where I find it. It's a huge benefit. It's always a discussion to we, it's the same discussions that customers have, should we say, on a stable release? Should we go like on the latest release, right? It's all these discussions, exactly a customer. And so I think the experience for us is invaluable, right? That we can really like know, hey, this is what customers will see. And can we actually get it done? Yeah, I really love that, that we are the first customer for our own products. And it's important to us that we take that approach because it drives quality into the product. It helps us be empathetic and sympathetic to what our customers are going through. So I really like that. And I like that approach. It's also important, right? And keep in mind, we sell a lot of, our approach is to be open for choice, right? It's open source, but also open for choice. And we have a lot of customers that pick and choose, right? Which is, OK, it's great, right? You run this on that, right? And for us, this is all building our software once together, does it really work together, right? And in the early days of Red Hat, right? Remember, we were like just a Linux company, right? And now we have a massive portfolio. And to keep this portfolio together, you've got to do things differently than we used to do before, right? And so I think that's a big step to seed its integration life. Yeah, just a Linux company seems to be underselling it a little bit when we talk about the early days of Red Hat. So I have sufficiently distracted us. I've sufficiently derailed our conversation here. So I wanted to circle back and ask about, we said you had been at Red Hat for 15 years now. Can you tell us a little bit about your career at Red Hat? How did you start? What was your first experience with Red Hat products? Was it here at Red Hat, or were you a customer or user beforehand? Yeah, let me tell you a story. I think that's crucial on how I got to Red Hat. And I was working for a different company, a big IT company. And I was in the engineering department as well. And we had a Unix product. And I remember this is 2005. One of the customers, a bank, a large bank, was pushing for, we got an upgrade. The hardware moved to the new platform and new Unix. And then our sales team, and this was in Red Hat, this was the other company, was pushing for, you got upgrade to our latest Unix. This is better. And the CIO, I remember well, he told me then, I was kind of the executive sponsor helping this, just being overlooking this bank. And the CIO told me, Mark, your sales team is not listening. I don't want to go to Unix. This is a good moment for me to go to Linux. And then short story, that sales team really didn't listen. I got involved and I did a bake off. I invited, I used to live in Boston at that time. I did bake off, I invited Red Hat, I invited Suze. And that company, that IT company had an industry server, Intel industry server division as well. They had a storage division. So I brought everybody together and we did a two-day workshop. And the customer walked out basically in the end, deciding how I'll do it on your hardware. So we saved the hardware a bit and on Linux, on Red Hat Linux, no enterprise Linux. And then at the same time, I have to say, I was working with Red Hat on the job offer, right? And I remember, well, I got this, eventually I called the CIO and told him, hey, I gotta tell you, I'm leaving this company. And he said, no, you can't do that, Mark. I just set the future on Red Hat Linux on your hardware. I need your insight. We need your help on kind of leading. I told him, it's like, now I'm going to Red Hat. And then he said, oh, that's even better. And so it's been a good journey with the CIO, kind of seeing him over and over different companies and being a good advocate for Red Hat. I joined Red Hat as basically a engineering manager for the support engineering group. So in the past, that was kind of the connection between product engineering and support. So a small team, and we kind of dealt with the most hairy problems that at that time happened in Wall Street with our clients there. But that's kind of my start in the career. And then I took over support, all support, I took over eventually all the functions that I had when I moved in Red Hat. Yeah, it's, as you said, 15 years is an impressive period of time to be at a company, especially a technology company where, I don't know, maybe I spent too much time working around the US government or even around Silicon Valley companies where there's a lot of, it's not all that common. So a question I have for you is one that may seem a little strange at first, but why do you choose to stay at Red Hat? What gets you excited about Red Hat and being here? You know what gets me, it's a really good question, right? And I think everybody gotta be honest, right? That once in a while we have this tendency, oh, I gotta move on, it's 15 years is a long time. But what keeps me here is literally the people and the environment we have. And I always consider myself a customer experience or customer advocate or a trusted advocate for the customer in every company I've worked. And to be at Red Hat, I think that's really meaningful because with our open source model, we gotta be really looking at the customer experience, right? And so it's not, I always joke, customer experience in some companies is in the janitorial services department because you sell the license and the rest doesn't really matter. And I think our model, and by now a lot of the, I would say in the industry today, there's a lot of companies that have a more honest model, be it the consumption model or be it different models that it's not the old license model. But that gets me excited. I have to say it's 15 years and seeing the company grow from 1,000 employees to I think, I don't know what we are, 17,000 employees now. It's pretty cool. It's really pretty cool, right? And on the side, I'm involved in a, I'm on the board of a startup as well that does open source software for drones that keeps me kind of in touch with what are really startups doing and how fast are they moving? And I have to say, I'm really excited that you've worked with a small startup but then you look at Red Hat and in some cases we can be really agile. We obviously have a higher risk. We have got to make sure the revenue and everything, we got to please all our customers. On the hand, we still move, right? And you look at our journey with OpenGift, right? That's in kind of how we evolved it from version to version. And I've seen this from the start when we bought this company Makara, right? With the first iteration on how we approached it and then eventually moved to Kubernetes. It's really exciting to see that story. So I'm grateful that I'm part of this journey, to be honest. Yeah, the word complacent comes to mind. A lot of times when I think of other companies, like you said, they have a licensing model. It's a proprietary product. They made the sale and then they kind of get complacent because the word entrapment isn't the right word but you don't have to focus on it as much. And Red Hat being an open source company, right? Everything that we do is public and we can't be complacent. We have to be constantly driving forward, focusing on customers and what they want and what they need. And I think corporately that's one thing. And as somebody who's been at Red Hat for not quite three years now, one of the things that really just blows me away as an employee is that everybody that I work with, they are constantly driven with that same sense of commitment, right? Nobody gets complacent with where we're at. We always want to do better. We always want to go forward. So it's something that's really, really inspiring to me. So I'm going to change directions a little bit and drive a little bit more. You kind of trailed over into OpenShift territory there, which is something that is of course my focus area as my job, as well as a passion of mine. Yep. So 15 years, right? You've been here since before OpenShift was OpenShift, back when it was OpenShift two in the cartridge days and it was all virtual machines. So with OpenShift three, with OpenShift four, Kubernetes, containers, what are you seeing customers doing? Are they mass adopting everything is going containers? Are they shying away from it? Is it somewhere in between? I would say the last few years, let's say the last two years, which is kind of funny with this pandemic here. I've seen all kinds of customers moving to OpenShift, right? And to change their approach, right? And I think a lot coincides with, a lot of companies just getting more agile, right? They realize that the days of waiting for hardware for three months and having pay performance going back and forth until you get hardware or even a VM to a certain degree, that didn't help anybody, right? And I think that's where I see with a few examples that I know they've seen this, right? That they had to get more agile and they used it that way, right? All of a sudden they have an OpenShift platform and for a developer to kind of put the container together or an application together, put in a container and go live within an hour. It's today, even for a college, like a normal company is possible, right? Like three, four years where we heard those stories, oh, this public cloud provider pushes three times a day after. And today you think I can be a regular company, insurance company, a public utility company, I can do that. That's I think what drives a lot, right? And I think what I've seen as well is, so this agility, this is really exciting to see, right? That a lot of companies see that. I think the other part that you see is some of the older technologies getting to a point that they wonder, it's like, what do we do with that, right? So be it the old J2EE application, right? That they kind of wonder, like, what do we do? And you do have those that kind of stick it in a container, yes, it's not cloud native, I know, but they fix it in ops, they kind of look at that this will run, this will help us. And then they start fixing, moving to more a microservices model, cloud native model. But I think that's where, and you see, obviously, for new stuff, you see customers developing cloud native, but I think that mix and that we allow that, right? It's not like, hey, you've got to use this from the get go, you got to be cloud native from the beginning. I think a lot of our customers use that, put everything in container, move it over and fix it as you go, which I think is a gem of the as well, right? Yeah, and this is a topic that strikes really close to home for me. I was one of those ops guys a decade ago that was responsible for the virtualization infrastructure and it was, no, you can't have a VM in two hours. I need like a week because I got to go through all these ITIL processes and all of this other stuff and I need time to go get coffee. And so do you see as this acceleration has happened, as this agility has increased, right? Which I think is a good word, even though it's sometimes a little buzzwordy, a little overused. What types of challenges do you see? And one of the things that I think gets stereotyped is, we have CIOs reading CIO magazine about how everybody's doing DevOps or everybody's doing containers and all of this and reality is maybe it's a small portion and they're not, not everybody is 100% there, 100% DevOps, 100% containerized. Yeah, I mean, I think you're asking two questions. I think that let me go on the second part first, right? As in, I think a lot of CIOs are, I don't know if it's the CIO push or if it's just basically teams realize we got to get more agile, right? I think there is some elements that was talking to a public company. I don't want to name, but they had this very strict ITL processes and it didn't get them anywhere, right? Then they outsourced everything because they're public together, basically take the lower speeder, right? So they got a big SI in there that kind of controls everything. And the SI obviously makes money of the kind of the processes, right? And so there it wasn't, I don't think that was a push from the CIO or from the C level. It was more from the business kind of, they want to sell more stuff, right? They want to be closer to like the consumers of the stuff. They were like with the developers and like, I can't wait three months or six months or you're going to have this quicker out, right? And especially with the pandemic all of a sudden, hey, we got to have this scheduling tool for the shots. You got to have online, can't wait six months and then like the country will go ballistic, right? And so I think that was started a lot of taking away that the bureaucracy from the past and I do think now a lot of CIOs are excited about that. I was actually skiing with one CIO a few weeks ago and he's probably more, he knows technology probably better than many other CIOs but he was so excited about his move and he did the move from OpenGIF to OpenGIF three. He did that, take some apps, move them in, clean them up afterwards and now they're moving to OpenGIF four and they're using this hybrid approach that they're using. Some will run in OpenGIF in a public cloud provider and some will be probably just stay behind for data reasons. And you saw that CIO was just lighting up as in opportunities and possibilities that gives them and with the consistency, right? That's not like you run something in a public cloud and you have the similar app on premise, right? It's the same stuff basically running. And so I do believe there is a, I don't know if the whole DevOps, if we can just check this off and it's done, I think I wouldn't go and preach about DevOps anymore but I think this, if you see these real examples from customers that you wouldn't think they're not the bleeding edge customers but they're using OpenGIF and containerization and cleaning up the amount of, that's what gets me excited to be honest. Yeah, I've noticed from my position, technical marketing, right? Supporting the field in a lot of ways and supporting our customers. We're seeing that more broad adoption. What's the infamous adoption bell curve? We're entering that majority phase and seeing more and more people, they're not, it's not bleeding edge anymore. The masses quote unquote are understanding containers. And I think that kind of leads me into my next question, which is, are you seeing a change in skill sets or an increase in demand for particular skill sets as that maturity happens? I, well, yeah, they're very good question on skill sets. I think if you look back at the last few years, right? I mean, at first it was like, anybody could spell Kubernetes was kind of like, their market potential increased, right? And I do think we have a more, it's not easy to find Kubernetes skills but it's definitely grown. If I look at the customers specifically, I think initially it was kind of that, oh, you understand containers, how do we shove an old app in a container or what does even cloud native development mean, right? So you got to have those skill sets, which I don't think we, I think that especially on the cloud native development, I think there is still, we still need more training and more schooling and I think also the universe, I just got to push, pull that in. I think there's a long way to go. But what I see, if you look at customers, right? I mean, they started with this more simple approach on how do you get stuff into containers? And maybe they did start with simple web apps that maybe the impact wasn't important, right? As in like, I know one, they show on display stuff that, when trains leave, et cetera, cool stuff, right? But it's not mission, well, it's mission critical if you wait for a train or a bus. But on the other hand, what you see now customers also moving into more critical environments like e-banking and how do you containerize a old e-banking application to work, right? I think that is a whole different, the skill set there comes as in, you got to understand the whole application development or the containerization. You also got to understand security, right? That's a real move then as in like, if you're in an e-banking application, which port can talk to which port, right? Then kind of like be it service, mash, be it the API management really gets critical. So I think that skill set is another one that will come. The more and more you see OpenGIF covering like super critical environments, which it does today, right? I mean, there's a lot of, I would say critical apps in all kind of industries, they use it, right? And I think that will be the security skill set, I think it's the one we security skill set in this context, I think it's a skill set of the future. Do you think that the platforms, so offerings like OpenShift becoming more mature and effectively abstracting and automating a lot of those low level worries away, does that help customers with that? Does it allow them to concentrate on the right things or do we still see a lot of customers that they like to be down in the weeds? They wanna be concerned about those things. I think they need to be concerned about these things. I mean, I think you have a lot of customers that, especially if it's an e-banking, right? I'm sure that the e-banking, there's regulatory requirements, et cetera. So they do need to understand the details, but I mean, if you look at what we did, I think two events, right? Like we acquired the company Stack Rocks, which is a really cool product that helps to identify, what are actually, what do you get a worry about from a security perspective? And then we have posted our partner certification for security vulnerabilities, right? Because right now, if you are the regular customer, you use one of these tools, everything will light up red and you have like thousands of vulnerabilities you got to worry about. And so I think we're trying with that certification, first of all, kind of getting to, yeah. You know, like some companies make money with like showing red, right? If everything is green, why would you buy that product? Now we got to also go one by one through these vulnerabilities as in, oh, does this even apply, match it to Red Hat's vulnerability, right? That the team does a really good job in actually describing how they rate it. And if they do something, if they don't do something, why not, right? And I think they do a good job on doing that. And this partner certification for this vulnerabilities can help them to make it easier. So not everything lights up red and then you got to kind of ignore all the false positives. I think that's really good. And obviously Stack Brocks is a good addition, kind of tied to that. I do think, as I said, service mesh and API management, those are critical things as well that we got to, that I think customers will need to understand. And some will be automated away by OpenGift and some will be probably depending on the application. And I think we kind of flirted around the edges there of something that your team put a lot of work into, which is the vulnerability scanner certification. Yeah. And I'm hitting the enter button to post this across all of the various chats. So, I'd be curious your perspective and your thoughts on why that's important and how that impacts customers when it comes to the security topic, which as we said, it's big. It's something that everybody needs to take into account now. Yeah. I mean, I think we did this certification out of necessity because we got hammered by all these requests as in, oh, everything is red, explain me this and this, right? And so like whatever tool you're using was kind of highlighting that. And in some cases, we saw so bad things, right? As in like something would highlight, oh, this is red because Ubuntu has this promise. Like, well, that's really this tool makes a mistake, right? And so that's where eventually we kind of said, we got to be better and actually telling a partner, hey, this is what they can validate against. They use our data because it was basically one-on-one combat with a lot of customers actually explaining, hey, no, this is why we believe in this rating. This is why it will not impact you. Or vice versa. No, this will impact you and you got to do something. And also with the partners, right? That they would use the wrong sources, et cetera, right? So this certification brings some sanity, I think to everybody, also like to the customers, right? That they can kind of see, oh, this tool has been served. This looks at the certified list from Red Hat is certified. This really helps. This cuts down hours and hours for us, but also for customers. There's something to be said for alert fatigue, whether it's alerts of something is wrong that are just not actually wrong or whether it's security alerts saying, hey, this needs to be investigated when really it doesn't. So again, Well, and then you can think about the vice versa, right? That's in like, you get all the reds that try, in like, my trust will go in a tool like that goes down pretty quickly as in, especially if you check a few, but then you wonder like, so if this tool you can't rely on this tool, what else are the open holes? It doesn't highlight to me, right? So that's what I get worried about in this case. But no, I think there's the vulnerability scanner certificate. It's a great step forward for us to actually help the industry, right? Doesn't, to make, to bring the sanity to a customer. And I want to keep in that thought process. And we've moved from DevOps to DevSecOps is the new buzzword when we think of that term. And do we see challenges associated with that? You know, we, yes, we're working on tools, right? We acquired Stack Rocks, right? All of that other stuff. But I think going from a reactive security posture, right? Hey, I see this vulnerability. I need to take action to a proactive or even preemptive type of approach. Do we see that happening? Are there challenges associated with that? Yeah, I think customers want to be proactive. I think that's where, where I think they're exemplary with the e-banking of a bank, right? They do want to be proactive. They can't go into the market with just like, hey, if there is something popping up in the vulnerability, we'll change it in a day or two days, right? I think that's, you know, I think there are being much more proactive and much more thinking about, hey, how do we do this? I think that's maybe also to the earlier question, right? That is a challenge that I think with OpenShift, they have a great platform to do this and to do it sane. But I do think customers need to understand their application, need to see, you know, what else can you track, right? Doesn't kind of making sure. No simple things, right? Doesn't like this port shouldn't talk to that port or that port should just talk to that port for, with that payload, et cetera, right? I think those areas are to be proactive if you really talk from a security, from an external aspect. That makes sense to you, right? It does. And I think it's, you know, regulations like GDPR and, you know, the California data protection and all of those things, it forces, you know, not just Red Hat, but our customers who are creating applications who are managing, you know, customer data, they really have to take that into account. And, you know, going back to that. No, that's a really good point, right? I mean, if you look at from a data perspective, I live in Switzerland now and we have our own data laws, right? And so, you know, we're not part of the EU, right? And so we kind of take in GDPR and then adding our special sauce. But then it gets really tricky as in what data can leave the country borders, right? And then those are the things it's always been very tricky, right? And it doesn't get easier. Yeah, it's the financial incentive is there to do it ahead of time, not after the fact, especially with those, you know, really strict laws. Yeah, there's huge penalties, right? I mean, I think if you talk to CIO from a bank, from a large bank, right, they do vary, right? And still you see stuff happening, not in the, well, I haven't seen it in IT recently, but you see this regulatory, they all complain about regulatory, but then you still see like issues like that banks get really like by bad investments, et cetera. But I think from a technology perspective, it's the stuff that they do. I mentioned before one CIO, that kind of looks at the hybrid cloud, right? And that's exactly for data reasons they do. Some stuff can go into the public cloud and even a public cloud that has data in locally, but then some stuff they do in-premise exactly for that reason. This data can go, this data can't go, and they do it kind of design it that way. And I think also, Red Hat has a certified cloud provider, CCSP, so they're called. And I think in Europe, we have 71, I think that run OpenShift or they can buy OpenShift on. And think about that in some cases, the better option, right? That you do have a hyperscale or the big hyperscalers for some workload and then maybe you have one of these regional cloud providers and then maybe on-premise. And again, if they all run OpenShift, then you have a chance to actually keep this secure and sane. Yeah, and I guess a question, I don't know the answer to. For example, do the managed services, the OpenShift managed services teams, are they underneath your organization? They are not actually, they are not. We kept them in engineering for the same reason that they are actually closer to basically the product development. Because one of the things, if you look at the OpenShift dedicated, the key there, yes, our support team will actually interface with the customer and then they go to the SRE team. But the SRE team is aligned to the product engineering group because you don't want the SRE just fix something in production and never goes back to the product, right? For us, it's always been, if you do like an OpenShift dedicated or all the other managed services abroad, it gotta go back into the product because the consistency gotta be maintained. Yeah, I've always, I was never clear as to whether they were aligned with engineering or with effectively the support or the, not the TAM organization, but that side of the house. And it really does make sense to have them more aligned with engineering for that very purpose, right? They can reinforce that direct fix in the product type of interaction. Well, keep in mind that, there's a org boundaries are here to be broken, right? So I do think it would work all the way around but it gotta, I think from a scalability perspective, we did it initially there, eventually if that changes, who knows? But I don't think we have those boundaries because like today, if you run something in OpenShift dedicated, it literally goes into the support organization. They figure out, is it actually a problem with the platform or is it another problem, right? And I think that's the power of the support organization. They're worldwide there in every country we have pretty much, every country we are operating, we have people from the support organization. We don't believe in like one central system. And so you always have like, customer is in Chicago, there is somebody in the Chicago area and maybe the US is a bad example, but take an Asian country, right? That in an Asian country, we always have local people. They speak the same language, they can figure out, hey, what's really going on. And then the support team, our support team can engage the SRE team, they speak the same, they speak English. And so it kind of bridges that and it's the better customer experience. And sometimes for some customers, they go direct, they will open up the discussion directive with the SRE team, et cetera. But I think the first touch we, I think it's good, especially in non-English speaking countries to do it a bit different. Yeah, you mentioned breaking down or Red Hat is a very flat organization, right? Going across business units, across organizations is just taken for granted. And it's funny because that was something I had to adjust to when I came to Red Hat because I get emails and I see emails from support folks going to like the OpenShift SME mailing list. I can go to GitHub and because I'm a member of the Red Hat organization, I can see the repo that the SREs use to document issues and see the things that they're working on and how they fix them. And it gets just that openness and that unabashed willingness to share information is to your point, very critical. And it just leads to a better overall customer experience and product. And think about it. I mean, that's why we are strong believers in the open source model, right? Because I mean, that internal reflection that you kind of just, you know, we don't use levels here, right? And so that's also in the communities, right? And I think that's, and be it open source community, but also be a community of customers, right? Doesn't, you know, I pride myself to be just the regular guy even when I talk to customers, right? I don't want to have this, oh, I'm the vendor, et cetera, right? Doesn't kind of say we want to be a partner to the customer, we want to make them successful, right? And not as a buzzword, but literally, I get excited when I hear from customers what they are trying to solve with our products, you know, like it's exciting, right? And you see how they go into these, like I said before, right? They take some old applications and kind of refactor them and move them around. It's pretty cool, right? And you see that more and more, right? That excites me, right? I think that's the approach. So with the, I'll say the status of the world, you know, the pandemic and travel effectively being shut down, I don't know if that affects you more or less than how much communication you have with customers, but do any of those interactions stick out to you recently? Like you were just saying, you know, the things that they're doing are really exciting. So do you have any examples off the top of your head? Yeah. So first of all, so I used to travel a lot, right? So I'm based, I used to be based in the US and Boston and then I moved for personal reasons back to Switzerland, kept my role, my global role. And so I was traveling like crazy. And now you think 12 months later, being one time on a plane, it just blows my mind and it works, right? And I do miss, to be honest, I do miss interactions with our associates. I used to travel to the biggest offices, I mean, to the Boston office, fairly regular, Raleigh as well, but then also to Brno in the Czech Republic, we have an office, India, China, et cetera, right? I used to hit like them just for my internal communication, kind of help strategy and also understand what's actually really happening on the front lines. So I do miss that, hopefully eventually that comes back. Also sharing a meal with a fellow associate, Red Hat, I look forward to that day. From a customer perspective, I think everything changed, right? Before I used to travel and meet customers in person, now it's all virtual, it seems to work, but it seems to work, it's working, right? It's different when it's a new customer, right? If you meet the new customer, if you have an established relationship, it's obviously easier just to have a video call or a phone call. But with new ones, it's a bit tricky. But if you ask me the recent one, I'm pretty involved, it's actually exciting. It's a public reference. They will talk at the Red Hat Summit as well. It's Schlumberger. And Schlumberger, I'm probably not characterizing that company well, but it is a software company, or I think they are called the oil service company, oil field service company. I think they do more than software. I think they do hours and everything. But Schlumberger came to us with their application, an interesting application that's also legacy. I don't know where it run legacy Delphi's application. And again, they will talk at the summit about it, but I find it really interesting. So they're refactoring the application as well to OpenShift, and they will use OpenShift on Azure as their platform. And exciting enough that they run into the same issue that their application needs to run in some places where the country doesn't want their data. Think about it. The country has oil reserves. Do you really want to share them in a public cloud where the fear, we talk Middle East, we talk Asia, where the fear is, well, what if the US all of a sudden has this oil data? It's probably more fear than anything else, but they're saying, no, no, no, we're not using that, but we want to have a local provider. And so that's where I think it's really exciting. You have an ISV basically refactoring their application to run on a public cloud. But then also making sure the same application runs on a regional cloud. I think that's pretty cool. And I do think we'll have more of those that we'll see happening. I think there was a announcement, a public announcement around another ISVs. I think more European one that IBM is on top. This, I think it's Salonis is in the middle and they do the same thing as in kind of the refactoring. And so I think that those are the exciting things. So we have first customers using it, but now also ISVs realizing this is a really powerful ecosystem that we have, right? That you can run it everywhere, right? There's a hybrid cloud in a similar way. It's also from my ISV, probably the maintenance cost is much less if you have the same app running everywhere. But yeah, so that's one exciting example. I think I talked a little bit about the other example of the client doing that hybrid cloud approach that yeah, I do keep up my conversations with customers. And as I said, I always get excited when I see what kind of stuff they do. And also worries me, right? And some customers, I know I depend personally on it be it's financially, be it transportation. It just buried in as like, oh wow, if this thing doesn't work then I'm personally screwed as well, right? And so I think that's the excitement, right? Which is, you go back in history 15 years ago when Red Hat had the first large wins on Wall Street, right? That was exciting as well. All of a sudden it was like, ooh, New York Stock Exchange runs on this or this and that. That was exciting, right? And now we have this excitement again which I think is pretty cool. So I'm gonna go off script on you because you mentioned the three letter word or three letter acronym that everybody seems to be a little hesitant about. And that's IBM. And I'm curious from your perspective the impact of the IBM acquisition. And I'll tell you from my perspective, IBM brings to us these really interesting, really challenging set of circumstances. Hey, we're working with this customer to do this. How can we do that? So I'm curious to your perspective of that. Yeah, I think the positive, I think there's a few, there's actually a lot of positive. One is like the commitment, Red Hat stays a neutral company. And I don't know, I think we're two years in it or maybe, yeah, I think a year and a half. I feel like very neutral. And if we talk about public cloud providers, it doesn't need to be IBM cloud. It's whatever public cloud company is around. So I think that neutrality, I would say Jack the Mark and it's achieved after almost two years, still good. What you mentioned is like in some accounts, some accounts really like it that, oh, this is all the same, right? I can buy Red Hat products through like the IBM rep or Bose account teams and get, you have that, right? And it's positive, right? And I think what you mentioned, which I think is actually the Schlumberger example, right? IBM has much more industry depth, right? That's in like oil exploration. Yes, Red Hat had a oil and gas practice. It was like a lot of oil and gas came to us with Linux, but it was Linux. It was just like the base, right? And you look at this Schlumberger situation, there is a lot of IBM people that really understand what oil exploration means with geologists, et cetera, which we never had the breath to do. And so when they bring like customers like that to the table and we can use and serve them with the same products, I think that's pretty cool. And so those are the positives. I actually have to say I was super skeptical and I admit that I think I had some public blogs and public notes on this. It was skeptical, will this really work? And I have to say I'm positive, right? It's a big company, but I think there's always challenges to work on, but if you meet the IBM, especially IBM engineers, they function the same as Red Hat engineers, right? And to be honest, if you talk to IBM salespeople or country manager, they know their country manager, the culture is very similar, right? There's always this spectrum, that spectrum. But yeah, I'm very positive right now. I feel like this wasn't... I shouldn't have been so negative two years ago. Yeah, I think anybody who had contacts inside of Red Hat knew there was a lot of apprehension. And I think all of that, or I would say from my perspective, all of it has disappeared since then. So we do have a question. Is there a lot of overlap with IBM and Red Hat products? And I'll say from my perspective, no. IBM has been really good about taking their capabilities. CloudPacks, of course, is the perfect example and putting them on top of the Red Hat portfolio, right? Leveraging things like OpenShift, et cetera. There is, of course, some overlap, but I don't see that as much. I'd be curious to your perspective as well. No, no, I think a little bit of overlap is okay. I think, to be honest, right? I think you can look at it. I was involved in a previous acquisition not Red Hat and other company. And there they looked at overlap is bad. They got to kill it from day one. And it caused a lot of customer frustration and didn't really bring anything. And so today, I look at this more like the obvious one. I'm sure the audience will pick up on that obvious, I wouldn't say overlap, but you look at the JBoss product suite and the WebSphere product suite. There is similar functionality. Is it a bad thing? No, it's a customer choice, right? The customer chooses WebSphere because of the add-ons that JBoss can't serve. It's great if they're actually moving stuff to, you know, like if it's just J2E, that works in JBoss is a customer choice, right? So, and we haven't had discussions, hey, we got to do this and that. I think what we've seen and you've seen it with the management suite, you know, some stuff that we take from IBM, open-source it and actually use it in our portfolio. And I think we actually took quite a few engineers over in some of these elements. So we are not looking at overlap. As you know, we got to stomp that out as a customer choice. And you know, IBM is a huge company. They have a lot of products. We are sticking to our portfolio. We've been very diligent as in this portfolio makes sense. And then we're not working on these things. I think let's kill this, let's kill that, right? And again, from my customer angle, right? This is where you lose customers, right? I mentioned how I got to write that is because the company did this overlap and go force customer on your platform. That opens up the doors to actually do something else. And yeah, we're not on that track. And I actually think it's good, right? Because you have customers that are traditional. They want to stay more on, hey, this is technology that worked and we built this 10 years ago. We'll run it another 10 years. And you have more of the customers that say, hey, we got to be more on the earlier edge. We got to change stuff. I think that's the angle. So that's an interesting thought of, for me, when I think of the oil and gas industry, I think big data, I think that they were definitely leading, leading bleeding edge when it came to doing things like analytics against that data. But in other areas, maybe, I don't want to say less business critical, but less industry or vertical specific, maybe they were slight laggards. Do you see variations in adoption of containers and Kubernetes and OpenShift across other verticals? That's a good question. I have to say, well, this is without using AI or without being really analytical. I have to say, I've seen in every vertical containers being adopted. I haven't seen one area where people are super, sometimes you have a new technology, right? And people say, ah, I can't do that. That would be weird. And we have products like that, right? And I think there was like a steeper adoption curve, right? And you can look back at, I would say OpenStack probably had a steeper adoption curve. People understood there, I gotta, this is how many years back, right? Customers understood they got to build the internal cloud, but then it was already, that skill level is too high. We can't do it, scale is not enough. I think with OpenShift, you actually have customers doing it small scale, right? Bear metal, bang, go, or some that use like OpenShift, OpenStack, a bit more scale. But yeah, based on the vertical, I wouldn't say, and it's also interesting for us, right? We always had the financial sector leading us, right? As in, there was always the vertical that pushed us. And then, you know, five, six years ago, we started doing more in the telcos space. That was an OpenStack, right? And a lot of telcos actually, with the network functions, virtualization, NFV, they kind of did this, I would almost call it a standout now, but they did this, right? And now with OpenShift, I wouldn't be able to tell you, is it the financial services? Is it the telco leading it? And is it transportation? I think there's a lot of, but it's a hard question. We would have to dig deep, but I do think OpenShift actually achieved that to be more a ubiquitous platform that can be used in every vertical and every size of the component. Yeah, I wonder if containers democratized access to a lot of those things, because it went from, you know, I'm a super smart developer, I created this super complex application and here's the 300 steps for the playbook to install it, to, you know, Podman Run. And, you know, now you can broadly adopt those. Yeah, I think that's right. You make a really good point, right? And with the automation, you have more and more, right? Also, like, I think a lot of customers are doing Ansible also to extend that automation. I think that broke down the barrier quite a bit. So I'm gonna dig us out of that hole. I'm gonna change directions on you. So we've only got a little less than 10 minutes left. So for all of our audience who's watching, please don't hesitate to ask any questions that you have for Marco in the chat. I'll be sure to pass those along. But I wanna kinda ask you what I hope is a light-hearted question, which is, you know, as the person who is ultimately in charge of, you know, organizations like support, what are the phone calls that, you know, where are you the most? I do, you know, it's funny, right? I mean, obviously it's a large organization. It's several thousand people, right? And so in the old days, I had myself on number posts publicly so customers could really reach out. I think we still do have that page with my leadership team and there's a vice president run support or the whole customer success he runs. That's probably still reachable. What I worry about is, well, I think there's two errors. If there is really like a company down, that really worries me, right? And like right now, especially if it's a healthcare company down, transportation, like transportation, like mass transport down, pharmaceuticals down, that obviously really worries me to be honest, right? If it's like a down situation. But on the other hand, I sleep well at night and I know I have a super team, right? There's engineers all over this world. We scaled it up over the last 15 years so much that it's top skills, full coverage. So I actually feel good. The other areas I worry about is data leakage, right? If something happens with like a security breach that happens to a customer, how can we help a customer? Those are the dicey ones, right? When you see recently I had a customer that got the ransom, I don't know how you call it, kind of ransom there in their environment. Then that CIR was panicked about what do we do, right? And large, large company. And we had a team just jumping on and saying, hey, is this also impacting the Linux environment? This is a Linux environment and it was a other environment. And then my team jumped on it in within hours. They were like, no, no, this one will not attack the Red Hat site and which man for this custom they could bring up all their ERP again. So it was a huge, huge relief. But those things give me heartburn, right? I mean, I think in that instance, the FBI got involved and like massive, massive investigation on that. But I was glad that, hey, it didn't turn out to be impacted on the Red Hat, but those are the security ones kind of burying me as in like, how do we do that with the customer, right? There's stressful situations. Yeah, ransomware is, it's scary. It really is. And so maybe the other point as well on just, I know we got to close, but you know, I do look at customer feedback every week and I'm passionate about it. And look, if I, we do use the standardized MPS program and I do look at this feedback every week and kind of, you know, it's not the phone calls that worry me, but even I see a customer really having a bad experience or they kind of complain, there's a lot of good, right? Our score is really good. And I think majority we provide a good experience. But when I see like this bad, it really hurts. I almost take it personal as in like, oh, I couldn't, we couldn't deliver against that expectation. And those are the things that keep me up as a more as like, how can we systemically approach things differently in some areas and approve? So we had a couple of questions from the audience. So from South Africa, Bafana, my apologies if I'm mispronouncing your name. What's your view on the African market? Have you noticed anything unique or different about that region? Yeah, that's interesting. For us, the African market is actually pretty interesting. We are in South Africa, we actually have a quite sizable office and there is also a consulting team that does a lot of engagements. It started with RHEL, but it's also like there's customers with open shift there and deploying that. But it's not just South Africa, it's also the areas and I have to apologize for my geography, but there is, and I'm just blanking on the Kenya is actually surprising one that we actually started seeing a lot of business. I do think we have one or two persons directly in Kenya. And then the rest of Africa, we cover quite a bit with partners, but you can imagine we mentioned oil and gas before it's happening in Africa as well. Nigeria and that area has a lot of business as well. Telcos in Africa are quite large open source Red Hat customers as well. So yeah, business in Africa is still small compared to the US, but it's definitely something that we cover with a direct team in some areas. So in our last two minutes here, do different verticals focus on different aspects of open shifts? In other words, is Telco really excited about SDN while banking only really cares about, for example, open shift container storage, or now the open shift data foundation since they just rebranded? Yeah, it's a really good question. I think we see some trends, you know, be Telco and being also the industry, we don't have an industry vertical, but I'll just use industry 4.0 as a buzzword. So I use my buzzword count as well. But in that vertical, you see use cases more on the edge, right? As in how do we actually deploy open shift in a smaller place, right? And you can imagine a 5G, probably if you listen to Chris Wright's webcast, he talks quite a bit about that. But those are the use cases that we see that I would categorize as edge, which I see mostly industry and Telco. And I think the financial market and all that vertical, I think they care about containerization as an abstraction layer. They also, like I said, right? Like how do you get old apps over there or how do you break up old apps, right? Older apps into smaller pieces, right? And so they use that kind of containers as well as in like kind of breaking that up. But that's, yeah, I think those are the big differences I would highlight. Okay. Well, we have reached the top of the hour. I want to say thank you so much for all of your time today. This has been incredibly enlightening and useful for me. I have learned a lot, you know, as somebody who's been at Red Hat for borderline three years now. So thank you so much for your perspective. I will happily give you the final word if there's anything you want to close out with. And thank you so much to our audience. Please feel free to reach out to us on social media or you can contact me directly at Andrew.SolomonetRedHat.com. Super, no, thank you very much for the audience. Thank you Andrew for hosting this and I wish everybody a good day and stay safe. And hopefully we all get out of this pandemic. Very soon. So stay safe. Thank you again. Thank you so much everyone.