- How release engineering and DevOps intersect.
- What DevOps and Continuous Delivery mean for the future of release engineering.
- Tips for grappling with release engineering in a DevOps world.
Here are a few of the top live questions answered by DevOps consultant J. Paul Reed.
Where do you see release engineering in 10 years?
In 2026, everything will be based on server-less architectures, meaning we can get rid of all those pesky operations and release engineers.
No, but seriously: I think the work currently associated with “release engineering” may start to be called something else, especially as we attempt to “continuous delivery” everything. The work will be very similar. In fact, as the Internet-of-Things heats up, I think the entire industry is in for a rude awakening. The web, in many ways, has coddled us such that we could mostly ignore all of the release engineering discipline and everything would still be “mostly OK”. (And easily fixable, if not!)
Of course, us release engineers know that companies made their lives harder by doing so. When you start shipping software to your toaster and your pacemaker and your electric car, suddenly all those considerations around the mechanics of release software become incredibly important again.
So in that regard, I wouldn’t be surprised if we experience a bit of a renaissance in release engineering. What remains to be seen is whether the industry will look backward 10 years to the lessons we’ve already learned. Or if it will do what it usually does, and try to re-learn everything from first principles again. Again of course, with the pain, gnashing of teeth, and customer-affecting failure that comes with that.
Can DevOps succeed without a centralized enterprise DevOps team?
In fact, many would say a “centralized enterprise DevOps team” is an anti-pattern. In large enterprises, I have seen the creation of centralized DevOps teams (or even worse: a “DevOps Center of Excellence”). It tends to be fraught with all sorts of problems:
- It’s yet another team: one of the problems DevOps tries to solve is the siloed nature of development and operations teams. But when you create another team in between these teams, that’s just another team to manage, with additional complexities to address. And it doesn’t solve the original silo problem.
- There’s been much discussion recently of the problems with “bi-modal IT,” the idea that there’s “one speed” for “legacy” IT, and the shiny, new DevOps way is another mode. This has a tendency to engender all sorts of animosity between the teams responsible for the “two modes” of IT. A centralized DevOps team is likely to promote this separation, which is starting to be widely recognized as problematic.
- Lastly, a centralized DevOps team doesn’t allow local development and operations teams to experiment, communicate, learn, wrestle with, and work in their local contexts, precisely where it would be most valuable. On the contrary, it restricts such behavior.
That’s not to say if you have one of these teams, you’re “doing it wrong” or it’s going to be horrible. But I would say: a centralized DevOps team does not guarantee success. In fact, in many ways, it may impede it.
Is Docker better than VM technology for DevOps? In a test environment? Is this the future?
There’s a lot of hype around Docker right now. Because of that there is confusion around what it’s good for, what it isn’t good for, and how it can best be leveraged in real-world environments.
A tweet I saw just the other day was from an engineer with a fair amount of Docker experience. She asked the audience she was presenting to “Who’s using Docker?” and noted that many hands went up. She then added “… in production”: the hands all went down.
There’s a fair amount of management and infrastructure tooling that’s currently missing in Docker-land. I think they’re working hard and fast on fixing that, but that’s also why you get a fairly wide range of “Docker usage stories”. For some users, the tools they need to manage at scale (in or out of production) simply aren’t there. They either have to build them, or abandon Docker.
Ultimately, Docker as a way to coordinate developers’ environments is a great use case, and it’s the one I commonly see. I don’t believe Docker solves all the problems that virtualization solved. It doesn’t solve all the problems that configuration management solves. But it does solve a problem. The best Docker rollouts are those that use Docker for certain solutions, but can still produce VMs, or AMIs, or other operable artifacts that are not Docker containers.
For more discussion on some of the concerns of rolling out Docker in an environment, read my good friend Julian Dunn’s blog post: The Oncoming Train of Enterprise Container Deployments.
For additional DevOps best practices, download J. Paul’s publication by O’Reilly media “DevOps in Practice”. For more webcasts on hot topics please visit perforce.com/events to register for upcoming webinars.