devopsy.kinsta.cloud

Category: DevOps Practice

  • GitGuardian Allies With CyberArk to Better Protect App Secrets

    GitGuardian Allies With CyberArk to Better Protect App Secrets

    GitGuardian this week revealed it has allied with CyberArk to streamline secrets detection and management by making it easier to share insights.

    Ziad Ghalleb, product marketing manager for GitGuardian, said the two companies have integrated their respective platforms using open source software that integrates GitGuardian Secrets Detection and CyberArk Conjur Cloud, a software-as-a-service (SaaS) platform for managing and rotating secrets as needed.

    In addition, CyberArk Conjur Cloud is now integrated with HasMySecretLeaked, a tool for discovering if a specific secret has been exposed on GitHub. That capability enables DevSecOps teams to periodically cross-reference secrets and credentials against a private database of secrets known to have been publicly exposed.

    GitGuardian claims to have uncovered more than 20 million publicly exposed secrets on the GitHub repository. While GitGuardian provides tools to discover exposed secrets, organizations rely on the CyberArk platform to manage secrets and remediate issues that arise when they are left exposed.

    The immediate challenge is to find ways to integrate secrets detection within the context of larger ecosystems, said Ghalleb. In the longer term, GitGuardian is working toward embedding its tool into integrated development environments (IDEs) to surface exposed secrets as developers build software, said Ghalleb.

    Naturally, there is a lot more focus on secret detection, and secrets management is getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. For many organizations, however, it’s still early days as far as adopting DevSecOps best practices to secure those software supply chains, but it’s clear more responsibility for application security is shifting left toward developers and the DevOps teams that support them.

    Unfortunately, too many developers still hard-code secrets in plain text into applications to create shortcuts as software is developed. Many forget to remove those secrets before an application is deployed in a production environment. Once an application is deployed in a production environment, it may be months before anyone discovers an issue—if it’s discovered at all.

    In the meantime, cybercriminals are becoming more adept at using scanning tools to discover secrets and then exploiting them to compromise applications after they have been deployed.

    Hopefully, DevOps teams will implement DevSecOps best practices to address those issues before any fines are levied. But the challenge, as always, is ensuring application security without adversely impacting the rate at which software is currently being built.

    It’s only a matter of time before more stringent regulations require organizations to revisit the security of software supply chains. Countries around the world are drafting legislation that would hold organizations much more accountable for the security of the applications they build and deploy. As more fines are eventually levied, the tolerance for leaving secrets exposed in applications is only going to decline.

    Secrets discovery and management is, of course, only one aspect of application security, but the more these issues are addressed before applications are deployed the less stressful cybersecurity becomes.

  • Cisco Extends Scope and Reach of Observability Platform

    Cisco Extends Scope and Reach of Observability Platform

    Cisco this week expanded the scope of its observability platform by adding predictive and generative artificial intelligence (AI) capabilities along with log analytics and a Core Web Vitals tool to make it simple to ensure web pages don’t lose their search engine ranking because of poor user experience.

    In addition, Cisco is now leveraging extended Berkeley Packet Filters (eBPF) in the kernel of Linux operating systems to provide visibility into Kubernetes workloads and a session replay capability for cloud-native applications. In addition, Cisco has allied with Komodor, a provider of a Kubernetes management platform, to gain additional visibility into these environments.

    Cisco also added digital experience monitoring (DEM) capabilities based on real user monitoring (RUM) and the full-stack observability it provides following its recent acquisition of Accedian, a provider of an analytics platform for monitoring end-user experiences.

    Finally, Cisco added a Data Security Posture Management (DSPM) Observability module to the company’s Business Risk Observability platform based on the same core platform.

    Announced at a Cisco Live EMEA event, these latest updates are part of an ongoing Cisco effort to extend the reach of its observability platform well beyond DevOps workflows.

    Gregg Ostrowski, executive CTO for Cisco AppDynamics, said as part of that effort, Cisco is making it simpler to aggregate telemetry data for the AI for IT operations (AIOps) capabilities it provides by pulling directly from platforms such as Cisco ThousandEyes and Cisco DNA Center as well as from third-party partners such as VMware, Zabbix and ServiceNow. Similarly, Cisco is now leveraging eBPF to collect data from Kubernetes environments.

    Ostrowski added that the overall goal is to reduce the amount of instrumentation effort that IT teams would have to undertake to instrument highly distributed IT environments.

    There will still be a need to instrument applications, but the collection of telemetry data from the underlying IT infrastructure environment is going to be increasingly automated, he noted. In the meantime, it’s become less expensive to instrument applications using open source OpenTelemetry agent software, added Ostrowski.

    In general, Cisco, in addition to enabling organizations to rationalize existing tools, is also making a case for improving collaboration by, for example, making use of natural language capabilities enabled by generative AI to launch queries and provide summarizations.

    At the same time, Cisco is partnering to add additional capabilities, such as the ability to monitor machine learning algorithms via an alliance with Aporia and AS/400 systems via an alliance with Perform IT.

    Ultimately, Cisco is betting that observability across the entire enterprise IT environment is going to become more unified as organizations increasingly look to correlate business processes with specific IT events, including indications of cybersecurity breaches. It’s not clear how far down that path enterprise IT organizations are just yet, but given the total cost of observing and monitoring IT environments today, there is more pressure than ever to find more cost-effective approaches to holistically managing IT. The challenge, as always, is unifying all the existing fiefdoms in IT organizations that have already embraced a wide variety of tools and platforms they are hesitant to give up.

  • Scrimmage for Control: On-Premises Vs. SaaS in the Observability Super Bowl of 2024

    Scrimmage for Control: On-Premises Vs. SaaS in the Observability Super Bowl of 2024

    Observability means data. It encompasses a set of practices and tools designed to track the performance and health of software applications, providing insights into the “why” behind system behaviors, not just the “what.” At its core are data pillars we’ve learned how to work with and hopefully get the most out of—metrics (quantitative data on system performance), logs (recorded events within the system) and traces (detailed views of request paths through the system) that offer a comprehensive view of the system’s operation in real-time. SaaS is where the industry has been turning towards for the past decade. It’s easy to operate and upgrade and takes away maintenance and manpower requirements.

    But, using a SaaS solution where data is stored on the vendor’s infrastructure can be compared to playing a football game at your opponent’s home field. Your team does not own the field and must play along with conditions that are outside their comfort zone. While your team can still strategize, execute plays and score points, the control over the playing environment, including the surface, lighting and even some rules, lies with the owner of the stadium (in this case, the SaaS vendor).

    You don’t get the home-field advantage and the comfort of your familiar surroundings, and you also can’t control the audience’s shouts and cheers in the stands across the arena.

    Just as a visiting team must trust the host’s management of the stadium and adapt to its conditions, organizations using SaaS solutions entrust their operational data to third-party vendors. They must trust its data protection policies and privacy agreements to ensure that the organization’s data is handled securely and in compliance with relevant regulations.

    And even more importantly, they have to adhere to its hosting costs.

    Let’s Leverage the Home-Field Advantage

    The alternative is clear: While playing on your own field, you, the coach—hell, the entire team—know this field by heart, and you know best how to keep and enforce your own rules.

    Just as a football team controls the ball and decides on the play, having on-premises data means a company or organization keeps its data within its infrastructure, offering direct control over its storage, management and security. The organization decides how to deploy, use and protect this data and even how to manage the tradeoff of data costs.

    The downsides? Playing on your home field at all times means you’re running slower than the world out there. You’re not quick to update your software to the newest common practices and you’re tasked with maintaining another stack—your observability stack—on top of building your product, which serves your users.

    There’s Another Way. Play the Data on the Scrimmage Line

    In football, the scrimmage line is the imaginary line across the field where the ball is placed at the start of each play. This line serves as the point of engagement between the two opposing teams, with specific rules governing how players can position themselves and how the play begins.

    What if we can keep the data on-premise, in the home field, a little like having the ball on our side of the scrimmage line, within our team’s possession and control? We have the ball, and we decide and strategize how to advance the ball or score from the position behind the scrimmage line, but we can still interact with the outside world (or the opposing team) under a set of rules to which we both adhere.

    This is exactly where observability solutions are heading: A combination of the advantages of SaaS—easy to update and maintain value, with an easy way to distribute the solution inside the organization, alongside the advantages of on-premise—data privacy, data control and full transparent and controllable data costs.

    I call this approach inCloud. It is a modern on-premises approach—data in your cloud environment, protected and controlled by the user, but still governed, managed and served with a guaranteed SLA just like the best SaaS offerings out there.

    Just like the scrimmage line in football that provides a clear boundary and set of rules for how the game is played, inCloud acts in a similar way. Data is kept on-premises, allowing the organization full control over retention, privacy and data integrations. And on the other hand, inCloud defines a set of strict rules under which a control plane is allowed to operate and pass the scrimmage line, or past the organization’s cloud borderline, to manage and access the data like a SaaS solution does best.

    So when we sit down to watch the Super Bowl this Sunday—let’s use that halftime show to think about where we’ll be taking our organization’s observability capabilities in 2024. Will the data be in our hands, crossing that invisible scrimmage line? Or will we lose to our opponent’s home-field advantage?

    May the best team win.

  • How Can DevOps Teams Use Customer Intelligence Data?

    How Can DevOps Teams Use Customer Intelligence Data?

    Customer intelligence involves collecting and analyzing data about customers’ behaviors, preferences and needs. It helps businesses understand their customers better and tailor their products and services to meet customer demands. The data is gathered from various sources, such as customer feedback, web analytics, social media, purchase history and software usage metrics. The insights drawn from customer intelligence can be used to inform business strategy, product development and marketing efforts.

    The goal of customer intelligence is to create a detailed understanding of the customer’s needs, preferences and habits. This information can be used to predict future behavior, improve customer service and drive sales. For instance, if a software company knows that a particular customer segment mainly accesses their software on mobile devices, the organization can improve their mobile support or create dedicated mobile applications for that customer segment.

    How Can DevOps Teams Use Customer Intelligence Data?

    There are several ways that a DevOps team can leverage the data gathered from customer intelligence.

    Prioritizing Feature Development Based on Customer Feedback

    When developing new features, it’s useful to analyze customer feedback to understand what features customers find most valuable and prioritize those for development. For instance, if feedback suggests that customers want a more intuitive user interface, the team can prioritize UI improvements.

    By focusing on the features that customers find most valuable, DevOps teams can improve the usability and functionality of their products. This can lead to higher customer satisfaction and loyalty and, ultimately, increased sales. Additionally, prioritizing feature development based on customer feedback can help DevOps teams avoid wasting time and resources on features that customers don’t value.

    Tailoring UX and UI Design Based on Customer Preferences and Behaviors

    By analyzing data on how customers interact with their products, teams can identify pain points and areas for improvement. For example, if data shows that customers are having difficulty navigating the website, the team can redesign the navigation to make it more user-friendly. 

    Alternatively, if customers abandon their shopping carts at a certain point in the checkout process, the team can investigate and make necessary improvements.

    Using Customer Data to Drive Personalization and Customization Features

    Personalization is about tailoring the customer experience to the individual user, while customization is about giving customers the ability to tailor the product or service to their specific needs.

    For instance, by analyzing data on a customer’s browsing and purchase history, a team could develop a feature that recommends products based on the customer’s past behavior. Or, if a customer frequently purchases a certain type of product, the team could create a feature that allows the customer to customize that product to their liking.

    Leveraging Predictive Analytics to Forecast Future Customer Needs and Trends

    Predictive analytics involves using historical data to predict future events. In the context of DevOps, this could mean using customer data to forecast future customer needs and trends.

    For example, if data shows a growing interest in eco-friendly products, the team could anticipate this trend and start developing more eco-friendly products. Predictive analytics can also help teams identify potential issues before they become problems, allowing them to address those issues and improve the customer experience proactively.

    Best Practices for Effectively Using Customer Intelligence in DevOps

    Here are some best practices that DevOps teams can use to make the most of their customer intelligence data.

    Integrate Customer Feedback Early and Often

    Customer feedback from surveys, social media, and customer service interactions provides invaluable insights into what customers need, their pain points, and their preferences.

    By integrating this feedback into the DevOps process, teams can better understand customer needs and develop products or services that address those needs effectively. Early integration of customer feedback allows teams to pivot and make changes more swiftly, thus saving time and resources.

    It’s also important to obtain feedback regularly. Customers’ tastes and preferences evolve continuously, and their feedback reflects those changes. Feeding frequent customer intelligence into the development process ensures the DevOps team’s work stays aligned with the shifting customer landscape.

    Leverage Analytics Tools

    Analytics tools can help DevOps teams sift through large volumes of customer data and extract actionable insights. These insights can then be used to inform decision-making and drive innovation.

    Some tools excel at data visualization, helping teams understand complex datasets through graphs and charts. Other tools excel at predictive analytics, helping teams forecast future trends based on historical data.

    Choosing the right analytics tool depends on the specific needs of the DevOps team and the nature of the customer intelligence data they have at their disposal. The key is to leverage its capabilities fully to extract the most value from the customer intelligence data.

    Ensure Data Quality and Relevance

    Not all data is created equal, and if it is poor quality or irrelevant, it can lead to misguided decisions and wasted resources.

    Data quality refers to the accuracy, completeness, consistency, and reliability of the data. DevOps teams should implement robust data quality checks to ensure that the customer intelligence data they’re using is of high quality.

    Data relevance, on the other hand, refers to the data’s applicability to the task at hand. Not all customer intelligence data is relevant to every DevOps project. Teams need to carefully select the data that is most relevant to their specific project and ignore the rest.

    Balance Quantitative with Qualitative Data

    While quantitative data provides hard numbers and concrete facts, qualitative data offers deeper insights into customer attitudes, perceptions and behaviors.

    Quantitative data can help DevOps teams identify trends, measure performance, and track progress over time. However, it often fails to explain why certain trends are occurring or why performance is changing. 

    It also can help DevOps teams understand the reasons behind the numbers. It can provide insights into why customers behave the way they do and what they truly think and feel about a product or service. Balancing quantitative with qualitative data gives DevOps teams a more holistic view of the customer landscape, enabling them to make more informed decisions.

    Cross-Functional Collaboration

    Customer intelligence data is valuable for all teams across the organization, not just DevOps. By collaborating with other teams, such as marketing, sales and customer service, the DevOps team can gain additional insights and perspectives. 

    Cross-functional collaboration also fosters a culture of data-driven decision-making across the organization. When all teams use customer intelligence to inform their work, the organization as a whole becomes more customer-centric, agile and innovative.

    Conclusion

    Successfully using customer intelligence data in software development allows teams to remain responsive to customer needs and increase the value of their products. DevOps teams need to integrate customer feedback early and often, leverage analytics tools, ensure data quality and relevance, balance quantitative with qualitative data,and foster cross-functional collaboration. By following these best practices, DevOps teams can use customer intelligence data to drive innovation and create products and services that truly resonate with customers.

    Image source: Josh Sortino via Unsplash  

  • API Management: A Weak Link in the Cloud-Native Chain

    API Management: A Weak Link in the Cloud-Native Chain

    Managing APIs is like navigating unfamiliar terrain during a road trip: There’s an old way and a new way to do it, and the new way is just better in many cases. For API management, the old way of doing things involves practices like writing proprietary scripts, manual transaction monitoring and relying on individual employees to take charge of managing specific APIs – leading to more manual work, slower release processes, slower incident recovery and lower reliability. It’s akin to navigating a highway using a paper map, stopping at gas stations to ask for directions and crossing your fingers that you end up at your intended destination.

    The new way of managing APIs looks like this: Using declarative configurations, automated processes and stateless APIs, teams scale and centralize the tasks of configuring, monitoring and updating APIs. They also deploy API changes several times a day, and they can instantly mitigate incidents in production.

    It’s like navigating with a GPS: A simpler, faster and more flexible approach that gets you where you want to go with much less hassle and risk.

    To prove the point, allow me to walk through the reasons why traditional API management strategies fall short for modern environments, then discuss what it takes to manage APIs better.

    What is API Management?

    Let me begin by defining what I mean by API management.

    I’m referring to all of the practices, processes and tools that businesses use to support the APIs their workloads depend on. API management encompasses API design, development, monitoring, testing and security, as well as making updates to APIs after they are in production.

    These tasks are important, of course, because APIs are everywhere today. They handle 83% of internet requests, according to Akamai, which means that keeping APIs documented, updated and monitored is a critical requirement for virtually any organization that deploys Internet-connected applications.

    Without an efficient and scalable means of managing APIs, it becomes difficult not just to defend against challenges like security risks involving APIs but also to guarantee a positive developer experience. The more time and toil your developers have to invest in API management, the less time they have to do the things they want to do and that matter most to the business – like developing cool apps and bringing them to market.

    The Pitfalls of Traditional API Management

    APIs are not new, and most teams that support them have long had API management practices in place. However, in many cases, those practices were conceived in the era when monolithic application architectures and bare-metal servers or virtual machines dominated the IT landscape. They weren’t designed for today’s cloud-native, software-defined, distributed-everything world.

    As a result, traditional API management falls short in modern environments in several key respects:

    ● Slow change management: When you are continuously pushing out updates to apps and APIs, you need an API management strategy that can handle continuous change. Traditional approaches can’t do this. They are too human-intensive to keep pace with rapid change.
    ● Lack of reliability: If you manage API configurations manually, you face a higher risk of introducing changes that accidentally break something. And if that happens, fixing the issue is slow because you have to reconfigure everything by hand.
    ● Slow recovery speed: When you experience an incident related to an API – such as a latency increase due to a misconfigured API – recovery is slower because it’s difficult to trace the surface-level problem back to its root cause, given the lack of a central source of truth for tracking the API’s status and revisions.
    ● Lack of scalability: Traditional API management uses imperative configurations that are stored in stateful databases, which have to be provisioned for each API you want to deploy. That works if you have just a handful of APIs to manage, but it’s impossible to scale if you need to scale to support dozens or hundreds. It also creates particular challenges if you have geo-distributed teams and infrastructure.
    ● Lack of modularity: Conventional API management architectures are not modular or composable, making it difficult to reuse configuration components between APIs. Instead, engineers are forced to “reinvent the wheel” every time they need to configure a new API or move an existing one from dev/test to production.
    ● Lack of standardization: Traditional APIs typically depend on proprietary technologies. As a result, they’re difficult to integrate with modern stacks that are based on widely used tools like Kubernetes, OpenTelemetry and Git.
    ● Poor collaboration: Documenting APIs and sharing monitoring insights between teams is also challenging when configurations are imperative and there is no single source of truth that all stakeholders can refer to when tracking the status of an API.

    These challenges lead to a nightmare for teams tasked with Day 2 operations, meaning those that support APIs after they are in production. Slow, inefficient and unscalable management processes lead to struggles in detecting and fixing problems with API performance or security, as well as in updating APIs. And again, they hamper the developer experience by forcing developers to devote time and energy to deciphering APIs and versions to use, finding up-to-date documentation, and so on. As a result, developers whose main job is to write software, not manage APIs, become burdened by API management requirements.

    A Better Way to Manage APIs

    The good news is that a better world is possible – at least when it comes to API management. For modern apps and environments, API management should be rooted in the following principles:

    ● Composability: Your API management stack should be composable so that you can pick and choose from different ingress controllers, monitoring and analytics tools, load-testing solutions and so on. You shouldn’t be bound to a rigid, inflexible “stack.”
    ● Statelessness: Stateless API management, which frees APIs from dependency on stored configurations, enables scalability, simple rollbacks and consistency across environments because you can deploy APIs anywhere with minimal provisioning.
    ● Automation: The more you automate the processes involved in API management, the faster you can implement changes and the lower your risk of mistakes and inconsistencies due to manual management.
    ● Immutability: The underlying infrastructure that powers your API management stack should be immutable so you can replicate it easily and quickly – a benefit during processes like troubleshooting following a rollback.
    ● Auditability: You should be able to maintain a timestamped log of every change to your API that documents when changes are made, who made them, why they happened and what the potential implications are.
    ● Open and standards-based: The ability to monitor and manage APIs using open, standardized tools and frameworks – such as OpenTelemetry and kubectl – also leads to consistency and simplifies collaboration between teams. In addition, API contracts should be standardized using specifications like OAS.
    ● Efficient incident response: When you discover a performance problem or failure linked to an API, you should be able to troubleshoot and resolve the issue quickly without having to chase down documentation or find the one person at your company who understands how the API works.

    When you manage APIs according to these principles, you escape the tedium and inefficiency of traditional API management. By extension, you can easily support the many APIs that tie your cloud-native environments together.

    The Role of GitOps

    Going a step further, a declarative, stateless, automated approach to API management also enables GitOps, meaning that you can manage APIs via declarative configurations that you store in Git repositories.

    This practice also leads to greater reliability (thanks to consistent, repeatable and scalable configurations), collaboration (because Git serves as a shared, central source of truth for API configurations and workflows) and efficiency (due to the ability to automate and customize deployments using Git-based triggers and actions).

    Conclusion: API Management at Cloud-Native Speed

    In a world where more than half of existing applications are cloud-native and a majority of new apps will leverage cloud-native principles, traditional API management just doesn’t work for these new platforms. It leads to change management processes that are slow and unreliable – exactly the opposite of what businesses need to thrive in a dynamic, cloud-native world. It also slows down recovery, leading to lower levels of reliability and higher risk for the organization. On top of this, it’s tedious, inefficient and unscalable. So yes, cloud-native API management is currently broken.

    We need a radical new approach to API management with one goal in mind: Automate Day 2 API operations with a modern approach. Modern solutions should be rooted in stateless, declarative configurations, open standards and Git-based automation. They must enable change management with high reliability and instant recovery, so you don’t have to worry about API management becoming the weakest link in your ability to innovate quickly and with minimal risk.

    We envision a new world where managing APIs is no longer a burden that developers and platform teams must bear but instead a process that helps teams innovate as quickly as possible, no matter how complex the API architectures they are working with. We also want to help businesses bring products to market faster, as well as troubleshoot incidents more quickly and with less effort.

    Ultimately, we want to empower organizations to take full advantage of cloud-native technologies and paradigms by adopting a cloud-native approach to API management.

  • Empowering Developers Fuels IT Resilience and Business Transformation

    Empowering Developers Fuels IT Resilience and Business Transformation

    Developers are feeling the brunt of global economic pressures on their organizations to move digital transformation projects forward while having to do more with less. Adding to this pressure is the explosion of technologies like generative artificial intelligence (generative AI) and edge computing, which have made infrastructures more interesting and possibly more complex. The overall result is an increased mental load for developers tasked with bringing innovation to life while minimizing all the added complexity. And it’s DevOps teams who are carrying the weight of ensuring seamless integration, deployment and automation of new technologies. It’s incumbent upon IT leaders to give developers and DevOps teams a simplified, trustworthy data architecture to ease this burden if they want their modernization efforts to thrive.

    It’s a difficult juggling act IT leaders know all too well — controlling costs and improving efficiency while increasing agility and resiliency. Management, budget and technology challenges have been causing digital transformation projects to be put on pause to avoid potential drawbacks or failures. In fact, 68% of organizations facing modernization challenges were forced to push digital transformation goals back by more than three months, with delays costing organizations $4.4 million on average.

    Despite the hurdles — many of which were brought on by the COVID-19 pandemic — enterprises continue to focus on modernization: Nearly 60% said their key digitization goal is to improve business resilience and add AI-powered efficiency in the face of the evolving global economy. Recent research revealed that 53% of executives have already deployed some form of generative AI, with 45% forecasting that integration of automation and AI tech will catalyze a major transformation in their industry within the next five years.

    The call to empower developers and DevOps teams is loud, and IT leaders should heed it.

    Putting Developer Empowerment at the Top of the IT Agenda

    Developers and DevOps teams must constantly adapt, from keeping up with changing market demands and customer expectations to navigating technology stack intricacies across a myriad of platforms, tools and frameworks. They also need to stay updated on the latest security practices throughout the development life cycle. Through it all, the pressure to innovate rapidly looms large.

    Given their central role in today’s business, empowering the people who build and run modern applications must be a top IT investment priority. These investments have a synergistic payoff. They not only strengthen developers and DevOps teams, but the entire business reaps the benefits:

    • When given the support and tools they need to successfully embrace new technologies and create new services, developers are empowered to take on new projects, implement new technologies and take advantage of growth opportunities. For example, cloud-based solutions, such as database-as-a-service (DBaaS) and containers-as-a-service (CaaS), offer developers vast opportunities to enhance their agility and efficiency to drive competitive advantage for their organization.
    • Additionally, low- and no-code platforms, AI coding assistance and serverless computing allow IT to create opportunities for other business units to build their own services. This reduces reliance on developers for simpler tasks that line-of-business teams can accomplish themselves, freeing developers to focus on expediting innovation and helping to increase productivity across the organization.

    Freeing Developers to Innovate With AI Increases Their Productivity

    IT spending on AI is sure to evolve over the next few years. IDC predicts generative AI spend will reach $143 billion in 2027. Gartner recently stated that “while GenAI has not yet had a material impact on IT spending, investment in AI more broadly is supporting overall IT spending growth.” IT teams are working on their AI strategy and still need to better understand the role of generative AI or large language models (LLMs) before fully adopting them across the business. However, if one thing is clear to IT leaders today, it’s that AI can make developers more productive and speed up the pace of software development.

    Furthermore, with AI, software development can be more efficient, accurate and adaptive, leading to faster development cycles, higher-quality applications and better user experiences. AI tools can assist developers in writing complex code, detecting and fixing issues faster and automating the testing process. AI can also offer many ways to enhance the overall DevOps process by automating repetitive tasks and analyzing workflow data to optimize processes.

    As organizations aim to modernize and take advantage of generative AI, IT leaders should empower developers and DevOps teams to use it to simplify how they develop, deploy and run applications. By prioritizing the adoption of new technologies, such as cloud-native IaaS, AI, edge, mobile, serverless and low- and no-code computing, IT teams can help make DevOps teams more agile, cut down on costs and speed innovation.

  • F5 Looks to Streamline Application Networking

    F5 Looks to Streamline Application Networking

    At its AppWorld 2024 conference this week, F5 announced a software-as-a-service (SaaS) edition of its NGINX application networking portfolio, which are now all available under a single enterprise license.

    Shawn Wormke, general manager for NGINX, said NGINX One will eliminate much of the friction enterprise IT teams currently encounter when implementing NGINX Plus, NGINX Open Source, NGINX Unit, NGINX Gateway Fabric and the Kubernetes Ingress Controller the company provides.

    As part of that effort, F5 is also now making available a unified console across its application networking portfolio that promises to streamline the management of the F5 application networking portfolio.

    Currently available under an early access program, NGINX One creates an as-a-service platform through which enterprise IT organizations can invoke and pay for these capabilities on an as-needed basis, said Wormke. The overall goal is to reduce the total cost of application networking by eliminating the need for IT teams to integrate the various elements of NGINX One on their own, he added.

    In general, application networking has become more complex with the rise of cloud-native applications based on microservices. By reducing the cognitive load required to network those applications, it becomes simpler to make network operations a more natural extension of DevOps workflows, noted Wormke.

    Most organizations have some level of experience with application networking using proxy servers, but as application environments have become more complex, the need for gateways and ingress controllers to provide these capabilities at scale has become more apparent. As a result, more IT organizations are starting to revisit how they are structured. There may always be a need for dedicated networking specialists to manage the physical network underlay, but as other networking services become more integrated with DevOps workflows, responsibility for some networking services is starting to shift further left toward DevOps teams that will either deploy these capabilities themselves or take advantage of a SaaS platform such as NGINX One. The overall goal is to be able to dynamically provision application networking services without having to wait for a network administrator to provision them.

    There are, of course, a lot of approaches to application networking that are now emerging. Regardless of how application networking evolves, however, the rigidity that has characterized the delivery of network services for decades should finally start to fade away. Today, outside of a cloud computing environment, it’s still common for IT teams to provision virtual machines or Kubernetes pods in hours only to wait days or even weeks for network connectivity to be provisioned. As IT environments become more hybrid and more workloads are pushed to the edge, there is a clear need for a more agile approach.

    Each organization will need to decide how best to approach application networking across legacy monolithic applications, microservices and event-driven applications at a time when IT environments have become much more complex to manage. The challenge, as always, is reducing as much friction as possible without unduly raising the total cost of IT to a point where it becomes unsustainable.

  • Kobiton Open Sources Test Script Generation Tool

    Kobiton Open Sources Test Script Generation Tool

    Kobiton today announced it is open sourcing a script generation tool for the Appium automation framework that automates the running of test scripts.

    The overall goal is to make the tool, which makes it simpler to create more testing scripts, more widely available and, ultimately, lead to higher-quality applications being deployed.

    Kobiton CTO Frank Moyer said the tool makes it possible to generate tests from a test case that has been captured in a Node.js format. Rather than having to hire hundreds of testers to create those scripts manually, it’s now possible to automate those tasks using an open source tool, he added.

    On average, Kobiton claims the tool it developed can write a 30-step script in 10 minutes, whereas a manual approach could take as long as four hours to construct a similar test.

    Once created, those test scripts can automatically be executed using the Appium framework. The output from that tool can also be used on other testing platforms, including Sauce Labs, BrowserStack and LambdaTest or integrated with low-code testing platforms from Perfecto and Tricentis.

    It’s no secret that the quality of any given application tends to vary widely, not just between organizations but also within them. Most of those issues can be traced back to a lack of testing that usually occurs because there isn’t enough time. As deadlines near, one of the first places organizations look to make up for delays is the time available for testing. The hope is that whatever issues arise will be addressed via the next update. Of course, when the update falls behind schedule, the testing process is again cut back.

    Ideally, application development projects would not be allowed to go forward without adequate testing, but given business pressures, they often do. The only way to limit the impact of application development delays is to reduce the time required to create and run tests. The more automated that process becomes, the less time there will be spent on manually running routine tests. In fact, hopefully, there might even be enough time to run more complex tests to uncover issues that might adversely impact the user experience in ways no one might have otherwise considered.

    One way or another, the quality of the applications being deployed needs to improve if for no other reason than end users have options. Most end users will never give a mobile application a second chance if the initial experience doesn’t meet expectations. At the same time, application security regulations are only going to become more stringent. The tolerance for known vulnerabilities discovered after an application has been deployed is falling. Many organizations will find themselves subject to fines being levied simply because there was not enough adequate testing baked into the software supply chain.

    In fact, application security should, in the final analysis, be an element of a large quality assurance process that begins with adequate testing.

  • Survey Surfaces Raft of Ongoing Agile Development Challenges

    Survey Surfaces Raft of Ongoing Agile Development Challenges

    A survey of 788 software development professionals finds 71% are using agile development methodologies within their software development life cycle (SDLC) but only 44% said it is working very well (11%) or somewhat well (33%) in the enterprise.

    Conducted by Digital.ai, the survey identifies end-to-end visibility and traceability from business initiative through deployment as the top opportunity for improvement (44%), followed by an ability to measure cycle time, wait time and bottlenecks (34%), continuous testing (29%) and identification and measurement of technological risk (28%).

    Nearly half (46%) identified too many systems as a primary reason Agile was not scaling, followed by siloed teams (37%), culture clash (34%), inconsistent adoption (30%) and the inability to measure business value (28%).

    Despite these issues, nearly two-thirds (63%) said they have visibility into their Agile pipeline, with 55% claiming they have complete visibility. However, only 36% said DevOps teams currently work together as one team to accelerate innovation and deployment of high-quality and more reliable software. At the same time, only two-thirds (66%) claimed at least 50% of their applications were delivered on time and “with quality.”

    Joyce Tompsett, general manager of the State of Agile project at Digital.ai, said the survey makes it clear many organizations are still trying to strike the right balance when it comes to developing software. For example, the survey finds the top two reasons organizations adopt Agile (tied at 41%) are to accelerate time to market and prioritize delivery and measure customer/business value. Most software development teams are being evaluated both based on velocity (33%) and the value delivered (29%), the survey finds.

    The survey also identifies customer satisfaction (43%), time to delivery (39%) and competitive advantage (34%) as their top priorities for 2024.

    In general, the survey finds that 33% of respondents reported business leaders and executives are actively leading and participating in company-wide agile transformation. However, more (41%) said there was not enough leadership participation. Well over a third (37%) said business teams simply don’t understand what Agile is or what it can do. More than a quarter (27%) said there is not enough training.

    Not surprisingly, the most widely adopted methodology is Scrum (63%) with the Scaled Agile Framework (SAFe) being the most widely used (26%). Another 22% don’t have a mandated framework, while 12% said they have created their own.

    The debate over what precisely constitutes agile development is, of course, ongoing. Each organization tends to adopt the elements of the framework that make the most sense for them, so the actual state of adoption from one organization to the next will vary widely. The one thing that is certain is the more complex the IT environment, the more challenging it can be to embrace agile development.

    And there continues to be lots of room for improvement. If only two-thirds of organizations are delivering half (50%) of their applications on time with an acceptable level of quality, it means there are more projects that are failing to meet that standard than many software development teams might care to admit.

    As more organizations become more dependent on software, however, tolerance for that level of failure will only continue to decline as businesses and leaders lose patience with application development practices that do not live up to expectations.