Welcome back to the DevOps.com series, ‘Enterprise DevOps Q&A’. Remember, if you have specific questions about Enterprise DevOps, let me know and I will try to answer them for you.
Today’s question is:
Q. In large enterprises, there are always environmental differences. From public cloud to internal hosting, from virtual desktops to legacy and mainframe – it is not possible to have full consistency between environments. Do you have any suggestions for approaching this gap?
The Challenge of Enterprise Complexity
This is a huge problem in larger enterprises, especially as DevOps practices grow beyond just isolated departmental applications. Architects have one system for prototyping; developers have a different system to code on; test and QA have their own unique ‘standard’ systems; while operations have untouchable systems for production.
Add to this the complexity of backending into CICS or IMS applications, accessing data from DB2 or ADABAS on iSeries, or automating WebSphere deployment onto HP/UX; plus licensing for an Oracle database on AWS or an SAP client on Azure; and meeting compliance requirements for data privacy and operational security. This enterprise complexity and environmental inconsistency so often means new code is not properly tested until it hits production, resulting in unacceptable bug counts and an average annual downtime cost of almost $700K per incident!
No Snowflakes
Many will say that you cannot perpetuate ‘unique snowflakes’, so you must standardize environments. This dogma is easy to preach – and in principle is a best practice – but in reality it is too simplistic for most enterprises. Disparate environments often exist for good reasons (e.g. to accommodate cost, skillset, throughput, integration, or other technical requirements). In any case, you cannot simply run roughshod over established architectures. So standardize if and when you can, but realize that this path is unlikely to solve the problem.
Abstract Platforms
When you cannot fully standardize, you can still approach consistency by abstracting unique platforms. For example:
- save that bespoke Windows config as a virtual machine, then you can subsequently redeploy it automatically onto a standardized Linux virtualization platform
- don’t forget that traditional systems like UNIX can also be virtualized out-of-the-box; even IBM i systems can be virtualized using PowerVM
- use an enterprise Infrastructure-as-a-Service (IaaS), whether private or public cloud, hosted or on-premises, especially for newer applications
- adopt Platform-as-a-Service (PaaS), either out-of-the-box or (as my company has been doing) building a PaaS that will support your unique environments
Automate Complexity
Automation can also help manage enterprise complexity to lessen the impact of environmental inconsistency. For example, solutions for enterprise-grade configuration automation or release automation can both streamline the handoff between dev and ops teams, where environmental inconsistency causes significant issues. Or adopting test automation technologies like service virtualization that can streamline development, test, QA, and other use pre-prod use cases, resulting in
“shorter test times, increased productivity, and better production quality” by enabling complex environments to be consistently replicated on demand.
Tool Selection Matters
Be careful though. DevOps is not all about tools, so automation is not a complete answer; and for enterprises in particular, tool selection is harder too. For more complex enterprise environments, you will likely need to look beyond the trendy open source/webscale/startup tools. For example:
- Chef and Salt both claim support for Linux, Windows, and Solaris, but not AIX or HP/UX
- Docker claims support for Linux and Windows desktops, but not for UNIX or Windows Server
- Ansible only documents support for Windows control machines in a recent beta version
- Most cloud services only support x86 architectures, and then only Windows or Linux
- There is limited specific support for Mobile DevOps beyond Jenkins and some blogware
- Only traditional large vendors support traditional large systems like IBM i or System z
And, it must be noted, many ‘enterprise’ tools don’t support newer environments like MacOS, Azure, or Google; or don’t integrate well with a diverse toolchain.
So when selecting automation and other solutions for your DevOps toolchain, make sure they support your environment, from mobile to mainframe, whether on-premises, hosted, or in the cloud.
What is Your Solution?
These are some solutions for the consistency gaps large enterprises are facing, but are just scratching the surface. I would love to hear your solutions for handling enterprise complexity within a DevOps approach. Or if you have any Enterprise DevOps questions, let me know and I will try to answer them. You can leave your ideas or questions in the comments below; hit me up on Twitter at @AndiMann; or send me an e-mail to me at andi.mann@ca.com.
