devopsy.kinsta.cloud

Author: Mike Vizard

SaltStack Extends IT Automation Framework

SaltStack today added three open source modules to its portfolio that make it easier to automate the management of IT at scale.

Heist is a plugin that allows organizations to create agents that will dissolve after a specific amount of time. Umbra is a plugin that gathers data streams to make it easier for machine learning algorithms to consume.

Finally, Idem is a declarative programming language that enables IT teams to create workflows based on stateful constructs that can be used in conjunction with any IT automation framework or systems management tool.

All three modules are based on the Salt Plugin Oriented Programming (POP) model. Company CTO Thomas Hatch said SaltStack created POP to make it easier to manage modules and libraries of code within a monolithic application without having to transition to a different microservices-based architecture based on containers.

That POP approach also serves to make it easier to test modules within a monolithic application environment, he said.

SaltStack used POP to create Salt, an open source IT automation framework that serves as the foundation for the commercial IT automation platform provided by SaltStack. Organizations that have embraced the open source Salt project include Juniper Networks, Cloudflare, Nutanix, SUSE, LinkedIn and eBay.

Heist extends the Salt project by giving DevOps teams an alternative to having to commit to either an agent or agentless-based approach to managing IT. Instead, DevOps teams can create an agent to collect data that will run only as long as it’s needed.

Umbra, meanwhile, prepares data to be consumed by machine learning algorithms transparently, which Hatch said is critical in providing visibility into how artificial intelligence (AI) models are constructed. That capability is going to be a requirement in any regulated industry that requires organizations to comply with IT audits, he noted.

IT automation frameworks are, of course, foundational to any set of best DevOps practices. While most of the initial IT automation management frameworks were proprietary, the entire category has gained more traction as open source implementations of these frameworks became available. Now DevOps teams have a plethora of open source and commercial IT automation frameworks on which to define a set of DevOps processes.

The biggest challenge in getting IT teams to embrace these frameworks historically has been the preference of many IT professionals for scripts they develop. However, as the scale of the IT management challenge has increased in the age of the cloud, relying on scripts that are often undocumented has become problematic. Industrial-scale IT organizations require IT automation frameworks that allow them to create reusable playbooks that are easily documented. Otherwise, every time an IT professional who authored a script leaves the company, the IT organization soon discovers the script they’ve been relying on that has broken can’t be fixed easily.

The day when all IT organizations rely on some form of an IT automation framework is fast approaching. In fact, the remaining IT automation challenges have a lot more to do with the culture within the IT organization than they do any of the technical capabilities of the platforms being considered.

— Mike Vizard

January 15, 2020
Perfect Sense Open Sources Gyro to Automate Cloud Provisioning

Perfect Sense has launched an open source project dubbed Gyro that provides an alternative approach to automating cloud infrastructure provisioning and management.

Gyro was developed as an alternative to other open source projects such as Terraform and Pulumi, said CTO Jeremy Collins. It is designed from the ground up around a programming language that allows DevOps teams to define infrastructure as code, and features logic built into configurations to make it easier to create more precise workflows, he said.

Adding logic to create equivalent workflows in rival platforms is more complex, Collins noted, adding the ability to add logic makes it easier to not only provision cloud infrastructure but also to roll it back when necessary.

Perfect Sense developed Gyro to make it easier to manage the infrastructure for its Brightspot content management system (CMS). As such, Gyro can support multiple cloud computing platforms.

In addition to making it possible to add cloud platforms to an existing configuration, Collins said it can be used to create custom commands and define multiple extension points directly within the Gyro language.

Perfect Sense developed Gyro to automate the provisioning of virtual machines. Since then, the company has extended its capabilities to add support for emerging cloud-native platforms such as Kubernetes.

Collins said Gyro provides a single extensible tool spanning a broad range of DevOps processes, from provisioning infrastructure to discovering what services already exist.

Despite the popularity of rival tools such as Terraform, it’s still early days in the adoption of infrastructure as code. Most IT organizations are a long way from standardizing on any one platform for automating the provisioning of infrastructure. In fact, it may not be uncommon for different DevOps teams within the same organization to employ different platforms for provisioning infrastructure.

Gyro’s ultimate success will depend much on Perfect Sense’s ability to foster an open source community. The Brightspot CMS is used by the Los Angeles Times, Walmart, Mattress Firm, Univision, Sotheby’s and US News and World Report, so Collins said there is a base of support for Gyro on which to build a community. Perfect Sense is looking to build a community that will continue to extend the reach and scope of the platform by adding additional plugins.

Regardless of the approach taken, as the number and rate at which workloads are being deployed on cloud platforms increases, it becomes critical for IT organizations to find a way to automate processes. It’s not clear to what degree those workloads will be provisioned by developers themselves versus traditional IT operations teams that have learned how to program. However, one way or another the provisioning of cloud infrastructure is going to be automated.

— Mike Vizard

January 13, 2020
Compuware Extends Alliance With CloudBees

Compuware has become a premier member of the CloudBees Technical Alliance Partner Program (TAPP), as part of an effort to accelerate the adoption of best DevOps practices in mainframe environments.

Sam Knutson, vice president of product management for Compuware, said his company has already developed six plugins for the open source Jenkins continuous integration/continuous delivery (CI/CD) platform. By joining TAPP, Compuware is signaling it will develop more modules in collaboration with CloudBees that can be employed on either the open source edition of Jenkins or the enterprise edition supported by CloudBees, he said.

Compuware doesn’t plan to build a CI/CD platform itself. Rather, Knutson said Compuware is pursuing an “open borders” approach to CI/CD platforms that complement its Topaz tools for building mainframe applications. As such, IT organizations should expect to see Compuware allying with multiple providers of CI/CD platforms. However, in terms of overall adoption in mainframe environments, Compuware is seeing more instances of Jenkins than any other CI/CD platform, Knutson noted.

Compuware also updated Topaz to provide a new editing experience that guides novice developers using COBOL, PL/I and JCL programming languages. It also now includes native integration with Eclipse integrated development environments (IDEs) and real-time COBOL and PL/I syntax-checking.

Knutson said the adoption of best DevOps practices and CI/CD platforms are on the rise in mainframe environments, thanks mainly to the rise of digital business initiatives that require organizations to update applications more frequently. IT teams can choose to build those applications on distributed systems that then need to be integrated with existing applications running on a mainframe, or they can modernize the applications they have running on the mainframe, he said.

The latter approach not only reduces the amount of technical debt any IT organization will need to manage, but it also results in a more secure application environment running on a mainframe, he noted. In fact, Knutson described building applications that duplicate functionality at the edge of a mainframe as “an unnatural act.”

Knutson said IT organizations that employ mainframes are at varying levels of maturity when it comes to DevOps adoption. However, he predicts in 2020 there will be many more organizations highlighting their success building and deploying applications on mainframes using DevOps practices.

Naturally, Compuware is not the only provider of mainframe tools trying to foster the adoption of best DevOps practices in mainframe environments. However, mainframe environments have employed waterfall processes for decades to build highly reliable applications. Many of the organizations that rely on those legacy processes are hesitant to abandon them if it means the application being deployed might be less stable or secure. At the same time, IT organizations that have mainframes are definitely under pressure to roll out application updates faster. As such, many of them have begun to incorporate agile programming techniques and best DevOps practices to achieve that goal. In fact, a recent survey published by Compuware finds organizations have increased deployment frequency an average of 41% for new mainframe features.

Like it or not, change is coming to mainframe application development and deployment.

— Mike Vizard

January 13, 2020
Opsani Applies AI to Rein in Cloud Costs

Opsani has added support for cloud computing environments to its namesake software-as-a-service (SaaS) platform that leverages machine learning algorithms and other forms of artificial intelligence (AI) to optimize the IT environment.

Company CEO Ross Schibler said Opsani AI not only proactively tunes resources such as CPU and memory, but it also can optimize middleware configuration variables such as Java virtual machine (JVM) type and pool sizes; kernel parameters such as page sizes and jumbo packet sizes; and application parameters such as thread pools, cache timeouts and write delays.

Given the size and dynamic nature of most cloud computing environments, Schibler said it’s not possible for IT administrators to manually optimize cloud computing environments to match the specific needs of each class of application workload being deployed. The Opsani platform makes it possible to leverage AI to optimize settings for the lowest cost or best performance every second, he said.

Opsani claims existing customers are seeing more than 200% increases in performance per dollar while saving up to 80% on their cloud spend.

In addition, Opsani has made available plugins for a variety of DevOps tools including GitHub, Terraform, Jenkins, Spinnaker, Wavefront, DataDog, SignalFX, Prometheus, Splunk and New Relic, on all the major cloud computing platforms.

Schibler said Opsani can be applied to existing monolithic applications as well as emerging microservices-based applications based on containers running on Kubernetes clusters. The goal is to make it possible for IT teams to rein in cloud costs at a time when most cloud resources are being employed inefficiently, he said.

Individual developers are deploying applications on virtual machines in the cloud with little to no appreciation for total cost, noted Schibler. Before most IT organizations realize it, the cost of running applications on a public cloud has far exceeded budget allocations. IT organizations not only need tools to rein in those costs, but Schibler noted Opsani also makes it possible to model those costs before an application is deployed or upgraded.

The adoption of public clouds and DevOps often go hand in hand. The challenge organizations are encountering more often is that as the number of applications running in a public cloud computing environment increases, they often wind up overprovisioning resources. Over time, the need to optimize the consumption of cloud resources becomes a more pressing financial concern. However, most IT organizations don’t have the resources or expertise needed to manually tune each instance of cloud workload. At the same time, the typical IT organization doesn’t have the ability to build its own AI engine. Opsani is making the case for a SaaS platform that provides that capability without requiring an IT organization to build its own AI models from scratch.

Naturally, many IT professionals are dubious of AI because there may not be enough transparency into the AI models being employed. However, because Opsani is a SaaS platform, the risk of experimenting with AI to optimize cloud workloads is relatively slight. Of course, there’s no absolute requirement to employ AI at all. However, as financial pressure on IT organizations continues to mount, there doesn’t seem to be much of an alternative either.

— Mike Vizard

January 7, 2020
Certificates a Fly in the DevOps Ointment

The way cybersecurity teams have managed certificates is turning out to be a major impedance that could best be addressed by more organizations adopting best DevSecOps practices in 2020.

A survey of 108 attendees at the recent DevOps Enterprise Summit 2019 conference conducted by Venafi, a provider of tools for assigning identities to machines, finds 75% of respondents said they are concerned that corporate certificate issuance policies slow down development.

In addition, 39% of respondents believe developers should be able to circumvent corporate certificate issuance policies to meet service level agreements (SLAs) and about half (48%) said they are confident that developers always request certificates through authorized channels.

Kevin Bocek, vice president of security strategy and threat intelligence at Venafi, said the root cause of the friction between developers and cybersecurity teams can be traced to reliance on ticket-based systems for managing IT. DevOps teams in the age of the software engineer are building and deploying applications faster than ticket-based systems based on manual requests can keep up with, he said.

Rather than wait on IT Operations teams, DevOps teams are doing an end-run as business leaders push for applications to be deployed faster. In many cases, DevOps teams are attaining certificates directly from a cloud service provider such as Amazon Web Services (AWS), Bocek noted. Unfortunately, that can lead to other issues: More than half of respondents(55%) said their organization experienced a certificate-related outage in the past 12 months. Not all those outages are likely to have resulted from DevOps teams working without internal IT, but it does confirm how deeply flawed the existing process of issuing certifications already is.

To address that issue, Bocek said organizations will need to shift to an approach for issuing trusted certificates that is based on a standard set of REST application programming interfaces (APIs) and is a natural extension of the DevOps processes baked into a continuous integration/continuous delivery (CI/CD) pipeline.

Unfortunately, most organizations are not especially aware of best practices for issuing trusted certificates. The Venafi survey found three-quarters of respondents (75%) are unfamiliar with the “Securing Web Transactions 1800-16 Practice Guide,” available in draft form from the National Institute of Standards and Technology (NIST).

Bocek said the days when cybersecurity teams could employ certificates as a means for governing when applications are deployed are all but over. Cybersecurity teams need to collaborate with DevOps teams to define a set of best DevSecOps processes through which trusted certificates still play a role in helping secure the IT environment without slowing down the application deployment process, he said.

It may take a while for DevOps teams and cybersecurity professionals to get on the same page in terms of issuing certificates. However, as pressure to deploy applications faster continues to mount, cybersecurity teams will need to adjust their policies and processes. How certificates are issued may be as good a place to start their DevSecOps transition as any.

— Mike Vizard

January 6, 2020
PagerDuty Focuses Incident Response Efforts on the Cloud

After helping to pioneer the adoption of incident management software in on-premises IT environments, PagerDuty is now focusing its attention on the cloud with the launch of PagerDuty for Cloud Operations.

Jukka Alanen, senior vice president of business development and corporate strategy for PagerDuty, said that as cloud computing evolves to include containers and serverless computing frameworks, it’s becoming apparent that managing IT incidents on public clouds is fundamentally different than on-premises IT environments. As such, demand for incident management platforms optimized for specific cloud platforms is increasing, he said.

PagerDuty initially will focus its efforts on the Amazon Web Services (AWS) platform because that’s where most of the initial demand is coming from, Alanen noted. As part of that effort, an instance of the PagerDuty digital operations management platform running on AWS has been integrated with Amazon CloudWatch, AWS Personal Health Dashboard, Amazon EventBridge, AWS Security Hub, Amazon GuardDuty and AWS CloudTrail cloud services.

Rather than replace all the capabilities already being provided by cloud service providers, Alanen said PagerDuty is committed to making them more accessible within the context of an incident management platform. With the rise of DevOps, the types of IT professionals who need to be able to access an incident management platform in the cloud era is also expanding. To resolve issues as quickly as possible, Alanen said it’s more critical than ever to make sure the right problems are being presented to the right teams within an IT organization.

In terms of making that transition, however, IT organizations are all over the map. Many are trying to extend existing IT operations processes developed for on-premises IT environments. To the extent that organizations are essentially lifting and shifting monolithic applications running on-premises into a public cloud, that approach is feasible. However, once organizations also begin deploying cloud-native applications based on microservices and serverless computing frameworks, most will need to rely more on management and monitoring tools provided by cloud service providers.

The next challenge then becomes defining workflows that automate responses to potential service disruptions or a security breach. At the same time, many organizations are adopting best DevOps practices that shift responsibility of many aspects of incident response on to the shoulders of developers who now need access to an incident management platform. The existing reactive approach to managing IT needs to be replaced with a proactive approach that automates responses to incidents whenever possible, Alanen said.

To help organizations accelerate their move down that path, PagerDuty has crafted a Digital Operations Maturity Model, which provides benchmarking data and best practices for organizations looking to modernize their IT operations as part of a larger transition to increased reliance on automated workflow processes.

Of course, once IT organizations define these workflows it won’t take long before IT organizations find themselves needing to extend more proactive approaches to incident management across multiple cloud computing environments. The challenge then becomes finding a way to weave all the application programming interfaces (APIs) and services exposed by multiple cloud service providers into what one day will become a truly hybrid cloud computing environment.

— Mike Vizard

January 6, 2020
GitLab Open Sources Monitoring Tools

GitLab has decided to make its monitoring and observability tools available as part of its core open source platform to help reduce the total cost of DevOps. Previously, the tools were available as part of the commercial tools in GitLab’s DevOps platform.

Kenny Johnston, director of product/Ops products for GitLab, said that as responsibility for observability shifts left, it is clear developers are now exercising more influence over which monitoring tools are employed. As developers begin to employ monitoring tools early in the application development process, most of them prefer open source tools because it’s unclear whether the application being developed will ever make it into a production environment, he said.

However, if the application does make it into a production environment, it can be challenging for developers to make a case for standardizing on whatever monitoring tools they’re using in place of an existing commercial offering employed by an IT operations team. In addition to reducing costs, the GitLab approach could serve to eliminate any potential friction in the DevOps environment, as applications move from development into production environments.

GitLab’s move to make its monitoring tools available as open source software comes at a time when more telemetry applications being employed to collect data are also based on open source software. In addition, developers of modern cloud-native applications based on containers are taking advantage of open source Prometheus monitoring software developed under the auspices of the Cloud Native Computing Foundation (CNCF) to monitor their applications. GitLab already provides integration with Prometheus.

GitLab is also making it clear it expects its monitoring tools to benefit from the contributions of a larger pool of developers. Specifically, GitLab is calling for help in the areas of ongoing integrations with Prometheus along with improved logging, tracing and alerting capabilities.

It’s not at all clear just yet to what degree DevOps teams will prefer to rely on open source versus commercial monitoring tools. While open source tools have some obvious advantages in terms of cost, many organizations have already standardized on commercial monitoring tools for a wide variety of existing applications. Open source tools often are more difficult to deploy and don’t tend to provide as much observability depth for IT operations teams. In addition, most of the providers of commercial monitoring tools are integrating their offerings with both open source telemetry software and Prometheus to bridge any divide that might occur between when an application is developed and deployed in a production environment.

The one thing that is clear is a lot more individuals within the IT environments will be accessing these tools now that developers increasingly are being held accountable for the performance of their applications in production environments. In addition, modern applications require monitoring tools to make sense of all the dependencies that existing between microservices. Previously, IT operations teams tended to limit usage of monitoring tools based on commercial software to their most critical applications because of the costs involved. With the rise of open source monitoring tools, the opportunity to apply monitoring more broadly becomes more economically feasible.

Regardless of the path forward chosen, the more visibility into IT environments provided, the easier it becomes to embrace best DevOps practices.

— Mike Vizard

January 3, 2020
Datadog Adds Support for Microsoft Azure DevOps

Datadog has added support for Microsoft Azure DevOps to its namesake monitoring and analytics platform.

Ilan Rabinovitch, vice president of product and community for Datadog, said Microsoft Azure DevOps, formally known as Visual Studio Team Services, is gaining traction as a continuous integration/continuous delivery (CI/CD) platform that can be deployed on-premises or in the cloud.

Via this integration DevOps teams that have adopted Microsoft Azure DevOps can now pull in events to create metrics from their continuous integration pipelines, and then correlate that information in real-time against Datadog is pulling from their entire stack in Datadog. DevOps teams can also configure to monitor gates in their Azure DevOps deployment pipelines, enabling them to detect and abandon bad releases automatically, said Rabinovitch.

Finally, DevOps teams can also employ Datadog to measure the efficiency of their processes by tracking, for example, how often builds are completing or failing or the frequency of code commits, added Rabinovitch.

Microsoft has been pouring significant resources into building out Microsoft Azure DevOps over the course of the last year. At the recent Microsoft Ignite 2019 conference, the company released Azure DevOps Server update 1.1 release candidate to address some bug issues before organizations deployed the platform in production environments. Microsoft also has added previews of auditing tools, extended reporting capabilities, enhanced the user interface for the repositories page to be more mobile device friendly and added more billing options.

Microsoft Azure DevOps in time will play a much larger role in the company’s bifurcated approach to hybrid cloud computing. On the one hand, the company is driving an increasingly larger portfolio of Azure public cloud services. In on-premises IT environments there is a massive base of Windows servers coupled with a nascent Azure Stack platform that provides organizations with the option to deploy the same IT environment Microsoft employs on its public cloud. The long-term goal is to make it easier for organizations to build and deploy applications across hybrid cloud computing environments using the same DevOps pipeline.

Of course, Microsoft Azure DevOps is not the only CI/CD platform that might be employed to achieve that goal. As rival CI/CD platforms continue to extend their reach into Azure and Windows environments, Microsoft will find itself competing with a small army of rival DevOps platforms that span not only Azure, Windows and Linux platforms but also rival cloud platforms such as Amazon Web Services (AWS) and Google Cloud Platform (GCP).

In the meantime, IT organizations should expect to see a host of third-party tools becoming available for Microsoft Azure DevOps as the CI/CD platform gains traction. In some cases, organizations will standardize on Microsoft Azure DevOps. In other cases, Microsoft Azure DevOps will become one of several CI/CD platforms that different teams within an organization are employing. Regardless of the CI/CD platform adopted, however, organizations that do wind up employing multiple CI/CD platforms are likely to want to consolidate as many as the monitoring tools they rely on as possible.

— Mike Vizard

January 3, 2020
Xen Project Advances Hypervisor Project

The Xen Project announced this week that the latest version of the open source hypervisor can now take advantage of core scheduling, an experimental technology that enables Xen to group multiple processors together to create a single virtual central processor unit (CPU).

Lars Kurth, chairperson for the Xen Project advisory board, said this capability also represents an important first step toward developing a more secure form of hyperthreading. Since earlier this year, many IT organizations have turned off hyperthreading because of cybersecurity concerns. However, such decisions have resulted in significant performance penalties for many applications.

In addition to adding support for core scheduling, version 4.13 of Xen Project Hypervisor adds support for live patching and late uCode loading that makes it possible to install updates at runtime without having to reboot the hypervisor.
The latest version of Xen also adds support for additional processors, including AMD 2nd Generation EPYC, Hygon Dhyana 18h, Raspberry Pi4 and Intel AVX512-based platforms.

Finally, version 4.13 of Xen adds support for OP-TEE, which enables all guests to concurrently run trusted Applications on TrustZone, firmware created by ARM to isolate processors on the same system, and improvements to Dom0less, which makes it possible to partition processors running in parallel.

The Xen Project Group also announced it has created a Functional Safety Working Group, which is committed to making the Xen hypervisor compatible with ASIL-B requirements, a set of compliance requirements defined by the automotive industry. That effort represents a significant challenge because it requires code and development processes to comply with key tenets of ISO 26262, a set of standards for embedding electronics into any road vehicle.

The Xen Group is also working on developing a secret-free hypervisor, which Kurth said will play a critical role in thwarting side-channel cybersecurity attacks. Cybercriminals can employ side-channel attacks to break encryption algorithms by measuring and analyzing the physical attributes such as the amount of radiation being generated by a processor.

Kurth said version 4.13 represents a major milestone in the ongoing development of Xen. In the future, Xen will also be able to take advantage of the Rust-vmm project being led by Intel that will make it possible for a processor to run multiple types of hypervisors in a modular fashion. In addition to providing a more agile way of isolating virtual machines, Rust-vmm will reduce the amount of time required to spin up a virtual machine. Specifically, Intel is trying to make it easier for a processor to be able to run different classes of hypervisors that are optimized for legacy monolithic applications and cloud-native applications based on containers that require a much lighter-weight hypervisor.

It’s not clear to what degree advances in technologies such as core scheduling will influence the selection of hypervisors and virtual machines. However, from a DevOps perspective, it’s clear core capabilities being added to the next generation of hypervisors will not only improve application performance, but they should also significantly advance best DevSecOps practices.

— Mike Vizard

December 19, 2019
CNCF Graduates TUF Project to Secure Software Updates

The Cloud Native Computing Foundation (CNCF) announced today that an open source specification for securing software update systems has graduated to becoming a top-level project.

The Update Framework (TUF) is made up of a set of libraries, file formats and utilities that can authenticate files and images before they are downloaded from a software repository. Justin Cappos, associate professor of computer science and engineering at NYU Tandon School of Engineering who led the development of TUF, said the framework enables IT organizations to better secure their software supply chains.

In addition, TUF isolates artifacts in a repository in a modular fashion that not only limits the amount of damage that can be inflicted by a breach of the repository, but Cappos said it also makes it easier for IT organizations to roll that repository back to its last known good state.

For a CNCF project to graduate it needs to demonstrate thriving adoption, an open governance process and a strong commitment to community, sustainability and inclusivity. TUF was developed at the University of Washington in 2009 by Cappos and Justin Samuel. TUF has been based at New York University Tandon School of Engineering, which makes a reference implementation available to any interested party, since 2011. It became a CNCF project in 2017 and is now the first security-oriented project to graduate among the eight other CNCF projects that have graduated.

TUF is already employed within Notary, a separate CNCF project that provides a mechanism to both certify the validity of the sources of Docker images and encrypt the content of those images. TUF is also employed within Uptane, which is employed to deliver software updates to automobiles. Other organizations using TUF in production environments include Amazon, VMware, Google, IBM, Red Hat, Datadog and DigitalOcean.

Cappos said he would like to see TUF adopted more broadly to secure software supply chains in medical systems as well as critical infrastructure systems such as the power grid. As cyberattacks targeting these systems increase, Cappos said it’s apparent there is a need for a more resilient approach to securing software running on these types of platforms.

Longer-term, as organizations embrace best DevSecOps processes, it’s now only a matter of time before organizations focus more of their time and energy on securing the software supply chain. However, Cappos said right now there is too much focus on trying to discover application dependencies and scanning images. While those are important tactical tools, Cappos said there needs to be more focus on strategic approaches to securing software supply chains.

It’s not clear to what degree DevSecOps will ultimately push organizations to embrace a more holistic approach to building and managing software supply chains or whether larger concerns about the security of software will push more organizations to embrace DevSecOps. Regardless of whether the impetus for building and deploying more secure software comes from the top down or the bottom up within an organization, the important thing is that in terms of tools and processes rapid advances are finally being made.

— Mike Vizard

December 18, 2019