Making your IT operation DevOps friendly can improve Bank's ability to respond to rapid changes in FinTech deployments.
For many years now, the biggest challenges banks face have been "soft" and cultural as much as technical. CIOs and IT directors need to align with business values, nurture security awareness, and cultivate a forward-facing workforce with considerably more urgency than they apply when they look at, say, a migration to IPv6, certifying SOC2 compliance, or calculating the ROI of a shift from spinning disks to flash memory.
The latest wrinkle for IT is how to befriend DevOps talent, or more precisely, how to leverage DevOps capabilities and resources. This introduction describes DevOps, distinguishes DevOps and IT cultures, and concludes with a handful of specific ideas IT should consider in response to DevOps fashions.
What is DevOps?
Make no mistake: A significant fraction of DevOps practice is fashion, in the sense that belief in the benefits of those practices is far more widespread than objective documentation of the same benefits. That doesn't mean that all of DevOps is bunk. It just means that DevOps deserves the same critical scrutiny from IT as functions like data management, legal, or marketing. All of them ultimately have a responsibility to communicate how they promote the organization's mission.
The "DevOps" neologism aspires to capture collaboration between software development (Dev) and IT operations (Ops) skills and experiences. One sign of DevOps' mind-share is that it has inspired even more contrived targets, such as DevSecOps and Lean DevOps.
DevOps is often explained as a contrast to outdated silos of responsibility. In the latter model, programmers code up functionality, then toss their source code "over the wall" to a distinct engineering or operations crew responsible for delivering that functionality at a production level and scale. Ignorance of operations realities often results in developers choosing architectures or coding styles that scale poorly and fail clumsily, and are hard to monitor.
Similarly, operations staff who work without deep programming insight have only blunt tools to attack such real-world requirements as a sudden need to multiply capacity by a factor of 10 or harden an application against hostile actors.
DevOps practitioners should have sufficiently broad and deep perspective to step around such pitfalls. The current hot market for DevOps hires reflects the expectation that DevOps practitioners should be solidly grounded in both development and operations.
Another strong theme in DevOps culture is that practitioners automate and generally treat as software as much of operations as possible. A traditional operations staff might install and test operating system patches during downtime hours, while dedicated DevOps workers are more likely to have hosts under automatic control so they can launch new resources and migrate workloads during business hours. Similarly, a new version of an OS should be just another configuration element to update.
When things work well, DevOps takes credit for reliable, highly scalable results delivered to customers, with rapid turnaround of feature requests.
Hybrid vigor
Those certainly sound like desirable qualities. Can traditional IT hire a few DevOps practitioners and acquire the goodness for itself?
Yes and no, as with any important question. Yes, there's plenty DevOps can bring to traditional IT. There are also numerous hurdles to overcome to avoid wasting IT resources and annoying DevOps adepts.
Part of DevOps reality in 2017 is intimacy with cloud service providers, from Amazon Web Services (AWS), Google's G Suite, and so on. Most DevOps professionals take for granted the rich ecosystems of management and orchestration that have grown around these services. A traditional IT on-premises environment—where a new host or storage unit might take weeks to approve and physically requisition rather than seconds to select and deploy—can upset DevOps hires profoundly.
How can central, traditional IT best welcome DevOps talent? These following four ideas—right target, tech clarity, broad perspective, and API opportunity—will take you a long way toward making the right DevOps impression.
Right target
First, keep the goal clearly in mind: While the title of this piece targets "friendly" relations, that's a metaphor. The real goal is to promote the organization's business mission; "friendliness" or "comfort" are means to that end. A traditional IT department probably should never aspire to the "leading edge" technology turnover that some DevOps relish. At the same time, a traditional IT department can speak frankly about the specific help it needs from DevOps and the opportunities to apply DevOps principles outside the usual DevOps domains. The right candidates prize that sort of honesty and challenge.
Technical clarity
Clarity about the organization's infrastructure plans is also important. Is the department adopting private cloud on-premises? DevOps can help define its configuration. Has the company decided on a hybrid cloud architected to allow loads to migrate from on-site to off-site and back? Hybrid remains a specialized, narrowly understood technology likely to excite many DevOps professionals. Is the company committed to legacy architectures in its own data center?
A smart company can remain with legacy at that level and simultaneously work to virtualize and streamline management of those legacy resources. Good DevOps professionals can recognize that, although on-premises legacy architecture won't help them keep up with the latest AWS releases, integration and modernization projects offer abundant opportunity to apply DevOps principles and tools. Part of recruitment should be to sort out the DevOps candidates you encounter: Does a particular individual hunger to be at the bleeding edge of technology? Is the candidate's reward more in using existing tools to fulfill the organization's needs? While both prospects can equally claim "DevOps" status, the latter is likely to be a better fit for integration in centralized IT.
It's more than just a GitHub account
The DevOps focus is on automation and lifecycle management. While this applies immediately to provisioning, that focus can help traditional IT in other areas, including capacity planning, availability, and business continuity. Certainly the past decade has seen a great improvement in tooling around performance, but much of that tooling is still poorly understood by traditional IT. DevOps will assume Logstash, Kibana, Redis, Elasticsearch, Nagios, Puppet and/or Chef, a messaging bus, and other such tools are available. Even the most traditional IT departments probably need to open up to these basic building blocks. IT probably also needs to support Git or a comparably modern source code management system, along with an integrated issue tracker and source review manager. The department doesn't have to hand everything over to GitHub—but it better offer something almost as good or DevOps careerists will think they're just wasting their time.
Embrace APIs
Join the API gold rush. APIs represent another (at least?) double-edged sword, of course. Plenty of past IT attempts to provide programmability have resulted in ill-conceived uses that made more work for IT, however much the intent was to encourage departments to construct their own robust applications. APIs play a different role in 2017, one DevOps will insist be supported well. Cooperate with DevOps and they will show how APIs can be published and consumed more inexpensively than in the past.
Blended strengths = enormous opportunity
A traditional IT department in a non-technology company does no one any favors by pretending it is DevOps paradise. If it's clear about its goals and plans, though, and ready to move on from break-fix and physical craftwork approaches, it can present its IT plans as great opportunities for the automation and management DevOps does best.
There's no need to view cloud providers and convergence technologies as enemies to traditional IT. Rather, they are simply new challenges that deserve thoughtful response in support of traditional IT's longtime strengths in business continuity management, security routines, identity management, cost accounting, and so on. The opportunity to blend the strengths of DevOps and traditional IT is enormous, at least for those IT decision-makers clear about their plans and resources to support them.
No comments:
Post a Comment