devopsy.kinsta.cloud

Category: Features

  • Survey Reveals Slight Decline in Level of SRE Toil

    Survey Reveals Slight Decline in Level of SRE Toil

    The amount of routine toil that site reliability engineers (SREs) perform declined slightly in the last year even though IT environments in general are becoming more complex to manage.

    An annual survey of 300 SREs conducted by Catchpoint, a provider of an IT monitoring platform, in collaboration with VMware and the DevOps Institute suggests that the amount of toil—defined as low-level manual tasks—declined 15% in the last year.

    Only 22% of respondents claim to be scientifically measuring toil, so, to a degree, the survey results are apocryphal. Overall, the survey, published this week, finds SREs are, not surprisingly, spending the bulk of their time on responding to incidents and outages, followed by participating in postmortem analysis and on-call rotations. The primary sources of toil cited in the survey are too much technical debt, lack of alignment of priorities and goals, lack of appreciation of business value, lack of training and support and lack of collaboration.

    In terms of automation adoption, the most common use cases cited are release management, infrastructure management and application management. The tools most commonly employed by SREs are used to monitor infrastructure, networks and application performance. Adoption of artificial intelligence (AI) tools to manage IT operations (AIOps) remains low. The survey also finds respondents are roughly split evenly between centralized (42%) and decentralized (38%) approaches to managing IT. Another 20% said they have adopted a hybrid approach. Lack of visibility across the stack (53%) was the most cited cloud application monitoring challenge.

    The survey also finds only half of respondents continually refine their service level objectives (SLOs).

    Leo Vasiliou, director of product marketing for Catchpoint, said it’s clear that SREs are becoming more proactive in terms of preventing and containing the impact of IT incidents. The challenge they face is lack of visibility and context as those IT environments become more complex. Complexity is increasing, in part, because of the rise of cloud-native computing platforms running microservices-based applications that have lots of dependencies.

    Less clear right now is the percentage of IT environments managed by SREs today. In theory, a single SRE can do the same amount of work as multiple IT administrators by automating processes using various DevOps tools rather than relying on traditional graphical tools. However, SREs are hard to find and retain. It’s also not always apparent to what level of automation needs to be attained to qualify to be an SRE or, for that matter, what certifications may be required. Interest in becoming an SRE is rising, in part, because they typically command higher salaries.

    In the meantime, it’s clear organizations will need to find ways to automate the management of IT to a much greater extent. Most organizations cannot afford to hire a small army of IT professionals to manage IT environments that become more complex with each passing day. Everything from DevOps best practices and next-generation observability tools that promise to provide more context to AI platforms will all be part of the mix. The challenge is finding a way to implement those tools before IT management spins further out of control.

  • Grafana Labs Acquires k6 to Add Open Source Load Testing Tool

    Grafana Labs Acquires k6 to Add Open Source Load Testing Tool

    During its online GrafanaCONline 2021 conference today, Grafana Labs revealed it has acquired k6, a provider of an open source load testing tool.

    Raj Dutt, Grafana Labs CEO, said load testing will complement the observability platform Grafana Labs currently provides based on open source Prometheus software. Most of the output of any load testing processes are typically evaluated using a platform that analyzes metrics, he noted.

    The k6 platform has been gaining traction among developers that require access to a tool that makes it simpler to dynamically scale load testing up and down as required versus having to guess how much infrastructure might be required to test an application workload, said Dutt. That capability not only makes it simpler to integrate testing within a DevOps workflow, Dutt added, but also serves to reduce testing costs.

    In general, Dutt noted testing is shifting further left as developers assume more responsibility for quality assurance. The challenge is finding a way to enable developers to automatically incorporate testing within a continuous integration (CI) process that allows them to easily observe how synthetic tests are executing, added Dutt.

    There’s no doubt developers are running more tests before promoting workloads into a production environment as part of an effort to reduce the number of issues that might be encountered when an application is deployed in a production environment. In many cases, the support calls that arise now go directly to developers who now have a vested interest in reducing the volume of those calls.

    The issue that developers are contending with is as they embrace microservices, the dependencies that exist across multiple applications makes it more challenging to successfully deploy those applications. Grafana Labs has been making a case for a cloud platform that makes it simpler to centrally view data collected from instances of Prometheus distributed across multiple application development environments. Prometheus, now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) that oversees the development of Kubernetes, is now being deployed more widely by IT teams to observe legacy monolithic applications alongside emerging microservices-based applications.

    It’s not clear the degree to which organizations are also employing dedicated application testers. In many cases, those testers will surface issues that developers overlooked (or simply chose to ignore) in the face of tight application delivery deadlines.

    In the longer term, however, it’s also apparent artificial intelligence (AI) will be playing a larger role in application testing. Someone will still need to review those tests, but many more rote tasks will increasingly be automated.

    One way or another, the total cost of testing is declining, thanks in part to increased reliance on open source testing tools that, in many cases, developers are simply downloading themselves. Those tools are reducing much of the licensing friction and cost restrictions that developers might otherwise encounter.

    In fact, the easier it becomes to test applications, the better overall application quality will become in the months and years ahead. At at time when organizations have never been more dependent on software, that potential improvement to the overall state of application quality can’t arrive soon enough.

  • PagerDuty Allies with JFrog to Modernize IT Incident Management

    PagerDuty Allies with JFrog to Modernize IT Incident Management

    PagerDuty has integrated its IT incident management platform with the continuous integration/continuous delivery (CI/CD) platform from JFrog as part of an effort to streamline troubleshooting of application environments.

    Steve Gross, senior director of strategic business development at PagerDuty, said the overall goal is to make it easier for IT operations teams and developers to collaboratively discover the root cause of issues by, for example, being able to identify builds within a JFrog pipeline that might be having a negative impact on a production environment.

    At the same time, IT teams employing PagerDuty can now also receive notification from JFrog Xray, a tool that discovers both vulnerabilities in open source software and license compliance issues.

    Organizations of all sizes are attempting to minimize the impact of an IT incident by providing deeper insights into how applications were constructed. The goal is to reduce the amount of time IT teams currently spend looking for the root cause of a problem.

    PagerDuty JFrog

    Ideally, IT teams would discover those issue before they impact end users. The challenge they face is it can take weeks to discover the root cause of an issue that takes a developer a few hours, at most, to fix. Armed with insights from the CI/CD platform, Gross said it becomes easier for IT operations teams to proactively pinpoint the source of an issue in a way that provides the developer with enough insight to act.

    That is critical because, more often than not, it’s the last build of application that was deployed in a production environment that is usually the source of an issue, especially when that IT environment was operating normally before that build was promoted into a production environment.

    The data collected by PagerDuty from various DevOps platforms is fed into the PagerDuty tools via a Change Events application programming interface (API). Over time PagerDuty will also be able to apply machine learning algorithms and other forms of artificial intelligence (AI) to identify issues long before they reach a meaningful level of disruption, noted Gross.

    In general, there’s a movement to modernize IT incident management in a way that aligns with DevOps best practices as part of an effort to identify issues before an application is actually deployed. The hope is that those efforts will reduce the number of “war room” meetings that need to be convened to determine the root cause of a performance or security issue after an application has been deployed.

    It may be a while before IT incident management processes are modernized to that level. However, as IT environments become more complex—in part because of the number of microservices-based applications with multiple dependencies that are now being deployed—it’s apparent existing approaches to IT incident management don’t allow IT teams to respond fast enough to an issue. In fact, that’s more challenging than ever now that many of the members of an IT team are working from home more often.

    The pressure to modernize IT incident management increases in almost direct proportion to IT teams’ stress levels. The challenge now is to modernize those processes before the members of an IT team are too burned out to appreciate the effort.

  • WSO2 Applies AI to API Management

    WSO2 Applies AI to API Management

    WSO2 today unfurled a Choreo cloud platform through which DevOps teams can create and manage application programming interfaces (APIs) more efficiently by leveraging machine learning algorithms and other forms of artificial intelligence (AI).

    Eric Newcomer, WSO2 CTO, said the integration platform-as-a-service (iPaaS) eliminates all the tasks associated with setting up a platform for and managing services based on APIs.

    Choreo, available in beta, employs AI to learn historical activities and performance behaviors in order to anticipate the needs of a developer. As developers build an API, the platform will provide performance feedback, identify anomalies, map data and even complete code, said Newcomer.

    The Choreo platform also comes with built-in observability tools for monitoring API usage and troubleshooting APIs, added Newcomer.

    In addition, Choreo provides access to the open source Ballerina programming language the company developed to enable developers to create APIs using both low-code and procedural code as they see fit, noted Newcomer. The low-code diagram that developers create generates source code that developers can then run wherever they want, said Newcomer. Developers can close the entire repository Choreo provides, Newcomer added.

    Developers can also trigger low-code integration logic to control hundreds of software-as-a-service (SaaS) APIs via pre-built connectors and templates provided by WSO2 or ones they create themselves.

    WSO2 is also making it possible to deploy APIs via a single click in Kubernetes environments, which eliminates the need to manage cumbersome YAML files. That capability is based on technology that WSO2 gained via the acquisition of Performer that the company revealed today.

    Finally, WSO2 is making available an API marketplace through which organizations can share APIs, event streams, data sources and templates.

    With the rise of microservices-based applications, API management has become a lot more challenging. Each additional microservice adds an API that needs to be managed and maintained. As more APIs are employed, it becomes increasingly difficult for DevOps team to keep track of the dependencies that exist between all those APIs without the aid of machine learning algorithms.

    It’s not likely machine learning algorithms will replace the need for DevOps professionals anytime soon. However, it’s becoming apparent that many of the manual tasks that DevOps teams routinely perform today are becoming automated by machine learning algorithms. In other cases. DevOps teams are gaining new capabilities that would have either been impossible for them to do on their own or would simply have taken too much time to complete.

    Of course, it takes time for any AI platform to learn the DevOps environment. IT teams need to invest a significant amount of time training an AI model to recognize relevant issues in much the same way they might train any new member of a DevOps team. The only difference is, once a machine learning algorithm learns something, they never forget it. Nor do they take a day off or announce one day they are leaving the company because they got a better offer somewhere else.

    It may take a while before DevOps teams are able to strike the right balance between man and machine, but one thing that is certain is that AI in DevOps environments is here to stay.

  • Harness Employs ML to Streamline DevOps Workflows

    Harness Employs ML to Streamline DevOps Workflows

    At the online {Unscripted} 2021 conference, Harness today announced an update to its namesake DevOps platform that includes support for feature flags that expose new capabilities to a select number of users for testing purposes along with the ability to prioritize the running of those tests based on the likelihood an application is likely to fail them.

    In addition, Harness is adding a unified pipeline capability that enables DevOps teams to streamline the management of multiple tools that make up a workflow and has updated its cloud cost management module to enable DevOps teams to automatically stop idle workloads. That capability is based on technology the company gained with its recent acquisition of Lightwing.

    Steve Burton, chief marketing officer for Harness, said Harness is now employing machine learning algorithms to identify which tests an application is most likely to fail. That test intelligence module enables DevOps teams to run those tests first versus testing an application only to discover close to the end of that effort that an application will need to be updated and then retested. The amount of time spent on testing is then sharply reduced, noted Burton.

    Overall, Harness is reducing the amount of time and effort spent maintaining DevOps pipeline and workflows, said Burton.

    The cost of maintaining a DevOps platform will naturally vary as the overall environment becomes more complex. It may not be clear how much time a DevOps team is spending on testing, but the faster that process becomes the more likely an application will be thoroughly tested before it is deployed in a production environment. Fixing applications after they are deployed in a production environment is, of course, considerably more expensive.

    At the same time, as the number of applications being built simultaneously increases, the amount of cloud resources being consumed also increases. Developers, however, don’t typically pay close attention to what workloads are consuming which cloud resources, which can result in an unpleasant surprise when the monthly bill from the cloud service provider comes due.

    In general, Burton says machine learning algorithms and other forms of artificial intelligence (AI) will soon become table stakes for any provider of a DevOps platform. The expectation is the platform will routinely employ AI to streamline processes and reduce total costs, noted Burton.

    Many of the manual tasks that DevOps teams regularly perform to maintain a DevOps platform will increasingly become automated as usage of machine learning algorithms becomes more pervasive. It’s not clear to what degree organizations may abandon a legacy DevOps platform to take advantage of those capabilities. However, over time it will become apparent that some organizations are spending a lot more time building and deploying applications than others as the next generation of DevOps platforms, infused with machine learning algorithms, are installed.

    In the meantime, DevOps teams might want to make a list of the manual tasks they perform today as part of an effort to determine how much time they are wasting that might otherwise be spent on tasks that are more valuable to the organization.

  • Akamai Adds Service to Optimize API Traffic

    Akamai Adds Service to Optimize API Traffic

    Akamai today launched an API Acceleration service specifically designed to accelerate application programming interface (API) calls using special purpose hardware, reserved capacity and prioritized routing.

    At the same time, the company is also making available a globally distributed key-value store dubbed EdgeKV that enables stateful applications to be deployed on its EdgeWorker nodes.

    Finally, Akamai is also making available free tiers of services that provide access to a combined 60 million serverless EdgeWorker events per month with a limit of up to 30 million EdgeWorker events per tier. The two tiers are made up of a basic compute service for applications requiring lower CPU and memory consumption and a dynamic compute service for those applications demanding additional resources.

    Josh Johnson, an enterprise architect for Akamai, said Akamai is expanding its offering at a time when many organizations are starting to deploy microservices-based applications across an extended enterprise using serverless EdgeWorker nodes deployed at the network edge. EdgeKV provides access to a low latency data store that also enables those edge computing applications to process data closer to the point where it is being created and consumed.

    In general, Akamai reported that, in 2020, its platforms processed more than 300 trillion API requests, a 53% year-over-year increase. Much of the increased activity is being driven by distributed applications that are deployed directly on the Akamai CDN, rather than being deployed in a local data center to take advantage of a global network of data centers that allow IT organizations to take advantage of caching. In effect, the CDN becomes the target platform when an application developed using DevOps best practices is being deployed. The rise of edge computing has increased the number of use cases where DevOps teams are relying on CDNs to deploy applications.

    Naturally, competition among providers of CDNs has increased considerably as the number of applications deployed at the edge continues to increase. There may even come a day when there are more applications deployed at the network edge than there are in the cloud as more organization deploy applications that need to process and analyze data in near-real time as part of a larger digital business transformation initiative.

    Akamai, of course, as the provider of the largest global CDN, is betting it will be able to leverage the size of its CDN to convince developers to deploy applications on its platforms rather than smaller rivals.

    Regardless of the approach to edge computing, the applications being deployed will be more latency sensitive than ever. Each IT organization will need to decide to what degree they want to count on infrastructure to optimize API calls those applications make before they time out or need to be redirected to another microservice. One way or another, the laws of physics still apply. No edge computing application is an island. It depends on a complex web of infrastructure ranging from routers and switches to servers running back end services in the cloud. The challenge is finding a way to optimize all those interactions in a way that developers never have to be concerned about.

  • Enterprises Face Growing Technical Debt

    Enterprises Face Growing Technical Debt

    Technologists are always espousing new, trendy development solutions. More robust frameworks, increased delivery, better integration. But rarely do these proponents consider the long-term side effects of introducing new technologies. As a result, technical debt is an all-to-common occurrence in most companies.

    Nearly a third of IT budgets are dedicated to addressing technical debt. Devoting so much effort to maintaining legacy code leaves fewer resources to support the status quo, let alone develop new solutions. In fact, a recent study found that 69% of IT leaders identify technical debt as a significant threat to their companies’ ability to innovate.

    “The Growing Threat of Technical Debt,” a report from OutSystems, surveyed 500 IT leaders about this conundrum. Below, we’ll explore the top causes of technical debt and consider ways to prevent it from getting out of control.

    What is Technical Debt?

    Technical debt seems counterintuitive. Isn’t technology supposed to help organizations become more productive? Why would it be a burden? Well, technical debt often arises from hasty decisions taken in the short term that have long-term consequences. It’s also often the result of a company juggling many competing technologies, some of which have become outdated.

    Technical debt can carry a hefty price tag. But this debt isn’t so much measured in the cost of hosting legacy technology or running broken code, but in the hours lost maintaining and patching it. The report found that, on average, businesses devote 28% of their IT budgets to addressing technical debt. This number increases to 40% within large enterprises.

    Common Causes

    There is not one single factor causing technical debt. Many issues within an organization contribute to the problem, including reliance on stale technology, pressure to deliver in the short term, constant change, developer churn and incorrect architectural decisions.

    The top cause of technical debt is too many development languages and frameworks, cited by 52% of respondents as a big or critical problem. Legacy technology can weigh an IT department down. But, it’s not necessarily only old tech getting in the way—it could be that IT is supporting too many competing agendas.

    The second top cause is a high turnover rate within developer teams. In today’s competitive climate, quality engineers are in short supply, and hiring can be challenging. It is thus difficult to attract and nourish steady engineering talent. If developers frequently leave for greener pastures, especially before documenting their procedures, best practices can easily be lost and efficient use of technology is stunted.

    The study found that other common causes include accepting known defects to meet deadlines, using outdated programming languages and frameworks and dealing with challenges in serving new markets or segments. At times, teams release software with known defects simply to meet deadlines. The sheer size of a large organization can lead to increased technical debt, and not addressing it compounds the issue further.

    In terms of industries, the report found the health care and social assistance category hit hardest. In this sector, 35% of IT budgets go toward addressing technical debt, on average. The next most-burdened group is the financial category, which was at 29% according to the report.

    The Costs of Technical Debt

    What are the costs of technical debt? There’s a high price to maintain, reduced hours for innovation and a detrimental effect on overall software performance. Team dynamics could also incur adverse reactions from sustaining technical debt.

    Technical debt requires an disproportionately high amount of time to maintain. On average, engineers spend 33% of their time dealing with technical debt, found Stripe’s “The Developer Coefficient” study. This equates to about 13.5 hours of an average work week.

    The more debt you take on, the smaller the budget left for running status quo operations and building new capabilities. Supporting technical debt not only has financial implications but could stifle future prospects; in fact, 69% of respondents said technical debt limits their capacity to innovate. In today’s acceleration economy, not setting aside resources for digital innovation, could break a business.

    “The combination of old code along with the new generation of mobile apps, stack applications and SaaS sprawl are robbing organizations of resources, time and the ability to innovate,” said Paulo Rosado, CEO, and Founder of OutSystems.

    Technical debt could also stunt performance. According to the survey, 61% of respondents said it causes a significant drag on their company’s performance. Stale projects could interfere with streamlining customer experiences and digital transformation goals.

    Lastly, technical debt could also negatively affect morale. Few engineers take pride in repeating inefficient processes or working with obsolete tech.

    Alleviating Technical Debt: Be Intentional

    Similar to financial debt, technical debt comes with compounding interest. This interest could grow exponentially if left unchecked. So, what steps can organizations take to reduce their technical debt?

    To help alleviate the problem, the report recommends reversing the top two causes of technical debt by stemming turnover in development teams and limiting the number of new programming languages and frameworks you adopt.

    Other methods involve taking stock of your holdings to understand the presence and impact of legacy technologies. Next, rethink and redirect your strategy from simply maintaining legacy dependencies to addressing them and replacing them with modern styles.

    “A lot of bad tech debt comes from building too much and getting stuck spending more time on maintenance and bug fixes than expected,” said Jon Thornton on the Squarespace blog. ”The key is to be intentional about what you invest time in and aware of the costs you’re taking on.”

    Of course, enterprise IT must take on some form of technical debt to function—it’s futile to get rid of it entirely. Therefore, as Thornton advises, be intentional about it and stay aware of the costs you take on. When adopting new technologies, it’s best to consider maintenance implications and plan with longevity in mind.

    For more insights, download “The Growing Threat of Technical Debt” report in full here.

  • Broadcom Adds VSM Platform to DevOps Portfolio

    Broadcom Adds VSM Platform to DevOps Portfolio

    Broadcom Inc. today added a dedicated value stream management (VSM) application to its portfolio of DevOps offerings as part of an effort to make it simpler to prioritize software development initiatives.

    Serge Lucio, vice president and general manager for the enterprise software division of Broadcom, said that while the company has previously provided VSM capabilities within its tools this addition to its ValueOps portfolio marks the first time Broadcom is making available a complete VSM application.

    The offering is unique because it combines the IT investment capabilities found in the Clarity project management software provided by Broadcom with the Rally platform for managing agile software development processes, added Lucio.

    In comparison, other VSM offerings don’t provide the same level of depth in terms of connecting software development projects to actual financial costs, noted Lucio. The Broadcom platform, for example, in addition to surfacing dependencies between software projects and potential developer capacity issues, also enables IT organizations to forecast the impact changes to funding will have on software development projects, said Lucio.

    In fact, Lucio noted that tracking code as it is developed is relatively easy. Surfacing the financial implications of software development projects requires an additional level of analytics not found in rival VSM offerings, he said.

    VSM, as a concept, traces its roots to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a process that is automated as much as possible using DevOps best practices, an appreciation for the value of monitoring the impact of missed software development deadlines on the business is growing as organizations realize how dependent they now are on software to achieve business goals. A VSM platform aggregates technical metrics gathered from DevOps workflows and then maps them to key performance indicators (KPIs) defined by business leaders. Once those KPIs are defined it then become possible to apply advanced analytics to assess the financial impact changes to software development schedule will have on the business.

    In general, Lucio said organizations are evolving their approach to software development as they embrace digital business transformation. Rather than managing individual software development projects in isolation, organizations are now managing software development in much the same way they manage product development. As a result, a collection of related software development projects are now being managed in a way that better aligns to the strategic business initiatives, he said.

    It’s not clear at what rate organizations are adopting VSM platforms, but as the number of stakeholders in an organization that have a vested interest in software development increase there is a need for tools that enables those individuals to more easily track processes in a way that doesn’t depend on them mastering the project management application employed by the software development team.

    Regardless of approach, the appreciation of software development in organizations has never been greater. That same increased appreciation, naturally, is creating a level of anxiety among business leaders that need to make decisions that impact the entire organization based on processes that today they often have limited visibility into much less actual understanding.

  • Majority of Orgs Lack Visibility Into Container Vulnerabilities

    Majority of Orgs Lack Visibility Into Container Vulnerabilities

    Today’s blend of third-party application dependencies and polyglot software development often makes assessing risk difficult. With many new cloud-native deployment models, it can be tricky to discover potential vulnerabilities. These threats take the form of insecure default settings in Kubernetes, over-permissive states, CVEs that threaten container integrity, and other vulnerable conditions.

    Plugging gaps throughout the cloud-native strata is now crucial to avoid exposing data and breaking privacy regulations. Yet, gaining visibility into these holdings is challenging, and traditional application security practices may not cut it within a cloud-native context.

    A new 2021 CISO Report released by Dynatrace, “Precise, automatic risk and impact assessment is key for DevSecOps,” demonstrates increased false positives and a general lack of real-time container runtime vulnerability scanning among enterprise IT departments worldwide. Of the 700 CISOs surveyed, most report that microservices, containers and Kubernetes have caused security blind spots across their organizations.

    Below, we’ll cover the major takeaways from the study to see why new cloud-native development models are leaving security gaps. We’ll consider how CISOs can increase security throughout the cloud-native IT stack while still reaping the rewards of container-based delivery models.

    Cloud-Native Security Blindspots

    Adopting new container-based technologies may introduce multiple nuanced security implications. Of the tech leaders surveyed, 89% report that microservices, containers and Kubernetes have created new vulnerabilities within their organizations.

    Engineers are shipping code to maintain release velocity and to meet the demand for digital innovation. In the process, 28% of CISOs say application teams sometimes bypass vulnerability scans to speed up software delivery. Due to these realities, it’s no surprise that 71% of CISOs admit they are not fully confident code is free of vulnerabilities before going live in production.

    As some teams bypass security pre-production, it follows that more aren’t applying holistic security scanning during production. As a result, nearly all organizations (97%) lack real-time visibility into runtime vulnerabilities, found the report.

    Adding to the number of cloud-native blindspots is information overload. The report calculated that, on average, an organization receives a staggering 2,169 new alerts of potential application security vulnerabilities each month. Out of this high volume of alerts, 77% of CISOs say they are mostly false positives and not actual exposures.

    Due to minimal testing and a high number of false positives, organizations are likely to leave many vulnerabilities unpatched. To make matters worse, developers, pressed for time, may lack the bandwidth to resolve known issues.

    Faster Delivery, Harder Detection

    Much of the setbacks in vulnerability detection may lie in a general shift toward new ways of working and faster delivery cycles. For example, 63% of CISOs reported that DevOps and agile methodologies are making it harder to detect and manage vulnerabilities.

    In addition, 74% of CISOs say traditional security controls such as vulnerability scanners no longer fit today’s cloud-native world, and 77% of CISOs agree that automation could help. This could involve replacing manual deployment, configuration and management with more automated approaches. Others agree that security-as-code is required to ensure high container security best practices.

    Another result of more frequent delivery is increased over-reporting. Of the total security vulnerability alerts received per month, CISOs report that only 42% of these alerts require action. More rapid release cycles could thus exacerbate already crowded vulnerability detection systems.

    Who Owns Vulnerability Management?

    Only 3% of organizations have real-time visibility into runtime vulnerabilities in containerized production environments, the study found. In reality, vulnerability scanning in production is only happening once a month or less within 68% of organizations.

    To compensate for this gap, most CISOs believe the onus is not on the security team but the application and DevOps teams to manage and respond to vulnerabilities—85% of CISOs believe these groups should hold responsibility for vulnerability management. These findings come to light as other stakeholders advocate for increased full-cycle developer control and encourage the DevOps mindset across roles.

    Handing more control to developers sounds good, yet, 64% of respondents say developers don’t always have time to resolve vulnerabilities before code goes into production. As a result, over one-quarter of application teams bypass vulnerability scanning entirely. Often, engineering teams may not frequently sync with security groups, and DevSecOps principles are not yet pervasive throughout all organizations.

    The report also highlighted the fact that existing security tools are often ineffective; 69% of CISOs say security tools slow down DevOps because they only focus on one state of the software delivery cycle.

    Cloud Use Requires Security Repositioning

    As cloud architectures rise in prominence, organizations are adopting cloud-native tools like microservices, containers and Kubernetes. There is also the chance of multi-tool conditions further complicating the vulnerability scanning process. With more systems to protect than ever before, teams may have to reposition their approach to vulnerability detection.

    “The increased use of cloud-native architectures has fundamentally broken traditional approaches to application security,” said Bernd Greifeneder, founder and chief technology officer at Dynatrace. “This research confirms what we’ve long anticipated: manual vulnerability scans and impact assessments are no longer able to keep up with the pace of change in today’s dynamic cloud environments and rapid innovation cycles.”

    The Global CISO report, “Precise, automatic risk and impact assessment is key for DevSecOps,” from Dynatrace, queried 700 chief information security officers (CISOs) on their monitoring practices concerning vulnerabilities. To review the report’s full findings, you can download it here.

  • Cortex Taps GitLab to Help DevOps Teams Manage Microservices

    Cortex Taps GitLab to Help DevOps Teams Manage Microservices

    Cortex, a provider of a platform for tracking ownership of microservices, this week announced its platform can now import services from the GitLab continuous integration/continuous delivery (CI/CD) platform.

    Anish Dhar, Cortex CEO, said the company’s platform is now integrated with more than 30 tools that are regularly employed by DevOps teams, including offerings from GitLab, Datadog, Sonarqube, Snyk and PagerDuty, as well as open source platforms such as the Kubernetes container orchestration engine and the Istio service mesh.

    Designed for site reliability engineers (SREs) and other DevOps professionals, the Cortex platform eliminates the need to rely on spreadsheets to manually track ownership of microservices. Instead, Cortex imports data residing within the tool employed by developers to surface who within an organization is responsible for maintaining which microservices.

    In addition, a Cortex dashboard enables DevOps teams to see which developers are on-call in the event of an unexpected incident, the latency rate microservices are experiencing and which vulnerabilities have yet to be remediated.

    Grades can also be assigned to specific microservices based on metrics that are associated with a specific microservice. That approach allows DevOps teams to apply gamification techniques using a scorecard to encourage developers to continuously improve their microservices, noted Dhar. That approach will also make it apparent to other developers which microservices running in a production environment can be most reliably employed, added Dhar.

    Cortex

    At the core of the platform is Cortex Query Language (CQL), a domain-specific language that allows DevOps teams to define granular rules that can be applied to, for example, on-call rotations, security vulnerabilities, package versions, service level objectives (SLOs) and the overall health of the microservice. Engineers can employ code in the form of YAML files to set reliability standards across teams and types of services through direct integrations with a variety of tools. In effect, Cortex provides a reliability-as-code platform, said Dhar.

    As responsibility for applications shifts further left, each development team is being held accountable for the life cycle of any microservice or application they create. The challenge enterprise DevOps teams are encountering is that when there are hundreds, even thousands, of microservices, it’s difficult to determine who on the development team is responsible for a specific microservice. Rather than trying to keep track of the relationship between development teams and microservices using a spreadsheet, Cortex is making a case for a tool that automates that discovery and tracking process.

    Most organizations today are embracing microservices to build and deploy more flexible applications at varying rates. However, it’s only a matter of time before they find themselves trying to navigate a web of interdependencies between microservices that can’t be managed using spreadsheets. DevOps teams, of course, might be inclined to use their skills to create their own tool for tracking microservices. However, given all the tasks at hand, maintaining a custom platform for discovering and tracking ownership of microservices is likely something better done by a vendor willing to maintain and support a purpose-built tool.