devopsy.kinsta.cloud

Category: Features

  • THE UPSKILLING IT 2022 SURVEY IS NOW OPEN

    THE UPSKILLING IT 2022 SURVEY IS NOW OPEN

    IT SKILLS IN FOCUS

    By Eveline Oehrlich, DevOps Institute

    According to McKinsey, nine out of 10 global executives and leaders are saying that their organizations are facing a skill gap or expect to develop additional skill gaps in the next three to five years. During the past few years, IT organizations, in particular, have already been facing skill gaps. The desire to accelerate technical innovations and digital transformation only makes it harder to identify and narrow current and future skill gaps. IDC predicts 75% of organizations will have a comprehensive digital experience implementation roadmap by 2023, up from 27% today. While 2023 is still a few years away, it is essential that IT organizations prepare for what skills are necessary, how to manage their talent supply and look at the underlying skills of people that must support this digital journey.

    DevOps Institute research team and sponsors, Palo Alto Network, Cycloid, and The Linux Foundation, are excited to announce the launch of the Upskilling IT 2022 Survey. The survey takes approximately 25 minutes to complete, and we’d love to hear from you. Your answers will allow us to better understand which IT skills are essential for the future, ensuring that organizations are able to accelerate their digital journey.

    The Upskilling IT 2022 Survey, by DevOps Institute with its yearly sponsors, is the only and longest running research of its kind. The results provide an unbiased view into what skills are essential across a variety of IT and other skill domains.

    Like the past three research reports, our goal following this year’s survey is to share a detailed analysis to help various leaders and roles, in order to help them determine what skills they should hire, retrain or upskill for, following the publication of the Upskilling IT 2022 Report in the first quarter of 2022.

    Don’t let IT Skill gaps be a competitive liability for today or in the future

    The survey is open for everyone, regardless of the size of your organization, or your organization’s industry. This year we have expanded the focus beyond DevOps and are homing in on cognitive and human skills.

    Some of the key topics we look to deep dive into this year include:

    1. Exploring where the biggest skill gaps currently exist and within which roles, such as leaders, developers or operations.
    2. How skill gaps are identified across the IT industry.
    3. How upskilling is done, funded and executed.

    While each person has their own unique experience, expertise, examples of execution or outcomes and various tolerances for exploration, for the fourth year, we are setting out to explore what the must-have skills are within different skill domains. This year we are focusing on the skills needed within modern IT organizations today and in the future.

    There are a variety of roles that are involved in recruiting, hiring or working within IT organizations. We are setting out to highlight and understand which must-have, nice-to-have and optional skills are essential within key skill domains. The skill domains include Automation, Human skills, Technical skills, Functional skills and knowledge, Process skills and framework knowledge, Business skills and leadership skills. We are targeting the community of IT leaders, developers, practitioners, team leaders, consultants, human resources and other individuals who are familiar with modern IT best practices, such as DevOps. We are targeting all industry verticals and all company sizes. Our survey questions are developed with input from a variety of team members and experts, and our goal is to achieve a sample size of 4,000 individual responses across North America, Europe, Asia Pacific and Latin America.

    Help us shape the future of IT and DevOps and make your voice heard by completing the survey now.

    The survey will remain open until January 31, 2022. We look forward to hearing from you.

    Take the survey now:  https://www.surveymonkey.com/r/Upskilling2022Blog

  • Can Web 3.0 Solve the Linkrot Crisis?

    Can Web 3.0 Solve the Linkrot Crisis?

    Data on the web is more ephemeral than you realize. A recent examination of linkrot and content drift by Harvard Law School found that as time progresses, web-based content is becoming more and more lost. By analyzing half a million links within New York Times articles, 6% of deep links from 2018 were found to be inaccessible, and 72% of links from 1998 were completely dead.

    The rotting web could have severe consequences that affect society’s collective understanding. Consider links used to substantiate pivotal arguments in the course of law. Studies now show that 49% of hyperlinks in Supreme Court decisions no longer function. The linkrot situation undermines humanity’s shared intelligence, which the Internet once promised.

    So much of the content on the web is outdated, inaccurate or has changed its URL destination, a problem known as content drift. Therefore, band-aids like the Wayback Machine internet archive have risen as a steward of the historical web archives. However, some proponents in the industry argue we need a more modern, decentralized, immutable reference for this historical data. You may have guessed where this article is heading—blockchain.

    I recently met with Jonathan Victor, Protocol Labs, to see how Web 3.0 and blockchain might be used to solve the linkrot endemic. According to Victor, smart contracts that reference canonical URLs could help create a more resilient web. This would, in effect, require a peer-to-peer model with shared ownership and incentive models to sustain content longevity.

    The State of Linkrot

    The longer data sits, the higher the likelihood of losing track of it. Forgotten databases and rising data storage costs can easily lead to whole networks of websites and user data being accidentally (or intentionally) destroyed. Putting so much faith in private companies to preserve data indefinitely is not viable, explained Victor.

    Public data isn’t really as public as you think it is. And older, user-generated content is often the first domino to fall. For example, a massive amount of media on MySpace was deleted in a botched server migration in 2015. In 2021, Yahoo Answers similarly erased 16 years of user-generated content in its shutdown. Surprisingly, users have little ownership or control of their data on forums and social media. A ban on Twitter, for example, could result in inactive links within posts.

    When an article points to a website, this imbues an implicit dependency on an external organization to keep the domain live, said Victor. The second dependency is on the domain owner to keep content unchanged. “If we can talk about content and how to reference it in a different way, maybe we can create references that are much more resilient,” suggested Victor.

    How Web 3.0 Can Help

    One way to solve the linkrot issue is to create a ‘fingerprint’ for web resources. This could be a canonical reference to specific pieces of content. Organizations would store and retrieve content based on a hash of that contract itself, Victor explained. Such a system would likely require an incentive-based, non-exploitative, decentralized network where web users own their data and control who profits from it.

    Some have coined this concept Web 3.0. Victor describes Web 3.0 as a broad classification of distributed technologies and tools that enable a peer-to-peer internet underpinned by blockchain.

    For example, one open source project spearheading progress on this front is IPFS, the InterPlanetary File System. IPFS is a peer-to-peer hypermedia protocol that uses blockchain to store cryptographic hashes. The project is “designed to preserve and grow humanity’s knowledge by making the web upgradeable, resilient and more open.” With IPFS, a client requests content using the hash and retrieves content. IPFS is based on Filecoin, a permissionless storage network.

    Benefits

    A decentralized nature fits the original goal of the open web, allowing creators to own and share content horizontally. If you can decouple data storage and retrieval from a specific location, it gives you an impressive ability to rearchitect modern communication, said Victor. This could have a number of benefits:

    • Redundancy: First off, a major benefit is the redundancy of data. Distributed nodes assure data is globally available and temporally accessible. Resources are in multiple locations, ensuring better global availability and temporal persistence.
    • Incentives: An incentive-based decentralized network could use block rewards to subsidize costs, helping fund storage initiatives. Building on the blockchain can also ease payment acceptance aspects — great for donation-based data hosting groups.
    • Efficiency: By using smart contracts, you can programmatically handle storage requests. “Blockchain gives you higher-level primitives to run this stuff automatically,” said Victor. This helps tie on-chain activities to real-world storage, Victor added.
    • Low-cost: It can be cheaper to store content on distributed networks than a typical cloud provider. Impressively, Victor estimated it would cost 1/1000 of the cost of Amazon. A distributed environment could also bring speed gains; similar to torrenting, seeding from distributed sources increases speed in orders of magnitude, said Victor.
    • Communal ownership: Such a model could spur more communal ownership for some content. This could benefit public-good assets that don’t have a clear owner. According to Victor, this aspect especially benefits universities and open source data initiatives that rely on public support to function.

    A Compelling Problem

    Constructing a new peer-to-peer Internet obviously has significant barriers. Namely, a decentralized structure requires a large group effort, and this community action may be difficult to encourage, let alone coordinate. It will also require consolidation around open standards and protocols, as many different decentralized projects crowd the scene. Shifting pre-existing architectures to this new style could also introduce roadblocks.

    “A lot of content on the internet becomes a public good,” says Victor. Yet, perpetual access to this content is fickle, even for well-established online communities. Some research has found the average lifespan of a website to only be 100 days. Hosting fees or accidental failures are often root causes for the loss of data.

    The fragility of the web is an issue that will take not only innovative development effort, but a radically new mindset to tackle. “It’s a really compelling problem,” added Victor. Using blockchain-based smart contracts to store canonical references for content is one proposed solution. But Web 3.0 is in a primitive stage, and to progress, it will take significant community action.

    Doing so in a way that is sustainable will be the trick. Open standards and blockchain-based protocols could allow the technical means for such a network to flourish. And a cryptocurrency backing could help incentivize participation and provide a means of funding. This decentralized non-ephemeral storage could help enable perpetual storage for the web’s most precious resources.

  • LogDNA Previews Streaming Module for Observability Platform

    LogDNA Previews Streaming Module for Observability Platform

    LogDNA is making available on a limited basis the ability to process streaming data to its observability platform as part of an effort to give DevOps teams more control over log data.

    Tucker Callaway, LogDNA CEO, said the data ingestion pipeline that LogDNA already provides can ingest, parse and normalize massive amounts of structured and unstructured log data. LogDNA Streaming adds the ability to automatically send log data to any application or analysis tool.

    That capability also helps reduce storage costs by limiting the number of copies of log data that might otherwise be created, he added.

    LogDNA also expects that DevOps teams will also be able to analyze data in flight as part of an effort to make it simpler to surface issues even before log data is stored, noted Callaway.

    While there are multiple streaming data platforms available, Callaway said LogDNA opted to build one on its own to meet the requirements of an observability platform. Ultimately, the goal is to shift observability left at the data level to provide more granular insights in real-time, he said.

    That capability will also lay the foundation for a wide range of autonomous processes that would be driven by the observability data collected via LogDNA, added Callaway.

    LogDNA

    Observability has always been a core tenet of any DevOps best practice. Most DevOps teams typically focus on some form of continuous monitoring to more proactively manage application environments. However, it can still take days, sometimes weeks, to discover the root cause of an issue. Monitoring tools are designed to consume predefined metrics to identify when a specific platform or application is performing within expectations. The metrics tracked generally focus on, for example, resource utilization.

    Observability combines metrics, logs and traces—a specialized form of logging—to instrument applications in a way that makes it simpler to troubleshot issues without having to rely solely on a limited set of metrics that have been pre-defined to monitor a specific process or function. DevOps teams can more easily employ queries to interrogate data in a way that makes it easier to discover the root cause of an issue. An observability platform correlates events in a way that makes it easier for analytics tools to identify anomalous behavior indicative of an IT issue.

    It’s now only a matter of time before providers of the platform widely employ machine learning algorithms to analyze machine data faster. There may even come a day when so-called “war room” meetings—that today need to be convened to identify the cause of an IT issue via a painstaking process of elimination—are no longer required.

    In the meantime, the percentage of applications that are instrumented in an IT environment needs to increase to achieve that goal. Fortunately, thanks to the rise of open source agent software, the cost of instrumenting applications is starting to decline. At the same time, DevOps teams should expect to see a marked increase in the volumes of incoming data, and they will need to find somewhere to store that data as well as determine the length of time it should be retained.

  • Relyance AI Shifts Compliance Left Using ML Algorithms

    Relyance AI Shifts Compliance Left Using ML Algorithms

    Relyance AI emerged from stealth this week to unveil a namesake platform for managing privacy and data governance in real-time within the context of a larger DevOps workflow.

    Fresh off raising $30 million in seed capital, Relyance AI co-CEO Leila Golchehreh said organizations can now quickly and accurately answer essential privacy questions and ensure compliance and governance by mapping requirements directly to their codebase. The platform provides transparency and visibility all the way down to the source code in real-time using machine learning algorithms, she added.

    Relyance AI co-CEO Abhi Sharma also noted most legal and data protection teams today have limited visibility into digital operations. Developers and data scientists are constantly creating and updating applications. By the time compliance teams gather the data required, it’s obsolete, said Sharma.

    The Relyance AI platform analyzes contractual requirements against the operational reality as determined by data processing in real-time. Compliance teams can then address privacy issues as they arise, added Sharma.

    At the core of the Relyance AI platform are five integrated components that first inventory assets by connecting to application programming interfaces (APIs); generate universal records of processing activities (ROPAs) by scanning code and understanding how data is being processed; share alerts when issues are detected; provide views into data life cycles to highlight data subject access request (DSAR) exceptions and extensions and address vendor life cycle management to ensure third-parties are complying with policies.

    Relyance AI

    Sharma said compliance, much like security, is shifting further left toward application development as organizations look to eliminate issues before they arise in a production environment. The Relyance AI platform is designed to be integrated with continuous integration/continuous delivery (CI/CD) platforms that are the core of modern software development life cycle processes, he added.

    Undoubtedly, as the worlds of compliance and application development collide, there will be cultural challenges similar to what is now occurring with the rest of DevSecOps best practices that require more collaboration between developers and security teams. The challenge is compliance officers tend to be even further removed from application development than their IT security counterparts.

    However, it’s now only a matter of time before compliance becomes code. Modern applications already make use of the Open Policy Agent, for example, to embed compliance rules in applications. AI platforms should make it simpler to identify compliance issues as they arise so that they can be addressed before any infraction ever occurs.

    DevOps teams, of course, have a vested interest in managing compliance as code. It’s not uncommon for DevOps teams to race to build and deploy an application only to encounter a wave of compliance issues that need to be addressed by recoding elements of the application. Not surprisingly, those compliance issues often result in application delivery deadlines being missed. Machine learning algorithms provide an alternative to the current raft of documents that compliance officers create, but not enough other members of the IT team read those, much less understand them.

  • Dell Updates AIOps Platform to Better Automate IT Ops

    Dell Updates AIOps Platform to Better Automate IT Ops

    Dell Technologies this week updated its IT operations platform infused with artificial intelligence, dubbed CloudIQ, to add support for its PowerEdge servers. In addition, Dell pledged to add support for its PowerSwitch networking hardware next month as part of an ongoing effort to extend the reach of its AIOps platform across the entire Dell EMC portfolio.

    At the same time, Dell next month also plans to employ webhooks and a REST application programming interface (API) to both integrate the CloudIQ cloud service with third-party platforms and share notifications and recommended actions via tools and platforms such as ServiceNow, Slack, Microsoft Teams, Ansible and vRealize.

    Dell has also defined an autonomous operations framework that defines the various stages of AIOps capabilities that organizations should be able to take advantage of as CloudIQ continues to evolve.

    Dell AIOps

    Drew Schulke, vice president of product management for Dell Technologies, said CloudIQ currently enables IT organizations to achieve level three of that framework. As Dell continues to update CloudIQ alongside delivering ongoing infrastructure upgrades, additional capabilities will be steadily added, noted Schulke.

    Dell is making a case for standardizing on both its infrastructure and the IT operations platform it provides. Whether acquired and managed by an internal IT team or consumed as-a-service provided by Dell, the goal is to convince IT teams to reduce their reliance on rival infrastructure platforms that are not as tightly integrated with CloudIQ. In effect, Dell is delivering continuous intelligence as an AIOps service, said Schulke.

    Of course, IT operations teams could opt to standardize on an AIOps platform that is integrated with infrastructure provided by multiple vendors. However, Dell is betting that an AIOps framework optimized for its platforms will reduce the total cost of IT in a way that IT organizations will not be able to ignore.

    Each IT organization will need to decide for themselves what path forward makes the most sense for them. However, as more AI capabilities are infused into IT operations platforms, it’s becoming clear that many of the tasks routinely performed by IT teams are becoming increasingly automated. Most organizations will need to make a decision in the months ahead about the degree to which they are comfortable waiting for their existing IT operations platform to be enhanced with AI capabilities versus acquiring a new one that might be more advanced.

    Regardless of the path forward, the level of cultural disruption AIOps will bring to IT teams will be high. DevOps teams, naturally, have always been at the forefront of IT automation. However, most of the recent advances in IT operations have generally been applied in a piecemeal fashion. Platforms such as CloudIQ are designed to be implemented on a more end-to-end basis.

    Thate level of automation will have a profound impact on everything from the number of applications an IT team can support to the roles of the individuals that make up that team. It’s not likely that AIOps will replace the need for those IT teams as much as augment them and redefines the job they are being asked to perform.

  • …And all Those Other DevOps Tools

    …And all Those Other DevOps Tools

    When we started going through the DevOps toolchain for our new project, we found a ton of bits that normally we (and most likely you) wouldn’t pay too much attention to, because they don’t matter—until they do. Then we all pay attention. That’s why we added them to the toolchain list of options before they became a problem.

    It is time to stop, take a look around, make sure you have an inventory of what tools are going into the process of making your secret sauce. The easy one is IDE. For the last little while—say, a decade—we’ve let this largely be a team or an individual decision, but the steps required to do things and the add-ons/libraries used make this less and less about individual choice and more of at least a team, often an organizational decision. We’re doing it at the project level, so functionally equivalent to team. Our Java/Spring app is done in Eclipse because most of you are doing the same for that architecture. But our new Godot project will be in the built-in Godot editor (for Godot Script) and VS Code for C#. Again, because that’s all the rage in several languages, including C#.

    Here is the thing though – if you are using VS Code, you should keep a detailed and current list of plug-ins. I’m not a fan of their whole extension installing methodology through the command palette and want to make sure everyone has the tools needed at hand. In an enterprise setting, the ROI is there to just set it up and distribute to developers what they need in a package. But this is only a real possibility if most developers are on the same platform.

    What Git Desktop client is in use? While all of them support Git command line in the same format, helping each other use the UI for different operations kind of begs for standardization. Our team doesn’t change much, so I’m not terribly worried about this particular issue. We’re officially using GitHub Desktop, but as long as I’m not doing tech support (because you have a tool that you can’t use well), I don’t care if people stick to it. You might care more about that than we do—in this regard, we’re more like a startup than an enterprise. Since they share a command line, we can afford not to care. If you, as an enterprise, are providing ready-to-code environments, that is a different story.

    A couple of years ago we would have had to worry about containers, but these days we’re okay saying Docker locally and Kubernetes for production. While the Godot app doesn’t have a server component (hence the reason we’re keeping the Java/Spring app around), the build environment will be containers because we want to be able to build wherever we need to.

    Keep rocking it. I just thought I’d drop a list of what we’re going over—there is more, of course; this bit was focused on the developer tools side of things. I’ll eventually update with the final full stack, but for now, this bit is being put on the back burner while I look at some other areas. ::waves at security peeps::

  • 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.

  • 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.

  • Google DORA Report Shows Modest DevOps Gains

    Google DORA Report Shows Modest DevOps Gains

    Google today published the annual Accelerate State of DevOps Report created by its DevOps Research and Assessment (DORA) team that finds 26% of DevOps teams surveyed can now be classified as elite performers. That compares to 20% the last time the study was conducted in 2019.

    DevOps teams, made up of a total of 32,000 IT professionals from around the globe, were evaluated based on their ability to frequently deploy, code, lead time for changes, time to restore service, change failure rates and operational performance. An elite team is expected to be able to restore service in the event of an outage in less than an hour.

    Dr. Dustin Smith, a user experience researcher for Google, said the increased rate suggests steady gains in DevOps maturity continue to be made despite all the challenges the COVID-19 pandemic presented. A full 96% of respondents said that prior to the pandemic they had not worked from home on a regular basis.

    The DORA report finds high and elite performers make up two-thirds of respondents. Elite performers were able to collectively decrease their lead time for changes when compared to previous studies. It’s also worth noting only elite performers have minimized their change failure rate. In previous years, medium and high performers were able to do the same.

    Overall, more than half of respondents (52%) report they have adopted site reliability engineering (SRE) best practices to some degree.

    Elite performers deploy code 973 times more frequently than low performers, who reported deploying less than once every six months. The normalized annual deployment numbers range from 1,460 deploys per year for the highest performers to 1.5 deploys per year for low performers. Not surprisingly, for elite performers, the lead times from commit to deploy are 6,570 times faster than low performers.

    Security practices have also improved with 60% conducting security reviews, with 58% reporting that the reviews include testing. Nearly two-thirds (63%) said they work closely with information security teams. The report finds teams with high-quality documentation were 3.8 times more likely to integrate security throughout their development process.

    Reliance on cloud platforms has also increased, with 56% of respondents indicating they employ a public cloud, a 5% increase from 2019. Only 21% of respondents reported deploying to multiple public clouds. Over a quarter (26%) of respondents did so to leverage the unique benefits of each cloud provider, followed closely by 22% that cited availability.

    Just over a third (34%) report they are using a hybrid cloud, while 29% have a private cloud. A total of 21% still don’t use a public cloud.

    The report also finds elite performers were 3.5 times more likely to have met all essential cloud characteristics defined by the National Institute for Standards and Technology (NIST). Those characteristics are defined as on-demand self-service, broad network access, resource pooling, rapid elasticity or expansion and measured service. Only 32% of respondents who said they were using cloud infrastructure agreed or strongly agreed that they met all five of the essential characteristics of cloud computing defined by NIST, an increase of 3% from 2019. Overall, usage of those characteristics of cloud computing have increased by 14% to 19%, with rapid elasticity showing the largest gain.

    The DORA report makes it clear there is still a long way to go before DevOps nirvana is more widely achieved. On the plus side, however, the number of organizations that have embraced DevOps to some degree continues to steadily increase.

  • OpsRamp Extends AI Reach to Incident Management

    OpsRamp Extends AI Reach to Incident Management

    OpsRamp today extended its IT operations platform infused with machine learning algorithms, also known as AIOps, into the realm of incident management.

    The Summer 2021 release of the company’s namesake platform adds alert predictions for preventing outages and incidents, alert enrichment policies for faster incident troubleshooting and enhancements for automatically ingesting metrics data collected from the Alibaba Cloud environment and open source Prometheus monitoring software as well as Hitachi, Poly, VMware and Dell EMC platforms.

    IT operations teams can now also visualize metric values that can increase or decrease within a fixed range using Gauge charts. IT teams can also now add alert context details to provide more relevant information. There’s also now a mobile app for both Apple iOS and Google Android devices through which IT teams can now respond to alerts and incidents.

    Finally, OpsRamp is also making available a beta release of dynamic Workflows, which enable IT team to maintain a single decision table to address specific operational scenarios.

    Sheen Khoury, chief revenue officer at OpsRamp, said the goal is to leverage artificial intelligence (AI) to increase application availability by enabling IT teams to better predict when there are indicators of an incident caused by, for example, higher volumes of seasonal traffic that could lead to an outage.

    At the same time, IT operations teams can improve overall time-to-value by leveraging the automatic monitoring tools that are embedded in the platform, he added.

    OpsRamp is betting that rather than waiting for incumbent providers of IT operations platforms to add AI capabilities, many IT teams will opt to deploy a new IT management framework altogether. Many of the manual tasks IT operations teams regularly perform today can then be automated faster, noted Khoury.

    Naturally, it takes time for machine learning algorithms to be trained, so the benefits of AIOps are not instantaneous. However, those algorithms will continuously learn the unique attributes of an IT environment in a way that makes it easier for IT teams to manage an IT environment more proactively. The algorithms provide the added benefit of making it easier for new members to join an IT operations team without having to spend months learning all the nuances that are unique to that environment.

    Each IT team will need to decide for itself the degree to which they want to rely on an AIOps platform to manage their IT environment. Initially, most IT teams will need to evaluate the recommendations made by an AI platform. However, as they gain confidence in the recommendations, they will trust the platform to automate more processes in response to events occurring in the IT environment in real-time.

    Regardless of how much faith IT teams put in AI, it has become apparent that enterprise IT environments are only going to become more complex. Many IT teams will not be able to manage some environments without the aid of an AI platform. Many IT professionals may not want to work for organizations that don’t provide some way to augment their skills using AI—the stress level would simply be too high.

    One way or another, DevOps teams that are highly committed to ruthlessly applying automation will be at the forefront of AI adoption in the enterprise.