Figure 1. Impacts and Savings from an IT Incident Management Automation Solution

This challenge is exacerbated by the way applications are built and deployed. Agile, DevOps-type environments are characterized by a “need for speed,” with the rate of deployment measured in days or even hours. Site Reliability Engineers (SREs) and other roles have emerged as a way of curating these deployments and managing any incidents, but these roles need to be properly informed and enabled to do their work.

The latest generation of incident management tools, such as Everbridge xMatters and PagerDuty Rundeck, go some way toward dealing with these challenges. In this report, based on field testing of both xMatters and RunDeck, we look at how these tools address incident reporting and response, how they bring automation into the mix to share information with stakeholders, and how they may automate any necessary resolutions. We found:

• Key components of a good incident response in a hybrid environment include standard integrations and workflows, automation for incident response, and the ability to define and experiment, do research, and improve the workflow if needed.
• Solutions in this space can have different areas of priority and focus. For example, some products concentrate on automating solutions with code, while others focus on no-code/low-code solutions for engineers who may not be developers. Either way, the idea is that the solutions to on-call alerts can be automated.
• The findings in this report demonstrate that the world of SRE and DevOps needs automated on-call/incident resolution, which is where xMatters excels.

Figure 2. Stages in the Incident Management Lifecycle

Figure 2 shows the incident management lifecycle, albeit without the after-action report (AAR) that may trigger a different process to start for the problem management lifecycle. xMatters and PagerDuty have the AAR delivered in the postmortem problem process/report.

The post Everbridge xMatters: On-Call Alert and Incident Response appeared first on Gigaom.

The software development and operations vendor landscape likewise has seen sweeping changes. This sector has always been fragmented, despite efforts by larger players to consolidate every decade or so. What is clear is that point products are not enough and can actually create a host of challenges, as noted above. As a result, incumbent DevOps tool suppliers are seeking to broaden their scope from a feature-centric, API-integration-driven base to one that addresses the top-down requirements of an end-to-end lifecycle. As vendors expand their mandate, they find themselves increasingly in competition with new rivals from different categories, such as application lifecycle management and agile planning.

A third element in this space is the evolution of target architectures, notably around distributed and multi-cloud models. The resulting distributed nature of applications has added complexity, even as it opens the door to a new set of vendors. It is against this background that VSM has emerged, delivering on value stream efficiency, integrations, and effectiveness as shown in Figure 1.

Figure 1. VSM Addresses Both Efficiency and Effectiveness

At the outset of writing this report series, several potential key criteria were considered, based on needs expressed by the organizations we work with. Some had to be ruled out as differentiating key criteria, simply because few if any vendors provided them. A case in point is “Innovation Management,” a concept originally defined to support innovation-led activities such as co-creation, hackathons, and so on. Large organizations across sectors are engaging in experiment-based activities such as these, but lack appropriate tooling to support them, relying instead on spreadsheets and other office tools (with vendors like Optimizely the notable exception). While it is likely that VSM will evolve to support innovation activity, we were surprised to see it currently absent from vendor thinking. Only Planview came close, with its Idea Management product.

Other capabilities didn’t quite make the cut. That includes the use of a normalized repository of data about the software development cycle (as offered by Plutora and others), as it is more a function of the platform than a differentiating capability for end users. Also considered, but not incorporated as a key criterion, was the still-nascent promise of artificial intelligence (AI) to offer “smarter” insights at the pipeline level. Hopes that AI can generate an ideal process are tempered by the fact that the notion of an ideal process is flawed. But AI could, at the least, help harness sources of data and interpret them in a way that speeds human decision making.

VSM is still maturing, but this report is designed to drive decisions today. Even in these early stages, enterprises need VSM practices and tooling to address the challenges they face. Yet organizations must contend with a confusing marketplace, in which vendors from diverse backgrounds are dropping other terminology and clustering around the term VSM. In fact, not every company listed in this report would categorize itself as a VSM provider, but that should not rule them out. We have avoided putting too much weight behind the term VSM, preferring to focus instead on what makes up the elements of a solid solution in response to the end-user challenges we see today.

The post GigaOm Radar for DevOps Value Stream Management appeared first on Gigaom.

Value stream management (VSM) in the DevOps world plays the role of Zen master across software development and operations, asking why things are as they are and whether they can be improved. It focuses on both efficiency (saving money) and effectiveness (adding benefit). VSM tools go hand in hand with best practices, offering real-time insights to help decision-makers:

• Prioritize development and CI/CD pipeline goals
• Identify areas for improvement throughout the DevOps workflow
• Increase the speed of innovation while ensuring efficiency and quality
• Enable collaboration on digital delivery goals

As such, tools can respond to the need for value stream efficiency by enabling organizations to identify and address bottlenecks in the development, testing, and deployment processes. They can also promote effectiveness by offering measures that link to return on investment, customer satisfaction, and other business-facing criteria. From an engineering and engineering management perspective, VSM tools can show metrics on operations, such as how long it took a pipeline to run, where it failed and why, and include tips on how to make pipelines more effective.

In this report, we review best practices around VSM and look at the table stakes, key criteria, and emerging advancements that are shaping and guiding VSM today. We also consider top-level evaluation metrics to inform decision-making around VSM tool adoption.

We recognize that VSM practices and tools are not an end in themselves, but act as enablers to help organizations scale their efforts and deliver software-based innovation more quickly. As a starting point for organizations looking to adopt VSM today, we offer the following guidance:

• Start, but do not stop, with efficiency—effectiveness is the ultimate goal.
• Drive incremental improvements and deliver value at every stage.
• Integrate VSM tools with broader IT and business dashboards.
• Manage workflows as products in their own right.
• Recognize challenges as starting points and catalysts for change.

Note: The terms “pipeline” and “workflow” are used largely synonymously in this report. A value stream can be seen as either one, but with an understanding of its benefits and costs built in.

The post Key Criteria for Evaluating DevOps Value Stream Management appeared first on Gigaom.

As technology becomes more SaaS-based and organizations deploy applications in multiple clouds, there are requirements for more visibility into the cloud environment and better incident response and resolution automation capabilities. The two elements required to achieve this are integrations and workflows in an incident response software solution and effective experimentation, research, and testing in the cloud and on-premise. GigaOm undertook testing xMatters, an incident response platform, to check the availability and ease of use of workflows and integrations built into the solution, test automated incident response, and run experimentations to ensure that the integrations and workflows that were built to automate incident response work.

The post Reliability Through Automation for Your Infrastructure and Applications at Scale appeared first on Gigaom.

Manually typing in commands or even navigating a GUI is frequently an error-prone endeavor, and humans can’t be counted on to be consistent over time. Furthermore, reducing the time spent doing repetitive tasks with a monolithic script requires complex logic and is generally tightly coupled to a specific version and set of conditions.

For these reasons, IaC emerged with the goal of creating code segments with a global set of variables, arguments, and parameters to support re-use and maintainability. These components can be assembled by an orchestrated process to achieve a desired state and to maintain that desired state until it is authorized to change it.

As always with code, these code segments should be checked into a version control system (GitHub, GitLab, and the like) to ensure all committed changes include a description of what changed and why.

The goal of this GigaOm Radar Report is to investigate where vendors in the IaC space are aligning around features, usability, and target user base. IaC addresses two types of technology professionals: developers and infrastructure/operations engineers. Developers who seek to automatically deploy an application may use IaC to build the environment, while infrastructure/operations engineers will more likely use IaC to ensure that cloud and on-premises infrastructures are being built efficiently and with scale in mind. Regardless of who uses the IaC platform, code is employed to automatically deploy the infrastructure and cloud services. For this reason, there must be a use case for both professionals.

The GigaOm Radar Report for Infrastructure as Code analyzes the top IaC platforms currently in the market, weighs the key criteria and evaluation metrics used to assess them, and identifies important technologies to consider for the future. This report provides an overview of the leading platforms and recognizes those that excel in particular categories. It is intended to appeal to organizations looking to extend investments in existing platforms as well as to those yet to dip their toe in the IaC waters.

The post GigaOm Radar for Infrastructure as Code appeared first on Gigaom.

Thus, companies began to take advantage of configuration management (CM), a process that uses text-based configuration and APIs to manage the state of deployed resources, usually at the operating system or software application level. Fundamentally, CM tools ensure a system maintains a chosen configuration and keeps it in line.

It is important to differentiate here between configuration management tools and Infrastructure as Code (IaC). Some might argue that configuration management tools such as Chef, Puppet, or Ansible are different from those used to provision infrastructure and should not be utilized in this circumstance. Instead, provisioning infrastructure tools such as Terraform and Cloud Formation are more appropriate.

While it is useful to consider IaC and CM separately, there are similarities. IaC tools can deploy applications and CM tools can create cloud resources. With both sets of tools offering comparable functions, it can be easy to misunderstand which kind of tool to choose for a particular undertaking.

Configuration management tools are chosen typically to manage servers, both virtualized and in the cloud, to ensure the appropriate configurations (related to, for example, the installation of applications) are present in the environment. The ability to do this for any cloud or virtualization environment will play a big role in deciding which one to choose.

The goal of the Configuration Management radar is to evaluate where vendors stand with regard to features, scalability, ease of use, and market share. This GigaOm Radar report analyzes the top CM platforms in the market, weighs the key criteria and evaluation metrics used to assess these solutions, and identifies important technologies to consider for the future. The report provides an overview of the leading platforms and recognizes platforms that excel in particular categories.

The post GigaOm Radar for Configuration Management appeared first on Gigaom.

IaC uses text-based configuration and APIs to create, manage, and decommission resources such as servers, load balancers, databases, and other devices in the cloud. The most elementary use of IaC is to automate resource provisioning.

CM uses text-based configuration and APIs to manage the state of deployed resources, usually at the operating system or software application level. CM tools essentially ensure a system maintains its chosen configuration, detects any drift from that configuration, and remediates that drift when it occurs.

IaC is a technology shift that aims to expedite software deployment, simplify infrastructure management, and bring development and deployment together with infrastructure as part of a DevOps process. It’s a key element in the burgeoning world of DevOps and DevSecOps. It also offers unparalleled flexibility for developers and enterprises looking to create innovative and fast-moving solutions through automation tools, applications, and practices.

Deploying infrastructure traditionally has been a manual process. That was acceptable when infrastructure was relatively static, with only minor changes and upgrades happening every few months or years. Infrastructure is no longer a static resource involving only operating systems and applications. The advent of the cloud has made infrastructure more dynamic and has accelerated development practices. Applications are now more dynamic and scalable, and the infrastructure must follow suit.

IaC presents an opportunity to define the underlying infrastructure for applications and services using the same process and procedures as software development. Infrastructure deployment and management must become dynamic, automated, and consistent. Code-defining infrastructure should be stored in source control, added to Continuous Deployment (CD) pipelines, and tested for compliance and security.

At this point, it is important to differentiate between CM and IaC tools. Some might argue CM tools such as Chef, Puppet, or Ansible are different from those designed for provisioning infrastructure, and it is therefore not good practice to use them for doing so. Infrastructure provisioning tools such as Terraform or Cloud Formation would be more appropriate.

Many vendors have developed specialized tools for achieving IaC deployments. This GigaOm Key Criteria report details the Infrastructure as Code market, identifies key criteria and evaluation metrics for selecting the right IaC tools for your enterprise, and identifies vendors and products that excel in the space. This report will give you an overview of the IaC market and help decision-makers evaluate existing platforms and decide where to invest.

The post Key Criteria for Evaluating Infrastructure as Code and Configuration Management appeared first on Gigaom.

Figure 1. Architecture of the End-to-End CI/CD Pipeline

The CI/CD pipeline should align with broader elements of innovation best practices, each of which needs to incorporate the “continuous” principle, including:

• CI/CD and/or CD
• Target deployment environments—on-premises, cloud, or both
• Communication and collaboration
• Governance, compliance, and risk
• Management and planning
• Evaluation, visibility, and feedback

Together, these concepts make up the framework for how we can consider the shape of CI/CD today, and offer criteria for how enterprises can evaluate CI/CD tooling vendors. In this report, we provide a broad overview of the tools vendors are offering in response.

Please refer to the GigaOm Key Criteria Report: Enterprise CI/CD to get a complete description of the key criteria and evaluation metrics referenced in this report.

The post GigaOm Radar for Enterprise CI/CD Solutions appeared first on Gigaom.

How did this new approach come about? Without delving too deeply, it happened when tools designed to support software delivery were no longer able to keep up with faster-moving, agile development practices. These first emerged as the spiral, prototype-driven initiatives of the late 1980s, moved through the rapid and dynamic methodologies of the 1990s, and ultimately arrived at a watershed when Kent Beck conceived eXtreme Programming (xP) and made it cool to be a developer again.

Even as the need for speed increased, programmers still relied on custom build scripts that were complex and difficult to change. As xP took hold, tools appeared, enabling software builds to be defined and changed more easily, supporting better practices of building code often and early, and bringing in features that supported more rapid delivery—such as diagnostics and re-execution, should a build fail. Open source played its part, leading to the creation of the Jenkins CI tool, and while this claims a de facto standard position in CI, many other tools emerged and are in wide use today.

Thus, continuous integration arose both through necessity (the mother of invention) and because the very presence of tools created a market for them. The arrival of standardized software stacks and cloud platforms heralded the advent of continuous delivery—the ability to deploy executable code to a target environment, albeit requiring some degree of manual intervention for the process to begin. A further step in pipeline automation was introduced with the concept of continuous deployment, which seeks to eliminate manual intervention altogether: As soon as a CI process is complete, the continuous deployment process kicks off and the code is deployed.

Since notions of CI/CD were first proposed, the need to deliver software quickly and efficiently has only increased. Some have started to talk about “continuous everything,” but realistically, while many enterprises may be looking to apply more advanced concepts such as DevOps, they struggle to deliver on the basics of continuous anything (see also: “continuous in name only”). Meanwhile, many CI/CD tools still in use today were designed for a different time: Cloud-based architectures have evolved, new languages have proliferated, and software development approaches have matured even further.

As a result, it is more important than ever for enterprises to build a CI/CD foundation so they can accelerate their software delivery efforts, based on modern tools that work with the architectural norms of today, taking into account current and future needs. In this report we consider:

• The drivers of CI/CD’s continued evolution
• The core concepts of the end-to-end CI/CD pipeline
• Which CI/CD platforms offer full end-to-end CI/CD capabilities
• Why the use of CI/CD tools has extended from development into cloud engineering and infrastructure teams
• The differences between continuous delivery and continuous deployment, and where/when each should be applied
• Evaluation criteria for the tooling available and entering the market

Overall, we set out pointers that organizations need to guide them as they look beyond traditional CI/CD toward delivering on technology-based innovation at scale.

The post Key Criteria for Evaluating CI/CD appeared first on Gigaom.