6 Challenges Facing DevOps and Operations Teams in 2015
6 Challenges Facing DevOps and Operations Teams in 2015
Join the DZone community and get the full member experience.Join For Free
With the influx of DevOps-related products and services on the market, today’s application delivery toolchain has become complex and fragmented. Watch Avoiding the DevOps Tax to learn best practices for integration and automation to realize a faster DevOps lifecycle.
To say that Operations and DevOps will have a new set of challenges in the coming year is a bit redundant, as their entire job is based on solving problems and facing challenges.
However the current and future landscape of tools, technologies, and processes is changing dramatically. While this has always been true, it’s the pace that is problematic. Additionally, the pressure from business users who believe everything is solved with an “app” has moved from annoying to destructive.
Here are the 6 challenges we believe IT and Operations will face now and into 2015.
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?
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.
Thanks for the problems, what do I do?
How rude, I gave you all the problems without answers. This was on purpose. Because the answers are not specific to each problem they span several of them.
Collaborate: So much more can get done when these issues are discussed in an open forum. The modern techified organizations practice a curmudgeon based communication strategy that might at times be a little tense, but opens the doors for all teams to learn from each other and suggest solutions, or raise issues. Break the process chain for decision making and turn it into a flow of thought and ideas. The only trick is keeping the ideas to specific sessions, and not randomly throughout work activities.
Empower: Let teams pick their own tools, but request that they report them to you. Also consider the library of tools approach, where operations vets tools prior to adoption, and present to all teams “the library of tools you can pick from.” They can feel free to suggest new tools, but can only select from the list. The only problem is the new burden on IT Operations to keep current.
Speak Accounting: The issues of chargeback and OPEX need to be addressed so it does not hinder tool adoption. There are so many ways to do this, and most way beyond my skill set. But if IT helps finance understand what is going on in the world of technology licensing vs. cloud service they can fast track the shift, and help them intern with budget reporting, and bottlenecks.
Break the Immutable Infrastructure: While there might be a big upfront effort, it is one time, you can break the shackles that old infrastructure has created for you. The trick is to leverage advanced functionality of virtualization tools such as converting legacy systems to VMs and keeping them on-prem or unifying them with the IaaS servers. On-Prem virtualization can benefit from snapshots of VMs in their running states and linked clones to allow development work against large business systems, but on exact duplicates instead to eliminate the concern of breaking something. In fact in this scenario you are encouraged to push forward so fast that you will break something. It won’t impact anyone else. And for those nasty networking layers, leverage the powers of modern SDN technology, versus heavy vLAN and physical devices.
And Finally, Analytics first: Build analytics and monitoring into everything, and force your developers to do the same. By adopting a robust analytics platform, where all data is stored for applications and new tooling, operations can be aware and have visibility into all systems, even if it is out of their control. And todays log analysis platforms can alert operations of anomalies in the entire ecosystem without any additional effort on their part. Keeping their visibility without hindering adoption.
Challenges are not new to operations teams, but the pressure behind the increasing rate of change might be. And now that users have alternatives with shadow IT, it is even a bigger problem. However if you look at shadow IT as a wish list of tools your organization desires, and a scream for guidance, you can help. And if you leverage analytics to guide and manage the effort, you can become a facilitator, at the same time maintaining all required operations practices.
Published at DZone with permission of Trevor Parsons , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.