The portmanteau coming together of Dev (developer) and Ops (operations) represents an arranged married of sorts that, for some, will never have a happily ever after ending. So, what are the top five most contentious issues at hand today?
DevOps can be a thorny subject. The coming together in harmony of Dev (developer) and Ops (operations) represents an arranged married of sorts that, for some, will never have a happily ever after ending as both parties ultimately contest a battle of irreconcilable differences.
But despite the naysayers, the very existence of DevOps as a portmanteau (and perhaps sister labels like DevSecOps, to form a security sandwich) is in many ways a validation of the need to form a bond of tighter unity and harmony between two factions that have often been at odds with each other over the years, coming from different priority mindsets as they do.
Even with the popularisation, extrapolation and democratization that DevOps has enjoyed through the last decade, not everyone will be convinced of its worth, its effectiveness and some even doubt its very existence. Some say that DevOps already existed without a formalized label if you look back to the software practices IBM was championing a quarter-century ago.
One thing we can be certain of is that DevOps almost always throws up a few meaty bones of contention. Let’s face those antagonisms head-on than in the hope that we can harness some of the angst and turn it into positive energy for a DevOps-enriched future. As we look to analyze the most contentious and sensitive issues in this space, what should we be aware of and how do the big issues break down?
1. Is it a bird? Is it a plane?
Arguably, the biggest problem with DevOps is categorizing it. Some call it a methodology for software application development. Proponents of ‘classic’ software methodologies disagree with this idea as, for the purists, a software methodology is Agile, Waterfall, Extreme, Rapid, Joint or Scrum.
This reality means that many people would prefer DevOps to be classified as a culture, a workplace ethic, a technique, a culture, and mindset or (perhaps most vaguely of all) an approach. To be truly successful you must take a holistic approach and look at the entire development cycle from beginning to end. Closely evaluate the processes that go into development to find different bottlenecks and roadblocks to productivity. By finding the areas where your current processes come up short, you will be able to identify the areas to emphasize on when implementing a strong DevOps strategy.
2. Cloud-native DevOps
Anyone who hasn’t been living in a cave since the turn of the millennium will know that Cloud computing has grown, faltered occasionally and ultimately blossomed to become a new standard barometer measure for all organizations on their journey towards so-called digital transformation. That’s the good news. The perhaps not quite as good news is that Cloud (and the contemporary drive to go Cloud-native) is still complex from initial deployment and particularly onwards to ongoing maintenance, management and reporting.
Taking DevOps into the world of Cloud-native will ultimately pay off with a bounty of positives, but first, there will be challenges as teams get used to the new shape, form and function of altogether more abstracted and virtualized software toolsets.
The key to getting Cloud-native DevOps right will be a prudent approach to monitoring and observability. As Cloud-centric DevOps teams ingest the logs, metrics and traces they need to perform solid and dependable system observability, they will need a consistent set of tools in order to monitor and observe systems for the long term. Within this practice, it will also be important to remember that monitoring is lower-level granular information related to system performance. Observability includes all the information gleaned from monitoring, but it also includes higher-level tools, some of which will be data visualizations for DevOps practitioners to use. When the two are combined for Cloud-native DevOps, system health can be optimized, preserved and maintained while any debugging or root cause analysis is executed at the lower level.
3. Machines in the application loop
With machine-to-machine events now happening more prevalently inside the Internet of Things (IoT), the need to capture, integrate and analyze the event streams that go on outside of the human loop and then bring those log metrics back closer to the sphere of ‘human’ software engineering is not a plug-and-play quick fix.
Getting machines to ‘play nice’ and be a part of expansive and progressive DevOps teams should be a given. After all, they’re just machines. In reality, there will be specific skills needed and human DevOps personnel will be required to get used to updates and other alerts that they have not previously had to shoulder.
4. AIOps and automation limits
Related to our last point on machine events, we need to think about AIOps. When we build AI-driven DevOps and create AIOps, we will need to stop and question at what point we set limits where process automation and the wider elements of automation hit the limiter/restrictors. In order to know how far we build AIOps, exhaustive auditing and analysis processes need to be carried out, so the whole technology proposition here is no simple point-and-click affair. Even when we do establish workable AIOps, there will be perimeters.
Add all that to the fact that some AIOps will require what we like to call ‘human handoff’ support when the AI intelligence engine doesn’t know what to do next and needs additional data and training… and then we can start to appreciate that AIOps itself is no simple plug-and-play affair.
5. Lift & shift doesn’t scale
One of the unfortunate truths in too many real-world IT shops today is that, where the Cloud is used, it is used poorly. Too many technologies experience a somewhat unceremonious lift-and-shift process where they are simply shunted towards the Cloud instances that an organization procures. This makes Cloud-centric DevOps harder to achieve. But why?
Because what happens back down in terrestrial (i.e., non-Cloud) programming is the development of individual cross-functional software teams. This silo-based approach happens due to corporate legacy structures, company management systems and sometimes for personal parochial or cultural reasons. When different teams are all reinventing wheels (running diagnostics tests, setting up CI/CD pipelines, delivering upgrades… and so on) that should be shared and accessible to all, a natural level of inefficiency surfaces.
Conclusion
These are our five most contentious DevOps issues for the immediate future, and it would of course not be too hard to find and categorize another batch or handful. In the future, we might even need to argue over which developers should be categorized as core devs and which core members of the operations department to include.
For software developers, software architects, all the software engineering professionals who work in systems administration, database admin, testing, security, and all other forms of operations, there’s just quite a lot at stake and quite a lot to tussle over. We could suggest that that’s what makes DevOps great, so we will!
