DevOps and operations teams are under increasing pressure from tech-savvy, app-centric business users to collaboratively solve complex business problems with IT. Adding to the battle, the pursuit for the perfect synchrony between software development and IT operations is still ongoing, and striking the balance won’t happen any time soon. New tools, technologies and processes change and grow at a problematic pace – leaving us with no option, but to accept and address all upcoming challenges.
Teams must keep up the pace to succeed, but operations teams cannot handle it solo and must work closely with DevOps. The operations group is responsible to drive flawless, organization-wide execution – this was a straightforward request when the systems were configured and maintained by operations. However, recently, development became more collaborative, with involved users demanding more, using the newest tools and making the process harder to manage. Additionally, the product environment of business users has rapidly moved to portable devices, which are self-contained and hungry for enterprise-wide cloud services. This shift has created five principle challenges. These are my top 5 DevOps and Operations challenges for 2015:
Challenge 1: Building the DevOps Culture
Culture is an abstract group of ideas and behaviors, which makes it hard to identify a standard collection of requirements. It is much easier to decide which tools to use and how to use them in the most efficient way. Tools are material objects, but the people who use these tools are much more complex and difficult to change. As DevOps is all about continuous change – including reconfiguring a company’s core culture – there is a steep hill to climb.
Replacing traditional development and operations silos with cooperative teams of people from both camps can only get us so far. While DevOps is supposed to intentionally foster collaboration and results-driven effort, it needs the support of operations. Until operations can identify how to embrace the new mentality of culture-fostering activities into its daily regimen, there is no way to help this aspect of DevOps grow.
Challenge 2: Meeting the Quick-Fix Tool/App Mentality
While most end users now rely on a wide palette of tools to get their job done, they often circumvent the IT department to get the tools they prefer. As many are open source or offer initial trial versions, unsanctioned tools can be adopted without any internal oversight – leading to major issues down the road.
Making matters worse, business users believe everything can be solved with an app, but that is often untrue. While it is the overwhelming consensus that every tool should have an easy-to-use app, making the app a useful, secure one is much more complex. Even if there is an “app for that,” it must be properly integrated to back-end systems as part of the cohesive enterprise infrastructure. DevOps must balance tool delegation and management early on.
Challenge 3: From Legacy to Cloud
Technology-savvy business users may want to use the latest tools, but that is a tall order for operations. When it comes to DevOps tooling and configuration management, there is still a lot of confusion as to which tools do what, and how they play with each other – if it all. Tools need to be compatible with existing solutions and technologies used by the company, and that is becoming increasingly complex with the rise of hybrid environments.
New hybrid environments include on-premise tools, IaaS tools like Amazon, Google or Azure, PaaS compute services, and SaaS business applications. Somehow, DevOps must ensure that they all work well together and deliver a seamless experience for the business user.
Challenge 4: Networking
Network engineers – if they are applying automation at all – are either doing ad-hoc scripting or tap a dedicated software engineering team to build homegrown systems for their use. Inflexible networks run rampant in today’s IT environments.
Looking for an example? Even vLANs have a spider web of interdependent IPs, ports, routers, routing tables and perimeter networks. Changing, breaking, moving or replicating any part of that intricate web often seems impossible.
Challenge 5: Marginalized and Changing Budget
Taking another perspective: Will customers pay more for network automation tools from the equipment vendor to make the networking user experience better? If a networking customer is spending a lot of money on the physical equipment, they often do not want additional software tools from the vendor, even if the network engineers do. The gap between the network engineering teams that need the tools and the decision makers who pay for them is widening.
While capital expenses may be separate from operational ones, CAPEX spends are now often mirrored by OPEX ones. Trying to quantify spend on an on-premise project management tool with a SaaS application is a major headache that can no longer be left solely in the hands of the CFO. This shift impacts the structure of IT budgets – it could even take away IT’s control if OPEX spend becomes more distributed.
What can be done to overcome these growing problems? Taking the following five steps should help you start off 2015 in the right direction.
Collaborate Wisely:
It might seem to get a little tense at times, but open forum discussion is well worth it. Collaboration allows teams to learn from each other and suggest possible solutions. It also encourages critical thinking and creativity. When you have different people working together on a project, you get more expansive creative input. To manage the potential leadership glut (i.e., the excess of people trying to lead the group and not that many willing to slow down and focus on a specific task), break the traditional decision-making process chain and turn it into a continuous flow of fresh thinking and ideas.
Empower Users:
Let your business users pick their own tools, but make sure that they report them to you. It’s a good idea to consider a library of vetted tools available for them to pick from. Encourage business users to suggest new tools so they have a sense of decision power. However, keep the tools current and make sure they actually address user needs.
Speak Accounting:
Try not to let OPEX issues become obstacles in tool adoption. If IT can help finance understand what is going on in the world of technology licensing vs. cloud service, it can fast track the inevitable shift, and ease budget reporting and bottlenecks.
Break the Immutable Network Infrastructure:
With immutable network infrastructure, you run the risk of being locked into vLAN and physical devices. What is the solution then? Leverage advanced virtualization tools (i.e. converting legacy systems to virtual machines) and take Software-Defined Networking (SDN) on board. With a centralized, programmable network that can automatically and dynamically address changing requirements, you can reduce both CAPEX and OPEX by enabling algorithm control of the network and use ASIC-based networking hardware supporting pay-as-you-go models. Deliver agility and flexibility by helping organizations rapidly deploy new applications.
Prioritize Analytics:
Analytics should make IT’s life easier. Build analytics and monitoring into everything from the start and think about it as “making sense” of the data or logs being collected. This information helps IT determine the true business impact of a performance issue to better prioritize where and what to troubleshoot. A strong analytics platform, where all application and tools data can be stored, gives operations the systems visibility it requires. Become a facilitator while maintaining all needed operations practices.
There will always be challenges ahead as we work to get smarter/ faster and develop better systems and applications. However, the right analytics tools and collaborative processes designed for cloud-enabled, distributed environments can make 2015 much easier than years past.
About the Author
Trevor Parsons, as chief scientist and co-founder at Logentries, Trevor Parsons is responsible for product strategy and direction. He works closely with customers and partners to continuously understand what they need, and to validate product market fit. Trevor also leads the product management and UX teams and assures the best possible user experience. Trevor enjoys speaking at local dev ops meet-ups and events, and is always looking for how log data and analytics can be applied in more and more powerful use cases. Trevor was a post doctoral researcher and member of the Performance Engineering Lab at the School of Computer Science and Informatics in University College Dublin, Ireland. He received a PhD from University College Dublin for his thesis titled “Automatic Detection of Performance Design and Deployment Antipatterns in Component Based Enterprise Systems.” You can follow Trevor on Linkedin and Twitter at https://www.linkedin.com/in/trevparsons and https://twitter.com/trevparsons.
