Modern Services Demand a DevOps Culture Beyond Apps
The benefits of DevOps span far beyond business applications and far beyond only the release phase. Business services are comprised of many components that fall under both infrastructure and applications umbrellas. These components come in a wide variety of forms (physical, virtual, and cloud), with the components changing states and relationships continually.
DevOps becomes a necessity way of life in such complex, dynamic environments. DevOps relevance in new application development is well-known, but everything is now becoming software-defined, including the infrastructure. The same principles apply across the board, driving broader demand for the speed, flexibility, and dependability that comes from good DevOps thinking and practice. DevOps is not just for applications. It’s for everything you now do.
Chapters
Full transcript
The complete talk — auto-generated from the talk's captions.
Thank you. And don't applaud me, applaud this guy, because I go to a lot of conferences, way too many of these things. This may very well be the best one I've ever been to. It is just such a blast, and someday we're all going to look back and say, "We were there at the beginning." That's pretty cool.
So I'm here as part of this and I'm really humbled to be here, and I appreciate the invitation. I'm not a horse, I'm not a unicorn, but what we do at Forrester... I used to be a horse, and some people say I'm the other end of a horse. But what we do at Forrester is we try to help horses.
We sprinkle a little bit of this special Rogaine on their heads to try to grow a little bump that gets bigger and bigger. And that's really what we're trying to do. We're trying to help people become unicorns or become more unicorn-like. You may look at it and say, "Well, I'll never be a Netflix," or, "I'll never be an Amazon." But you know what?
You can be more Netflix-like. We can. And I'm not going to go into the whole DevOps on the application side, because so many people have already done that. My twist today is going to be expanding beyond the applications.
In some ways, John stole a little bit of my thunder, but I hope you're going to see this as a one-two punch. And by the way, the two worst nightmares of any speaker are coming after lunch and following a guy like John. How do I do that? And by the way, for those of you who don't know it, today is Curly's birthday.
He turns seven today. So it's not about technology. This is not a technology story. It's about services for the business.
And the CEO, this is the CEO. And how do we know that? Because he's old and he's rich. This is the guy that's calling the shots, and he's telling us what he wants, and we have to deliver what he wants.
Actually, we got to deliver what he needs, not what he wants. And he doesn't know what he needs necessarily. But we do know that there are certain aspects of what he's looking for. He's looking for services, and it's all about the economics to him.
It's about, what's it going to cost me, and how much is it going to make us? How are we going to be more competitive? How am I going to go out and beat the competition? Not just beat them, how am I going to obliterate them?
No CEO just wants to go out and beat marginally. They want to kill the competition. And that's our job to help them do that, because as we've heard over and over again, it's all about technology. That's how this guy's going to beat the world.
Now, these services, they're kind of packaged up and they have a nice front end to them, or at least they should. How do we deal with this? How do we start off with designing these services? We have to take a modular approach to this.
We take that service and then we deconstruct it down into sub-services, and we deconstruct those into sub-services, and we keep going down and down until we get to the atomic parts. Those atomic parts are a lot of the infrastructure and applications pieces that we know about. I show three layers. There could be multiple layers.
There could be seven, eight, 10 layers. It really depends on your situation. But the point is, there is a logical structure to this. There's a logical hierarchical modeling to this, and we got to approach this as a system.
How many of you have a background in systems engineering? Oh, good. I like that. Yeah, that's cool.
We in IT tend not to be systems engineers. We're lousy systems engineers. We focus on one of these teeny-weeny little bits in the middle, and we hone the daylights out of that thing. We are locally brilliant and globally stupid, and that's what gets us into a lot of trouble.
So we've got to become globally brilliant, and that's what systems engineering is all about. It's not optimizing each of the pieces, it's optimizing the whole thing. And the whole thing has a lot of different parts to it. The whole thing includes a lot of infrastructure components, a lot of application components, services from third parties.
Some of this stuff is internal, some of it's external. It really is a whole new ecosystem of options that we've got at our disposal. And in fact, I must have screwed up. I must have been a lousy analyst because they promoted me to management overhead.
So I think that answers Gene's question. But what happens is I took over this infrastructure team at Forrester, but we're looking at it very differently. We have to look at it very differently because it's not about servers and networks and storage and all these individual pieces. It's how it all works together.
So we're focusing a lot on this service design, this modular systems approach to things and the ecosystem around it. And the ecosystem has a lot of options, not all of which you're going to have control over, and that's okay. IT people have a really hard time with that. They want to maintain control.
"You got to let me control this. I am the only one who understands that cryptic Cisco command line language, and nobody else can do it. I am the master of the universe, and nobody will ever beat me." Well, I got software that can put you out of business, buddy. So all of these things are going to be there.
And we talk a lot about cloud, and yes, cloud is going to be increasingly a part of this, but there are other pieces that are going to be there for all eternity. Ever since about the time I first discovered girls, they said the mainframe is going to be dead. I'll be dead before the mainframe is, trust me with that. So that's going to be a part of your environment.
All of these things are parts of your environment. And some of it comes packaged from the third party, so a lot of SaaS and other services from the outside. And if you look at this, a lot of that complexity is hidden behind the scenes. That's okay.
I'm a Salesforce customer. Do I care what their servers look like? No. Should I?
No. They got it. I'm getting what I need. That's all I care about.
This is a new way of looking at the technology ecosystem and technology management in general. And all of this stuff is part of your ecosystem. And the new skill set, the new mastery, is how we're going to manage all of this stuff, how we're going to assemble it, how we're going to design these higher-level services.And it's all software, much to what John was just talking about. It's all software.
I mean, geez, back in the '80s, I was writing code to control the network. As far as I was concerned, it was a software-defined network even back then. It's very different now, but you get my point. But this is all software.
Yes, the application components are obviously software, but now software-defined infrastructure expands to everything. Even physical servers you can manipulate with software. That's cool. And then you've got these abstraction models that help you describe the higher level concepts, the higher level services.
And it's all software. It's all ones and zeros. This really changes the game quite a bit because you're not going to go in and tweak the ones and the zeros necessarily directly on the infrastructure. You're going to deal with the models.
And as we look at DevOps and the whole concept of DevOps, it's all about driving the world based on the models. Okay, that was just in there for comic relief. But people say, "Well, it's only a model. Big deal.
What does that get me?" It gets you a lot, because if you have a model, you can automate things. Because you take that model, the model is a description of reality. It's a software description of reality, and all other engineering practices have been following this principle for a long time. I did semiconductor design way back in the early '80s, back when semiconductors were about this big and took a lot of power, too.
But we even simulated our chips back then before we built them because it was an expensive process to build chips. Boeing simulates every detail of a plane before they put it in the air. Would you want to fly a plane that was never simulated? I don't think so.
So the model really tells us where we're going with this, and the tools that we're using will consume that model and create reality according to what that model says. That's a very simple concept, but it's a really profound one. And what it tells us is we're not in the command line. Let's get away from the command line, please.
That's not where we want to run our world. Manipulate the models and let the tools create reality. That's what it's all about. And this is all system software, and we've got to treat this exactly like we treat application software.
It's software. Software is software is software. Let's do it all the same. We can.
And that's really what the software-defined data center, whatever you want to call it, is all about. We can now automate all this stuff. And automation is really central to the whole concept of DevOps. If you can't automate it, it ain't DevOps because you're too slow.
Automation, of course, makes us go faster, but it also makes sure that we do it right. It's going to be higher quality. Somebody said we said the word quality too many times at this event, but I just said it again because it's true. Get the human beings out of the equation.
We're all morons. We all do stupid things. Let's stop it. And it's only a model?
The model is the secret code. This is the language. This is how you do things. This is what it's all about.
Get the model right and you've got it. Now, as we go down this path, automation and other developments render certain jobs obsolete. This is where it gets ugly, and this is where people say, "Well, I don't want to do that. It's going to automate me out of existence." Yeah.
Yes, it is, and that's okay. We're in technology. We are in the business of changing the world. If you don't want to change, get out.
You're in the wrong business. We don't want you here anyway. You're just get in the way. So what's going on here is as you automate these things, there are dying jobs, but there are also new jobs coming along.
So we don't have to worry about this. I've been trying to put myself out of work for 35 years, and I've succeeded many times, most recently about six months ago. That's okay. That's what it's all about.
So what are the dying jobs? Roughly speaking, if you've got the word administrator in your title, and some of you might be here You're dinosaurs. Now, does that mean you go away? Does that mean your skill sets are useless?
In some ways, yes. But in most ways, no. We just got to package those skill sets up differently. It's not about going into the CLI and tinkering with the CLI and knowing the magic language.
I got software that can do that. Let's use the smart people to do what smart people do well. We're doing too much intellectual grunt work. Smart people doing repetitive stuff.
Knock it off, Lisa. We are. We're doing too much of this stuff, and software can do that. So where do we go?
What are the new jobs? Well, if you're going to do automation, why not put some people on the automation? And let's start working with people. Let's start talking to people.
Yes, technology people, we've got to talk to other human beings. I'm sorry. We even need some bean counters in IT. We also need service engineers.
I talked about building this model of a service. Somebody's got to do that. That's a very technology-centric thing. So what we got here, the difference between the dying and growing is whether or not you're a sustainer or an innovator.
It's what happens to the geeks. So everybody says, "Oh, this is not good for the geeks." This is great for the geeks. And I'm a geek. How many geeks are out there with me?
We're proud. I compete at ham radio, so I'm a geek, trust me. I say there are geeks and there are geek imposters. The similarity is that they all do geek work, but that's where the similarities end.
The geeks love change. The geek imposters hate change. They want to keep doing the same geeky work forever. The geeks are the innovators.
They'll always be the innovators. They're always creating. We have short attention spans. We create something, we get bored easily, and we want to move on.We don't want to tinker with this stuff.
Not only do we look forward to Skynet, we want to build it. Yeah, I heard some agreement over there. The geeks have a wonderful future. So you geeks, don't worry.
You got nothing to worry about because you are the people who are going to create the future world. The geek imposters, learn how to say, "Would you like fries with that?" And even that ain't so good because McDonald's is automating that process, too. So how can you help me? My job is helping to put the bumps on the heads of the horses.
Help me do that. Help me and my colleagues do that. We want to hear your stories because I like to think I'm a fairly intelligent guy, but I don't know everything. What makes me a good analyst and what makes my colleagues good analysts is because we're out there talking to people like you all day, every day of our lives, and when you have that kind of exposure, any moron can see the patterns.
And that's where we need your help. We need to hear the stories. We need to hear your stories because that helps us help other people. It helps us spread the word and evangelize the stories.
And we are changing the world. I keep telling my team, "We're changing the world." That's a really cool thing. But we are all changing this world, all of us in this room. We're doing it together, because we can't do it without you.
And talk to me, talk to my colleagues. Amy, who is the ops side of DevOps at Forrester, is in the audience. Hi, Amy. Please meet Amy because she's dynamite.
And it's not just the three of us. We've got a whole bunch of people in Forrester who are working on this. So work with us all. Thank you very much.