devopsy.kinsta.cloud

Category: Features

  • Leading DevOps Transformations With AI

    Leading DevOps Transformations With AI

    In my recent article Revolutionizing the Nine Pillars of DevOps with AI-Engineered Tools, I explained that AI-engineered tools can help with automating repetitive tasks, improving decision-making with predictive insights and facilitating proactive issue resolution. AI can drive a higher level of quality, security and performance in the software life cycle. Leadership, the first of the nine pillars of DevOps, is the catalyst for a successful DevOps transformation using AI-engineered tools. It’s the guiding force that brings about the alignment of people, processes and technology in the pursuit of continuous delivery and operational excellence.

    How AI-Engineered Tools Assist DevOps Leaders

    Vision and Direction: Leaders define the vision and strategic direction for a DevOps transformation. They set expectations, define goals and align all stakeholders around a common purpose. By clearly articulating the benefits and objectives of the transformation, leaders can secure buy-in from the whole organization and guide their teams toward success. AI can provide data-driven insights to assist in strategic planning and decision-making. By analyzing historical data and current trends, AI can help leaders make informed predictions about the future and set the direction accordingly.

    Cultural Change: DevOps is not just about technology, it’s about changing organizational culture. Leaders are instrumental in driving this change. They model the collaborative, open and learning-focused culture that DevOps requires. They facilitate communication and collaboration across traditionally siloed teams and encourage a mindset of shared responsibility for product quality and customer satisfaction. AI tools can facilitate collaboration and knowledge sharing, helping to break down silos. These tools can enhance communication, support shared workspaces, and even analyze team dynamics and communication patterns to provide suggestions for improvement.

    Resource Allocation: Effective leaders ensure teams have the necessary resources, including tools, training and time to successfully adopt DevOps practices. They advocate for their teams and prioritize investments in areas that will maximize the benefits of DevOps, such as automation tools or cloud services. AI can assist in optimizing resource management. Predictive analytics can help leaders identify where investments will yield the greatest return, and automation can free up team members’ time to focus on high-value tasks.

    Risk Management: Leaders play a key role in managing the risks associated with a DevOps transformation. They set the pace of change, balancing the need for speed with the need to maintain stability and security. They make tough decisions about when and how to deploy new practices or tools and they are prepared to deal with setbacks or failures as opportunities for learning and improvement. AI can play a crucial role in identifying and mitigating risks. By predicting potential issues in the development and operations pipelines, leaders can take preventative action. AI can also improve incident management, speeding up the detection and resolution of issues.

    Continuous Improvement: The nature of DevOps is iterative and based on continuous feedback and improvement. Leaders need to instill this principle within their teams, emphasizing the importance of regular reflection, learning, and adaptation. Leaders can drive ongoing improvement and innovation in their DevOps practices by fostering an environment where experimentation is encouraged and failure is seen as a learning opportunity. AI can support continuous improvement by analyzing performance data and identifying bottlenecks or areas for improvement. AI-powered analytics can turn raw data into actionable insights, helping leaders understand the impact of their actions and make informed decisions about future changes.

    Risks of Not Leading With AI-Engineered Tools

    In an increasingly digital world, the use of AI-engineered tools is becoming standard practice in DevOps. While every organization must assess its own readiness and capacity to adopt AI, the risks of not doing so are significant and could impact competitiveness and operational efficiency.

    • Missed Efficiency Gains: AI offers substantial efficiency improvements through automation, prediction and analytics. Organizations not leveraging these benefits could find themselves outpaced by competitors that do.
    • Decreased Competitiveness: AI can enable faster and more reliable software delivery, quicker response to market changes and more efficient problem-solving. Without AI, organizations might struggle to keep up with competitors in terms of innovation and speed to market.
    • Inferior Decision Making: AI enhances decision-making by providing leaders with data-driven insights. Without these insights, leaders might make less informed decisions, potentially resulting in suboptimal outcomes.
    • Reduced Agility: AI can help organizations anticipate and quickly respond to changes. Not using AI may limit an organization’s ability to adapt quickly to new market trends or customer demands.
    • Increased Operational Costs: AI can significantly reduce operational costs by automating repetitive tasks, predicting system failures and optimizing resource usage. Without AI, organizations may face higher operational costs.

    Transformation Roadmap With AI-Engineered DevOps

    The successful integration of AI-engineered tools into DevOps is not a one-time project but a continuous journey of learning, experimenting and adapting. Leaders play a crucial role in guiding their organizations on this journey, and developing their own AI competencies is a key part of that.

    1. Education and Awareness: Begin with enhancing your understanding of AI fundamentals, its capabilities, limitations and implications. This can be done through formal training, online courses, seminars, workshops or self-study.
    2. Identify AI Opportunities: Leaders need to identify areas in their DevOps practices where AI can provide the most benefit. This might be where automation could save time, where predictive analytics could provide valuable insights or where machine learning could improve system performance.
    3. Start Small and Experiment: Begin by piloting AI tools in one or two areas. This provides an opportunity to learn about AI’s capabilities and challenges in a controlled, low-risk environment.
    4. Gather and Analyze Data: Data is crucial for AI. Leaders must ensure their organizations have systems in place to collect, clean and manage data. They also need to learn how to interpret the data and insights provided by AI tools.
    5. Build a Multidisciplinary Team: AI requires various skills, including data science, software engineering and domain expertise. Leaders should aim to build diverse teams and foster a culture of collaboration between these different skill sets.
    6. Scale and Integrate: Once they have seen success with initial pilot projects, leaders can start to scale their use of AI tools and integrate them more deeply into their DevOps practices.
    7. Continuously Learn and Adapt: As with any technology, the AI landscape is constantly evolving. Leaders need to commit to continuous learning and stay updated with the latest trends, tools and best practices.
    8. Develop Ethical and Responsible AI Practices: Leaders should ensure AI is used responsibly within their organization, considering aspects like data privacy, transparency and bias. They should create guidelines and practices for ethical AI use.

    Pitfalls and Challenges

    By being aware of potential pitfalls and planning for them in advance, leaders can increase the odds of a successful implementation of AI-engineered tools in their DevOps practices.

    Resistance to Change: Implementing AI tools often requires significant changes to workflows and practices. This can be met with resistance from team members. Effective change management practices can help overcome this resistance. Communicate the benefits of the change, provide ample training and support and involve team members in the process.

    Data Privacy and Security Concerns: AI tools often rely on access to sensitive data, which can raise privacy and security concerns. Develop and adhere to strict data management policies, ensuring compliance with all relevant privacy and security regulations. Use secure AI tools that offer robust data protection features.

    Skills Gaps: Implementing AI tools often requires skills that existing team members may not have. Invest in training for your team, hire new staff with the necessary skills or bring in consultants or external experts to help.

    High Expectations: AI is often perceived as a magic bullet that will solve all problems. This can lead to unrealistic expectations and eventual disappointment. Set realistic expectations about what AI can and cannot do. Communicate clearly that AI is a tool that can enhance efficiency and effectiveness, but it requires human oversight and cannot replace all human tasks.

    Choosing the Wrong Tools: With so many AI tools available, it’s easy to choose ones that aren’t a good fit for your organization’s needs. Carefully evaluate potential tools based on your specific needs and constraints. Look at factors like compatibility with existing systems, ease of use, scalability and vendor support.

    Lack of a Clear Strategy: Implementing AI tools without a clear strategy can lead to disjointed efforts and wasted resources. Develop a clear strategy and roadmap for your AI implementation. This should outline your goals, the steps to achieve them and how you will measure success.

    Summary

    Leadership plays a crucial role in the successful transformation and adoption of AI-engineered tools in DevOps practices. The journey involves educating themselves about AI, identifying suitable opportunities, experimenting with AI tools, gathering and analyzing data, building multidisciplinary teams, scaling AI usage and promoting ethical AI practices. However, challenges like resistance to change, data privacy and security concerns, skill gaps, high expectations and selecting the right tools can be encountered. These can be mitigated with effective change management, strict data policies, training and hiring strategies, setting realistic expectations, careful tool evaluation and a clear AI implementation strategy.

  • Survey Finds Cloud Management Strategies Shifting

    Survey Finds Cloud Management Strategies Shifting

    Even though organizations continue to consume cloud resources inefficiently, they continue to increase the amount of money allocated. These were among the findings of a global survey of 1,000 technology practitioners and decision-makers conducted by Forrester Consulting on behalf of HashiCorp.

    The survey found a full 94% of respondents reported that their organization struggled with cloud waste. Top factors contributing to avoidable cloud spending included overprovisioning resources (50%), idle or underused resources (50%) and a lack of needed skills (43%). Nevertheless, more than half of respondents (56%) said they boosted their cloud spending in the last year compared to 22% which reduced it.

    At the same time, however, 92% of respondents said they are moving toward adopting, standardizing or scaling platform teams as part of an effort to centralize the management of cloud services, but only 39% are scaling the use of platform teams throughout the organization. The survey also found, however, that organizations are addressing skills shortages by adopting a common operating model/shared automated workflows (58%), reskilling/upskilling (56%) and working with partners (43%).

    The survey also found many organizations are also committed to multi-cloud computing, with nearly three-quarters (73%) reporting this strategy is helping them reach their business goals. Another 19% said they expected this strategy to help them achieve their business goals in the next year.

    The most-cited reasons for adopting a multi-cloud strategy were reliability (51%), cost reduction (48%), security and governance (45%), digital transformation (45%) and scalability (45%). Only 10% had no choice but to go multi-cloud due to acquisitions or other issues.

    Security (88%), availability (84%) and scalability (84%) were identified most often as being important/very important multi-cloud success factors, followed closely by regulatory/compliance requirements (82%), staffing and skill levels (82%), budget (80%), visibility into cloud infrastructure (78%), automated tooling (77%) and platform teams (75%).

    The top cloud initiatives were data protection (77%), followed by secrets management and access control (both at 75%), the survey finds. The top security concerns were password/credentials/secrets leakage (50%) followed by data theft (49%), phishing (46%) and ransomware (42%).

    Overall, respondents said the biggest benefits of having a multi-cloud computing strategy were a stronger security posture (74%) and helping attract, motivate and retain skilled staffers (68%).

    Chris Van Wesep, senior director of product marketing for HashiCorp, said it’s clear organizations are purposely using multiple clouds to reduce costs by pitting one cloud service provider against another. The challenge organizations face when using that approach is they need to define a consistent set of development processes that can be used across multiple clouds to keep total costs under control.

    Organizations that embrace multi-cloud computing are also more likely to implement security best practices because of their need to consistently manage multiple cloud computing environments, he added.

    Of course, there is always going to be a great disparity between high- and low-performing organizations. The survey found that about 25% of survey respondents are high performing, with an equal number falling at the other end of the spectrum. The rest fall somewhere in between those two ends of the spectrum. The issue is that the gulf between the high and low ends of that spectrum appears to be widening as more organizations fail to muster the level of skills and expertise needed to succeed in the cloud era.

  • Cycode Leverages eBPF to Secure CI/CD Pipelines

    Cycode Leverages eBPF to Secure CI/CD Pipelines

    Cycode today added a Cimon extension to its application security platform that uses extended Berkeley Packet Filtering (eBPF) to thwart cyberattacks against continuous integration/continuous delivery (CI/CD) pipelines.

    Alex Ilgayev, head of security research for Cycode, said Cimon uses eBPF to inspect network connections, running processes and file modifications within a pipeline to learn standard behaviors. Armed with those insights, Cimon will then surface any anomaly in real-time, he added.

    DevOps teams can then craft and embed security and compliance rules within their pipelines based on the severity of the anomalies discovered, said Ilgayev.

    eBPF makes it possible to run sandbox programs at the kernel level without adversely impacting performance. In effect, eBPF bridges the boundary between kernel and user space by enabling developers to combine and apply logic across multiple subsystems that, historically, were completely independent of one another. That approach enables, for example, a security tool to scale to the point where it can identify threats at much higher levels of throughput to improve overall scale at a time when the volume of cybersecurity attacks continues to increase.

    Cycode is taking advantage of eBPF to enable DevOps teams to not only defend against known attacks involving malicious package installation, typosquatting, repojacking, dependency confusion, dependency hijacking and other types of dependency attacks but also zero-day threats, noted Ilgayev.

    Cycode provides a platform for mapping metadata and events using graph technology that makes it simpler for application development and cybersecurity to consolidate alerts generated by their DevSevOps tools. Most recently, Cycode added a Cycode Application Security Orchestration and Correlation (ASOC) module that will automatically discover all the tools that make up a DevSecOps workflow without requiring any integration effort.

    The approach enables the Cycode platform to discover, for example, dependency issues that would otherwise be missed by software composition analysis (SCA) or static application security testing tools (SAST).

    While a lot of progress has been made in terms of adopting DevSecOps best practices, many organizations are still struggling with securing their software supply chains. Most of the members of a DevOps team have limited cybersecurity expertise, so they need the help of a cybersecurity professional to determine what specific actions are required to remediate a vulnerability. Cybersecurity professionals, conversely, don’t have a lot of application development expertise.

    As the number of regulations specifically focused on application security steadily increase, every organization that builds software will soon need to embrace DevSecOps to better secure software supply chains. Unfortunately, developers have too often viewed cybersecurity as an obstacle to deployment while cybersecurity teams have historically considered developers to be a primary cause of the breaches they are expected to clean up. The first step toward bridging that divide is, of course, to realize that application developers and cybersecurity teams need to be invested in each other’s success.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    Underdog.io
    New York, New York
    DevOps Engineer
    $114,000 to $206,000

    SimplyHired.com

    Verizon
    Lone Tree, Colorado
    DevOps Engineer
    $107,000 to $226,000

    Indeed.com

    Erie Insurance
    Erie, Pennsylvania
    DevOps Solutions Architect
    $104,838 to $167, 468

    Dice.com

    Nityo Infotech Corp
    Mountain View, California
    DevOps Engineer – AWS Cloud
    $100,000 to $140,000

    CareerBuilder.com

    Boston College
    Chestnut Hill, Massachusetts
    Senior DevOps Systems Administrator
    $96,000 to $120,000

  • Snyk to Add ASPM Platform via Enso Security Acquisition

    Snyk to Add ASPM Platform via Enso Security Acquisition

    Snyk this week announced it plans to acquire Enso Security, a provider of an application security posture management (ASPM) solution that tracks events and analyzes metadata collected from DevOps and security tools.

    At the same time, Snyk revealed it has added a DeepCode AI Fix tool that creates validated fixes for code written by either humans or machines and an Insights tool that helps organizations better prioritize remediation efforts based on the risk to the business. DeepCode AI Fix extends the capabilities of a generative artificial intelligence (AI) capability based on large language models (LLMs) that Snyk gained with the acquisition of DeepCode in 2020.

    Manoj Nair, chief product officer for Snyk, said all of these initiatives represent an effort to extend the reach of Snyk’s portfolio to address a wider range of issues within the context of a larger DevSecOps workflow as well as give developers tools that enable them to write more secure code.

    The acquisition of Enso Security is expected to close this quarter. The company has been making a case for an ASPM platform that eliminates the need to manually collect cybersecurity data from the various tools and platforms that a DevOps team may be using.

    Despite innumerable cybersecurity concerns, the rate at which applications are being deployed and updated continues to accelerate. The Enso platform makes it possible for cybersecurity teams to keep pace with those projects by discovering issues before an application is deployed in a production environment.

    The challenge, of course, is that most development teams are not going to be able to address every issue before an application needs to be deployed. In addition to knowing who is developing what application code, cybersecurity teams need to also prioritize potential issues versus rather than just sharing a list of potential issues that have been discovered. Enso Security’s ASPM platform provides visibility into events so that it’s simpler for cybersecurity teams to trace issues back to individual developers or the AI platform that generated them.

    That latter issue is becoming more significant as more development teams rely on general-purpose generative AI platforms to write code, noted Nair. Those platforms are writing that code based on samples collected across the internet, many of which are deeply flawed from a cybersecurity perspective, he added.

    The Enso platform is intended to enable cybersecurity teams to have the most impact on an application development project without being forced to interrogate every developer to determine what’s occurring in any application environment. In fact, one of the reasons developers resent those conversations is they know all the relevant data has already been entered into a system—cybersecurity professionals just need to access it.

    There’s still a lot of work to be done when it comes to bridging the historic divide between cybersecurity professionals and application developers. However, the more data that can be seamlessly shared between these teams, the simpler it becomes for organizations to embrace DevSecOps best practices.

  • Technical Debt is Inevitable. Here’s How to Manage It

    Technical Debt is Inevitable. Here’s How to Manage It

    Eventually, your organization will accumulate technical debt. It doesn’t matter what programming language, software stack, computing style, host, or slick hybrid mix you use. It doesn’t matter if you’re using a waterfall or agile methodology. Ultimately, most technology becomes technical debt one day.

    “Technical debt is inevitable,” said Insight’s North American chief technology officer, Juan Orlandini. “Technical debt is like credit card debt. If you’re not smart about how you use it, your balance keeps increasing.”

    Today’s technological trends will one day fall out of favor, especially as talent moves on and older maintainers retire. And while this all might sound grim, acceptance is the first step toward change. Realizing this pattern of technical debt and accepting its inevitability may be the key to building future-proofed, evolvable software ecosystems.

    I recently chatted with Orlandini to understand some of the significant contributors to technical debt and how software maintainers can plan for and address it. Below, we’ll outline some of the major causes of technical debt and suggest methods to tackle it and prevent it from accumulating.

    Major Contributors to Technical Debt

    Enterprises face growing technical debt. A study from Outsystems found that 40% of IT budgets are devoted to addressing technical debt in large enterprises. To mitigate technical debt, we must first understand the main contributors to it. The causes of technical debt are wide and varied but can be distilled into a few common areas, said Orlandini.

    Unsupported software stacks. One major cause of technical debt is outdated or unmaintained software. Too often, a consumer will purchase a proprietary system that eventually becomes sunsetted, said Orlandini. Or, the vendor may evaporate during an acquisition or merger. When this occurs, the package goes unmaintained and leaves a mess on your hands.

    Trends in programming languages. Another obvious area is the continual evolution of programming languages. Even today’s most popular languages aren’t that future-proofed—Python replaces Perl, Go replaces Python, Rust replaces Go and so on. The same is true for frameworks. Ruby on Rails used to be in, but now Vue.js is a more hip framework.

    Aging cloud infrastructure Just because you’re in the cloud doesn’t mean you don’t have technical debt, reminds Orlandini. When early cloud adoption began, many core services we take for granted today, like authentication and authorization, weren’t offered by the cloud service providers. Some of the first-ever cloud migrations were stitched together with homegrown tooling, which may not be aging well. Or, organizations may have “lifted and shifted” legacy services into the cloud. Operators overseeing these older cloud-based environments will likely feel the pressure to refactor into more modern, cloud-native styles.

    The proliferation of microservices and APIs. Furthermore, cloud services retire features all the time. Thus, it can be challenging to keep up with these minute changes to retain backward compatibility for things like API versioning shifts. In the DevOps world, web APIs are the glue that connects our tools. But in an increasingly complex landscape, it can become easy to produce shadow IT and lose track of dependencies.

    Legacy physical infrastructure: It’s not just the software that becomes debt; the systems and hardware it runs on might also become obsolete. For example, the network itself might be full of old edge switches and wireless access points, says Orlandini. Or, an enterprise may hold onto aging on-premises servers. (This is often due to the depreciation benefits of using a capital expense accounting model as opposed to an operational expense model.)

    Other factors that could contribute to technical debt are things like rushed decision-making, skills and resource gaps and failure to implement DevSecOps.

    Ways to Tackle Technical Debt

    Technical debt is a threat to innovation, so how can we mitigate it? Well, if you don’t already do so, it’s a good idea to build technical debt into your budgeting, planning and ongoing operations, said Orlandini. “You have to manage it, expect it and be responsible with your technical stacks in the same way you are responsible with your financial stacks,” he said. Here are a few other ways to manage the debt you have and avoid accumulating more.

    Consider using AI to refactor legacy code. Generative AI could be leveraged to reactor legacy code into more modern programming languages. This could help automatically convert PEARL code, for instance, into JavaScript. Today’s large language models (LLMs) could help solve many of today’s problems. However, since they are built on a pre-existing body of work, they will use less trendy languages and might cause some technical debt in the process, cautioned Orlandini.

    Don’t over-rely on new DevOps processes as a cure-all. DevOps can accelerate the time to release features, but it does not, by its nature, eliminate technology changes, said Orlandini. Just because DevOps helps deploy an aging framework doesn’t mean it will maintain or evolve the debt. As frameworks go out of style, IT teams must continually assess their software stack.

    Remain lean whenever possible. Preventing the accumulation of unnecessary technology should be top of mind. In the DevOps world, there is a proliferation of individual services, and it’s easy to loop in a tool because it’s “the next best thing.” While sleek tools can help quickly integrate new functionality, looping in too much unnecessary tech could introduce sprawl concerns, said Orlandini. In general, he recommends keeping things as optimized as possible and carefully vetting the introduction of new technology. This includes carefully vetting new partners to ensure their business model works and that they themselves are future-proofed.

    Continually maintain updates of dependencies. Today’s software infrastructure is largely composed, at its foundation, of open source software. And if these packages aren’t mature and well-supported, you may be sitting on an unstable house of cards. It’s a good idea to continually audit your OSS use and respond to updates in a timely manner.

    Managing the Inevitable: Tech Debt

    Tech debt is like credit card debt—easy to get into and tough to get out of. And just like its financial equivalent, you shouldn’t go too far into technical debt. Thankfully, we’ve covered some best practices to keep in mind that should help spot key problem areas and reduce bloat before things get out of hand.

    As a final note, consider asking: How much stuff are you using and why? It’s become a trope, but the principle of KISS (keep it simple, stupid) bears repeating in software architecture dialogues. Because if you reduce the surface area, it will make ongoing maintenance easier and reduce the potential of cyberattacks.

    The subject of technical debt is a multi-faceted issue with many factors to consider. For related insights, you can also watch the conversation between Techstrong Group Chief Content Officer Mike Vizard and Juan Orlandini on Techstrong.tv here:

  • Report Surfaces DevOps Challenges for Mobile Applications

    Report Surfaces DevOps Challenges for Mobile Applications

    An assessment of 1,600 DevOps teams involved in building and deploying mobile applications found that 62% were adversely impacted by manual processes that slowed the rate at which these applications were deployed and updated.

    Based on the Mobile DevOps Assessment (MODAS) created by Bitrise, a provider of a continuous integration/continuous delivery (CI/CD) platform for building and deploying mobile applications, the metric measured the creation, testing, deployment, monitoring and collaboration phases of building and deploying applications.

    The survey also found (44%) of respondents reported their release approval process is mostly or entirely manual, with only 9% having fully automated application releases. Only 22% of teams said they’ve been able to complete internal release processes in less than an hour.

    The survey also found that nearly two-thirds of organizations (66%) have deployed applications that can’t be opened in two seconds or less, which is widely considered the accepted level of performance required.

    In addition, three-quarters of organizations (75%) required more than two days to address bug fixes. Only 21% of teams said that they had implemented some form of app performance monitoring to keep track of bugs, the report found.

    Daniel Balla, chief strategy officer for Bitrise, said MODAS applies many of the concepts from the DevOps Research and Assessment (DORA) metrics that Google now oversees. Those metrics, however, are not specifically designed to assess mobile application development initiatives, he noted.

    It’s not clear what percentage of applications DevOps teams are building today are deployed on mobile devices. But given the emphasis on digital business transformation initiatives, many of these applications are increasingly mission-critical to organizations. The general expectation among mobile application end users is that apps will be regularly updated with new functionality. However, if release processes are largely manual, regularly improving the user experience can become problematic. In addition to the increased likelihood that mistakes will be made, manual processes are often the reason why a vulnerability was introduced into an application environment.

    DevOps teams will also need to also consider the level of scale that will be required to support mobile app development, noted Balla. Many of the tools that developers rely on today to build applications were not necessarily designed to enable developers to build and deploy mobile applications at scale, he added.

    Finally, most enterprise applications need to run on multiple devices, so the tools used to create these applications can’t focus on applications that can only run on one platform, said Balla.

    Regardless of the approach to building and deploying mobile applications, the amount of focus on them within most organizations is high; any issues that arise are likely to be noticed by the highest echelons of an organization. That level of attention can easily put pressure on DevOps teams that frequently work on multiple projects. The challenge and the opportunity now is to create a set of DevOps workflows optimized for mobile applications that almost by definition require much more frequent updates than any other type of application.

  • Microsoft’s 9th Outage in 2023 ¦ RISE of RISC-V ¦ Meta Ends WFH

    Microsoft’s 9th Outage in 2023 ¦ RISE of RISC-V ¦ Meta Ends WFH

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Redmond SaaS keeps failing, RISC-V is RISEing, and Meta is enforcing hybrid work. (more…)

  • Atlassian Advances DevSecOps via Jira Integrations

    Atlassian Advances DevSecOps via Jira Integrations

    Atlassian announced today it has allied with Snyk, Mend, Lacework, Stackhawk and JFrog to make it simpler to aggregate vulnerability data within the Jira project management software that many organizations rely on to manage application development and deployment efforts.

    Andrew Pankevicius, a senior product manager for Atlassian, said the collaborations will make it easier to prioritize a list of vulnerabilities that need to be addressed and for DevOps teams to automatically assign that work to a continuous integration/continuous delivery (CI/CD) pipeline. Atlassian provides those third-party integrations via an Open DevOps initiative.

    These capabilities, accessible via the Security Tab in Jira, will make it simpler for DevOps teams to manage output from the multiple application security tools that have become part of a larger DevSecOps workflow, noted Pankevicius.

    These additions to the Atlassian portfolio are arriving at a time when there is a lot more focus on securing software supply chains in the wake of a series of high-profile breaches. Those breaches have led to a wave of legislative proposals in the U.S. and Europe that will soon require organizations to embrace DevOps best practices to address increased potential liability that might stem from an application breach.

    For example, a proposed Cyber Resilience Act being negotiated by the member states of the European Union seeks to require organizations that sell internet-connected hardware platforms to ensure that their devices—and the software that runs on them—comply with cybersecurity best practices.

    In the U.S., meanwhile, a National Cybersecurity Strategy proposal put forward by the Biden administration seeks to hold organizations that collect data or build software more accountable for breaches.

    While both proposals are a long way from becoming the law of the land anytime soon, they are indicative of changing attitudes. Governments around the world are concluding the only way to ensure better cybersecurity is to require it. Previous suggestions made by government agencies are going to soon give way to actual mandates. As such, DevOps teams would be well-advised to get ahead of this sea change by implementing the tools and processes that inevitably will be required. As a result, many organizations are now embracing DevSecOps best practices that shift more responsibility for application security further left toward developers.

    The challenge is finding the right set of cybersecurity tools that surface vulnerabilities as code is being developed to make sure context isn’t lost, said Pankevicius. Historically, cybersecurity teams have discovered vulnerabilities long after an application has been deployed in a production environment. By then, however, most developers have moved on to other projects, so remembering how a specific piece of code was developed and by whom can be a significant challenge, he noted.

    There’s no doubt that when it comes to application security, a lot of progress has been made, but there is still much work to be done. The issue now is finding the best way to organize those efforts at a time when more applications are being simultaneously developed within organizations than ever.

  • PagerDuty Signals Commitment to Adding Generative AI Capabilities

    PagerDuty Signals Commitment to Adding Generative AI Capabilities

    PagerDuty has signaled its intention to add generative artificial intelligence (AI) capabilities to its cloud platform for managing IT operations via integrations with large language model (LLM) providers that it will disclose at a future date.

    These capabilities will make it possible to invoke natural language via PagerDuty Operations Cloud to automatically generate status updates, create drafts of incident postmortem reports and even co-author workflows in any programming language to automate remediation of an issue.

    Damon Edwards, senior director of product for PagerDuty, said as AI continues to evolve, the goal will be to minimize the need for human involvement as much as possible. That doesn’t mean there won’t be a need for humans to be involved, but it does mean that many rote tasks associated with managing an IT incident can be automated, he added.

    For example, the reports that are run to determine the root cause every time there is an incident can be automated, noted Edwards. In addition, summarizations of status reports or postmortems after incidents were resolved can be made readily available to any member of an IT team on demand, he added.

    Those capabilities will also make it easier to onboard new members to an incident management team as required, said Edwards. Today, it’s difficult to add new members to a team after an incident has unfolded because it takes time to bring them up to speed, he noted.

    In addition, generative AI also makes it easier to capture a lot of the tribal knowledge within an IT organization that would otherwise disappear when staff either leave the company or shift roles, said Edwards.

    The generative AI additions to the PagerDuty platform extend an artificial intelligence for IT operations (AIOps) capability that PagerDuty made available this spring. The PagerDuty AIOps platform leverages the data model embedded in its incident management software to reduce the amount of time required for an AI platform to learn how an IT environment operates and begin surfacing valid recommendations to optimize workflows.

    It’s not clear at what pace AI will be adopted within enterprise IT organizations, but it is rapidly becoming pervasive. Each DevOps team will need to decide the degree to which they can rely on AI to manage IT processes, but as IT processes become more complex, there is a clear need for AI to navigate all the dependencies that exist in an IT environment. As more routine tasks are automated, however, there will also inevitably be a realignment of roles and responsibilities within an IT organization. The overall goal is not so much to eliminate IT staff as much as it is to enable them to manage IT environments at a much higher level of scale.

    In the meantime, DevOps teams need to plan for not only what is possible using generative AI today but also tomorrow. After all, there’s not a lot of point in training someone to take on a new task if that task is automated a few months from now.