Design, deliver, and run enterprise blockchain workloads quickly and easily.
All servers and systems
Consider a successful DevOps project built on the public cloud. Now it's time to move it to central IT. What does it take? What's involved?
As important as these questions are, their answers aren't simple. The growing popularity of DevOps projects and approaches has left the meaning of DevOps itself rather cloudy. No brief explanation captures everything now happening in the name of DevOps.
Rather than a precise formula, this sketch identifies three central themes of DevOps, five principal reasons to migrate a project to central IT, four specific tensions likely to occur in such a migration, and ways to ease those tensions. Application to a particular project within a particular organization then becomes an exercise for the reader.
While DevOps is identified with a wide range of practices and technologies, a migration to central IT needs to focus on these three assumptions:
These principles may seem reasonable, but they can have unintended consequences. For example, DevOps began with a well-meaning effort to break down silos and inform development standards with operational insight, while streamlining operations practices with development tools. In 2017, DevOps practitioners pride themselves on a broad perspective that elevates end-user experience, service flexibility, and marketplace agility over the limits of particular techniques or engineering habits.
While DevOps has plenty to offer, it can't simply replace traditional IT. Even the best-intentioned DevOps professionals sometimes lack the deep expertise needed for such typical IT responsibilities as secure access to legacy services, business continuity requirements, organizationwide identity management, cost-effectiveness, and so on.
DevOps migrations also make an interesting contrast with shadow IT. Shadow IT, where departments buy services from public providers rather than their own central IT, is a well-documented fact of business life. DevOps projects differ from the usual shadow IT in that they're much less likely to result in the frightening technical debt often seen in shadow IT: spreadsheet-coded graphics, shared passwords, bizarre backup schemes, and so on. Independent DevOps projects are like shadow IT, though, in that their budgets, security, data, and management are outside the control of central IT.
The DevOps emphasis on continuous improvement—buttressed by continuous deployment, continuous integration, and so on—contrasts with more episodic IT traditions. There's no easy solution for uniting agile, continuous-improvement styles with waterfall or near-waterfall management approaches. That's one stylistic tension whose resolution is outside the scope of this outline. For the purpose of the migration at hand, put the attention on shared business goals. A polished synthesis of agile and waterfall will wait for a later day.
Any plan for migration of a DevOps project needs explicit business requirements and goals. Business requirements make a more essential guide than tables of technical correspondences. IT managers might think that a migration project is about setting up translations such as
Cloud::IAM->on-premises::ActiveDirectory. Such translations are secondary; the real point needs to be, in this example, to consolidate identity management for one project with the identity management on which the organization already relies for perhaps thousands of other existing services.
Those business requirements must also be directed to a positive target, rather than just away from the cloud. At a high level, typical business requirements for a DevOps->IT migration include a mixture of:
Explicit, written business requirements are crucial to the success of a migration project. Notice these requirements will include metrics from both sides. Some will seem more relevant to DevOps and some to central IT. A typical project might aim to save $65,000 per month in one kind of usage subscription at the same time it maintains the ability to serve a peak of 3,000 requests per second. The requirements being defined for the project need to make clear where the responsibilities for deliverables lie, either as part of the DevOps process or central IT support.
Migrations of this sort often start with a mistaken focus on the cloud. DevOps practitioners appropriately value all the benefits the cloud brings them but sometimes naively believe those same benefits are impossible in an on-premises situation. One starting point for discussion, then, is private cloud. Central IT can set a baseline by pricing a private cloud and migrating the existing DevOps project on-prem with minimal technology changes.
Ideally, this approach should eliminate the cloud as an ideological battleground. With a clear vision of private cloud as a baseline, all the other alternatives become implementation details that DevOps and central IT can constructively consider and analyze together.
Another typical rift between the DevOps and central IT perspectives has to do with scaling in time, service scope, and development style. DevOps often takes as a matter of faith that workloads are handled by multiplying instances—virtual servers, microservices, and so on. Central IT often has more experience sizing needs realistically. Central IT also realizes that some services—even mission-critical ones—are lightweight enough to run on a monolithic or not particularly scalable architecture. The best way forward is to emphasize the business requirements highlighted above and let the implementation teams fulfill them with technologies they trust.
A third common tension between DevOps and central IT—related to the first two, inevitably—is that DevOps pros often regard themselves as more technically sophisticated and fast-moving. DevOps sees IT as stuck with legacy assets and comparatively uninterested in learning the latest.
You can avoid this conflict by pushing both sides to focus on requirements and use common metrics. Pursuit of a common goal of meeting migration requirements encourages DevOps and IT to collaborate. Ideally, both sides contribute to solutions. This changes the narrative from one where DevOps loses the project to the attitude that DevOps and IT are working together to meet important goals.
Finally, conventional DevOps culture often becomes so computationally "transactional" that it undervalues persistent data. IT typically has more experience with data management perspectives that prize data as long-term assets. Data management is a specialty distinct not only from DevOps, but also from system administration, network management, hardware, security, user experience, and all the other domains IT typically juggles. IT needs to be on the lookout to pair DevOps contributors with data managers who can advocate for persistence and other data virtues the DevOps practitioners otherwise ignore.
The cloud is just another computational locus and implementation detail. Move your migration team past disputes about the cloud, and who and what is in it. Forcefully express business goals and requirements, and promote their measurement and calibration. When your implementation team unites DevOps and IT practitioners and perspectives, they can constructively collaborate on, rather than resentfully comply with, the migration. A successful migration might choose either Ansible or PowerShell (or, at a different level, NGINX vs. Internet Information Services). What's important is that the team as a whole buys into its common process for deciding and testing such technical selections. Make the most of DevOps' broad perspective on cooperation between development and operations, and IT's strengths in costing, data management, business continuity, and compliance.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.