For me, there have been a number of processes in typical IT that have been substantial challenges from a business risk, regulatory and latency perspective. I constantly ask myself: Why is the hurdle between Dev and Ops so high which causes so many to “trip and fall”. Many key DevOps projects focus necessarily on the agile developer/operational staff scrum in order to underwrite the risk of the addition of a new set of services into a production environment. Born from web-scale companies, enterprises have long struggled with getting to the singular operating model that these new companies try and effect: the Google, eBay, Facebook, Twitter envy that we are always hearing about. I’ve seen some companies move to “InfraOps” as a strategy to begin to hyper automate critical functions across an enterprise, but then they talk about proven <older> concepts like the CMDB and ITIL. But most of the time they focus on organizational streamlining and alignment but maybe a lack of understanding of the common functions holds them back.
Interestingly, if you looked at the typical SDLC, the software development teams seem to struggle with similar things: Continuous Integration and Continuous Delivery via version control and formal Release Management. Fortunately, the team at ServiceMesh agreed to join CSC as we set out to delivery Software Defined Data Center (SDDC) benefits to our customers. As such, we are refactoring our delivery process to substantially align infrastructure ops with app ops and to get to full scope DevOps.
Per Gene Kim, the advantages can be amazing (my interpretation) for the SDLC:
Agility (50-87% improvement*)
- Developer Productivity: lead time reductions
- Deployment Frequency: feature add, repeatability
- Deployment Success: Improvement in SLA
- MTTR: decrease in time to resolve
Efficiency (~50% improvement*)
- Resource Reduction: fewer resources per project <holding constant feature rate>
- Developer Productivity: % of time new vs. remediation work
If you say, I want that same advantage in IT operations then we need to start with some of the same lifecycle strategies… Test Driven Development, Continuous Integration, Release Management. And if we’re good, we’ll remove the leading cause of fault = People [with hands on keyboards], improve deployment success, and maybe most valuable to large enterprises, reduce compliance/regulatory risk through the declarative model that results from fully automated provisioning/patching of the runtime environment.This shift isn’t without it’s challenges, but the benefits can be remarkable!
What if we really could drive IT via an iPod, with fully automated provisioning and automated recovery!
