devopsy.kinsta.cloud

Category: Features

  • BMC Adds Generative AI Capabilities to Helix Management Platform

    BMC Adds Generative AI Capabilities to Helix Management Platform

    BMC today revealed it is embedding generative artificial intelligence (AI) capabilities across its BMC Helix service and operations management platforms.

    BMC CTO Ram Chakravarti said the company is incorporating the open source GPT-J large language models (LLMS) to build generative AI models. Those models are optimized for specific domains using data collected by BMC and imported from other data sources, like the Jira project management software from Atlassian. That persistent layer of storage is designed to aggregate multiple types of data within what amounts to a Helix data lake.

    The generative AI capabilities added to BMC’s portfolio include natural language summaries of issues and events captured by BMC Helix Operations Management, along with an ability to create a historical analysis of a user’s specific environment to identify recurring issues more easily.

    BMC Service Management, meanwhile, can now correlate incidents and provide resolution summaries that can be stored. It’s also now possible to run clustering analysis on chat archives to find new or improved utterances that help virtual agents answer queries better and execute workflows.

    BMC initially opted to build its own LLMs because general-purpose LLMs—such as the one created by OpenAI—are subject to “hallucinations.” Hallucinations are created when incorrect data is included in a model. BMC is training its LLMs on a narrow range of trusted data to ensure the recommendations and subsequent automations it creates are valid.

    Over time, BMC will add additional LLMs; the company hasn’t yet decided if there are use cases where it makes sense to rely on an existing general-purpose LLM to add additional capabilities, noted Chakravarti.

    Organizations can also opt to use a containerized version of the BMC LLM if they prefer, but BMC will encourage most organizations to invoke generative AI via its Helix SaaS platform, he added.

    BMC Helix is an IT services management (ITSM) platform that integrates with a range of DevOps platforms. Helix is part of a larger existing BMC Connected Digital Ops initiative that seeks to unify ServiceOps and DevOps with AIOps, DataOps and AutonomousOps. Generative AI will automate a range of tasks from within Helix that can then be extended to DevOps platforms such as Jenkins.

    It’s still early days as far as applying generative AI to processes, so organizations should focus on use cases where it will add some immediate value, said Chakravarti. Once they develop a level of trust in the automation created and executed, they can then pragmatically expand the number of generative AI use cases where they make sense, he added.

    One way or another, generative AI is going to be applied to the management of IT. Many routine tasks that conspire to limit the productivity of IT teams today will be eliminated, but there will always be a need for a human to remain in the loop to ensure the right outcomes are achieved. However, it will also soon become possible for existing teams to manage IT at levels of scale that were previously unattainable.

    Image source: Photo_Credite_Indira-Tjokorda via Unsplash

  • HashiCorp Releases Slew of Updates to Improve DevSecOps

    HashiCorp Releases Slew of Updates to Improve DevSecOps

    At a HashiDays event this week, HashiCorp launched updates to its Terraform implementation and a software-as-a-service offering, dubbed HCP Vault Secrets, that promise to simplify infrastructure security and ensure that secrets are not leaked.

    In addition, HashiCorp has added a self-hosted edition of its remote access security tool, Boundary, that can now also record SSH sessions. The company is also announcing general availability of Vault Secrets Operator, which provides a high level of abstraction for managing secrets in a Kubernetes environment and which synchronizes with the secrets management interfaces defined by the Kubernetes Technical Oversight Committee.

    Finally, HashiCorp is making available in beta a 1.16 update to the Consul service mesh for containers and virtual machines that adds a Sameness Groups capability to improve the resiliency of microservices by redirecting requests to an identical service. HashiCorp has also added a transparent proxy mode to enable failover between services along with a permissive mutual TLS (mTLS) that enables a service to be configured to accept both mTLS traffic from mesh-enabled services and non-Consul mTLS traffic from external downstream applications.

    Chris Van Wesep, senior director of product marketing for HashiCorp, said Version 1.5 of HashiCorp Terraform adds config-driven import workflow and check blocks capabilities that make it possible to declaratively use code to add existing resources into a Terraform state. Previously, the only way to update a Terraform state was to use an import command that could only be applied to one resource at a time. Terraform 1.5 also adds automatic code-generation capabilities for imported resources.

    In addition, version 1.5 of Terraform also includes a tool to validate that provisioned infrastructure is behaving as intended. That latter capability makes it possible to reduce the number of misconfigurations created by developers that might one day be exploited by cybercriminals to breach an IT environment.

    HCP Vault Secrets, meanwhile, provides a beta release of a SaaS edition of the existing Vault offering specifically designed to enable organizations to better manage application secrets that might inadvertently be exposed to cybercriminals in a production environment, said Van Wesep.

    HashiCorp is moving toward providing a portfolio of tools that enable DevOps teams to securely provision and manage hybrid cloud computing environments using a common workflow, he noted. A Forrester Consulting survey found nearly three-quarters (73%) of respondents are reporting this strategy is helping them reach their business goals, with another 19% adding they expected this strategy to help them achieve their business goals in the next year.

    It’s not clear whether organizations are fully embracing multi-cloud computing, but each additional cloud added to an enterprise IT environment increases the total cost of IT. The only way to mitigate those costs is to define a set of best practices for building and deploying applications that can be applied to any cloud computing environment.

    Unfortunately, many organizations will discover that, as they attempt to define those best practices, they have inadvertently become dependent on a set of proprietary application programming interfaces (APIs) that thwart those efforts.

  • Grafana Labs Slashes Time to Create Observability Dashboards

    Grafana Labs Slashes Time to Create Observability Dashboards

    At its GrafanaCON 2023 event today, Grafana Labs updated its core platform for visualizing data which makes it simpler to set up dashboards in minutes. The updates are part of a celebration of the 10th anniversary of a tool that is now widely used by DevOps teams.

    Ryan McKinley, a distinguished engineer for Grafana Labs, said Grafana 10 should help make DevOps more accessible to a wider range of practitioners with limited experience working with observability tools. The latest release also makes it simpler to share knowledge with external stakeholders via public dashboards, he added.

    In addition, Grafana 10 adds expanded role-based access control (RBAC) capabilities and streamlined implementation of the secure access markup language (SAML) to ensure authentication.

    Grafana Cloud has also been updated to provide a secure way to connect to data residing in an on-premises IT environment or in a cloud with the observability platform the company provides via a software-as-a-service (SaaS) platform.

    Finally, Grafana Labs is also making the engine it created to visualize data more accessible to third-party developers that are embedding visualizations based on Grafana within their applications, noted McKinley.

    Grafana Labs

    There are now more than 150 plugins for various data sources that have been made available to more than 20 million users of the Grafana visualization framework. Not all those users are working in DevOps environments, but Grafana is widely used to enable observability across increasingly complex IT environments. The Grafana Cloud seeks to capitalize on that popularity by adding a service that uses an instance of open source Grafana Mimir software to store data collected in a format originally defined for the open source Prometheus monitoring tool.

    It’s still early days as far as adoption of observability is concerned, but it’s apparent that as application environments become more complex, the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. Observability platforms promise to unify logs, metrics and traces to simplify launching queries to identify the root cause of an issue.

    The rate at which DevOps teams will embrace observability will naturally vary, but the biggest obstacle might not be the platforms themselves. Instead, the issue is understanding what queries can help DevOps teams better understand the root cause of an IT issue before there is a major disruption. In the long term, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify issues that might lead to a disruption long before it actually occurs.

    Of course, the result of any query that gets launched needs to be visualized in a way that is easily understood. Grafana Labs is now making a case for a more integrated approach that, at its core, employs its visualization tools to make it simpler to discern what’s occurring in IT environments. After all, no matter how talented any DevOps team may be, it’s still not possible to manage what was never seen in the first place.

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