6 Challenges Facing DevOps and Operations Teams

[gnanasekar6914]

Previously IT infrastructure was a service published to the rest of the organization. The systems were configured and maintained by operations. If there was a new request, the request was made, and then executed by the operations team.

In the modern world of users and development the process is a bit more subjective and collaborative. This is a good thing, but shifts the dynamic and responsibilities. Development users demand more, and are adopting tools at a nearly un-manageable pace. Business users are more technically savvy, know what they want, and often will try to address challenges on their own. Additionally their productivity environment has made a major move to mobile devices, which are self-contained and hungry for enterprise-wide cloud services.

I’m sure you have heard “knowing is half the battle,” and sometimes when in the weeds, you cannot spend the time to reflect on what has happened and what is coming. Knowing what you will face will help you brace and prepare in advance. Here is the list.

1. Who owns Culture?

You have heard that DevOps is culture first. And while you know what culture means, it’s never clear who owns it. The point of naming culture is to highlight that its creation should be deliberate. It does not mean Ninjas, Rockstars, and hoodies. Culture exists no matter what, but usually it creates itself. And in DevOps you are supposed to intentionally foster collaboration, and results driven effort.

Until operations can identify how they will include culture fostering into their daily activities, there is no way to help this aspect of DevOps grow. It is a must to get to the processes and proper implementation of the tools. Infrastructure is still in operations full control, but because large organizations are creating dev silos the culture is not, and because they are supposed to be tied, this is a bit of a contradiction.

2. Everyone has a tool

These days everyone has a tool for the job. Either they used it in the past, they heard about it from a friend, or recently saw it on TechCrunch. Many of the tools are open-source, or SaaS based offerings that users can get a trial of and start using instantly. The trick for operations is to support this and still maintain awareness.

These tools can be adopted without any internal oversight, which can lead to issues down the road. First because of support down the road if the original adopter leaves, but more importantly governance. What data is stored there?

This is usually not developments concern, but operations are expected to know.

Balancing tool delegation, which needs to happen, and tool management is something that needs to be addressed early on. This is where the concept of Shared Services comes in handy.

3. “There is an App for that, right?”

All those tools are simply an app you download and use, right?

Nope.

They have to tie into everything else, and it’s not the App that is the challenge. The challenge is getting it adopted, integrated, and quantified. For example a functional testing tool fixes QA challenges, but it has to fit in with delivery automation tools as well.

4. Cloud + Legacy

The reason operations don’t jump at tools at the pace that development and business users would desire, is not because they do not want to. Often it’s because that tool has to fit into an ecosystem of existing applications. Usually there are a few grandpa applications in there that lack have the agility the modern tools have. But they still have to work together.

Not only does the new hybrid environment include on-premise tools, IaaS tools like Amazon, Google, or Azure, PaaS compute services, and finally SaaS business applications. But, they all have to jive together too!

5. Networking is a drag

Networking, not servers, is often the immutable object that is not easy to make agile. Even when working with vLans there is a spider web of IPs, Ports, Routers, routing tables, perimeter networks etc who’s interdependency can’t simply be changed, broken, moved, or replicated.

6. Marginalized and Changing Budgets

it is very cliché to say budgets are being squished while demands are increasing. But that is not the point. The point is the structure of budgets is changing, and many organizations have not figured out how to align that with the shift in types of technology. There are the capital expenses that are separate from the operational ones. However CAPEX spends often are mirrored by sister OPEX ones.

It becomes very confusing when you try to quantify the spend on an on-premise project management tool with a SaaS one as well. While this is a job for the CFOs it impacts the structure of IT budgets, or sometimes means that IT gets even less control over OPEX spends because decision making is distributed, and can happen on a credit card.

Source: logentries