DevOps Part 1 - What is DevOps

Show video

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

Show video