I never really, you know, connected Dell with DevOps before. It's not something that is synonymous for me. When I think of DevOps, Dell is not top of mind. So I think for many people out there, Dell, DevOps - not synonymous, you don't connect the two. If you do, it's kind of fuzzy. And what I would hope is for people to watch this
docuseries and come away feeling, okay, this sounds legitimate, sounds like they're involved. I don't know how far, but I'd like to learn more. I think the thing I enjoy the most about working for Dell is surprising people. You know, a lot of the questions I had when I came to work for
Dell and a lot of questions that we have when we go to conferences, why Dell? Why do we why do we need developer advocates? What are we doing in the cloud based technology thing? And I love that. I love the opportunity to talk about the cool stuff we're doing, about the things we want to do and the ways that we have helped and we want to help, and I love that aspect of what I'm doing. If you were to ask me what I like about working for Dell, there's several things that come to mind. I think one of them
is the variety of positions I've been able to have. So while I've been here 14 years, I've worked everywhere from central marketing to the office of the CTO and all around. I think the other thing that comes to mind is integrity. And I think that's something that I believe in
and I think comes from the very top from Michael Dell that he sets this type of environment where integrity is is expected and where it's embraced. Last but not least. What I've really noticed as of late is we really started picking up momentum and we've always gone at a good chunk. But it just seems in the last two or three years the pace has really quickened. And I'm really excited about some of the new areas that we're getting into. So with Dell, I really enjoy kind of the culture.
I found a lot of friends of Dell, a lot of people that I love talking to technology, industry, you name it with. So it's really from a Dell perspective, it really is about the people, the culture and just really giving back. Dell is a brand everybody knows, right? You've probably heard of someone who had a Dell or dude, you got a Dell. I think that culture extends into every team, every kind of place in the org that I work with. And so everybody's really excited to kind of work on new and innovative things. I really like that about Dell. So Dell started back in 1984,
so this guy by the name of Michael Dell was a freshman at U.T. University of Texas, came over from Houston and out of his dorm he started this computer company. So what he realized is if he could take off the shelf parts, make it IBM compatible, sell it via mail order, you could sell it for so much less, and you could also communicate with the customers directly. And he did that. 15 years later, it was the number one PC manufacturer in the country. So it's it's had a long, rich history. When the company first launched, it was called PC’s Limited. So that's that's great if you're selling PCs, but it kind of binds you to PCs if you keep that name. So it changed it to Dell Computer Corporation, which is a little bit broader.
And then as you go further, then it became Dell Inc. And then over the years we've expanded the portfolio. You went from PCs to laptops, then start bringing in servers, networking, growing the portfolio. After that, we acquired EMC and then we got a robust portfolio of storage, networking and now it's Dell Technologies. When I think of Dell, just like many other people, especially, I think people our age where you grew up in the days of you bought a PC and it was always going to be like from Dell, right? And then when you moved on from your personal PC, like, I started out my career as a sysadmin, and so that meant that I had a bunch of, you know, Dell servers and storage devices. Quite honestly, when I think about Dell,
maybe quite wrongly, my first impression is like, those are the people I call when I want to manage a fleet of laptops, or maybe the people I need to call when I need several thousand pounds of server gear deployed in the data center really, really quickly. So it's funny when people talk about Dell Hardware is always the first thing somebody mentions. People think of Dell as a hardware only company because they see that Dell brand on a monitor or a laptop or a keyboard. And those are the things that people see first. Dell is definitely more than a hardware company. If I was kind of put it together,
right? Dell's more about taking the hardware that we do really well with a lot of the other systems and solutioneering such as storage, data protection, partner ecosystem things pulling them together and delivering outcomes. And it's not just about the hardware, it's the hardware plus, plus, plus that really gets us what Dell delivers. Absolutely. Every single piece of hardware has software that goes along with it. I don't think a lot of people realize that Dell is also enabling customers with services and much more than just hardware. If you look at Dell, traditionally we really had hardware, we had software and we had services.
Now people think about the hardware. What we see now is as we start to move into a multi-cloud environment, we're separating out that software piece. What we grew up with as a company speeds and feeds boxes. Right? I love I love a good box. I love a shiny box and a pretty bezel, you know? And I do love lights. Cool lights.
The lights are cool. I love a hero number. Great. I think we have to up the level of conversation to truly understanding our customers and what they're struggling with and really talking about the technology almost last. And I think that takes a long time, right? I think of us as Dell is a fleet of tanker ships. We are powerful. We are a powerful engine. We can do a lot, but…changing direction. It's going to take some time. It's going to be incremental and we're going to have to do that and kind of chart our course as we go. But you can see it. I think this this is the beginning of us becoming truly software led.
The conversation I've been having with a lot of folks, less so outside, but absolutely inside of Dell, is kind of who is a Dell customer of the future, right? We know who the Dell customer is primarily now. They're the I.T. administrators. They're the storage admin. They’re the enterprise kind of legacy application administrators. But if we look at companies like Amazon or Google or Microsoft, especially with their with their cloud infrastructure services, their customers are different than our customers. And they've been able to move people over by catering to those needs.
Right. A lot of our internal perception and certainly our external perception is that we're not interested in those customers. And I feel like going forward to 2023 and beyond. Right, that those are that's where we grow as we grow by getting the people who were born in the cloud, we…by offering them the things that they need and listening to their concerns and building the solutions that are going to work for them. The partners are getting better. Well, Dell included, right? We're changing, too. I mean, everybody's changing. We're we're moving a lot faster now, which is awesome. It takes a while to move this huge aircraft carrier to turn
it kind of this way. Yeah. It's a big company. And we have to keep listening and learning as we go as well, because it's not it's not exactly clear how we get there. You know, one thing that I'm very proud of about this company, we're very customer first. We're very customer empathetic. So we need to ask the right questions and really listen.
We've been working on DevOps for a while, but it really has ramped up recently from our multi-cloud group. When you talk about DevOps, one of the things that's plagued it from the beginning is a common definition and common language. But if you don't have a common vernacular, you're talking at cross-purposes. We're over ten years into this concept, right? And we're still here talking about what is DevOps. If you asked of a whole bunch of people at KubeCon, I'm sure you'd get different answers.
We did. So what is DevOps? The million dollar question. I think quite simply the two things, the dev writing, the software apps, running the software and the practice of each side, having empathy for the other, being together instead of siloed DevOps for me is a mindset where you have to combine your development skills with operations. DevOps is a process. DevOps for me generally is knowing a bunch of services, and how to deploy the services and how those services communicate with each other. As a practice is the combination of of making sure that we provide the relevant tools for application developers. I tend to think of it as like it's like a
buffet. It's kind of the hygiene of being a good citizen when you're you're eating at a buffet. It's a lifestyle. DevOps is more the problems that we need to solve, the people that need to solve them, and then the tools that they may or may not need in order to solve those problems. For me, the DevOps is like bringing code to production quickly. I think DevOps is more a culture, is a methodology of DevOps. DevOps is the automation of building an application, packaging it up, scanning it for vulnerabilities, producing images or producing VMs or whatever the format is for delivering that app and then delivering that to either a dev environment or a production environment when you're ready to go there.
DevOps is a culture of collaboration where people come together to produce software and ship it faster. DevOps is a community first and foremost, but it is also a way to ensure that we are always doing things better, both for the developers, the things, the people that are actually building the applications, the operations teams that are supporting those applications and making sure our infrastructure exists and is stable. And for the users what we want to do ultimately is make it easier and more reliable to build more software fast. It's the idea that, you know, there's
so many people involved in a project and rather than having it be these little silos that everybody tries to work through, now it's taking all of those experts, putting them at the table at the very beginning. And then every time we hit a major milestone, everybody comes back together to make sure that we're still on the same path and we're still in the same plan and that we can work together to solve any problems that are there. For me, DevOps is mainly a culture and organizational shift towards delivering better software elements, and there are a lot of tools in the DevOps ecosystem that go along with that.
But honestly, DevOps is more of that culture change and organizational change, meaning if you just throw the DevOps tools that you hear about under that DevOps umbrella, you won't find success without that culture and organizational change. So for me, DevOps is that org and culture seems tied to delivering better software. DevOps is like it's just fascinating. It's, it's like a curse and a blessing, right? And sort of the curse is, it doesn't really have a definition. The blessing is it doesn't have a definition. I've never seen one topic be understood in such radically different ways as DevOps. DevOps has a ton of definitions in the industry, and I think part of it is until probably about five years or so ago, DevOps was kind of all over the place because people didn't understand what it meant, where it started, the reality is I think people are trying to understand DevOps in real time. People sometimes apply their own concepts, their own definitions to a term, and in this case DevOps really has had people apply different concepts to the common term. People see DevOps differently depending on their
experience, you know, where where they come from in the industry. So you've got people who are were did other things outside of technology and they tend to to define DevOps in a certain way. Then you've got, you know, tenured or, you know, crusty folks such as myself who've been doing this for a long time. You know, I've been focused exclusively on the discipline of infrastructure
architecture and systems management for 25 years. That's all I've ever known. Of course, I've got many, you know, great friends that have been software developers for 25, 30 years. I think those folks have a very unique view of DevOps. There are so many different definitions of DevOps because it's sort of like a recipe, I think of it as. Right? Everyone has a different version of a recipe. I have one that's a favorite,
a Hungarian goulash that I learned from my father in law. He learned from his mother, and I bet you every single one of those is slightly different, even though it is the same recipe. And DevOps is a lot like that in the sense that it is a recipe of things, whether that's tools, culture changes, organizational shifts that all might culminate a little different. So people through experience get their own definition of what DevOps looks like to them. And I think that,
you know, is really why we hear different versions of DevOps, even though they probably have tiebacks to very similar concepts. It seems like the definition is like this organism that keeps evolving and, you know, broadening over time. And the more people that get involved in it, especially from different disciplines, that that's adding more, more spice to the dish. I think DevOps is a term that is fraught with so many people's misconceptions. After so many years of being around. One of the misconceptions is DevOps is a title. Are you DevOps engineer? Yes, I use Jenkins, right? Now it's like, are you a DevOps engineer? Yes, I use Kubernetes or whatever. So it very much is. People naturally go to the tools.
Some of the biggest misconceptions of DevOps is really it's tools and tech only. DevOps has a lot of tools and tech and there are a lot of great products and software out there to help you achieve a DevOps sort of methodology at a company. But it isn't just tools and tech, right? Again, I think if you throw tools and technology that are in that space as a team, they'll probably wind up failing 95% of the time, in my opinion. You can have all the tools you want, but they're going to wither on the vine if you still practice the old culture.
But if you focus on what you're trying to do with DevOps in terms of that culture and that organizational changes, the mindset shift, that ties together and it has to go together. It's a lot easier to talk about automation and tools that are easy to grasp versus this culture of collaboration that we have to build at a company. People have shifted. People have shifted over time into thinking that it's just about the tools or just about the automation are really focused on CICD as a continuous integration, continuous delivery, continuous deployment, and instead we've lost that focus on culture and change and transformation. To me, the biggest misconception around DevOps is that CICD is DevOps. That is one that we hear quite a lot. See, CICD is central to DevOps, but it is not DevOps at its heart. In response to that,
a lot of long standing DevOps community members and practitioners like to immediately screech that DevOps isn't just a tool, DevOps is a culture and that's true. It is, but it is maybe also getting a little bit tired that we say that every time. Second misconception out there for me is definitely that DevOps is one thing, one way of doing things. You can't do that. DevOps is really process journey led initiative that you have to undertake to change the culture, to change that operating model. And it's not one thing. DevOps is multiple things that have kind of come
together to help you with that transformation. Some organizations use it as like a marketing term and it's a cultural shift, right? And so it kind of depends on on how your organization sees it. Do they see it as a marketing term and they're not really adopting the practices, or do they really take it seriously? And it's an actual cultural shift. And I think that we can see from the outside looking in when it's a marketing term versus a cultural shift.
And so I think that we still have a lot of work to do. DevOps is really coining of two words: developers and operations, and it's bringing together these two disciplines which were traditionally considered to be very, very disparate. What we've learned is there is a more efficient way of bringing together these two disciplines and you can do it in a very seamless way. So that's really what DevOps is.
From our perspective DevOps is really an operating model. When you distill it down to its core essence. DevOps is a culture and it's an ideology, and that culture and ideology inspires a set of practices and procedures that allow groups within an organization to interoperate and operate together in this method that is informed by the concerns of this group. And they requirements of each group. It's not just dev and artist security, it's finance. It's marketing. It's all the various concerns of what you have to role a product out to a customer. All of these things are incorporated in DevOps. They're iterated upon, they're improved upon and they're informed by your measurements, informed by your metrics, informed by the needs of the customers you're serving. And in the end, yeah, you can build tool and
build automation and all those other things, but those are things that are inspired to enable DevOps, but those aren't DevOps. A lot of times prior to when DevOps, including Agile, kind of started to become more normal, what we saw were application developers or application owners were just tossing things over the wall at the IT ops folks. And what DevOps was starting to do is to give those IT ops folks a level of power to be able to create guardrails, to give those end users more controls in place, but controls with freedom, if that even makes sense. It's like the notion of how do we help people
do their job better by giving them just enough of the guardrails without putting them into a box and saying, figure out how to make that work. You know, when we first started the DevOps thing, Andrew Clay Shafer had created this character called the Wall of Confusion. And it was the sort of the Devs throwing the artifacts over the wall, Ops catching it and going “what do you want me to do with that”? You know, almost like back and over…and his point was we need to crush that wall. Working with Dr. Steven Spear at the MIT
Sloan School of Business. We wrote this little vignette about two people trying to solve a problem together, and in this case, they're trying to move a couch. And you might think, Yeah, moving a couch just seems like all brawn work, you know, no brain work required. But for them to move a couch through a narrow doorway or go down through a narrow twisting set of stairs, there's all these problems they need to solve, like where is the center of gravity? Or you need to get through the narrow doorway which axix to you rotate around or to go down the stairs. Yeah. Who goes first, do the face forward or backwards? And so what's amazing is that, you know, one can expect that the instant they pick up the couch.
They're solving problems or getting feedback to trial. You know, they have trial and error, they’re communicating, coordinating. And there's all these things we can do as leaders that make the job much more difficult, like we turn off all the lights, right? Or we, you know, introduce a lot of background noise like a siren so they can't communicate and coordinate or we introduce an intermediary because we won't let and Jean talk directly to each other anymore. And what's amazing is that, you know, suddenly very important messages like my finger is stuck in the doorjamb. Can you please stop? Or like, you're going too fast, right? Could you please go slower? They don't get through and suddenly it will take longer to move the couch. It's probably going to damage the couch,
the furniture around it, or maybe Steve and Gene? Or someone is actually going to get hurt. And I think what's what's so impactful to me is that, you know, is that's sort of what the DevOps movement was all about, right? Is that we prevented dev and ops from talking directly to each other. And we were so surprised that, you know, they couldn't do a good job easily or well. So, you know, I think as leaders, what we try
to do is create these coherent systems where we really recognize where are two people doing joint problem solving together and what we need to do to enable to, you know, communicate, collaborate, you know, versus splitting them apart? The way that I see it, there's software development and operations are two fundamentally unique trade crafts. You see the world of technology through totally different lenses, or at least historically speaking, the challenge with DevOps is each one of these trade crafts has to see each other's points of view and adopt the tools and techniques of each of these disciplines. It's pretty simple and it's getting people to work together within a company. So whether that's marketing and sales,
engineering and marketing, you need to work together. And by doing that, not surprisingly, things go more efficiently. It's interesting. I would describe DevOps to people who are not in technology at all and they're they're actually surprised that like you haven't been doing that all along, They're like, What's wrong with you? And so that was that was really foreign of a concept to us. And then I I'm usually I'm an apologist. My computer science is kind of a young discipline and we don't really know what we're doing. We're
still trying to figure that out, you know? I think this whole DevOps space has been so interesting, partially because it has not been as crisply defined. I think in one hand that lack of a common definition, crisp definition has hindered it, but at the same time it's allowed for creativity, it's allowed for discussion, it's allowed for participation from a larger group and it then has different facets of it. That's the really, really powerful part because you can think about it from so many different angles and then there isn't one, just one answer. It's probably a bunch of different answers. So ultimately, in the end, DevOps isn't for
dealing with machines and computers, it's for dealing with people.
2024-03-03