Maksim Samasiuk - Fotolia
At the upcoming Container World conference, there's no question that Baruch Sadogursky's talk, "DevOps @Scale (Greek Tragedy in 3 Acts)," stood out from other more prosaic topics. Sadogursky, a developer advocate at JFrog, which offers a software infrastructure management platform, spoke with senior technology editor Valerie Silverthorne about his talk in January. Unfortunately, while the talk will still be given at Container World in Santa Clara, Calif., at the end of February, Sadogursky's colleague Mark Galpin will be handling it. Here's Sadogursky's preview of DevOps at scale:
Why do you call it a Greek tragedy?
Baruch Sadogursky: That's easy. (DevOps at scale) usually ends badly and everybody dies. With DevOps there are always bodies littering the street.
And it's in three acts?
Sadogursky: The talk that we give is a three act play in which things go from bad to worse. It starts off badly then gets a little bit better and then way worse. You hit a certain scale. Just when you thought you got it understood -- why DevOps is needed -- and you start trying a little bit of scale and you get to real DevOps at scale you hit a new set of problems. You're not ready. But the good news is in a Greek tragedy you can have an epilog. There can be a Hollywood happy ending. We know how to solve those problems.
How do you know?
Sadogursky: What we know is we have more than 4,000 customers by now and most of them are big ones. What we see a lot is that just a fraction of them, just 5%, implement what it takes to make DevOps right. We know what it takes, but we also know it is hard to follow the remedies. It's hard. But there is some hope that eventually they're going to figure it out. But right now mostly the DevOps journey is full of bodies and is kind of a tragedy.
So what is the solution?
Sadogursky: It's a simple answer, but it's impossible to solve. It's culture. It's a very simple question with a simple answer, but it's very, very hard to achieve and that's just because the software industry is not new. We all have our experiences and we're going to do what we do. When we hear about Netflix giving production access to junior engineers we feel our hair standing up. It's horrible. It sounds like a recipe for a disaster. And that's of course the biggest problem. The one way to solve it is pain. Pain is extremely instructional. When you have a couple of late nights because of deployments that have gone bad that really helps in transforming the culture. And if you think about it all our guides for DevOps starting with The Phoenix Project to any other book of how to do DevOps (or DevOps at scale) talks about how instructional pain is. There is no other way to make this change. You cannot talk people into changing their behavior. That's fine. That's OK, but there's just going to be collateral damage on the way.
That's a unique take. Are people surprised by this?
Sadogursky: They are surprised of course. As engineers we look for everything to be solved by technology. This is how we work now; this is DevOps. Engineers say, 'Ok, let's change ... all we need is a new set of tools. A new set of products is going to solve this pain.' They onboard Dev and Ops onto platforms that will help them collaborate; they use Chef and Docker and everything will be fine. They've got the tools they need, they start to collaborate and it hits them that it's not the problem. It's not the tools. It's not the technology. The problem is completely different. Until the behavior is changing tools won't help. As engineers it's hard to accept because we solve problems with tools.
How long will it take people to figure this out?
Sadogursky: How long it's going to take is a broad question. It depends on the size. A team of three people is going to figure it out faster than a team of 100 people. It also depends on the scope. If you do a completely DevOps or Agile process for a very simple or small product, you probably won't be able to just scale it to huge deployments or huge systems. I really don't think we can name any number that makes sense. Most of the cases (of doing DevOps at scale) are so different.
Getting off on the right foot with DevOps
Understand DevOps from the inside out
Grappling with the elusive DevOps culture issue