What the Future May Hold for Ops (All-Star Panel Discussion)

Damon, I’ve seen you champion this, so I’m going to give you the chance to kind of define it. What do we mean by next gen ops?

I think it’s just saying how do we, in this modern world, go fast and the lock it down? We have this next generation of infrastructure platform technologies, so how do we operate this new stuff so that we can do the new business, and meet the new business demands?

Sort of the problem we’re solving is the development side of the house has had almost 20 years of agile sort of seeping into their brains. Ops hasn’t had that.

Ops has had since 1990 Itel seeping into their brains, which is a different way of viewing the world. So this modern operations idea is about how do we take these DevOps and agile ideas and break them down into the first principles and apply them to all this new technology, and these new business demands, so that we can transform operations the way we’ve done a good job of transforming dev in the DevOps world.

And then I got there, I was working on a platform as a service and realized that it was just as much an ops story as it was a developer story. So I’ve had that benefit of having come from the development side and then seeing some of the challenges we have on the ops side.
And so, what’s super interesting is to take this idea, the idea that Damon just described, but apply that to slightly different, (very much related,) but slightly different themes, because there are different jobs to be done by the ops people than there are the developers, and a new set of primitives.

And to bring those two things together, so it’s kind of from the above and coming up from the below, the below being all the primitives that you have, the platforms that Damon mentioned, and from above being the requirements. And so it’s the requirements that are changing. We’re moving a lot faster and the developers are actually bringing things to us more quickly, us being operations folks, and I have new platforms. And that’s very intriguing.

I think being part of IT Revolution has created an incredible network for all of us, being part of DevOps Days has created a network, being at Docker. So a lot of people, all my best friends are all taking jobs as VP of Next Generation Platform Development in large corporations. So I see this macro trend within the last two years. And we’ve had the pass, and some of that is still in play … But large corporations are starting to ask this question about, “Okay, in 2018, what do we need to look like in the next three years?”

This is more of a technology. I totally agree with both of you on the meta side, but I see Nick Weaver going over to Nike, and he’s a platform genius, right? And different people like that are taking these new kind of roles back in large corporations. So that tells me there’s this yearning in the enterprise to whatever past is prologue. And so then now I’m interested in what does that look like. I have my opinions, of course, but I think that’s to me the fabric of the future and how are they going to evolve?

Life goes on and the interesting question about how do you manage that at scale comes along, then a technology called Kubernetes comes in, and now basically it’s a mess because nobody knows who owns that. So like with Docker the developers now have this freedom to drive infrastructure pretty deep into it and some places have a lot of control of the delivery for an infrastructure standpoint.

Then you get into how do you scale the architecture? Kubernetes starts getting incredibly popular, and now really from what I see, in most cases, the developers are responsible for maintaining Kubernetes and now they’re like kind of worse off than they were. And I’m pro-Kubernetes all the way. I mean, I think that is the future, I’ll say that right now.

But it is kind of messy right now, because what looked like a clean path just got awfully ugly all over again. And developers are like, “Well, this is a lot harder than the Docker’s stuff.” You know, especially when you get into stateful stuff, right? Anyway, so there is this weird, developers looked like they had this clearer path, and now we’re back kind of being messy all over again.

And I think that now what we’re seeing with the platform, the smarter companies going sort of to platform organization, right? It’s no longer about operations. It’s about how do you bake the best practices of operations into as much of that platform as possible? And then give control to the rest of the organization through kind of pull-based self-service, but it’s that ability to build just the right amount of platform. But they have to re-think it.

On Operations we’ve got all these different silos, and we have ticket queues. And that’s how the Operations in a lot of organizations still works. So now, the challenge of the platform organization is to try to bake all of that, send the ticket queues into a self-service platform. And really offer that operations, but for the rest of the organization.

And that’s a new operating model. It totally, fundamentally breaks how people in operations think about their job and their specialties and their silos.

So I just think  it hasn’t caught up yet. That’s kind of my point about dev, the agile side, has been seeping in for a long time, and ops, it’s still the Itel mindset that’s been baked in for the last 20, 30 years.

Back to your [John’s] point of Kubernetes, that has completely made fuzzy that, what that contract is, and so I actually think of it not so much as a flattening, but what we’ve done is added an extra layer in there and we haven’t figured out what the right contract is for the application teams and for the developers.

So I think a lot of the counter-reformation or pushback you’re getting from these different sides, ’cause it doesn’t make sense that they’re each saying different things. It’s just a reaction to that it’s actually cutting deep. Actually getting deeper into these organizations and affecting broader change, and that’s just hard.

But can you go a little deeper into contracts? Because I think that’s incredibly interesting. Like the transition of where we kind of felt safe, and now we’re kind of unsafe?

And now enter Kubernetes, and there’s this idea that the developers are going to interact with the Kuber —and actually in practice they’re interacting with the Kubernetes APIs. So they’re generating these YAML files, where they’re creating their pods, and their creating their policies, and they’re creating their storage volume claims, and all of these things. And what we don’t, what the industry hasn’t really grappled with is this idea that Kubernetes projects much more of an infrastructure Dial Tone.

And that’s probably not what application teams, DevOp teams, really need, because that’s actually going to slow them down. And so the platform—

We’re changing how you work, and that’s totally different, and that parts has to be figured out. Otherwise you can’t escape this sort of infrastructure dial-tone. You can’t escape those primitives, because then anything you bake in is just going to be … if everyone is doing ten different things, you’re going to satisfy one person, and nine people you’re going to upset.

So everything stays at that low level until people do the hard work and the false starts to figure it out, and then you can kind of jump up a level and say, “Okay, now we’ve kind of got a common idea on that. That’s gotta-“.

But there’s people out there that think that. Just get my hands on these new tools, all this stuff’s going to go away. Then you see the chaos and the blow back when people do, try to do that.

Or, okay, maybe we’re going to consolidate, which means five long-running VMs on one physical machine. So you’re not really fundamentally changing how developers create, and you’re not really changing how you operate. You’re just adding another kind of layer of complexity in there, or complication, I guess you could say.

You know one of the greatest things I love about Pivotal, I had this kind of epiphany the other day — I was at a customer and we were debating whether Kubernetes and Pass and what it should be, and one of the things they said, ‘the greatest thing that Cloud Factory did for us is it forced us to do twelve-factor app.’So I realized, you know, I’m not paying as much tribute to a technology that, like you went to it, and to go to it, you had to be twelve factor app. And that’s kind of brilliant. You leave some people behind. But my longer point is this whole Cloud Native, twelve factor, micro-server, whatever you want to call it today, we’ve been winding down this path.

When people started going to Amazon they realized you really had to refactor stuff, you had to decouple. You know, went to containers of costs. That was a beautiful collision of micro-services and compute infrastructure.

And what you guys have done with the twelve-factor app and pushing it. So I think Kubernetes is going to move a little faster, because I mean, a lot of the green-filled world in most enterprises is kind of hip to this model. So I think there’s still going to be a lot of legacy stuff.

But I do think it’s still ugly, it’s still the wild west.

So we’ve got to think about that, it might take three years for Kubernetes to kind of mature to more of a mainstream operation, but then are we going to look back and go, “Oh, this was the Open Stack of the mid-2010s?” And there’s something five years from now where like, “Oh, yeah, remember Kubernetes?” It’s just one of those where, do we foolishly think that like, this is it, when there’s a bunch of other things coming?