While there are many enterprises talking about their devops implementations, there are very likely fewer getting their devops efforts done right. Bringing about successful devops transformations is a lot more than installing a few toolsets and holding more meetings between development operations teams.
Devops is more than a collection of new configuration management collaboration tools. Doing devops right is actually the proper orchestration of both collaboration and automation supported by enterprise software. And whether we label this as "devops" or not, collaboration and automation are absolutely essential in today's enterprise driven by continuous IT, which is the movement toward continuous integration and development pipelines, cloud platforms, virtualization and microservices, and continuous inputs from the IoT and other data sources.
With the move to such disciplines as continuous integration and development pipelines, the trend toward devops isn't a surprise. In fact, it's a requirement. However, bringing these teams together can create a lot of contention in some organizations, as both developers and infrastructure teams grapple with the changing ways they work in the enterprise. So what is the answer?
The answer is automation. By automating as many processes as possible within IT pipelines many of the conflicts, organizational turf battles, and bad processes are solved as continuous is realized through automating processes rather than through interactions and manual actions.
Fortunately, the practice of devops lend themselves to of Four Rules of the Continuous Enterprise:
- No appdev process shall be implemented that can't be fully automated.
- If an app, or process, can be rewritten to take advantage of new technology and improve its operation or maintenance, it should.
- When an app, or process, can be replaced with a third-party service, it should.
- When the Second or Third Law are limited by the First Law, look to the Second and Third Law to automate more.
Sounds simple, but the challenge and the implementation isn't easy. Within Salesforce, we started our move to devops in 2012, with the need to move swiftly and remain as competitive. Because Salesforce's development teams are established as functional groups, they require a lot of collaboration to deliver a high-quality cloud service.
Salesforce met those challenges by implementing CAMS (Culture, Automation, Measurement, and Sharing) model and ways to measure progress. In years past, if we needed to measure, we had to jump through a lot of hoops get get service tickets. We automated all of that to be self-service.
We've long benefits from automating a lot of our development processes. Salesforce as a very extensive test automation infrastructure for many of our software services. It's why we release enhancements and updates with such frequency. And we sought to bring very similar automated tests to our infrastructure efforts. In addition to being able to deploy more quickly and more frequently, automation also helps us to make sure our test and production environments are aligned.
However, for many the challenge to move to devops is complex. So complex that the research firm Gartner now recommends organizations embrace what they call bimodal IT, which advises enterprises to setup two IT distinct staffs, one team that focuses on legacy technology and another that focuses on modern development approaches such as devops for more innovative and fast-moving aspects of the business.
Many enterprises have turned to devops as a way to help streamline development efforts, and help reduce technical debt associated with legacy systems. And many of our customers running self-service clouds find that as cloud infrastructure and tools are made available to developers, the time it takes to get the application delivery actually lengthens. Developers end up having to provision virtual machines, make infrastructure decisions, and deal with very mundane tasks like maintenance and patching -- all of which distracts from what developers love and need to do: build apps. This isn't the way it was meant to be.
That's just one way developers are learning to better manage the connected everything and continuous IT. In our next piece we will dive into the details surrounding microservices best practices.