The state we’re in: DevOps in 2020-21

When I was growing up in South Wales, my Mam would regularly shout at me, “Look at the state of this room!” My teenage bedroom was indeed a tip, as my coalmining Dad would appropriately call it. In the mainframe world, DevOps is about to hit its teen years. Adolescence beckons. So, is DevOps currently in a state of disarray or is it about to evolve into a fully-rounded member of mainframe society?

First observed in Belgium in 2009, DevOps aims to combine software development and IT operations, shortening development lifecycles by providing continuous delivery and continuous integration with high software quality. Complementing the Agile development methodology – like siblings in the same family – DevOps aims to deliver software “better, faster, safer, cheaper and happier” than previous efforts.

Is it actually achieving that? When you think about it, we don’t even have a unique verifiable definition for DevOps yet. That still eludes academics and practitioners alike.

What we do know is that DevOps is BIG. Of the 40 million software developers worldwide, DevOps represents 20% of all programming efforts. It’s pervasive. Bury your head in a Waterfall, perhaps, but you can’t get away from it. And as it goes through its growing pains, DevOps runs up against various cultural barriers in an organisation:

  • Devs vs. Ops
  • Devs vs. IT Security
  • Devs vs. DBAs
  • Devs vs. Sysadmins

Each glares at the other with suspicion, mistrust and FUD (fear, uncertainty and doubt), like rival gangs in the playground. Each assumes mis-aligned incentives or motives of the other. The Devs thinks the Ops are there to hinder their progress. Ops think the Devs are going to run roughshod over their finely tuned production system. And so on. It’s like the Sharks and the Jets in West Side Story, but with fewer dance routines and more mainframes.

But I digress. There are many suggested solutions to this clash of cultures. Here are a few from me.

Source Code Analysis: various methods exist to perform this, both automatic and manual, but it provides Ops with the confidence that what’s coming their way isn’t going to, ahem, hit the fan any time soon.

Test-Driven Development: this is the “shift left” we’ve been hearing about. Don’t chuck your code at the testers and run away, build testing into the development process.

Dynamic Application Security Testing: “Black box testing” with no access to the source code.

Security-Driven Development: build security into your development process, testing for vulnerabilities as you develop the source code.

Tooling: ah yes, the “Periodic Table of DevOps”. Take a look at “the industry’s go-to resource for identifying best-of-breed tools across the software delivery lifecycle.”

Culture change and education: I cannot stress the importance of this enough. Get both sides of Dev and Ops (and the rest) to understand each other. Break down those silos. Trebuchet those Ivory Towers. You are all working together to deliver value to the customer, who, at the end of the day, pays your salaries.

Now that DevOps is maturing and heading towards high school, what can we expect in the near future? Here are my top eight observations and suggestions.

  1. Software delivery and operational performance are key. If we want businesses to truly flourish as they adopt DevOps, and if we want to allay the fears or Operations staff and management, then operation performance must be built into the product. Clean code. Efficient code.
  2. Where possible, smaller incremental changes should be released more frequently, that are easily backed out. This will ensure a low impact to production availability and performance.
  3. Use metrics and analytics. Change records, development times, deployments, incident counts, fixes, mean-time-to-recover… all must be logged and analysed. How can we get better at this?
  4. Everything automated. Automation mitigates the risks of single points of failure. Automation and Orchestration are vital to software delivery.
  5. Everything coded. If it can be documented, it can be coded: knowledge bases, business processes, IT processes, infrastructure, architecture… everything as code! If everything can be coded, everything can be audited, validated and automated.
  6. Everything connected. Once coded, it’s easier to achieve a complete end-to-end mapping of anything, including your software stack, business processes, interfaces, APIs, networks, systems and subsystems. Once mapped, these elements become easier to manage, administer and deploy.
  7. Everything resilient. Everything secure. Once you have a documented coded map of everything, it becomes easier to protect from vulnerabilities, both to security and to service.
  8. Cloud: organisations that fully embrace DevOps generally embrace an on-prem/off-prem/hybrid cloud architecture of some description. DevOps deploys easily to a cloud infrastructure.

So where does all this leave the mainframe? Traditionally in conflict with all of the above, mainframers have often been defined as dinosaurs, faithful only to the Waterfall method of development, reticent to adopt anything new. Barriers to change, bastions of bureaucracy.

In short, the digital equivalent of the elderly Great Aunt: full of riches but not dead yet.

At this point, I want to politely but vehemently disagree. The mainframe is fast. Very fast. It is also scalable, resilient, secure, flexible and available. It can handle the workload of thousands of x86 servers for a fraction of the TCO and manpower.

With the right procedures, tooling, education, culture shift and mind set, the business-critical applications that currently run on mainframes can easily be integrated into a DevOps operation. Efforts like Zowe, run by the Open Mainframe Project which is itself managed by the Linux Foundation, have opened up the mainframe to modern developers. Linux, Docker, Kubernetes, Git – once the property of x86 machines now have the might of the mainframe behind them!

The mainframe is the original cloud and it’s been reigning for over 50 years. You can teach an old dog new tricks. Just look at me: far from being a tip, my bedroom these days is clean and tidy – and all the better for it.

Marcus Davage works for BMC Software. Chair of the GSE UK Db2 Working Group, his specialities include Product Development, AMI, DevOps and Db2. Proudly Welsh, all views expressed are his own, and not necessarily those of BMC Software or GSE.

Back To Top