Taking Care of Business: Breaking Down Business Barriers to DevOps Transformation (third of three)

Author’s note: This is the third in a three-part series about why DevOps transformation can be so hard for an enterprise, Be sure to read Part 1: Overcoming Process Barriers to DevOps Transformation: A Herculean Task and Part 2: Winning at Whac-a-Mole: Overcoming Psychological Barriers to DevOps Transformation.

At its core, DevOps is a strategy for enhancing the speed and quality of business services to drive competitive differentiation in the marketplace. This strategy unites application development and IT operations into a cohesive unit focused on delivering the results the business needs.

Ironically, in our work with global enterprises we have found that business obstacles can get in the way of the DevOps mission of “Taking Care of Business.” Here I’ll provide suggestions for overcoming three business obstacles you may face in your DevOps Transformation:

1. Seek Environmental Alignment

Every enterprise has the usual complement of environments to develop, test and deploy their code. These have names that include Dev, DevTest, Integration, Load, Prod, etc.

Each of these environments serves a specific function to meet the needs of the business—from development work to integration to production, and everything in between. Unfortunately, even if these environments were set up the same way in the beginning, the lack of central management will guarantee that there is drift in these environments over time. The resulting discrepancies add complexity to the deployment process.

These differences often affect the non-functional requirements for an application, such as load balancer software / hardware, storage, security, cloud platform, and others. During a manual installation, most of these differences are just “known,” and people will account for them based on their knowledge. However, during a DevOps transformation, these environmental differences will become very evident (almost immediately) to the teams that are automating the deployment of any application.

Remember, one of the goals of a DevOps process transition is to create infrastructure that is immutable. To support this goal, the same infrastructure automation code should be utilized across all environments, starting with the developers. If you are writing code specific to an environment, your infrastructure is no longer immutable. (Granted, your code will need to account for things like IP Address changes and the like, but these fall in the category of configuration management and do not represent environmental differences that should impact the application.)

Getting these environments aligned presents a great challenge for many of our enterprise customers. This is especially true when the environments have different system owners and different budgets and may be deployed in different parts of the world. Fortunately, as we progress further into a world where infrastructure is becoming code—with API-driven infrastructures like AWS, OpenStack, Docker, SDN and others—standardization becomes easier to achieve.

2. Enhance Software Development Skills

If you look at the skill-set requirements of the enterprise infrastructure engineering, networking, and operations teams, you’ll notice that software development skills have not been a priority. Certainly members of these teams often have some level of scripting skills and basic bash, but a deeper software development skill set is needed in the modern DevOps support model.

These teams need to learn basic git workflows to succeed in an environment where infrastructure is maintained as code. I have seen a lot of resistance to hiring for these skills and to providing training to develop these skills, and that’s a huge mistake. Software development skills are crucial to the success of enterprise IT now and will only become more critical in the future.

3. Manage Applications Not Servers

Years ago when the concept of virtualization was just being introduced, many IT operators did not want to give up on bare metal. We called these folks “server huggers.” Most people have since moved past server hugging, but, now that we are transitioning to a cloud world, we have a new generation of IT operators resistant to moving beyond their comfort zone, and we call them “VM huggers.” In most large enterprises today, you will find remnants of both server huggers and VM huggers, still clinging on.

For DevOps transformation to succeed, we have to release those old mindsets and think differently about what our job really is:

The goal should be to transition from managing servers and virtual machines to managing applications.

Let me give you an example. We tend to focus all of our measurements on the host level. While this will give you insight into how the server is running, it is only part of the picture. Understanding how the application is performing and reacting to those details is generally more significant and will greatly improve the business case for the application being monitored.

Consider this: When an application becomes unresponsive, it will take more time to determine that a server has filled up its disk than to simply add more VMs. Once the application is performing to meet the business requirements, details on what went wrong can be evaluated out of band from any single incident. Then you can take the troubling VMs out of service, review the incident, and provide feedback to the development team for remediation. This greatly simplifies the process for everyone and reduces the work being done “off-hours” for the entire team. Businesses care about applications, not virtual machines. The added cost of these “additional” VMs during a “failure” state is minimal compared to the downtime of the service.

Over the course of this three-part series, I’ve identified a few of the common barriers enterprises may face in their DevOps journeys. I’ve given you some things to watch out for and some time-tested strategies for overcoming those obstacles. More importantly, I hope I’ve made three things clear:

1. All of these obstacles are surmountable
2. The DevOps journey is well worth the effort
3. and The Solinea team is here to help.

Share your thoughts on these topics with us. We’d love to hear feedback from others walking the path to enterprise DevOps Nirvana.

Author: Seth Fox