devopsy.kinsta.cloud

Author: Mike Vizard

GitLab Updates Advance Its CI/CD Platform

GitLab has expanded the capabilities of its continuous integration/continuous development (CI/CD) platform to include tighter integration with collaboration platforms from Slack and Mattermost along with the ability to support Docker containers running on Windows.

Version 11.11 of GitLab adds a caching dependency proxy for Docker images to the Premium edition of GitLab along with the ability to provision an instance-level Kubernetes cluster using instances of GitLab that are managed by an internal DevOps team. Those capabilities are arriving on the heels of GitLab last month announcing its initial support for Kubernetes as a platform on which its CI/CD environment now can be deployed.

The latest edition of GitLab also adds support for multiple assignees for a merge request capability, which allows multiple members of a DevOps team to manage merge requests within a DevOps pipeline.

Finally, GitLab 11.11 also provides guest access to releases, extends the add-on CI runner minutes to the GitLab Free edition, supports the OpenID Connect authentication protocol, includes serialized commit graphs and simplifies reviews by auto-resolving a discussion whenever a suggestion is applied.

Priyanka Sharma, technical evangelist for GitLab, said GitLab is starting to see increased interest in using Docker containers to build applications on Windows. A Windows Container Executor for GitLab Runners capability makes it easier to orchestrate pipelines that include Docker containers destined to be deployed on Windows. Previously, DevOps teams needed to rely on a shell executor to orchestrate Docker commands. This update makes it possible to employ Docker containers on Windows in the same way they are deployed on Linux platforms. GitLab also has improved support for PowerShell, in addition to making available helper images for various versions of Windows containers.

Sharma said GitLab is starting to see IT organizations that have embraced Windows starting to catch up in terms of enthusiasm for Docker containers. Also, DevOps teams that have embraced both Linux and Windows platforms are looking to apply best DevOps practices to both platforms.

Microsoft has signaled its intention to continue investing in making Docker containers a core element of its overall strategy. As the work progresses in collaboration with Docker Inc., the need for a CI/CD platform that can support Windows environments will become more acute.

In the meantime, GitLab continues to focus on making it easier to implement best DevOps practices at scale, Sharma said. As enterprise IT organizations continue to embrace DevOps, many of them soon discover the need for a CI/CD platform designed from the ground up to support pipelines that are being accessed by many concurrent users.

The decision many of those enterprise IT organizations will have to make is how much they will want to rely on an open source versus closed source platform. The enterprise edition of GitLab is a closed source platform, but the company does make available an open source community edition. While the open source Jenkins platform currently dominates among CI/CD platforms, enterprise IT organizations that have adopted DevOps have shown a willingness to embrace proprietary DevOps platforms that address challenges ranging from the scale of deployments to security and compliance.

It’s too early to say how the next major CI/CD battle involving the shift to microservices will play out. However, if history is any guide, there should be plenty of room for both open source and proprietary CI/CD platforms.

— Mike Vizard

May 30, 2019
CloudBees Increases Size of DevOps War Chest

CloudBees has increased the pool of dollars it is aggregated to drive further consolidation across the DevOps sector by $10 million, thanks to an investment from HSBC. The investment comes on the heels of $62 million in funding that CloudBees raised last year, which brings the total amount invested in the company since 2010 to now more than $120 million.

CloudBees CEO Sacha Labourey said that funding announced this week will be used for, among other things, adding more products and services to the CloudBees portfolio via acquisition. CloudBees last month revealed it acquired Electric Cloud, a provider of a continuous delivery platform for both monolithic and microservices-based applications.

Labourey said the HSBC investment represents of vote of confidence on two levels: Banks tend to be more conservative when it comes to investing in IT companies, and HSBC has already adopted CloudBees’ open source Jenkins continuous integration/continuous delivery (CI/CD) platform.

Citing industry analysts’ estimates, CloudBees says the DevOps sector is currently valued at $4.61 billion. Within that sector, CloudBees estimate there are more than 15 million developers using some instance of Jenkins to automate their software delivery pipelines and 46 of Fortune 100 enterprises—including three of the Fortune 10—rely on the CloudBees Suite to implement Jenkins.

While CloudBees clearly is a dominant provider of DevOps tools and platforms, the category is starting to draw attention from financially well-heeled vendors such as VMware. The virtualization platform arm of Dell Technologies earlier this month announced it will acquire Bitnami, a provider of tools for packaging applications that has gained a following among DevOps proponents.

That wave of acquisitions coincides with a major shift from monolithic to microservices-based application development. CloudBees launched Jenkins X to provide a CI/CD platform optimized specifically for microservices. But just because CloudBees and Jenkins were able to dominate the first DevOps wave, it doesn’t necessarily follow that Jenkins X will be widely adopted as a de facto standard for building microservices applications. Competition to provide the CI/CD platform for next-generation cloud-native applications based on microservices is already considerable.

In the meantime, traditional enterprise IT organizations will continue to monitor with interest merger and acquisition activity across the DevOps sector. Enterprise IT organizations tend to be wary of standardizing on development tools and platforms when there’s a chance the provider of that tool might be acquired by another vendor or entity they’d rather not work with. On the plus side, all the money being invested in DevOps startups is one of the primary reasons why DevOps is one of the most vibrant category in all of IT.

It remains to be seen which company or tool will come out on top. But the contest will be fierce. The ultimate beneficiary of that competition is almost always the end customer—assuming, of course, they bet on the right DevOps horses in the first place.

— Mike Vizard

May 24, 2019
CircleCI Adds Integration With Atlassian Jira

One of the trickier issues IT vendors in the age of DevOps are dealing with is that very few organizations have standardized on a platform from a single vendor. Not only do organizations mix and match tools as they see fit, but different departments within the same organization also embrace different tools to automate the same tasks. That DevOps reality requires collaboration between IT vendors that normally would prefer to not work together, whether they like it or not.

Case in point is a move by CircleCI, a provider of a continuous integration/continuous delivery (CI/CD) platform, to provide integration with the Jira project management software developed by Atlassian. While Atlassian makes its own CI/CD platform, customers and business partners alike have made it clear they needed CircleCI to support Jira, says Tom Trahan, head of business development for CircleCI. In some cases, those organizations have adopted Jira without having Atlassian’s CI/CD platform in their environment, while in other cases, a department within one part of an organization has opted for CircleCI while others are employing a CI/CD platform from Atlassian.

At the same time, Trahan notes that many DevOps projects now span multiple organizations that have standardized on different DevOps platforms. Jira provides a way for teams in differentorganizations to manage those projects collaboratively, he says.

To achieve integration with Jira, CircleCI now offers its CircleCI for Jira module, through which teams can assign new tasks and fixes based on job status with CircleCI orbs, a set of reusable configuration packages that allow CircleCI customers to integrate external tools into their workflow. That capability also makes it possible to launch new Jira issues directly from the job page within the CircleCI user interface.

Trahan says that in the polyglot world of DevOps, it is apparent vendors are being required to expose open application programming interfaces (APIs) that enable organizations to build and integrate various DevOps platforms anyway they want. Organizations won’t consider IT vendors that are too rigid in terms of what level of integration they enable, he says.

As DevOps continues to evolve, it’s clear that a wave of merger and acquisition activity is makeing the IT vendor landscape somewhat volatile. Providers of DevOps tools that organizations have standardized on are being acquired at a rapid rate. IT organizations can’t be certain that any given tool or platform they are using won’t be scooped up by a vendor they might not want to engage. In that kind of environment, it’s critical for IT organizations to leverage open APIs that not only make it easier to collaborate, but also replace elements of their DevOps stack whenever they deem necessary.

The challenge, of course, is that IT vendors are always trying to lock customers in as much as they can. Those efforts are not as heavy-handed as they once might have been. But almost inevitably, the extension being offered to access functionality will disappear if the underlying platform that enables it suddenly disappears. IT organizations, therefore, need to determine whether those extensions are worth any potential trouble they might cause somewhere down the DevOps road.

— Mike Vizard

May 23, 2019
Chef Extends Automation Reach and Scope

At its ChefConf 2019 conference today, Chef extended its core platform in ways that collectively serve to automate further the management of applications and the IT infrastructure they are deployed on.

Extensions to the Chef Enterprise Automation (EAS) Stack include the addition of Application Operations Dashboards, Migration Accelerators for moving applications to the cloud and tighter integration between the Chef Infra and Chef InSpec modules within the Chef Habitat management framework.

Brian Goldfarb, chief marketing officer for Chef, said these latest additions to Chef Enterprise Automation Stack are part of an ongoing Chef initiative to make it easier to seamlessly unify the management of infrastructure and applications in keeping with best DevOps practices, which Chef refers to as the “Coded Enterprise.”

As part of that effort, Chef Application Operations Dashboards provide visibility into both applications and infrastructure to simplify troubleshooting and compliance, said Goldfarb. For example, IT teams will be able to see how individual security and compliance controls are performing across a heterogeneous computing environment that now includes Microsoft Azure and Google Cloud Platform (GCP) alongside Amazon Web Services (AWS), he said.

At the same time, Chef is trying to make it easier to lift and shift applications to the cloud. EAS Migration Accelerators automate an application migration process that today requires most organizations to spend considerable time and effort to accomplish manually, said Goldfarb.

An EAS Migration Accelerator for Windows, for example, will scan existing .NET applications running on IIS to discover configuration and dependency details and then package that information as code. That approach significantly reduces the time required to build application packages in Chef Habitat.

Within Chef Habitat, the integration between Chef Infra, for automating infrastructure configuration, and Chef InSpec, a tool for automation compliance, is now more unified via pre-configured compliance profiles and cookbooks that make it easier to customize and modify which security and compliance controls are tested and enforced.

Finally, Chef has also added support for high availability to the EAS platform to make sure the environment is always accessible.

Goldfarb said the goal is to continue to make automation more accessible to IT generalists versus requiring them to hire and train dedicated specialists. One of the primary reasons that DevOps practices have been adopted so unevenly within IT organizations is the bar to master them has been set too high. By making it easier to automate the management of both infrastructure and applications, Chef is moving to lower that bar and make it easier to manage IT by unifying the management of applications and infrastructure, said Goldfarb.

It’s too early to say to what degree IT automation will advance the adoption of DevOps. What is apparent is that IT environments are becoming too complex for mere mortal IT administrators to manage manually. IT organizations are also expected to be able to respond faster to any issues that arise, which requires IT teams to have a unified view of applications and the infrastructure o which they are deployed. In fact, as IT organizations continue down that IT automation path, many of them one day may discover they have embraced DevOps without even realizing it.

— Mike Vizard

May 21, 2019
Survey Finds CI/CD Adoption Has Long Way to Go

At the KubeCon + CloudNativeCon Europe 2019 conference, Codefresh published the results of a survey of 130 developers that finds not only are nearly a third (32%) not using any type of continuous integration/continuous development (CI/CD) platform at all, but 60% said their organization has yet to take full advantage of automation to accelerate application development and deployment.

In fact, according to the survey, it takes more than two weeks for two-thirds of developers (64%) to push a commit into a production environment. Additionally, the survey finds that for 39% of respondents, less than 10% of their company’s processes are automated from Git commit to code to production.

Not surprisingly, only 19% of developers said they deploy code at least once daily. Roughly a third said they release code into a production environment only once a quarter. At that rate, it may be difficult for those organizations to justify investments in a CI/CD platform.

Dan Garfield, chief technology evangelist for Codefresh, which develops a CI/CD platform, said that while much progress still need to be made in terms of spurring adoption of CI/CD platforms and best DevOps practices, the shift toward microservices-based applications inevitably will force the issue. The inherent complexity associated with building and maintaining applications consisting of hundreds of microservices based on containers, which regularly are ripped and replaced, will require all development teams to adopt a CI/CD platform. Right now, however, the shift to microservices is even less nascent than DevOps—21% of survey respondents said they are not employing cloud-native architectures because they are overwhelmed by the prospect.

Garfield said once organizations more aggressively embrace microservices to increase the rate at which applications are developed and deployed, Codefresh is betting most will opt to standardize on a CI/CD platform based on Kubernetes. Most organizations have come to realize they will be building and deploying applications across multiple clouds. A CI/CD platform based on Kubernetes, such as the one offered by Codefresh, enables organizations to consistently apply the same set of best DevOps practices, he said Garfield. As such, competition among vendors that provide CI/CD platforms based on Kubernetes is sure to be fierce in the months ahead.

In the meantime, a 10-year effort to convince organizations to employ best DevOps practices more broadly appears finally to be on the cusp of becoming mainstream. Organizations of all sizes have embraced DevOps unevenly. In fact, while most organizations have been able to achieve continuous integration with a handful of development teams, very few organizations are anywhere near close to achieving continuous delivery of application code within a production environment.

The shift to modern applications based on containers, however, will require most organizations to standardize on a set of best practices across the enterprise. Pressure to deliver applications faster in the age of digital business transformation is mounting with each passing day. The only unknown at this point is to what degree will organizations be able to automate those processes.

— Mike Vizard

May 20, 2019
Adobe Aims to Build Developer Ecosystem

Adobe today outlined an approach to building a developer ecosystem that revolves around open source code, application programming interfaces (APIs) and DevOps processes.

Matt Asay, head of developer ecosystem for Adobe, said in the last few years Adobe has increased its reliance on open source code to deliver offerings such as Adobe Experience Manager, a content management system that incorporates open source code for as much as 65% of its modules. In the course of that effort, the company has made reciprocal code contributions to a variety of open source projects being developed under the auspices of the Apache Software Foundation (ASF), including Apache Sling, a web development framework; Apache Oak, a content repository; Apache Felix, an implementation of a services gateway; and Apache Lucene, a text search engine.

Adobe also recently launched Adobe Experience Cloud, which relies on a variety of open source technologies to create a big data repository on top of which Adobe is encouraging developers to invoke APIs to build applications. Rather than build their own big data repositories, Adobe is making a case for relying on a multitenant big data platform it manages on behalf of customers.

Based on GitHub data, Adobe currently ranks as the 14th largest corporate open source contributor, up from No. 32 in 2017. One of the primary reasons Adobe was able to move up that list so quickly was its move to acquire Magento, an e-commerce platform based heavily on open source code. But now that the company has come to appreciate what can be accomplished by relying on open source code, organizations should expect to see Adobe accelerating the rate at which it will be making contributions to a wide variety of open source projects.

At the same time, Asay said, Adobe is making major investments in developing microservices that it plans to make it possible for developers to consume via its APIs. The Adobe Experience Cloud, for example, is a suite of software-as-a-service (SaaS) applications that employ a common data model deployed on a set of Kubernetes clusters running in the Microsoft Azure cloud.

Asay noted Adobe is trying to make it clear that it has a lot of empathy toward developers committed to open source code. Adobe is a provider of commercial software-as-a-service (SaaS) applications, but it wants to develop a developer ecosystem that consumes the data residing in those applications via its APIs. To foster the development of those applications, Adobe has already signaled it is willing to share best DevOps practices with organizations that commit to invoking those APIs.

Adobe is one of many providers of commercial software that are increasingly dependent on open source code. It will be interesting to see where the line between the desire to use open source projects to build applications and actual open source applications lies in the years ahead. But the one thing that is clear is that without DevOps processes and a well-defined set of APIs to guide them, there’s not much chance any vendor would be able to build a meaningful developer ecosystem of any size.

— Mike Vizard

May 15, 2019
New Relic Doubles Down on DevOps

New Relic today unfurled an extension of its monitoring platform specifically designed for DevOps teams tasked with managing complex IT environments.

Nadya Duke Boone, vice president of product management for New Relic, said New Relic One, available to existing customers at no additional cost, makes it possible for DevOps teams to now visualize all the data that exists across multiple New Relic accounts their organization has created in a single set of dashboards.

New Relic One also makes it possible to create an “entity” to track their relationships and dependencies to provide more context to the metrics surfaced by New Relic. That context is critical anytime a major incident occurs because these days so much of the revenue any organization generates is determined by the availability of their applications, said Duke Boone.

To achieve that goal, New Relic One provides Service Maps spanning entities; search and discovery tools based on universal tag filtering; dashboards through which queries can be launched using visual tools; an ability to more easily extend visualizations; and a new home page designed to make it easy to drill down into various dashboards.

Other capabilities included in New Relic One include Monitoring for the AWS Lambda serverless computing framework, a Kubernetes cluster explorer and distributed tracing global search.

New Relic also revealed today it plans to deliver both a log monitoring solution and AIOps offering within New Relic One by the end of the fiscal year. New Relic earlier this year acquired SignifAI to gain access to AIOps platform.

Duke Boone said all this is now possible because of the investments New Relic has made in developing a persistent store for monitoring platform, which she said represents a strategic initiative on the part of New Relic to expand the scope of the services and capabilities it provides.

Downtime in the age of digital business directly equates to lost revenues. Organizations that face that challenge typically are at the leading edge of adopting best DevOps practices. That challenge these organizations face today is they are drowning in complexity, a situation that likely will only worsen as organizations deploy cloud-native applications based on containers, she said, adding New Relic One not only serves to make it easier to manage all that complexity, it also makes it simpler for teams within an organization to share best DevOps practices.

Of course, one of the issues that restrains organizations from adopting DevOps practices in the first place is a reluctance to make IT environments any more complex than they already are. Organizations are demanding that IT organizations become agile enough to support a wide range of digital processes. The challenge they all typically face is the current reliance on highly structured processes that are intended to minimize potential errors. As well-intentioned as that might be, however, they often result in IT organizations being unable to adjust rapidly changing business requirements. The good news is as DevOps tools become more sophisticated, the skepticism of many IT professionals have toward DevOps will continue to quickly diminish.

— Mike Vizard

May 14, 2019
Microsoft Gains DevOps Momentum

Microsoft, at its recent Microsoft Build 2019 conference, launched a series of efforts intended to make it easier for organizations to embrace best DevOps practices, including making it possible to address both continuous integration and continuous delivery within the same YAML file using Azure Pipelines.

Microsoft also announced it will extend Azure Pipelines to provide tighter integration between GitHub, which Microsoft acquired last year, and Kubernetes. Via that integration, Azure Pipelines can be used to automate everything from creating container images and packaging them as Helm charts to generating Kubernetes deployment artifacts and then deploying the workload.

Continuing that Kubernetes theme, Microsoft also is launching the Kubernetes-based Event Driven Autoscaling (KEDA) project, which makes it possible to run Azure functions on top of Kubernetes clusters. Developed in collaboration with Red Hat, KEDA is available in developer preview for the Red Hat OpenShift platform based on Kubernetes.

In addition, Microsoft has extended the Azure IoT Edge runtime to Kubernetes to enable internet of things (IoT) applications to be deployed on Kubernetes and Azure SQL DB Edge, which is packaged as a container and makes it possible to deploy a database on ARM or x86 systems deployed at the network edge.

Also during the conference, Microsoft launched MLOps, which applies DevOps principles to deploying artificial intelligence (AI) models using the GitOps workflow; Azure SQL Database Serverless, which allows organizations to consume a database service on a per-second billing basis on the Azure cloud; and ML.net, a framework for building AI models.

Microsoft also announced it is now making available a full Linux subsystem within Windows 10 and the ability to link IoT devices to the Azure cloud without writing code.

Scott Guthrie, executive vice president for AI and cloud at Microsoft, told conference attendees Microsoft is squarely focused on making it easier to build applications that can be deployed in hybrid cloud computing environments anchored around the Microsoft Azure cloud.

Microsoft historically has focused on making it much easier to consume emerging technologies at the point in time they start to appeal to the broadest number of customers. As DevOps best practices continue to find mainstream adoption, that same philosophy is being applied to cloud services. Microsoft may not have invented the concept of CI/CD, but it is working to make it easier for organizations that have struggled to implement continuous delivery, for example, to master that challenge. The same concept applies to Kubernetes, which some argue is still too complex for the average IT organization to master and deploy.

It remains to be seen how much Microsoft’s efforts, most of which are only available as previews, will result in more applications being deployed on Azure. Because an application is built on a public cloud doesn’t always mean it will be deployed on that cloud. It does, however, increase the chances of that occurring. In fact, providing a better DevOps experience across a hybrid cloud computing environment is clearly key to Microsoft’s strategy as it seeks to gain ground on Amazon Web Services (AWS).

— Mike Vizard

May 13, 2019
With RHEL 8, Red Hat Adds More Automation to IT Ops

At the Red Hat Summit 2019 conference, Red Hat today announced the general availability of Red Hat Enterprise Linux (RHEL) 8, which includes among other things a Smart Management add-on designed to make it easier to manage RHEL 8 across hybrid cloud computing environments.

In addition, RHEL 8 includes Application Streams, a set of utilities for updating languages, frameworks and developer tools without impacting the core resources, as well as updating RHEL 7 to RHEL 8 in place.

RHEL 8 also adds Red Hat Enterprise Linux System Roles, which provides modules to automate complex tasks using the Ansible automation framework along with support for the Red Hat container toolkit and the general availability of the Red Hat Universal Base Image, a userspace image derived from RHEL that makes it easier to build Linux containers certified to run on RHEL.

Red Hat also revealed that Red Hat Insights, a set of predictive analytics tools, will be included with the RHEL 8 subscription and that RHEL 8 supports both the OpenSSL 1.1.1 and TLS 1.3 cryptographic standards.

Gunnar Hellekson, director for product management for Red Hat, said Red Hat is focusing on automating as many tasks as possible as part of an effort to make the life of IT operations teams simpler. As part of that effort, Hellekson said Red Hat is moving to lower the barrier to becoming a RHEL administrator by abstracting away many of the complexities historically associated with trying to manage Linux environments using a command line interface (CLI). Much of that focus will manifest themselves via ongoing enhancements to the Compose and Cockpit tools Red Hat provides for deploying and managing instances of RHEL, said Hellekson.

Red Hat is making it clear it wants to make RHEL much more accessible to a larger number of IT administrators, especially those that historically have favored a more graphical approach to managing operating system environments. At the same time, however, Red Hat is infusing more automation into RHEL 8 as part of an effort to make it easier to manage deployments at scale. That latter capability is crucial for DevOps teams that, for example, need to be able to update a development environment without waiting for an IT operations team to reconfigure and reboot an operating system. Via add-ons to the core RHEL platform, Red Hat is now starting to expand those automation capabilities across both on-premises and public cloud computing environments.

It’s unclear going forward how many instances of RHEL any one IT administrator might be able to manage on their own. Trying to determine that number might not even be worth the effort because advances in automation are now coming so rapidly that trying to determine that right number of IT administrators per environment is not possible to determine consistently. Instead, IT organizations should just assume that, thanks to automation enabled by machine learning algorithms and predictive analytics, the operating system environment is now flexible enough to scale up and down as needed.

— Mike Vizard

May 7, 2019
IT Operations: PagerDuty Unveils Hybrid ITSM Platform

PagerDuty today unveiled a framework intended to make it possible for organizations to bridge multiple styles of IT service management (ITSM) methodologies for IT operations.

Rachel Obstler, vice president of product for PagerDuty, said PagerDuty Solution for HybridOps provides a comprehensive incident management framework capable of spanning both ITIL and DevOps processes for IT operations.

PagerDuty Solution for HybridOps combines existing and new product capabilities such as Event Intelligence and Modern Incident Response with machine learning algorithms and bi-directional integrations the company has developed between its incident management software and more than 300 third-party products.

Those capabilities make it possible to facilitate real-time communications between platforms that tend to be favored by IT shops relying mainly on ITIL processes, such as ServiceNow, and DevOps teams that rely on Slack to communicate with one another, Obstler said.

Rather than forcing an entire IT organization to transition to single framework for IT operations, PagerDuty Solution for HybridOps allows organizations to selectively apply each model where and when they best see fit, she said.

The latest version of the ITIL framework goes a long way toward injecting some flexibility into what historically has been viewed as a rigid approach to managing IT. The ITIL framework is still a long way from being as agile as the various forms of DevOps that many organizations have adopted over the last several years to accelerate application development and deployment.

Obstler said PagerDuty is moving to bridge that divide by leveraging machine learning algorithms to group all the various alerts generated by all the tools in an IT environment. That capability not only reduces the amount of alert fatigue any IT operations group is likely to suffer, but it also makes it easier to identify the root cause of any IT incident, she noted.

One of the primary reasons DevOps has been adopted evenly in the enterprise is that IT operations teams are expected to be able to programmatically adapt IT infrastructure to meet the demands of developers. The number of IT operations that have those skills, however, is limited. In theory, IT operations teams without programming skills could rely on automated frameworks to achieve that goal. But that approach requires IT organizations to standardize on a single IT automation framework across compute, storage and networking services. The number of organizations that have been able to bridge all the islands of automation that have been adopted across all the services they deliver are few and far between. Put it altogether and it’s clear that both legacy and modern approaches to ITSM will need to coexist well through the next decade.

In the meantime, IT leaders might want to consider that old proverb about leading a horse to water. IT leaders can issue all the mandates they want. But when it comes time to accomplish a task, most IT professionals are naturally going to fall back on what they know. The challenge is to create ways to wean the IT operations staff off those legacy processes in a way that doesn’t necessarily result in everything grinding to a halt because nobody knows how to fix an issue that simply wouldn’t otherwise wait.

— Mike Vizard

May 6, 2019