The following is the transcript of a conversation between Ryan Ward, Marketing Manager at Telegraph Hill, and Rob Schoening, Principal Consultant, regarding DevOps trends that Rob is seeing throughout today’s marketplace.
Ryan Ward: Thanks for taking some time with me, Rob. To jump right in, let me ask: Is it difficult for small, software-based businesses to switch to an Agile approach or DevOps methodology if they have previously established themselves without those practices in place?
Rob Schoening: I think you need the right leadership, with the VP of Engineering or CIO position to set the cadence for the path going forward. Is the change possible? Is it difficult to change? I don’t know, it’s always hard to change people, but once “muscle memory” sets in, I don’t think it’s that hard. It’s much harder to change a large organization that has organizational divisions, but until you get to a place where you have really large separation of duties and complicated organizational structures, it can always be changed.
RW: So it starts from the top, with a buy-in at a management level?
RS: If it hasn’t started from the bottom organically, it definitely has to be championed from the top. Based on experience, though, most places where DevOps has been successful, it’s started organically.
RW: How would you measure success when it comes to continuous delivery?
RS: Features delivered per unit-time with a quality component; I don’t know, every organization comes up with their own metrics, but they’re all going to be somewhat the same, really. Features delivered, number of releases…who knows, maybe for some organizations frequency of releases isn’t, in itself, going to be a measure of success. Just getting from a quarterly release cycle to a monthly release cycle might be, without sacrificing quality, considered a success. It’s different for every organization. But achieving agility and improving time to market, without sacrificing quality for small, startup businesses that can tolerate it- that’s the goal.
RW: Are there popular 3rd party tools out there right now, related to DevOps, that you’re seeing, like Chef and Puppet?
RS: There are, but less so those you mentioned. Those can be a peripheral part, but Jenkins would probably be the most popular, because it’s free. Hudson’s was the forerunner of Jenkins, also Bamboo. Ruby 1 is kind of new, and that’s gaining adoption, but I don’t see it gaining traction in the enterprise marketplace. There are the old school IBM products, but I think for the most part, you want something “light” and where switching costs are really low, meaning it can be deployed easily, it can be un-deployed easily, and it isn’t an anchor to the organization.
You need an easy user-interface, where both non-technical and technical users can use it. It needs to be a simple, clean interface, with a button on a page that everyone can understand. It can get very complex very quickly, which is why you need something like Jenkins. They’ll deploy simply, and you don’t need a lot of fancy customization. You just need to say “here’s a process, I’m going to define it, there’s the button to invoke it”, and then check it in to source control so that it’s repeatable, auditable, and so you can figure out “what happened last night, what happened last week, etc.” That’s the most important part, and then obviously you need some rational build and deploy framework, which is a little different than just a user-interface.
So to summarize, you’ve got your continuous integration tools- your Hudson, Jenkins, Ruby etc. Then your build management tool, Maven, etc. Then your operations infrastructure automation tools, like Chef, Puppet, etc.
RW: A DevOps solution brings Dev and Ops together, preventing one from hindering the other. Who is more resistant to the change, in your opinion, Dev or Ops?
RS: You know, it’s making sure that there aren’t organizational boundaries to process flows and being able to get something done. Some companies, they can’t even conceive the change, because it runs counter to what they believe is giving them process maturity. It might be the company culture that you need to take 7 steps to get something done, and that’s just the way it is. Moving slowly, avoiding mistakes by making it really difficult to do anything.
Any larger organization that is risk-averse is a challenge, and for good reason…that isn’t a bad thing. But it’s software, and if software is the core part of the business, you really can’t afford to spend a quarter-million dollars on changing 20 lines of code. You just can’t afford to do that.
RW: Really, a quarter-million dollars on something as simple as 20 lines of code?
RS: You’d be surprised. That’s where in the industry, to stay competitive…this goes back to the top, where “more rapidly, higher quality” is the key. Are CIO’s being urged to be more agile, or is it OK to spend tens of thousands of dollars on some mini-project, just to make sure it doesn’t get screwed-up? I think you’ll see more of that in large companies; they’ll start to get away from that mentality and realize that they can’t be competitive with those kinds of behaviors. Someone else will just come along and eat their lunch, so to speak.
RW: So the ideal candidate for a DevOps solution is…?
RS: Well, a company that’s a little further up the maturity latter, where it’s not there organically. We’re working with a company currently that is a perfect example. They have the technical skills there, and they have the “squeaky-clean” aspect of DevOps there, and they’re looking for squeaky-clean infrastructure, but the automation just didn’t kick-in. And then heroics just take over, and you see week-by-week successes and you’re OK with what you’ve got. They’re a great example, because they’re crossing that threshold between startup and small enterprise.