staging-devopsy.kinsta.cloud

Category: DevOps Toolbox

  • Why an Embedded Analytics Maturity Framework is Essential

    Why an Embedded Analytics Maturity Framework is Essential

    Contextual analytics, or embedding analytics directly into a business application’s transactional environment and core workflows, is the most sophisticated stage of business intelligence (BI) currently available to organizations today. It is one level ahead of the traditional integration of analytics, which is a standalone capability presented as a separate dashboard or reporting module.

    Today, there is an increasing shift among organizations toward embedding transactional analytics into their enterprise applications. Because contextual analytics is the most advanced option in the market, there is also an increasing need for assessing our analytics readiness first.

    The fundamental difference of contextual analytics lies in how it offers analytics to the user to explore data or derive insight within their transactional environment rather than accessed as an external tool. This approach requires a deeper evaluation of the product’s analytical maturity level using a formal framework. Having such a framework can act as a deployment guide for your developers for every stage of embedded BI implementation, including contextual analytics.

    But first, what makes contextual analytics so different that it necessitates a readiness evaluation?

    Contextual Analytics Vs. Embedded Analytics

    With contextual analytics, dashboards, reports and charts are no longer separated but are part of the main user experience. This integral change necessitates a closer look at your data and integration capabilities to align what it brings with all aspects of your software, including existing analytics.

    Embedding these elements directly into core software workflows isn’t a replacement for any existing analytics, but is instead another big step toward making data and analytics a more seamless part of your end users’ everyday work.

    It should be stressed that contextual analytics accommodates various levels of implementation and business requirements. Analytics can be embedded lightly, such as in the form of basic in-line charts and graphs users can see as they explore your software, or embedded deeper to offer AI-assisted insights and real-time alerts that trigger action from users while they work. It can be integrated with an experienced BI vendor partner or in-house if you possess the skill set internally.

    Avoidable Pitfalls of an Improvised Approach

    The need to assess your application’s analytical maturity and readiness for embedding analytics directly into the transactional workflow comes down to avoiding unnecessary BI roadblocks. 

    For many organizations, BI and analytical capabilities are traditionally lower in priority than other aspects of the software. Intending to add BI features later is well-meaning and understandable, but leaving developers to add in features intermittently and leaving it to your users to demand them when needed creates an issue of visibility. Vendors typically lose sight of what their application currently is capable of analytically, or what development needs to make the addition of a new feature not only technically achievable but worth the time and cost investment.

    If you take the time to reassess your application’s analytical capability, your developers and leaders can better understand that your product could be at an earlier stage of readiness than previously believed, and prepare accordingly before seeking out a contextual or other BI solution.

    For example, approaching contextual analytics ad-hoc could mean you find an unexpected older dashboard module, a cost that could have been accounted for in a formal maturity assessment. 

    What it comes down to is this: Implementing a basic dashboard module or data export feature, completely separate product features, is fundamentally different from fully embedded analytics in your users’ core workflow experience. Pursuing a formal evaluation to guide the introduction of contextual analytics—or even a form of embedded analytics at an earlier stage—means your users and product receive the best type of analytical capability your business is ready for today.

    The Five Stages of Embedded Analytics Maturity

    Based on our experience, there are five possible stages of product development, as illustrated in the embedded analytics maturity curve below. As contextual analytics is the final, most advanced stage of an embedded analytics integration available to product owners, the need for a formal assessment of maturity is most important, should it be the target state.

    Accelerating the implementation of contextual analytics comes down to your skillset, which will allow you to identify and evaluate your state of readiness accurately and determine a BI solution’s flexibility. If you do not have the internal expertise, implementing contextual analytics is easier with the help of specialized BI vendors that can help you in your assessment, and offer a contextual analytics platform built around openness. We recommend you look for vendors and partners that allow for:

    • Advanced APIs that lower total integration time and ensure the need to rearchitect the software is minimal to zero.
    • Customized experiences to make your desired contextual linkages, such as showing a user a relevant embedded chart when they click on a table of a client, possible.
    • An open platform that allows for options for on-premises, cloud, multiple operating systems that guarantee long-term security, scalability and flexibility with your analytics.
    • Rapid adaptation to your product development roadmaps with automated processes and administrative tools to lower total cost of ownership
    • White-labelling to make the rebranding and blending of the analytical solution and your native application components seamless.

    Ultimately, having an awareness of your product’s readiness and taking the time to examine your application’s current state means you avoid costly integration mistakes, save time and ensure developers implement the best solution according to your exact needs now.

  • Sumo Logic Extends Observability Scope and Reach

    Sumo Logic Extends Observability Scope and Reach

    During the online Illuminate user conference, Sumo Logic revealed how it is integrating capabilities it gained with the June 2021 acquisition of Sensu, a provider of open source monitoring tools, with its continuous intelligence platform in addition to adding support for data collected via open source OpenTelemetry software.

    Sensu Go, a set of tools for implementing monitoring-as-code, is now a core part of the Continuous Intelligence Platform. The company is also now making available in beta Sumo Logic OpenTelemetry Distro and Ecosystem Support, a single agent through which all logs, metrics and traces can be collected from instrumented applications. Sumo Logic is also supports the AWS OpenTelemetry Distro, an offering from AWS that provides similar capabilities. Sumo Logic has also increased the capabilities of Sumo Logic Free to include monitoring-as-code tools created Sensu.

    Bruno Kurtic, vice president of product and strategy, said as responsibility for managing applications shifts left toward developers it’s critical to provide observability capabilities that can be programmatically infused into applications. As part of that effort, Sumo Logic is now also offering Sensu Plus, which provides access to an analytics engine for the data the platform collects.

    Sumo Logic is also adding machine learning algorithms to provide more context to the alerts the platform generated via an Alert Response feature that is part of the core platform.

    The company is also adding support for the operator software that Red Hat created to make it simple to deploy Sumo Logic Continuous Intelligence Platform alongside the Red Hat OpenShift platform for building and deploying applications on top of Kubernetes clusters. In addition, Sumo Logic is also providing integration with a total of 38 either new or updated observability applications that integrate with a wide range of third-party platforms.

    Finally, Sumo Logic is extending the security observability platform it provides based on its platform to add support for containers and serverless computing functions alongside virtual machines and integrations with third-party endpoint detection and response (EDR), network detection and response (NDR), threat intelligence and managed detection and response (MDR) platforms. The company has also added or updated 26 applications for specific third-party platforms.

    Kurtic said Sumo Logic makes it possible for developers and IT operations teams alike to observe an IT environment on an end-to-end basis via a single pane of glass. In some cases, the members of an IT operations team will require a user interface to manage that environment. Developers, meanwhile, might prefer an application programming interface (API) through which observability data is made accessible from within a continuous integration/continuous delivery (CI/CD) platform.

    Regardless of the type of user, however, IT teams should not have to hire their own data science team to analyze observability data. Instead, the observability platform should embed machine learning algorithms that surface all the benefits of data science without the need to hire additional headcount, he said.

    One way or another, DevOps teams will soon routinely benefit from the additional levels of context that observability platforms provide. The challenge will then be determining how best to fix a raft of issues that many DevOps teams today simply didn’t know existed.

  • Harnessing the Value of Log Data Analytics

    Harnessing the Value of Log Data Analytics

    Each day, the average enterprise’s cloud applications, containers, compute nodes and other components throw off millions of tiny logs. Each log is a file whose data describes an event such as a user action, service request, application task or compute error. Logs also capture messages that applications and other components send to one another.

    There’s a wealth of information and value hidden in those logs, which is why businesses are so keen on using them to address business needs like customer engagement, IT security and cloud operations. 

    The need for understanding and managing this data is so high that Markets and Markets valued the market for log analytics data at $1.9 billion in 2020. Analysts predict this to grow to $3.7 billion by 2025. It’s not just the sheer growth of data driving this market—it’s also the demand to gain business insights. 

    That’s why ChaosSearch recently conducted a survey to better understand how businesses are currently using and managing their log data. Insights were collected from practitioners at 50 medium-to-large enterprise organizations. What the survey found is that organizations see a lot of value from tapping into their log data to achieve better outcomes across both business and IT functions. That said, these practitioners face challenges handling the scale requirements and they know there are still more opportunities for them to expand the scope and discipline for log management.

    Top Use Cases

    This study confirmed that businesses are using log data in a number of ways, spanning both business and IT functions. We see that more than 90% of respondents are using log management and analytics for at least two primary use cases. It’s not surprising that the top use cases for log management are security (70%) and IT monitoring (68%), but many are prioritizing BI & analytics (46%) and business operations (28%) as well.  

     

    It’s interesting to look more closely at the security use cases: Investigations (45%) and insider threats (45%) top the list of SecOps uses for log data. Audits and compliance (32%), threat hunting (32%) and anomaly detection (30%) also made the list. 

    Growing Desire to Support Business Operations

    We also saw that these practitioners want to use log data to support business operations—specifically to drive better business outcomes and improve competitiveness. For example:

    1. A global industrial equipment manufacturer attached IoT devices to farm equipment to track weather, temperature, humidity, time of day, depth of planting, soil conditions, seeds planted and geo-routing on farms. This raw data is continually collected and analyzed within the central log analytics solution, thereby allowing the vendor to deliver farm productivity reporting and recommendations back to their clients.
    2. A biopharmaceutical firm tracks cell culture logs with alerts on temperature and humidity. The company uses its log analytics platform to store long-term data to run queries that help in hypothesis testing. They also conduct various long-tail analyses that reveal trends and allow scientists to make informed decisions about future experiments. 
    3. A large online retailer leverages log data from web visits and other customer activities to develop 360-degree profiles of customers and analyze the steps in the “customer journey” to identify opportunities for improved efficiency and increased revenue capture.

    Tackling Challenges of Growth and Complexity

    Even with more interest in using log data for security and business operations, the surveyed practitioners called out a range of challenges. The top three being: Complex infrastructure (48%), managing costs (42%) and managing growth (34%). They also said the lack of centralization, reporting and data quality were problems. These challenges are perhaps exacerbated by the expectation that data will continue to grow and data retention will increase. 

     

    There are a lot of variables that drive the volume of log data generation, like the number of users, devices, applications, IT environments and infrastructure elements. The survey found two things were universal—data growth rates are high and are a source of pain and data retention is an increasing priority. 

    Among the participants, 94% ingest at least one TB or more of data per day, with 18% in the 10TB + range. Consider this—the average daily ingest volume for these companies was 7.9 TB! 

    The problem is, despite the massive amounts of data being ingested daily, only 28% of respondents are capturing 80% of log data or more today. And 78% believe that capturing more than 80% of log data is ideal. That’s a big gap. 

    Practitioners Rate Most Important Log Management Capabilities

    We also learned that these practitioners are generally satisfied with their existing solutions, but many of them still expect to bring in a new solution for log management and analytics within the next three years. That’s because they want better scale and a cloud-native solution. 

    When we asked about important capabilities for a log management platform, scalability (58%), resilience (54%) and advanced analytics (52%) topped the list. 

     

    Budgets Increase to Meet Demand for Log Analytics

    To address these challenges and opportunities before them, survey respondents are growing their budgets; 86% anticipate their budgets will grow by at least 20% and 36% expect an increase of 50% or more. These budgets will not only support more data capture and increase retention periods but also help them go after the growing use cases for supporting the business. In fact, 68% said they expect the number of use cases to grow in the next 12 months.

    There is no doubt: Companies who value log data and invest in capturing data will harness insights that will propel their businesses forward.

  • DataOps: How to Turn Data into Actionable Insights

    DataOps: How to Turn Data into Actionable Insights

    Enterprises‌ ‌have‌ ‌struggled‌ ‌to‌ ‌collaborate‌ ‌well ‌around‌ ‌their‌ ‌data, which can impact everything from digital transformation to advanced concepts like AI and ML.‌ ‌DataOps is not without challenges; building, managing and scaling data pipelines requires careful thought around reusability, portability across infrastructure and applications and long-term maintenance and governance. And these are just a few of the issues facing enterprises. For this reason, DataOps technology stacks need to focus on providing key capabilities include data extraction, integration, transformation and analysis.

    The Importance of DataOps

    The enterprise is undergoing a seismic shift from siloed application development and data repositories to more composable and reusable architectures. Additionally, there is a growing demand for speed and agility as well as the influx of disruptive technologies such as the cloud, IoT and AI. Organizations that want to win big must act and adapt quickly to deploy and scale new software and solutions that provide customers with a superior experience and satisfy their rapidly evolving needs. To do that, they also must be able to rapidly aggregate, integrate and analyze data sources.

    Even with this need for speed, the tools and processes for the creation and processing of data are not standardized‌ in‌ a way that promotes rapid innovation‌ and ultimately helps organizations transform. DataOps is critical to address the challenges involved in acquiring, storing and governing data. In addition, companies are dealing with increasing complexity in their IT environments. In a recent survey, more than 80% of enterprises have a hybrid cloud or multi-cloud strategy. In order to have cost-effective and secure management of increasingly large amounts of data, enterprises must adopt DataOps.

    Managing Data Growth

    DataOps has been around for about a decade, but has recently gained momentum because of the overwhelming challenges companies face today in dealing with large, complex sets of data that are being generated at increasingly faster rates. With new technologies like the internet of things (IoT), cloud computing and the power of big data now integrated into everyday use, companies are generating at least 50 times more data than they were just five years ago. And with more data comes a need for greater efficiency and higher demand for data experts.

    DataOps potential impact on businesses might lead you to think of it as a radical new methodology. But many companies have already been using similar practices to deal with some aspects of data management, particularly around data warehousing and analytics. And just like DevOps, DataOps isn’t a product, but rather a cultural shift supported by many products—many existing products. So it’s important for businesses looking to adopt DataOps to consider what they already have, such as enterprise data warehouses and ETL tools, and what they may need to acquire, replace or modernize. In the end, companies will end up with several systems to support the data pipeline.

    DataOps and Big Data Challenges

    Most enterprises have invested in significant data infrastructure to extract, load and store their data to take advantage of Big Data analytics and technologies. However, these infrastructures are often layered, hard to manage and full of legacy tools that hinder the transfer and integration of data. Additionally, organizations have invested significant resources in tools such as data warehousing and data marts. These data warehouses have been used to model data but have been typically implemented with a predefined data model. A business intelligence (BI) system, an enterprise data warehouse or any other set of tools might assist in the execution of a data transformation job.

    The technological revolution is creating unprecedented opportunities to make things happen with data. By analyzing the data that powers modern business, we are able to provide value in every dimension of our organizations. As is the case with every transformation, the benefits of building an integrated, self-service analytics environment will be realized by users rather than IT. Leveraging the power of data science, business leaders can achieve operational excellence and compete effectively against the growing waves of competitors. For the data science and analytics staff to be successful, they must be exposed to all of the necessary technology and processes to support effective use of data.

  • Clubhouse Becomes Shortcut to Transform Software Project Management

    Clubhouse Becomes Shortcut to Transform Software Project Management

    Shortcut, formerly known as Clubhouse Software, today announced that its project management software for software development teams has been expanded to include additional workflow capabilities.

    CEO Kurt Schrader said team-to-workflow functionality is being added to the software-as-a-service (SaaS) platform and will make it easier to share workflows across software development teams in a more standardized way.

    Organizations can standardize workflows across multiple teams while still giving each team the ability to customize workflows for their own unique processes. As work gets created and assigned, it automatically moves into a workflow without having to manually update processes.

    Shortcut is designed to make it simpler for development teams to collaborate in a way that maintains transparency with other teams working on projects that are part of the same larger initiative, said Schrader. It allows product managers, engineers and designers to plan, track and measure their work without friction as the organization continues to grow in size, he added.

    For example, Shortcut will surface what teams need to focus on as priorities and timetables change within a specific project in addition to allowing users to define sprints using start and end dates, and the tool then sends reminders so the team can reserve time to focus on specific projects.

    Shortcut will also integrate with continuous integration/continuous delivery (CI/CD) platforms via application programming interfaces (APIs) to enable the development of custom workflows that include, for example, integration with real-time conversations occurring via the Slack collaboration service.

    Most of the project management software DevOps teams employ today is too complex and intimidating for the average business executive. Rather than forcing business users to learn how to master these applications, a case can be made for a more intuitive set of project management tools for both software development teams and the product managers they ultimately serve.

    As more organizations realize how dependent they are on software to drive business processes, many of them are reviewing the tools they currently rely on to manage software development. The goal is to not only reduce friction and enable more transparency across teams but also to provide stakeholders outside of the development team with more visibility into the status of any given project.

    At the same time, organizations are simultaneously launching more software development projects that have many dependencies. Many of those initiatives are based on microservices that are being built in isolation from one another before being aggregated to create an application. The dependencies between those microservices require organizations to make sure they are developed and deployed in a way that doesn’t leave one software development team waiting on another to finish a project before they can complete their work.

    Shortcut

    Schrader said that humans, as a species, are bad at organization. Project management applications should make it simpler for companies to understand how projects are not only organized but also all the dependencies that exist between them.

    Regardless of how software development projects are managed the need for greater visibility is obvious to all. Less clear is the best way to go about achieving that given all the communications channels available.

  • 5 App Modernization Best Practices

    5 App Modernization Best Practices

    An organization’s digital transformation is ineffectual if it doesn’t bring out the best from its applications. This is a near-universal concern since most enterprises still have core applications that are architected primarily to work in legacy IT landscapes in an on-premises dedicated environment, slowing down IT and business performance, stymieing innovation and increasing vulnerability to risk. Businesses are paying the price of their technical debt by forsaking agility, adaptability and competitiveness. That’s bad enough in regular times; in a post-pandemic scenario, this can have devastating consequences. 

    Acquiring a few cloud-native applications that are not integrated with existing systems is of limited value and, at best, provides just part of the answer. On the other hand, overhauling the legacy application landscape is usually out of the question. The only reasonable solution, then, is application modernization. But where does an enterprise begin?

    Pick and Shift

    A great place to start is by examining existing applications. Understanding every application’s function, performance and issues and what it can gain from modernization will help to establish a ‘universal set’ to pick from. The candidates for modernization can be prioritized based on technology factors—for example, when the architecture adds cost, vulnerability or complexity—as well as business considerations, such as compromised agility or value potential. Finally, the enterprise needs to weigh the potential benefits, especially ROI, against the difficulty of modernization.  

    Typically, the biggest, most important applications at the core of the enterprise are the hardest to modernize. But without their involvement, the transformation will most often be incomplete. Rather than lifting and shifting these monolithic applications and their vast data to the cloud, the enterprise can enclose them in an API layer to connect them to all the other applications that are being migrated as well as any new applications that are deployed. Using APIs to expose the functions and data of a legacy core system, such as ERP, allows it to be widely used, reused and modified, as well as leveraged to build new solutions and services. 

    Split Into Microservices

    Refactoring is a useful way of modernizing legacy applications that involves breaking them into microservices, which are then connected to cloud infrastructure such as Docker or Kubernetes. These microservices, which are loosely coupled, can be ‘called’ and scaled individually. Since refactoring requires significant rewriting and restructuring of the code, it is best done progressively over several iterations to make sure everything is functioning properly.  

    Provide Full-Stack Visibility 

    Even when an application is modernized into microservices on the cloud, it needs to communicate with other legacy systems in the enterprise. The problem is that now there are more services and environments to monitor and secure, not to mention single points of failure, which not only increases complexity but also denies the enterprise full-stack visibility. But visibility across environments—edge to core (on-premises) to cloud—is imperative for success. This is achieved by ensuring that the modernized applications fit within the organization’s data fabric. The enterprise needs to capture data across the stack, from end to end, and process it in real-time to have an uninterrupted view of the performance and availability  of its applications.

    Modernize the Process Landscape

    A perfectly executed application modernization program can fail to deliver results if the surrounding requirements—for example, planning and meeting quality standards—are not met. Legacy processes can be a drag on modernization efforts. It is therefore necessary to address this issue by rearchitecting processes to fit a more automated setup by supporting code developers with teammates who understand the business requirements, adopt best practices and follow the example of successful digital natives. 

    Track Performance Metrics

    Going back to the point about visibility; enterprises need to establish key metrics to track so they can monitor the performance of applications right down to the code level. And it’s not just applications—the entire infrastructure, from cloud to databases to networks, needs to be tracked continuously to identify problems before they blow up. The performance of applications needs to be compared with the corresponding pre-modernization values to understand the benefits as well as identify areas needing optimization.

    Balance and Act

    Application modernization approaches range from rehosting and refactoring to rearchitecting and replacing, which are progressively costlier and riskier, but also progressively more impactful. Enterprises need to decide what’s best for them based on considerations of effort, cost, risk and result. While some enterprises may go slower than others, eventually they will have to modernize all their applications to be competitive and meet their customers’ needs in the most effective way.

  • Zero-Trust Network Access Platforms Slash DevOps Bottlenecks

    Zero-Trust Network Access Platforms Slash DevOps Bottlenecks

    In a prior article, I indicated why a new remote zero-trust platform is needed to support DevOps teams.

    Traditional remote access configurations are not well-suited for DevOps given a shifting user population comprised of employees, contractors and other third parties often using their own devices; the large number of tools and systems to which access must be provided and the hybrid nature of the infrastructure itself (on-premises, hybrid and multi-cloud).

    DevOps Pain Points

    Three pain points are associated with traditional approaches when used with DevOps.

    1. DevOps user experience is poor in traditional remote access configurations. Each DevOps service must be accessed as separate secured sessions, which is confusing and tedious.
    2. System management requires IP whitelisting rules in VPN, static SSH keys in Bastion, firewall rules controlled by different teams and application-specific authentication. The coordination and execution of so many touchpoints for common actions—including the onboarding of new team members, changing roles or adding a new service—invites mistakes that cause productivity issues and introduces unforeseen security holes.
    3. Security is complex and error-prone. DevOps users must be granted restricted access to the individual services they need to be productive. Administering restricted access for individuals and groups is time-consuming. Security policies typically require monitoring detailed audit logs of user access.

    How a Zero-Trust Remote Access Platform Works with DevOps

    In my whitepaper, Zero-Trust-Remote Access-For-DevOps, I explain how a zero-trust remote access platform can resolve the requirements for improved DevOps user experience, consistent and manageable administration and simplified, less error-prone security.

    Improved DevOps User Experience

    By replacing the need for the user to tediously set up separate sessions for each DevOps service they need to use, a client-side DevOps service catalog enables all DevOps services to be accessed with a single click. This service catalog approach is more convenient for DevOps users and provides a form of DevOps governance. It does this by encouraging DevOps teams to select choices that are available in the catalog instead of creating new choices that result in expensive DevOps tool sprawl.

    Simplified DevOps Management

    Management of remote DevOps users is simplified by consolidating access for all DevOps users and services under a single unified service manager and connector. The need to manage each user and service with different teams, each with their own processes, is unified and streamlined when the management requirements for DevOps users and services are consolidated under a common zero-trust remote access platform.

    In addition, this approach makes it much easier to implement more adaptive policies across the breadth of users and services.

    With a zero-trust remote access platform, onboarding new DevOps users and groups is accomplished within a single session—not separate sessions for each onboarding requirement.

    Simplified and Less Error-Prone Security

    Consolidating access to DevOps services under a common zero-trust remote access platform with unified services and services connectors enables simplified and less error-prone security controls, improved security monitoring and policy management. Audit logs of access are reported consistently for all services. Monitoring and changing access rules can be supported for individuals or groups when adjusting a policy. Trust-based access controls can be implemented consistently. Granular policies ensure access is predicated on appropriate device trust score thresholds being met. Rather than a single check prior to granting access, these production services policies continuously assess the security of the users and devices accessing the services.

    Transforming to a Zero-Trust Remote Access platform for DevOps

    Transformations of all types, and especially those for DevOps, are made more certain by following a
    seven-step transformation process, described in my book Engineering DevOps. This process serves as a framework for implementing the zero-trust remote access platform.

    The first two steps, vision and team alignment, involve getting the leaders, key influencers and implementers of an organization to recognize and establish actionable goals for the implementation of the zero-trust remote access platform.

    The third step, assessment, requires taking inventory of the current state of DevOps users, DevOps services and policies that need to be supported by the new platform.

    The fourth step, road map, requires determining the plan for implementation. Typically, it makes sense to start with one application. Start with a set of DevOps users and DevOps services needed for a single application or pipeline which can serve as a model to drive adoption to other applications as the solution is proved and accepted.

    The fifth step, realize, is the step in which the zero-trust remote access platform is installed and set up for the initial model application or pipeline. Banyan Security explains how an example tool vendor helps to simplify this step.

    Capabilities to look in for in zero-trust remote access tools include:

    • Deploys in minutes, with no integration requirements on any existing DevOps services or infrastructure.
    • No need to set up VPNs, open inbound firewall ports or manage DNS.
    • Use existing DevOps user devices without diminishing security.
    • DevOps service catalog provides users visibility and one-click access to DevOps services.
    • Support for bundled services, favorites, and autorun capabilities.

    In step six, operationalize, the procedures for commissioning and using the zero-trust remote access platform are proven, benefits are measured and playbooks are hardened for the organization.

    In step seven, expansion, the zero-trust remote access platform deployment is expanded to other DevOps applications pipelines, DevOps users and DevOps services across the enterprise.

    What This Means

    Traditional remote access configurations are not well suited for DevOps administrators or users given the dynamic nature of services, team members, and environments. A zero-trust remote access platform addresses the need for an improved DevOps admin and user experience, simplified access management to DevOps services and simpler, less error-prone security practices and monitoring.

    I want to express my appreciation for the time spent with the Banyan Security team, who has pioneered many of the concepts outlined in this blog and contributed valuable insight.

  • MongoDB’s Atlas Turns Five

    MongoDB’s Atlas Turns Five

    In June 2021, Andrew Davidson, VP of cloud products at MongoDB, talked with Alan Shimel about MongoDB and the fifth anniversary of launching Atlas, the company’s database-as-a-service offering. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hi, everyone. Welcome to another segment here on TechStrong TV. Our guest for this segment is Andrew Davidson. Andrew, welcome to TechStrong TV.

    Andrew Davidson: Thanks, Alan. Good to be here.

    Shimel: It’s great to have you on. Andrew, I purposely didn’t say a lot about – I just said Andrew Davidson. I didn’t give your company, your title, or anything. I’m gonna let you do that, if you don’t mind.

    Davidson: Well, thank you very much. Yeah, so I’m Andrew Davidson. I’m VP of cloud products here at MongoDB. I’ve been here nearly nine years. I’m a Silicon Valley native originally, but I moved to New York City and found this amazing opportunity here. MongoDB, for those who don’t know, is actually headquartered in New York City. And it’s been an amazing journey since that time, just seeing this incredible explosive growth out there over this time.

    Shimel: Absolutely. Y’know, if you couldn’t tell from my funny French accent, I’m from New York originally. So I got into tech around 1995, 1996. And at the time, I think the mayor of New York was Mayor David Dinkins, and he had started a project that they were calling Silicon Alley. Right?

    Davidson: There you go.

    Shimel: It was downtown. And I actually had an office – first company I sold – on John Street, 55 John Street. But it was shortly after that – eh, shortly; it was probably seven or eight years after that at least, I bet, that Mongo started in that Silicon Alley, New York kind of cauldron of tech stuff.

    Davidson: That’s exactly right.

    Shimel: Yeah. Oh, I remember. I was in New York then. And it was a point of pride, actually, right? I mean, it wasn’t Oracle. We didn’t wanna be Oracle, right? It was the new guys, the new sequel guys, and they made a name for themselves and did well, right? And so I’m glad to hear you made that move from Silicon Valley –

    Davidson: Totally.

    Shimel: – to New York, and it’s a pretty cool thing. Of course that, as I said, was 15, 17 years ago, right? We’re here to celebrate a birthday/anniversary today, too, and that’s the – If I’m wrong, Andrew, correct me. It’s the fifth anniversary of Atlas from MongoDB, right?

    Davidson: That’s exactly right. We launched MongoDB Atlas, which is our global cloud database service, five years ago this month, and we’re just so excited. We’ve come so far. We’ve reached the psychological milestone this same month of 51 percent of our company revenue growing more than 70 percent year over year. We all know that this is the future of the platform. This is the foundation on which we can deliver really the world’s preeminent application data platform. And the value –

    Compared to where we were, y’know, when you mentioned when MongoDB was coming out of Silicon Alley so many years ago, it’s just a completely different universe today. At that time when MondoDB was first created, I think it was largely about timing. There was this combination of factors, giving developers this document model that was totally native for them, and also democratizing a distributed system right at the time in which cloud was democratizing commodity hardware.

    That combination led MongoDB to explode. But this idea of self-managing databases that we realized six, seven years ago, that was gonna go away. People are gonna move up a whole level of abstraction. It’s gonna be all declarative. An end-point in the cloud you can read and write from, and build wonderful applications – that’s what MongoDB Atlas was all about. And five years in, over 25,000 customers, over 100,000 developers signing up every month, it’s just unbelievable.

    Shimel: It really is. Y’know, I mean, look. Again, having been there, the original attraction with MongoDB was “no SQL,” right? It was a no sequel database. Everybody was using SQL scripts, and whether you were using MySQL or MS SQL, it was – And then the idea of no SQL was really huge. But why was it huge? I think you hit it, Andrew. Number one, it was easier for developers to do what they wanted to do, how they wanted to do it. Number two, it was just lighter and easier and more fungible, if you will, especially as we were moving to cloud in 2005 and 2006, right?

    Cloud burst on the scene. And it lent itself. It lent itself to multi-nodes and all of these things much better than relational SQL database.

    Davidson: Totally.

    Shimel: But of course Atlas comes in as a service.

    Davidson: Absolutely.

    Shimel: And I think that – it’s more than just a service. A database is a service, or data is a service. But fundamentally I think that is the next leap forward, right? We went from like 2001: An Odyssey, right? Someone _____ to throw a rock, and that was a big leap forward. But it was the next leap forward with fire, that defined it.

    Davidson: That’s right. The obelisk, I suppose you could say.

    Shimel: Right, the obelisk, no, totally.

    Davidson: ‘Cause I mean, like you were saying a second ago, why is it so important for developers to have a data model that’s so native for them? Well, it’s because every company today has that incredible sense of urgency that they must be come software companies. In every vertical, every part of the world, everyone’s either fighting to keep what they’ve got or being challenged by upstarts. And you can’t buy this off the shelf any longer.

    You have to bring that DNA in house and really reflect your company’s unique value propositions and users and internal logistics and all of the above for software, and data is the heart and soul of software. It’s always been the hardest part of, frankly, building software. We change how we build software. We layer in microservice as next-gen frameworks, et cetera. But if the data model hasn’t kept up, and if the data model continues to be this sort of tabular model that goes back to the ’70s, a time in which storage was the key bottleneck in computing because it was expensive to have storage then –

    We flash forward to today. The bottleneck is actually our technical people’s ability to understand and build that software. And so MongoDB flips this whole thing on its head and allows those people to be kind of these artisans of the business today, unlocking their ability to really make those businesses competitive. And that’s why I think the strategic value of this is rising. And then when you deliver it in a service, you get so far away from this kind of plumbing of dealing with infrastructure management, operating systems –

    Who wants to be talking about that stuff? It’s non-differentiating, right? You have to move to your custom software, and you have to be able to utilize the best-in-class capabilities. Best in class database as a service globally on the Big Three public cloud, like MongoDB Atlas. Use that with best-in-class other capabilities, and really weave together your unique business, your unique company. That’s what’s happening out there.

    Shimel: Agreed. You said something earlier, too, that wasn’t lost on me, and I wanna make sure it wasn’t lost on the audience. Here on the first anniversary of MongoDB Atlas, it now accounts for more than 50 percent of revenue for the company, which means it’s the dominant revenue-maker for the company. And how long are you working on the Atlas project now, Andrew?

    Davidson: Since the beginning. I mean, really five, six years on Atlas, but at MongoDB almost nine.

    Shimel: Yep. So I guess the question is, and be honest –

    Davidson: Yeah.

    Shimel: – don’t fudge it – did you imagine five years ago that this would be the dominant revenue source for Mongo? Or did you always think it was?

    Davidson: That’s a great question. I think part of me thought, “Y’know, it’s gonna be so hard to get to the point where you can be trusted to power the back end of these mission-critical applications all over the world. This is gonna be such a massive mountain to climb!” I think I had doubts at times, but on the flip side I knew: this is the future of databases. The only way we’re really gonna get to that next level, the only way we truly can disrupt this massive database market, is if we nail it with this service.

    So we knew, and I think we had pretty solid buy-in at every level of the company, that we had to make Atlas successful. In the early days, y’know, as is always difficult, we were kind of a start-up in the company, a whole new go-to-market model, largely self-service led, credit card customers coming in, long tail. We weren’t ready yet to go out to the enterprises on year one. And kind of earning that right, getting battle tested, getting all the security controls, the regulatory capabilities, the sort of the reference wins.

    Y’know, those early customers like 7-11, and Liberty Mutual, and NBCUniversal. Doing great big things on the platform, really showing that you could do it at scale, you could do it safely and securely. And just validating the value prop that we always knew was gonna be there – it just got easier and easier. The flywheel starts moving, and you started feeling like, “Y’know, we really have a shot, here.” And we started doing more and more deals – SMB, corporate, kind of mid-market segment.

    And then probably year three, we started really going big in the enterprise, and you just kinda knew, “It’s gonna happen. We’re gonna do this.” The growth rate was so high. And now, boom. Yeah, you get to that point. The 50 percent chasm is crossed, growing twice as fast as the traditional software, and it’s like, “What a feeling!” I talked to so many customers, even, who are transitioning from kind of being open-source software companies to SAS companies.

    It is a very hard DNA shift to go through. You go from really just writing software that other people run on their own, to being responsible for the business of your customer. And it’s a whole different trust dynamic that’s really important.

    Shimel: Absolutely. Look, congratulations to you and to the whole team with that. It’s an accomplishment, for sure, right? ‘Cause it’s easy to go from zero to one; it’s easy to go from one to two. Two to four is harder. Four to eight is harder. Eight to 16 is yet harder. When you’re talking about 50 percent of the revenue of a company like Mongo, it’s not a zero to one, right? Five years ago, Mongo was already – I guess it was public. Was it public five – ? I don’t know. How long – ?

    Davidson: I think we went public more – no, I think it was more like three and a half years ago, if I’m not mistaken.

    Shimel: It was still a sizeable amount of revenue, right? It wasn’t just _____, y’know –

    [Crosstalk]

    Davidson: Oh, yeah, absolutely. Yeah, yeah, totally. Yeah, yeah.

    Shimel: So that is a mountain to climb. All right. I’m gonna ask you – We’re running low on time. I got a few other things. I’m gonna ask you to put on your visionary goggles now.

    Davidson: Sure.

    Shimel: Here we are, Andrew, talking to Alan five years from now. I hope not. I hope I’m somewhere in Maui or something. But five years from now we’re talking, celebrating the tenth year of Atlas. It’s now 80 percent of Mongo’s revenue, unless something new came up to disrupt it – who knows?

    Davidson: Totally.

    Shimel: But what does Atlas look like five years from now?

    Davidson: Yeah, look. I mean, the whole philosophy of our platform in many ways is it’s fundamentally about user experience. It’s about making it possible for these application developers and operators and enterprises and start-ups, everyone in between – make it easier for them to build modern applications on a modern application data platform. And what we think makes us really unique is, it all starts with this document data model. The document data model is very much the superset data model.

    You can express key value inside a document. That’s just, y’know, a document with a single index. You can express relational inside a document; it’s essentially a flat document. Y’know, spatial, graph – it’s all expressible in this unified interface. So you can do all these data models and all these use cases, which makes it very widely applicable, very multimodal. But then the important step beyond that is to drive multiple workloads behind the scenes.

    The workloads are kind of how you store the data behind the scenes, the algorithms you use to analyze it. Our philosophy is, behind that same unified, elegant interface, you should be able to express all of the wide array of workloads that power modern applications – operational, transactional, the most mission-critical applications; search, which is about human-powered experiences; mobile experiences on iOS and Android devices, synchronizing data back up and down from the cloud to the mobile device –

    real-time analytics; data-like use cases, with object storage economics. All of that should be accessible at your fingertips through this superset data model. And when we think about kind of wrapping all of that up, continuing to deliver it at scale, secure, highly available, highly scalable, multi-cloud service on the Big Three public cloud, we’re just gonna keep taking this vision to the next level. Be laser focused on the user and on delivering what they need to build the next-generation applications of tomorrow.

    Shimel: I love it, man. Good stuff. Andrew, we’re about out of time. For people who wanna get more information on MongoDB Atlas, where do they go?

    Davidson: Well, you can absolutely go to mongodb.com, but you should also check out our upcoming developer conference, mongodb.live, on July 13. Look forward to seeing you there.

    Shimel: Is that virtual only?

    Davidson: Virtual. Absolutely. Virtual conference this year. Next year I’m hopeful, very hopeful, we’ll be back with the real deal, what we used to call MongoDB World, in New York City.

    Shimel: Absolutely. I’ve been there, been there more than a few times.

    Davidson: There you go.

    Shimel: I’m looking forward to it.

    Davidson: Absolutely.

    Shimel: Y’know, I’m gonna be in New York that week of July 13th. I wish you guys were doing it in person. But –

    Davidson: Well –

    Shimel: Next year. We’ll wait.

    Davidson: Yeah, yeah. Look forward to seeing you _____.

    [Crosstalk]

    Shimel: Andrew, congrat – Absolutely. Andrew, congratulations on your fifth anniversary with Atlas, and great work. It’s something to be proud of, man.

    Davidson: Thank you, Alan.

    Shimel: It’s good stuff. Big stuff.

    Davidson: My final comment is, this community’s growing like crazy. Like I said, 100,000 people sign up for Atlas every month. You should sign up today if you haven’t experienced a free forever sandbox cluster, build your Hello World application. We’ve got courses for you to learn from, documentation up the wazoo, because this is big tent community. Thank you, Alan.

    Shimel: Absolutely. Talk to you soon, Andrew. A pleasure. Andrew Davidson, MongoDB. Fifth year anniversary of Atlas – check it out. We’re gonna take a break here on TechStrong TV, and we’re gonna be right back with another guest.

    [End of Audio]

  • DevOps Dozen² Awards 2021 Nominations Now Open

    DevOps Dozen² Awards 2021 Nominations Now Open

    The DevOps Dozen² Awards are back and open for nominations. This past year has been quite a journey and we are very proud of the DevOps community in their ability to pivot, innovate, adapt and think ahead in these challenging times. Some outstanding leaders and vendors have worked nonstop to reach their goals and achieve the highest level of success. We are thrilled to celebrate their hard work and achievements.

    The DevOps Dozen² Awards honor the most dedicated and inspiring thought leaders and innovators who have made significant contributions to the community. For the second year, we have expanded our awards program to include two different DevOps Dozen sections: DevOps Dozen Tools and Services Awards and the DevOps Dozen Community Awards.

    There are 12 awards for each section:

    • DevOps Dozen Tools and Services Awards — Recognizing the companies that develop and deliver outstanding solutions to empower developers, DevOps and IT operations teams.
    • DevOps Dozen Community Awards — Honoring the leaders who have made a positive impact in the DevOps community.

    Nominations are made by the audience. Anyone can nominate a tool or service, although there is a $250 entry fee for the Tools and Services Awards nominations. We implemented this fee last year to cut down on spam and superfluous nominations. However, there is no fee for Community Awards nominations. Please note that commercial tools and services are not eligible for the Community Awards and will not make it through to the finals.

    Finalists will be selected and winners will be chosen from among the finalists. The finalists will be determined by general public voting (weighted for 40% of the final total) and our judges’ selections (weighted for 60% of the final total).

    The last day to submit your nominations is October 22. To vote, follow the steps outlined on the DevOps Dozen² website.

    Who Are the DevOps Dozen² Judges?

    The following DevOps experts make up the DevOps Dozen² Awards 2021 panel of judges, and will review the submissions made by the public and choose the winners:

    • Alan Shimel, founder, CEO and editor-in-chief at MediaOps
    • Jayne Groll, co-founder and CEO at the DevOps Institute
    • Mitch Ashley, founder and CEO at Accelerated Strategies Group
    • John Willis, senior director of the Global Transformation Office at Red Hat
    • Helen Beal, chief ambassador at DevOps Institute and ambassador at Continuous Delivery Foundation

    The 2021 DevOps Dozen² Categories

    DevOps Dozen Tools and Services Awards

    • Best End-to-End DevOps Tool/Service

    Consolidation in the DevOps space has led to a greater selection of platforms offering end-to-end solutions. This award honors the platform with the most diverse and robust solution for DevOps teams.

    • Best DevOps Repo/GitOps Tool/Service

    Git has led to GitOps and it has become an integral part of the DevOps toolbox. This award is presented to the most outstanding Repo/Git/GitOps tool.

    • Best CI/CD Tool

    This award recognizes the best CI/CD tool that helps teams to deliver quality code better.

    • Best Value Stream Management Tool

    Value stream management has come into its own as an important tool for measuring the business value of DevOps and application development. This award recognizes the value stream management tool that most effectively helps visualize the value stream, track metrics and measure improvement.

    • Best Observability Solution

    This award recognizes the best observability solution for observing and monitoring to understand the performance of individual components and systems and entire applications.

    • Best DevSecOps Solution

    This award honors the best DevSecOps solution, which enables security to be included earlier and continuously throughout the SDLC.

    • Best Testing Service/Tool

    Testing is a mainstay in the DevOps toolchain. This award recognizes the best testing tool for ensuring the quality of code.

    • Best Kubernetes Platform/Service

    The adoption of containers has paved the way for an entire solutions ecosystem supporting and enhancing the container technology. Kubernetes is perhaps the most widely recognized and utilized tool in the space. There are many platforms and services that offer Kubernetes-based solutions. This award honors the best Kubernetes platform/service available.

    • Best Cloud-Native Security Solution/Service

    The cloud-native movement has taken the IT world by storm due to the depth and breadth of the solutions available and the benefits of building applications and services specifically for cloud-native environments. This award recognizes the best tools, solutions and services considered cloud-native.

    • Best DevOps for Mainframe Solution
      Mainframes are far from being the dinosaur of the IT world, and a variety of solutions are available for enabling DevOps practices in mainframe environments and hybrid environments. This award recognizes the best of them.
    • Best DevOps for DataOps/Database Solution
      Databases often have been left out of the DevOps conversation, but that is changing. The whole concept of DataOps is gaining greater traction. This award recognizes the best solution in the database for DevOps and DataOps categories.
    • Best New DevOps Tool/Service Provider
      This award recognizes the best new service provider or tool that has brought innovation to the DevOps space in the past year (must be less than 24 months old).

    DevOps Dozen Community Awards

    • Best DevOps Industry Implementation
      This award honors organizations that have successfully adopted and implemented DevOps principles and practices.
    • Best DevOps Survey/Analysis/Research
      This award recognizes research that has significantly and positively impacted the DevOps community.
    • Best DevOps-Related Video Series (video)
      This category highlights the most entertaining, educational and inspirational DevOps video series—those with the most engaging and highest-quality content.
    • Best DevOps-Related Audio Podcast Series
      Which is your favorite DevOps podcast from this year? This category celebrates the many great DevOps podcasts sparking some interesting discussions on a multitude of topics from CI/CD and testing to DevSecOps, Kubernetes, containers and more.
    • Best DevOps Book/eBook of the Year
      Each year sees a plethora of well-crafted DevOps-related books and ebooks. This category highlights the most popular and best read of the year.
    • Top DevOps Evangelist
      This category is one of our favorites. There are so many great evangelists who spread the DevOps gospel and we want to know who does it best. Nominees can work within the DevOps space or outside of it.
    • Best DevOps Transformation (non-vendor)
      In a year in which digital transformation became a must-have for survival, we want to know which organizations stood out in their efforts to transform their business through DevOps.
    • Best DevOps Virtual Event of the Year
      COVID-19 has changed the game when it comes to hosting events. In 2021, virtual events remain the norm, reaching a global audience while everyone stays safe at home. Which DevOps virtual event stands out from the others?
    • Most Innovative DevOps Open Source Project
      Open source projects are meant to promote innovation and increase efficiency, velocity and quality. While there are many great open source projects out there, the best ones are those that create a community of people who work on and with the technology and support each other.
    • DevOps Executive of the Year (non-vendor) This category celebrates excellence among DevOps leaders at the C-suite (or equivalent) levels.
    • Best DevOps Presentation of the Year
      This category recognizes the best DevOps-themed presentation from the many (virtual) conferences during the year.
    • Best staging-devopsy.kinsta.cloud Article of the Year
      staging-devopsy.kinsta.cloud publishes multiple new articles every day. Which was the best article from 2021? Let us know so we can recognize the author.

    All the solutions nominated to the Tools and Services Awards will automatically be registered into the DevOps Tools Guide authored by MediaOps and Accelerated Strategies Group. This initiative is our effort to create a comprehensive listing of tools and tools vendors to help end users better understand the DevOps market landscape.

    Choosing a winner is difficult when there are so many talented and inspiring leaders doing an incredible job to empower and support our community. Although not everyone can win an award, being nominated says a lot about each and every one of you. We greatly appreciate your dedication and service to the DevOps community.

    For more information, please visit the DevOps Dozen² website. If you have any questions regarding entry process, awards, timing or any technical issues regarding the website, please contact us at DD@devops.com.

    Alan Shimel

    CEO, MediaOps

  • Choosing the Right Metrics for DevOps Adoption

    Choosing the Right Metrics for DevOps Adoption

    DevOps adoption has skyrocketed in recent years. Its impact on traditional development platforms has long been well-documented, but in more recent years it has started to influence low-code platforms, too. In its recent survey on the state of Salesforce DevOps, Gearset found that 69% of teams are already using source control and another 20% plan to start this year. Additionally, 45% of companies have implemented CI/CD, and that number is set to increase by 33% this year. However, for high-performing developer teams to recognize the benefits of DevOps and strive for further DevOps adoption, they must use the right KPIs.

    While it can be tempting to take a ‘big bang’ approach to DevOps adoption, teams see more success when they take it one step at a time, with each stage building on the last.

    That said, to experience the full ROI of DevOps adoption, it’s still critical to see the journey through to the end. It’s not uncommon for teams who begin the process of DevOps adoption to stop halfway through or, worse still, lose motivation and halt the process entirely. DevOps adoption is a process full of technical and cultural change, and one of the most common causes of its failure is an emphasis on the technical at the expense of the cultural.

    The best way to tackle this is to encourage teams to take a product mindset and apply it to DevOps adoption. Simply put, rather than tasking your teams with “adopting CI” for instance, they should be asked to solve a specific business problem. For example, “When we finish work on a story, it takes weeks for it to get released!” It sounds obvious, but focusing teams around business impact rather than on individual tasks makes sure that there’s a direct correlation between the work that’s happening and the desired business outcome. This is the crux of adopting a DevOps mindset, rather than a purely technical and perfunctory approach to DevOps adoption.

    One of the key things a team can do to drive this type of change—and to avoid common causes of failure—is to use the right metrics at each stage of their DevOps journey.

    There are a number of well-recognized metrics for measuring DevOps success, including:

    • Deployment time
    • Change failure rate
    • Release cadence
    • Lead time
    • Recovery time

    These metrics serve two purposes. They’re well-documented and benchmarked indicators of performance that can help teams focus on their biggest problem areas. And they’re measurable outcomes that prove the business benefits of DevOps, such as agility, improved collaboration, higher quality systems and resilience, not to mention significant time and cost savings and efficiency.

    Choosing the Right Metrics

    Teams must choose the right metrics at the right time to identify their opportunities for improvement and to measure the impact of each stage of DevOps adoption. The right metric empowers a team to solve their most pressing challenges, and to demonstrate the value of their work to their leadership.

    Here’s how the benefits of each stage of DevOps maturity should be measured: 

    Stage of DevOps maturity

    Most relevant metric(s)

    Choosing your release tools

    Deployment time

    Adopting version control

    Change failure rate

    Recovery time

    Automating testing

    Change failure rate

    Automating deployments (CI/CD)

    Release cadence

    Lead time

    Integrating backup into DevOps tools and process

    Recovery time

    Let’s expand on each stage and the appropriate KPI.

    Choosing Your Release Tools

    This is more relevant to low-code platforms, but still broadly applies to the wider tech world. Even in the most mature of development processes, there will be manual steps. Getting changes into version control, reviewing changes, resolving conflicts, triggering releases—each of these is a manual step, and the effort involved in each of these manual steps is heavily dictated by the tools you use.

    Finding the right tool for each stage of your development and release process can therefore have a massive impact. The right deployment tool, for instance, can cut down deployment time by as much as 90%. This step alone increases efficiency and ultimately saves companies vast amounts of time and money. In extreme examples, teams that save so much time by picking up a couple of new tools to patch up their manual processes can be tempted to stop there. This is why teams need to look at other metrics as they proceed to adopt more DevOps processes.

    Adopting Version Control

    For most teams, a world without version control is unthinkable, having built their development and release processes around it a decade or more ago. For others, particularly in the low-code space where it’s yet to reach ubiquity, it can feel like an unnecessary burden. The introduction of version control is an extra step in the releases process and another level of complexity, with new tools and practices to learn. But version control is the foundation of an automated DevOps workflow. This step allows for more team collaboration and visibility into that collaboration, with code reviews and a detailed change history. Version control also allows teams to deal with merge conflicts early, rather than in the middle of a release. 

    After adopting version control, teams will see a reduction in their change failure rate due to code reviews and their recovery times will be shorter as version control offers rollback and a quasi-backup of the code and config captured by their version control system. But the real benefits of version control are in the DevOps processes it unlocks. 

    Automating Testing  

    It goes without saying that the purpose of testing is to improve the quality of releases. It does this in a few ways:

    • Unit testing – Exercising individual methods and functions in isolation generally results in more maintainable code, which has positive benefits for developer productivity and even things like handling merge conflicts.
    • Static code analysis – While this is not testing in the strictest sense, automatically verifying that code adheres to a set of best practices similarly improves code maintainability.
    • Integration testing – This type of testing ensures that combinations of classes interact and generate the expected results when combined together. This brings another level of validation that changes being made are likely correct.
    • End-to-end testing – UI testing is an example of this; exercising the system in the way a consumer would and verifying that the results are deterministic and correct. This also includes regression testing for key workflows and sometimes even acceptance testing.

    The more of these testing approaches a team uses, the more confidence they’ll have in their changes and the less human verification and intervention will be required. As teams’ DevOps processes mature, it’s often the human element that becomes the biggest bottleneck, so confidence in deploying changes is very valuable.

    When teams introduce more testing and test automation to their release pipeline, the right metric to watch is change failure rate—the proportion of releases that include a bug or error. The immediate benefit of higher-quality code translates to savings in the long term as less time is spent finding and fixing bugs or reworking code.

    Automating Deployments (CI/CD)

    If choosing the right deployment tool significantly reduces deployment times, automating deployments with a CI/CD workflow eliminates the time it would usually take to run those deployments manually. However, deployment times aren’t the key metric for measuring the success of CI/CD implementation. The most important metrics to pay attention to here are release cadence and lead times, which are dramatically improved thanks to painless, automated deployments. 

    With automated deployments, teams can increase their release cadence; rather than releasing huge batches of changes once a month, they might begin to release smaller packages every week. Ultimately, the goal is to have a steady stream of incremental improvements being released on-demand, and usually multiple times per day. Accelerated release cadences then result in reduced lead times—the period between work being finished and finally released to production. This is beneficial for developers and their end users as more frequent releases create more opportunities to act on user feedback earlier in the process. 

    Integrating Backup Into DevOps Tools and Process

    Recovery times are a key metric for DevOps success, as robust DevOps processes will improve the speed at which teams can restore after an incident. For even better resilience and faster recovery times, teams should integrate backup into their DevOps tools and processes.

    Restoring from a backup is comparable to a deployment, and this means that restore processes also can harness the power of DevOps so they feel like a familiar process—not something unusual that teams struggle to execute at the point when it matters most. It’s also important to make it as easy as possible to back up on demand just before a risky release.

    Downtime and data loss are massive costs to any business, so improving recovery times is a huge benefit of a fully mature DevOps process.

    See the Benefits of Maturing your DevOps Process

    When teams pay attention to the right metrics, they understand the benefit of each DevOps process individually and they are motivated to keep maturing their DevOps processes as a whole. It’s all well and good to take the pain out of deployments and releases, but high-performing DevOps teams effectively make deployments an asset for releasing more often and getting feedback earlier. As a result, they are better equipped to deliver more value to their companies—sooner.