devopsy.kinsta.cloud

Category: Continuous Testing

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

Application Modernization: A Catalyst for Fixing Sub-Optimal UX

Today, some of the biggest government programs in existence are Medicare and Medicaid with the two health care insurance providers serving over 43% of the U.S. population. The Centers for Medicare and Medicaid (CMS) spent $1.6 trillion in 2021 and continue to grow in both size and cost on an annual basis. With this type of investment and permeation into the American populace, one would assume that this program would be running on the most up-to-date applications available. However, both public and private health care insurance carriers continue to operate on legacy systems.

Recently, Andrea Fletcher, the digital services director of the CMS, described their system as operating on technology from the 1960s, which is alarming considering the responsibilities of the program. In fact, the Biden administration has only recently announced plans to modernize their organ matching system. This announcement came from a study conducted in February, which showed that only 26% of organs were procured from donors on average. This is just one example of how efforts to improve legacy systems, which are currently being used by over 40% of the population, allow both public and private organizations to operate in a more efficient manner as well as satisfy user needs. Further exploration will show how modernization improves other areas of business, such as creating user experiences that are both easier to navigate and more personalized as well as the ability to incorporate the latest cybersecurity updates.

Modernizing as a Means to Improve User Accessibility and Personalization

Given the size and diversity of the United States population, a modern flexible system is necessary for creating a smooth user experience for every individual. Today, users connect with insurance carriers using a variety of different devices while communicating using different languages and possessing different levels of technical expertise. The ability to create a personalized user experience for each individual will require a level of modernization that legacy systems were not built for. The importance of this flexibility is accentuated when considering that the purpose of Medicare and Medicaid, in particular, is to serve the elderly and underprivileged.

Prioritizing the modernization of the consumer experience is not limited to just government organizations. In an independent survey conducted by Evolveware, 46% of private organizations measure the success of their application modernization efforts through an expected improvement in customer experience. As health care insurers continue to rely more heavily on analytics and the population continues to adopt digital technologies, the process of creating a streamlined and targeted approach to purchasing and managing health care becomes essential to staying competitive. For a multitude of companies in the marketplace, having an agile system that can be customized to each individual user can be a major differentiator, especially given the variety of factors that each individual has when it comes to making decisions about their health. Moreover, by prioritizing the user experience, organizations can improve their brand loyalty and customer retention, which are key factors when dealing with a competitive marketplace with a lot of players. Insurers have recognized this, as a recent survey of CIOs by Gartner showed that improving the customer experience and application modernization were listed as the highest priorities in the insurance industry. As customers become more judicious with their money due to current macroeconomic trends, providers will need to make sure their platforms’ user experiences are on par with their competitors.

Modernization to Mitigate the Impact of Hidden Costs and Security Vulnerabilities

The costs of not updating legacy systems should also be taken into consideration when making the decision to modernize. While the expense and process of moving away from legacy systems can seem like a significant obstacle, these systems, due to on-site maintenance and operational costs, are already expensive to maintain on a continuous basis. In fact, health care IT teams spend around 60% of their time trying to maintain and manage legacy systems. Furthermore, the opportunity cost of IT teams focusing on maintenance over innovation is significant, especially given the potential of the latest technologies to deliver a more intuitive user experience. There is also an understated but pressing labor cost with legacy systems, as members of the workforce who are familiar with these systems are aging and retiring, and the replacement workforce is not well-versed in legacy languages and technologies.

Finally, legacy systems can also contain blind spots that are prime targets for cybersecurity breaches and hacks today. Legacy applications were built at a time when these types of attacks were not common and, therefore, don’t have the most up-to-date security capabilities embedded. Many of these systems also do not have up-to-date documentation, resulting in a high potential for hidden vulnerabilities. For health care organizations that have access to sensitive data, understanding and then shoring up these vulnerabilities using modern security features is critical.

Health Care Modernization Example: Chatbots

One prominent example of how application modernization can lead to organizational success is the integration of chatbots. As technology expands and businesses identify new ways to reach consumers, the addition of chatbots has become more prominent on platforms across industries. For the health care insurance industry, the bots provide both a cost-efficient way to process insurance claims as well as an enhanced user experience through ease of use. Recent estimations show that bots can handle the workload of two to five claims processors and can deliver 20 times the production relative to cost, allowing industry employees to focus on less tedious and more innovative tasks. Using generative AI models, chatbots will continue to become more sophisticated and varied in their responses to user input. As a result, modernizing legacy systems to optimize the integration of these bots becomes integral to remaining competitive in the marketplace.

Legacy Systems and the Future

As we look to the future, both government and private insurance carriers have plenty of internal and external factors that incentivize application modernization. As Medicare and Medicaid continue to grow due to the increasing number of eligible users, an agile system is integral for user accessibility. Meanwhile, macroeconomic factors such as high costs and an increasingly competitive marketplace will force private organizations to adopt systems that can integrate and adapt to the newest technologies for a better and more secure customer experience. With serious challenges facing both the public and private sectors of healthcare insurance, the necessity to modernize has never been greater.

November 10, 2023
Survey Surfaces Software Supply Chain Security Challenges

A survey of 268 security leaders and 252 developers published this week found that while there is general agreement on the importance of software supply chain security, there is a significant disconnect on what is required to achieve that goal.

Conducted by the Harris Poll on behalf of Chainguard, a provider of curated container images for building secure software, the survey found 92% of developers acknowledged software supply chain security is at least very important, with 39% noting it as absolutely essential. Similarly, 96% said effective software security practices are important to meeting government or regulatory requirements, with 93% noting effective software security as a critical component of their threat and risk mitigation strategy.

Overall, most security leaders (70%) and CISOs viewed software supply chain security as a top priority. However, only slightly more than half of developers (52%) agreed. Nearly three-quarters of developers (72%) said they are very security-conscious, but only 50% of security leaders rated developers as very security-conscious.

Roughly two-thirds of security leaders (69%) and developers (64%) agreed that lack of communication and collaboration between developers and security teams is a problem. More than three-quarters of security leaders (77%) and more than two-thirds of developers (68%) agreed that the need to prioritize security causes tension between their teams. Nearly three-quarters of developers said the work/tools their security team requires them to use interferes with their productivity and innovation. Tools in place included software bills of materials (SBOMs) (40%), and nearly half are implementing software supply chain security frameworks such as Supply-chain Levels for Software Artifacts (SLSA) (47%) and the Secure Software Development Framework (47%) defined by the National Institute of Standards and Technology (NIST).

The report also found that 36% of security leaders and 34% of developers viewed an overwhelming number of scanner false-positive vulnerability alerts as being among the biggest software supply security obstacles an organization faces.

Most security leaders (74%) and developers (85%) believed that prioritization of software supply chain security would increase over the next five years.

However, many developers don’t believe enough security teams understand core software. Developers said security teams are generally familiar with open source software libraries and projects (61%), source code repositories and source code management systems (60%) and software build tools (59%), but only 43% said security teams are very familiar with container images.

On the plus side, many security leaders and developers understand that best practices and tooling in software security to drive certain business outcomes is essential, including customer retention (43% and 40%), meeting or satisfying procurement contract obligations (36% and 32%), fewer breaches or compromises (34% each), and developer/engineer productivity (32% and 34%).

Kim Lewandowski, chief product officer at Chainguard, said the survey makes it apparent that while progress toward securing software supply chains is being made, much work still needs to be done as silos between the developers and security leaders who are ultimately responsible for application security persist. While more organizations than ever have embraced DevSecOps best practices to achieve that goal, the cultural and technical challenges many organizations encounter are often underestimated, she noted.

The issue, as always, is that given the limited resources available, many organizations, despite their best efforts, are clearly still finding it difficult to stay current with updates to remediate vulnerabilities as they become available.

November 9, 2023
MongoDB Allies With AWS to Generate Code Using Generative AI

MongoDB and Amazon Web Services (AWS) announced today that they have extended their existing alliance to provide examples of curated code to train the Amazon CodeWhisperer generative artificial intelligence (AI) tool.

Amazon CodeWhisperer is a free tool that generates code suggestions based on natural-language comments or existing code found in integrated development environments (IDEs).

Andrew Davidson, senior vice president of product for MongoDB, said developers that build applications on MongoDB databases will now receive suggestions that reflect MongoDB best practices. The overall goal is to increase the pace at which a Cambrian explosion of high-quality applications can be developed, he added.

Generative AI is already fundamentally changing the way applications are developed. Instead of requiring a developer to create a level of abstraction to communicate with a machine, it’s now possible for machines to understand the language humans use to communicate with each other. Developers, via a natural language interface, will soon be asking generative AI platforms to not only surface suggestions but also test and debug applications.

The challenge developers are encountering is that generative AI platforms such as ChatGPT are based on large language models (LLMs) that were trained using code of varying quality collected from across the web. As a result, the code suggested can contain vulnerabilities or may simply not be especially efficient, resulting in increased costs because more infrastructure resources are required. In addition, the suggestions that surfaced can vary widely from one query to the next.

As an alternative, AWS is looking to partner with organizations like MongoDB that have curated code to establish best practices that can be used to ensure better outcomes. These optimizations are available for C#, Go, Java, JavaScript and Python, the five most common programming languages used to build MongoDB applications. In addition, Amazon CodeWhisperer enables built-in security scanning and a reference tracker that provides information about the origin of a code suggestion.

There’s little doubt at this point that generative AI will improve developer productivity, especially for developers who have limited expertise. DevOps teams, however, may soon find themselves overwhelmed by the amount of code moving through their pipelines. The hope is AI technologies will also one day help software engineers find ways to manage that volume of code. On the plus side, the quality of that code should improve thanks to recommendations from LLMs that, for example, will identify vulnerabilities long before an application is deployed in a production environment.

Like it or not, the generative AI genie is now out of the proverbial bottle. Just about every job function imaginable will be impacted to varying degrees. In the case of DevOps teams, the ultimate impact should involve less drudgery as many of the manual tasks that conspire to make managing DevOps workflows tedious are eliminated. In the meantime, organizations should pay closer attention to which LLMs are being used to create code. After all, regardless of whether a human or machine created it, that code still needs to be thoroughly tested before being deployed in production environments.

November 6, 2023
Backslash ASPM Platform Prioritizes DevSecOps Efforts

Backslash this week made generally available a namesake application security posture management (ASPM) platform that identifies and prioritizes vulnerabilities based on how easy they are to exploit and reach.

Backslash CEO Shahar Man said the goal is to provide a comprehensive approach to providing a vulnerability exploitability exchange (VEX) platform integrated with tools for software composition analysis (SCA), static application security testing (SAST), secrets detection and creating software bills of materials (SBOMs).

That approach makes it possible to visually model threats within the context of the actual application architecture, noted Man. Armed with those insights, it then becomes possible to address cybersecurity issues by pinpointing the lines of code impacted and also identifying the developer who wrote that code.

While there is a pressing need to improve application security, current DevSecOps workflows are inefficient because there is simply too much noise, said Man. Development teams are inundated with alerts that lack any meaningful context, so after a while, they simply start to ignore them, he added.

In addition, cybersecurity teams will often create a spreadsheet with a long list of vulnerabilities to be addressed without knowing whether the code impacted is accessible via the internet or whether the code that might be affected is actually running in a production environment, said Man.

Other issues may involve transitive dependencies in open source software that developers might not even be able to address without the maintainers of those projects providing a patch.

Streamlining DevSecOps workflows has become crucial in an era where organizations are about to be held much more accountable for the security of the applications being deployed. Today, development teams are lucky if they can allocate 10% of their time to remediate vulnerabilities. Organizations need to be certain that time is spent addressing issues that could have the most impact on the business. Otherwise, a level of fatigue sets in the results in developers making the same cybersecurity mistakes time and again, noted Man.

The Backslash platform, on average, identifies one critical toxic flow for every 100 security alerts produced by other tools, he added. Once critical issues are identified, it becomes possible to more effectively apply the limited resources available to improve the overall state of application security in a meaningful way.

The debate, in the meantime, over how far left to shift responsibility for application security continues. In theory, developers are in the best position to remediate issues, but most of them have limited cybersecurity expertise. DevSecOps teams are generally going to be in a better position to identify which issues need to be addressed based on the severity of the risk they might represent. Otherwise, it’s probable IT teams will wind up wasting their time fixing issues while others that might lead to a major breach or blithely ignored.

Regardless of the approach to DevSecOps, the need for a common framework of understanding is crucial if the cultural divide between development teams and cybersecurity professionals that has existed for decades is ever going to be effectively bridged.

November 3, 2023
Software Deployment Security: Risks and Best Practices

In an era where software is at the heart of every business, deploying applications securely and efficiently has never been more critical.

From cloud-based systems that manage sensitive customer data to mobile apps that drive consumer engagement, software deployments come with a wide array of security challenges. Missteps in the deployment process can lead to disastrous consequences, ranging from data breaches to system outages.

This article covers the risks involved in software deployment and provides best practices to mitigate these dangers effectively.

What is Software Deployment?

Software deployment refers to all the processes involved in making a software system available for use. It’s a broad term that includes various stages like installation, configuration, testing and optimization. In simple terms, software deployment is the bridge that connects software developers with the end-users, allowing them to use the software product.

The primary goal of software deployment is to make a software application ready for use in a specific environment, be it a test environment, a staging environment or a production environment. It starts with installing the software system, which involves copying and configuring the software application on the servers where it will run. It then proceeds to the configuration of the software system, which involves setting the system parameters to meet the specific needs of the environment it will be running in.

Software deployment doesn’t end once the software system is up and running. It also includes monitoring and optimizing the software system to ensure it runs smoothly and efficiently. Moreover, it involves the implementation of updates and patches to fix bugs and enhance the software’s performance.

Risks in Software Deployment

Like any other process in the SDLC, software deployment comes with a set of risks that can potentially disrupt your software development projects:

Code Tampering

One of the risks in software deployment is code tampering. This happens when unauthorized individuals access the software code and alter it for malicious purposes. Code tampering can lead to the introduction of bugs, the loss of functionality or even the creation of security vulnerabilities.

To mitigate the risk of code tampering, it’s important to implement access controls that limit who can access your software code. Additionally, you should use version control systems that track changes made to your software code, allowing you to identify and rectify any unauthorized changes.

Third-Party Vulnerabilities

Third-party vulnerabilities are another risk in software deployment. These are vulnerabilities in third-party libraries and components used in your software application. If these vulnerabilities are exploited, they can compromise your software application.

To mitigate the risk of third-party vulnerabilities, it’s important to keep your third-party libraries and components up-to-date. Furthermore, you should regularly audit your third-party libraries and components for vulnerabilities and take the necessary steps to patch them.

Configuration Errors

Configuration errors are one of the most common risks in software deployment. These are errors in the configuration of the software system that can lead to the system not functioning as intended.

To mitigate the risk of configuration errors, it’s important to have a thorough testing process. This should include both functional testing to ensure the system works as intended and configuration testing to ensure the system’s configuration is correct.

Inadequate Environment Isolation

Inadequate environment isolation is another risk in software deployment. This happens when the test, staging and production environments are not properly isolated, leading to issues like data leakage or the unintentional deployment of untested code to the production environment.

To mitigate this risk, you should ensure that your test, staging, and production environments are properly isolated. This includes having separate servers for each environment and implementing access controls to prevent unauthorized access.

Lack of Monitoring

Lastly, the lack of monitoring is a risk in software deployment. Without proper monitoring, it’s difficult to identify and rectify issues in your software system.

To mitigate this risk, you should implement a robust monitoring system that allows you to track the performance of your software system. This should include error tracking to identify and rectify issues and performance monitoring to ensure your software system runs efficiently.

Common Deployment Strategies and Their Security Implications

Blue-Green Deployment

Blue-Green Deployment is a release management strategy designed to reduce downtime and risk by running two identical production environments, known as Blue and Green. At any time, only one of these environments is live, with the live environment serving all production traffic.

The primary security implication of the Blue-Green deployment is the risk of data inconsistency during the switchover. If not properly managed, sensitive data could be exposed, lost or corrupted. Furthermore, because two environments are maintained, security measures must be duplicated, potentially leading to inconsistencies and vulnerabilities if not properly managed.

Canary Deployment

Canary deployment is a strategy where new software versions are gradually rolled out to a small subset of users before being deployed to the entire infrastructure. This strategy allows teams to test and monitor the performance of the new release in a live environment with less risk.

Canary deployment can potentially expose new software versions to a smaller user base, potentially exposing vulnerabilities before a full-scale release. If a vulnerability is exploited during this stage, it could lead to a security breach affecting a subset of users. There is also the risk of vulnerabilities or malware “leaking” from the canary environment to the main production environment.

Feature Toggles

Feature toggles, also known as feature flags, allow developers to enable or disable features in a live environment. This means that new features can be deployed into the production environment but kept hidden from users until they are ready for release.

The main security risk with feature toggles is that if they are not correctly implemented, they can potentially expose unfinished or untested features to end-users, leading to potential vulnerabilities being exposed.

Rolling Deployment

Rolling deployment is a strategy where the new version of software is gradually deployed across all servers or nodes in the infrastructure, one after the other. This strategy ensures that there is always a version of the software available to users.

The primary security implication with rolling deployment is that there will be a period where different versions of the software are running concurrently. This could lead to potential vulnerabilities if the newer version has security improvements that the older version lacks.

A/B Testing Deployment

A/B testing deployment is a strategy where two versions of the software are run concurrently, with some users directed to the new version and others to the old version. This allows teams to test the performance and user acceptance of the new version before a full release.

The primary security implication of A/B testing deployment is similar to that of rolling deployment: different versions of the software running concurrently could potentially expose vulnerabilities. Additionally, directing users to different versions could potentially expose them to different levels of risk.

7 Best Practices for Secure Software Deployment

1. Code Reviews

Code reviews, also known as peer reviews, enable developers to learn from each other, enhance code quality and ensure adherence to coding standards. It’s a practice where multiple eyes scrutinize the code, spotting potential sources of vulnerabilities that a single developer might overlook.

However, code reviews are not just about hunting for bugs. They also foster knowledge sharing and collaboration amongst team members. A thorough code review process can help in identifying reusable code, reducing code complexity and increasing overall code efficiency.

2. Automated Security Scans

Automated security scans are another essential tool in your arsenal for secure software deployment. They help in identifying vulnerabilities in your code, such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF) that attackers can exploit.

Implementing automated security scans in your deployment process can save you a significant amount of time and resources. It allows you to detect and fix vulnerabilities before the software is deployed, reducing the potential for security breaches.

3. Environment Hardening

Environment hardening involves taking measures to secure your system against potential threats by reducing its attack surface. It includes practices like removing unnecessary software, services, and users, setting up firewalls and configuring system permissions.

One of the most critical aspects of environment hardening is system patching. Timely patching ensures that your system is not vulnerable to known security flaws.

Moreover, environment hardening also includes measures like regular system audits and continuous monitoring. It’s not a one-time process but an ongoing effort to ensure the security of your software deployment.

4. Principle of Least Privilege

The principle of least privilege (PoLP) is a crucial principle in secure software deployment. It stipulates that a user or a process should only have the minimum privileges necessary to perform its function. This limits the potential damage in a security breach.

Implementing PoLP requires a clear understanding of your system and the roles and responsibilities of each user or process. Regular audits can help ensure that PoLP is being followed and that unnecessary privileges are revoked promptly.

5. Secure Configuration Management

Secure configuration management is an essential practice in ensuring the security of your software deployment. It involves maintaining a standard, secure configuration for your system and regularly checking and updating it to address evolving threats.

The first step in secure configuration management is establishing a baseline configuration that adheres to industry best practices. This configuration should then be applied to all systems.

Regular audits should be conducted to ensure systems adhere to the baseline configuration. Any deviations should be promptly identified and rectified.

6. Immutable Deployments

In an immutable deployment, once a version of the software is deployed, it is never modified—any changes cause a new version of the software to be deployed. This approach reduces the risk of configuration drift and makes your deployments more predictable and reliable.

While implementing immutable deployments may require a shift in your deployment practices, the security and reliability benefits are significant. It can also help simplify the deployment process and make it more efficient.

Mastering the art of software deployment is a journey that involves the careful implementation and continuous improvement of various practices. While the road may seem long and winding, the destination—a secure and efficient software deployment process—is well worth the effort.

November 2, 2023
Measuring the Progress of the OpenTelemetry Project

The biggest compliment you can pay a technology standard is to say that it is “boring.”

Transport layer standards like TCP and UDP are boring. They are the underlying protocols powering pretty much everything we do on the internet. REST is boring. It brokers trillions of API transactions across the world’s distributed microservices.

Infrastructure standards get boring when they become common infrastructure plumbing that “just works.” They give open source creators and maintainers common foundations to innovate on top of. They give users confidence that their technology choices aren’t leading to dead ends. Look at any major evolution in computing, and it’s always propped up by boring standards.

When OpenTelemetry debuted at KubeCon in 2019, telemetry data for applications in distributed systems was far from boring. Two competing projects—OpenTracing and OpenCensus—were trying to encapsulate best practices around the still nascent distributed tracing discipline. They were “very similar in that they aim[ed] to unify app instrumentation and make observability a built-in feature in every modern application” (Merging OpenTracing and OpenCensus: Goals and Non-Goals). But having two fragmented communities around these two projects made it hard for distributed tracing to move forward—so it was a big deal when the two projects merged and OpenTelemetry was born.

Let’s take a look at how the OpenTelemetry standard is making this all possible.

Standard Semantic Conventions and a Single ‘Mental Model’

Semantic conventions are important to standardize how we describe common operations so that we have consistent telemetry for similar actions. Developers instrumenting applications need to be able to relate to clear semantic definitions to understand how to instrument everything from database drivers to SQL statements and how to consume that telemetry data for analysis.

For example, OpenTelemetry semantic conventions define where in the metadata the process name should be stored, but not what the process name should be. Similarly, if I’m deploying my application on Kubernetes on a cloud provider somewhere, I’d expect my telemetry data to have the Kubernetes pod and namespace it originates from, as well as the cluster and region.

OpenTelemetry also standardizes metadata for labels that span languages. So if I have an HTTP service and request, it doesn’t matter if it is in Java, Python or any other language — with OpenTelemetry, I can just start querying the data without having to think about the language behind it.

It brings a consistent mental model to how the different telemetry data types (traces, metrics, logs) are related: OpenTelemetry gives them the same base, so understanding how a span is modeled provides knowledge that can be reused when understanding metrics and logs. It can be used by any microservice and any HTTP- or gRPC-connected service or device. For any network device, OpenTelemetry gives developers semantic conventions that bring consistency to reporting telemetry data on any type of event. So, any engineer working with OpenTelemetry can compare latencies and queries between services—even if they are written in different languages—because of the semantic conventions.

Protecting Users From Vendor Lock-In

A decade ago, monitoring and logging vendors provided agents to their customers. They didn’t call it observability back then. But they told the market that if you want the best telemetry data, you need to use our agent. Every vendor had its own agent.

Adding these agents was risky and took a lot of time. Once a vendor got its agents into a customer’s environment, they were hard to change and you had to either pay the vendor or your team of engineers to remove that instrumentation in favor of another.

OpenTelemetry really commoditized the telemetry definition in such a way that we don’t need to use agents from vendors anymore. This means users can decide which vendor to use for observability tooling and have the flexibility to switch to different vendors down the line. With OpenTelemetry, they no longer have to instrument applications, restart applications and get into risky operations cycles to change the destination of their telemetry data.

Economies of Community – Scale for Drivers and Integrations

OpenTelemetry has achieved a very large and diverse set of contributors in a relatively short period of time. It’s become the second most popular CNCF project, behind only Kubernetes.

The project is drawing contributions both on the instrumentation side of things, as well as the collection side of things. Specifications are another big area where the project is evolving, including the API/SDK spec, the data model and the OTel protocol (OTLP). Accelerating all of this is the fact that OpenTelemetry has broad participation from the logging, monitoring and observability vendor ecosystem, which comprises many of its largest contributors.

We still have a ways to go. But in the last year, it’s become obvious that OpenTelemetry is so commonly regarded as the standard for tracing data that the language, library and database creators and maintainers are instrumenting for OpenTelemetry. This is the ultimate sign of maturity for any project or standard—when its popularity has created pull from maintainers designing around the spec and using it natively.

What’s Next For OpenTelemetry?

Looking to the future, I think we’re going to see an unintended consequence where OpenTelemetry moves the industry from operational data to more data intelligence. OpenTelemetry makes it much easier to instrument how users are interacting with systems and enables developers to add business metrics and compare those against actual user behavior.

OpenTelemetry also has a great potential marriage with eBPF and related projects like Cilium. These abstractions that make the Linux kernel “programmable” add a pool of much finer-grained telemetry data that can be extracted into logs from applications during run-time.

This all feeds into the concept of “Profiles” that OpenTelemetry is implementing. While distributed tracing emphasizes the horizontal cut of how a specific transaction is running or all the services that are tied through a single request, a profile is a different vertical cut that emphasizes the state of resources like memory, CPU and more at a point in time. Those profiles are collections that are stored continuously and another great slice of telemetry data that will be encapsulated by the OpenTelemetry standard.

October 31, 2023
FAQs for Software Testing: All the Background You Need

No matter what type of application you and your team are building, testing is a critical step in the software development life cycle (SDLC) that can not be overlooked. In this article, I’ll answer frequently asked questions about software testing, why software testing matters and suggest best practices to help ensure your application is ready to delight customers by the time it is deployed.

Why Do We Need Testing?

Software testing involves evaluating an application to see if it meets the requirements and functions it was built for. The process includes identifying defects, errors and bugs, along with flaws in user experience. Software testing is so critical because finding and fixing these bugs and issues in the development process means the end product reaching customers works properly and reliably and delivers a high-quality user experience. Additionally, testing during the development process makes bugs easier and less expensive to fix as opposed to making fixes after an application has been deployed.

Overview of Testing Types

Let’s quickly define the common types of software testing:

● Unit Testing: This process evaluates individual components of software to ensure they are working properly.
● System Testing: This involves ensuring an entire application or system meets requirements and functions as it should, end to end.
● Integration Testing: This looks at whether or not different modules of an application or system work properly together.
● Regression Testing: This process revisits previously tested components of software to make sure they work correctly after a change has been made.
● Acceptance Testing: This process determines whether an application meets the needs of end users and is ready to be deployed.
● Usability Testing: This process assesses how user-friendly a customer will find the product.

Creating the Plan

Any solid software testing plan is going to incorporate multiple testing approaches, including manual, automated, user experience, exploratory and non-functional testing. You’ll start by defining the scope for what parts of your application, integrations and functionality you need to test for. Then, you can decide what type of testing methods are needed for each and document these to ensure consistency.

You’ll want to combine code coverage and test coverage to ensure the code for your application is tested thoroughly. The type of tests you prioritize will vary based on different products, and your testing strategy will certainly evolve and grow over time.

Measuring Your Strategy for Thoroughness and Effectiveness

To ensure your testing strategy is thorough and effective, you will need to make sure to test for code, device coverage and all aspects of user experience. The bottom line for the program should be delivering value to the business by making sure the application works as intended for users. To be effective, testing should take place before an application reaches end users, so issues and bugs can be identified and fixed before deployment. To be thorough, testing strategies must be balanced, end-to-end, and look at functionality, usability, accessibility and more.

Effective software testing can be measured in a few ways, including:

● Code Coverage: The percentage of code that is tested.
● Test Case Effectiveness: The percentage of test cases that found defects or bugs.
● Time to Detect and Fix Defects: The time it takes to find and fix issues in an application.
● Defect Density: The number of defects found per unit of code.

Improving Your Testing Approach

Your software testing program should be evolving and improving over time and can improve by:
● Including test-driven development
● Leveraging a shift-left approach
● Using automation where possible
● Benchmarking QA for current projects versus previous ones
● Conducting a cost-benefit analysis

Testing Best Practices

While the below list is not exhaustive, here are some top best practices to keep in mind as you build out a software testing practice at your organization:
● Incorporate the voice and feedback of your customer into product design
● Make accessibility a priority
● Test throughout the entire SDLC, including in pre-production, after changes are made to code, and in-sprint testing
● Maintain a matrix for the different devices using your application
● Prioritize high-quality user experience
● Automate repetitive tests where possible
● Review and adjust testing processes regularly, as needed
● Track and report results to analyze trends and identify areas for improvement
● Balance between leveraging different testing types

Your organization’s software testing strategy directly impacts the quality of the end application you deliver to your customers. Poor usability, accessibility, and reliability of an application can frustrate users and send them to competitors, while high-quality user experiences and application performance can boost adoption and keep customers happy and loyal to your brand. With so much competition, taking the time to build out, adjust and prioritize software testing is critical for modern businesses.

October 30, 2023
IBM Applies Generative AI to Ansible Playbooks

IBM has extended the reach of the generative artificial intelligence (AI) tools it provides to automate the writing of code to the Ansible IT automation framework.

Ruchir Puri, chief scientist for IBM Research, said watsonx Code Assistant for Red Hat Ansible Lightspeed provides a natural language interface that makes the domain-specific language used to create the Ansible playbooks that automate IT workflows much more accessible. That approach, in effect, will help democratize DevOps best practices by lowering the skills bar required to embrace Ansible, he added. In addition to making it simpler to employ Anisble more widely within enterprise IT organizations, it will also make it possible for smaller organizations with more limited programming expertise to embrace DevOps as well, noted Puri.

IBM has been working with its Red Hat arm on Project Ansible Lightspeed, an effort to apply generative AI to IT automation, since 2022. With the addition of watsonx Code Assistant for Red Hat Ansible Lightspeed, there is now also a generative AI tool for writing code that IBM trained using the Granite large language model (LLM) that is based on a decoder architecture capable of predicting what code comes next in a sequence.

The difference between the IBM approach and other copilot tools is that the LLMs used are trained by IBM using curated code to minimize hallucinations that result when general-purpose LLMs trained using conflicting data are used to generate code, noted Puri.

IBM is now similarly committed to applying watsonx Code Assistant to other domain-specific languages as part of a larger effort to reduce the cognitive load required to build and continuously modernize software regardless of what programming language was used to construct it. IBM last summer also previewed a tool for converting COBOL code into Java code that can run on a mainframe.

There is no doubt that generative AI will have a profound impact on how software is developed. The next major challenge will be to converge DevOps workflows with the machine learning operation (MLOps) workflows that data scientists and engineers employ to build AI models, said Puri. The goal is to streamline the deployment of AI models that will soon be embedded in almost every application, he added.

Organizations will also need to learn how to deploy and manage some type of vector databases to customize an existing LLM by presenting their own unstructured data in a format that an LLM can recognize. The LLM then uses that external data alongside the data it was originally trained on to generate better-informed responses and suggestions. Organizations can then go a step further by using a framework to build and deploy an AI application. Some organizations may even go so far as to build their own LLM to ensure the highest level of accuracy.

The number of organizations that have the data scientists, data engineers, application developers and cybersecurity experts required to build and deploy generative AI applications is still fairly limited, but as it becomes possible to employ natural language to write code, it’s now only a matter of time before it becomes much simpler to converge tasks that previously each required mastery of a domain-specific programming language.

October 30, 2023
OpsCanvas Generates Code to Automate DevOps Workflows

OpsCanvas, Inc. today emerged from stealth to unveil a Draw & Deploy platform that generates code to provision cloud infrastructure.

OpsCanvas CEO Brian Kathman said as an alternative to traditional infrastructure-as-code (IaC) tools, this offering makes DevOps practices more accessible to a wider number of organizations.

The OpsCanvas platform analyzes application architecture diagrams to deterministically create known-good code that the company has vetted to replace scripts DevOps teams would otherwise have to create. The platform then, via a single click, makes it possible to automate common tasks for deploying, cloning, updating, rolling back, extending and decommissioning resources.

Unlike generative artificial intelligence (AI) platforms, OpsCanvas does not use a large language model (LLM) to generate code. Instead, vetted code is created based on the diagrams that the platform creates. OpsCanvas also encodes best practices, standardized network topology for applications and provides integration with multiple continuous integration/continuous delivery (CI/CD) platforms.

As a result, DevOps teams are provided with a comprehensive view of diagrams, including the number of stored versions and deployment status, for every application deployed.

The goal is to enable organizations of any size to manage entire DevOps workflows using a platform that can generate more than 10,000 lines of already-tested, custom configurations in less than 30 seconds, said Kathman.

In effect, OpsCanvas aims to democratize DevOps by eliminating the need for specialized skills to provision and deploy applications. In addition to accelerating the pace at which applications are built and deployed, that approach will also make it feasible for more small-to-medium businesses (SMBs) to embrace DevOps, noted Kathman.

Regardless of the path chosen to make DevOps more accessible, the days when software engineers wrote scripts to provision cloud infrastructure are now numbered. Either using code that has been vetted by platforms such as OpsCanvas or relying on co-pilots to generate code using large language models (LLMs), provisioning and deploying applications is about to become both simpler and more secure.

Many of the cybersecurity issues that organizations experience today can be traced back to misconfigured infrastructure provisioned by developers using IaC tools. As generative capabilities become more widely used, the quality of the code used to provision infrastructure should substantially improve. As that transition occurs, DevOps engineers should be able to allocate more of their time to address more complex challenges.

One way or another, DevOps is about to become less tedious in ways that should help reduce burnout that leads to turnover. At the same time, the number of organizations capable of embracing DevOps best practices should increase as it becomes simpler for IT administrators who lack programming skills to provision infrastructure.

In fact, the velocity at which software is built and deployed today is about to exponentially increase in a way that most DevOps professionals never imagined might be possible.

October 24, 2023
OpsMX Adds Deployment Firewall to Ensure Compliance

OpsMx today added a deployment firewall to its Deploy Shield portfolio for securing continuous integration/continuous delivery (CI/CD) platforms.

The deployment firewall automatically applies rules to ensure DevOps teams comply with mandates such as the payment card industry data security standard (PCI DSS) or the Health Insurance Portability and Accountability Act (HIPAA). It then evaluates a release against a checklist of policies and blocks any deployments into a production environment unless a specific exception has been defined. In those instances, DevOps teams can also set an alert to address that issue at a later date.

In addition, DevOps teams can extend those rules defined by OpsMX to address specific compliance requirements.

The checklist includes making sure vulnerability scams have been run, tracking when the manifest was last updated, confirming that operational controls are being followed, checking whether images have been modified and evaluating the infrastructure being employed and performing an analysis of the performance impact.

A simulation feature also allows developers to check their release for compliance before it is time to deploy.

OpsMx CEO Gopal Dommety said the goal is to streamline the effort that is required to meet multiple compliance mandates as the pace at which applications are being developed and deployed continues to increase.

Today there are simply too many data silos for DevOps teams to manage, with each one presenting yet another opportunity to run afoul of a compliance mandate, he added. The overall goal is to reduce the cognitive load being placed on developers as more responsibility for compliance is shifted left, noted Dommety.

The deployment firewall currently supports DevOps platforms such as Jenkins, Argo and Spinnaker, with support for GitHub Actions and GitLab to follow.

OpsMX claims its overall customer base has increased by more than 60% in the first half of this year, with customers including Google, Cisco and Western Union. In addition to Deploy Shield, the company provides a Delivery Bill of Materials (DeliveryBOM) tool to capture a consolidated record of every step in the application software delivery and deployment process. Security checks, approvals, policy enforcement and audits are tracked via one tool. In addition, the company provides tools for managing the deployments of software via either the Argo or Spinnaker CD platforms.

It’s now only a matter of time before various regulations that apply to the building and deploying applications become more stringent. Tolerance for sloppy application development processes is dropping as legislative bodies increasingly determine that software development practices are a big cybersecurity problem that threatens national security and the global economy.

Organizations that fail to comply with those regulations will be subject to even heftier fines than the ones that already exist. In many cases, that may slow down the rate at which applications are deployed unless DevOps teams find ways to manage compliance-as-code more effectively as part of a larger DevSecOps workflow.

When it comes to DevSecOps, progress tends to be slow in most organizations, but as more tools become available to automate various tasks, it’s now only a matter of time before software supply chains are more tightly secured. Hopefully, the pace at which those advances are being made will occur faster than cybercriminals can exploit the vulnerabilities that today are too numerous to manually track.

October 23, 2023