devopsy.kinsta.cloud

Tag: application code

Postman Makes AI Tool for API Management Platform Available

Postman today generally made available a generative artificial intelligence (AI) tool for its platform for building and managing application programming interfaces (APIs) that automatically creates tests and documentation.

Announced at a POST/CON 2024 conference, Postbot is included with version 11 of the Postman platform which also adds workspaces that make it simpler for software engineering teams to collaborate.

Postman CEO Abhinav Asthana said the overall goal is to improve the quality of the APIs being developed while at the same time reducing the level of friction that occurs as APIs are developed and updated.

Developers are already making extensive use of AI tools to write code, but Postman is using a combination of open-source large language models (LLMs) and LLMs from Open AI and Microsoft to automatically generate tests and documentation based on the data its platform collects. In addition to making it easier to create API tests using a conversational interface, the overall quality of those tests will improve using LLMs specifically trained using Postman data, noted Asthana.

Developers Need to Rely on AI Tools

That’s critical because the ratio between developers and the number of services that expose APIs is much too high, said Asthana. Developers will need to rely more on AI tools to create and manage APIs as the number of services they are expected to manage continues to steadily increase.

It’s not always clear who within organizations is managing APIs. Developers undoubtedly create APIs, but the management of APIs might be assigned to a DevOps team. As more organizations embrace platform engineering as a methodology for managing DevOps workflows at scale the more likely it becomes APIs will be managed centrally.

Ultimately, the rise of microservices-based applications has dramatically increased the number of APIs that need to be managed. APIs play a crucial role in making data available externally to other applications. However, the bulk of APIs being created today are for integrating all the microservices that make up a modern application environment. Those largely internal APIs are increasing at a pace that makes it challenging for individual developers to manage at scale. As a result, many organizations now have a significant API change management challenge, noted Asthana.

Each organization will need to determine to what degree the management of microservices is sustainable. Rather than getting caught up in philosophical debates, many organizations are deploying a mix of microservices alongside monolithic applications that also expose an API. In effect, monolithic applications are becoming large microservices. Regardless of approach, the number of APIs, including rogue and zombie APIs that organizations either didn’t realize were built or have simply been forgotten, is dizzying. In many ways, APIs in the absence of a management framework quickly become too much of a good thing.

There are multiple ways to manage APIs but the one thing that is critical to remember is the approach taken needs to integrate well with the tools used to create those APIs in the first place.

May 1, 2024
Unused Code: Proving a Negative

We have a ton of code that is no longer being exercised. We really don’t talk about it much, but it’s out there. From feature flags shutting off code to API versioning making an interface obsolete, it’s just hanging around out there. Like an albatross. Waiting for someone to misuse it. Or, to address the more pedestrian concerns, confusing people new to the codebase. But that code is not contributing a thing.

Easy example. You are on version 3.2 of your API. Version 2.1 is not called by anything, but the code is still hanging out there. It is not that 2.1 cannot be called, but that it is not currently called. The problem with that is that new devs have to work through what’s current, and since 2.1 and 3.2 probably share 95% of their code bases, what portion of that code base is unused? And the API is sitting there, waiting for someone to penetrate your network and find malicious uses for it.

Proving a Negative

But here is the problem: Identifying that a bit of code–be it an API, a method, just a few lines in an if statement, whatever–is never exercised is terribly difficult and, in highly complex environments, borders on the impossible (it is never impossible, assuming IT owns all of the code that could exercise that bit). The old adage about proving a negative absolutely applies. We can–and testing tools in both the functional and security spaces do–generate a list of code that is exercised, or identify code that isn’t being exercised. But not a list of code that is never exercised. That functionality in test tools is super useful, because it helps prioritize issues that are being used a lot and leaves the ones not seeing a ton of traffic for later resolution.

But I’ll say that in most organizations, that’s no longer far enough. The cruft in your code causes problems, and you need to clean it up. If you’ve worked in IT for any length of time, you’ve been through the “Oh, that bug is because the developer called something no longer used” scenario at least once. And it is a straight-up waste of time.

So here is my proposal. Test tools generate a list of what isn’t called from systems under test. Pick one–security testing or functional testing–and require it for any bit of code, no matter how small, to go into production. That means that the system knows about all source code and thus knows definitively if a bit of code has been exercised.

Clean Up as You Go

Is that a tall order? Yes. Testing isn’t free. But given a scenario where you reduce technical debt by eliminating excess code, I think it will pay for itself. And that is not counting the security posture improvement that reducing the code base implies.

You’re running the systems that present your organization to the world, so you may as well do some due diligence on yourselves. Keep making cool new stuff and upgrading the old, but clean up as you go with some form of monitoring, this or a more procedural one, so the quality is high and the excess is low.

September 13, 2023
Building DevSecOps With Value Stream Management
As teams develop software, testing for potential security risks and flaws is mission-critical, just as it has always been. Yet, cyberattackers continue to exploit code vulnerabilities as open source code remains the foundation for the majority of commercial applications across all industries. Security firms are churning out solutions at an aggressive rate, and both project managers and their teams hope they can purchase some bolt-on tool or license a service to take care of security, painlessly. In the end, vulnerabilities still occur.

The most effective pathway to secure software code has always been to eliminate vulnerabilities. The question today is, “What is the best way to achieve that goal given such an accelerated, threat-laden landscape?” Before we dig into that answer, let’s take a closer look at the problem.

Software Security Is Everyone’s Issue

Even the largest organizations, from Adobe to Microsoft, have been humbled by the number and scope of code vulnerabilities that have been overlooked—and therefore escaped into public release—due to the frenzied pace of software updates. Here’s just one example:

On May 11, 2021, Adobe issued a security update for Adobe InDesign that addressed multiple critical vulnerabilities. “Successful exploitation could lead to arbitrary code execution in the context of the current user,” the security bulletin read. “Arbitrary code execution in the context of the current user” is cybersecurity speak for “an attacker can execute arbitrary commands or code on a target machine or process.” Arbitrary code execution vulnerabilities are known to be one of the top attack vectors that lead to system penetration resulting in data breaches.

Given the enormous effort companies and their software teams are exerting today, and the importance of avoiding software flaws in the current threat landscape, how is this happening? It doesn’t help to have publicly available lists of software vulnerabilities posted on the dark web and CVE (ironically, a database of vulnerabilities launched to help companies improve their cybersecurity). Hackers — from solopreneurs to nation-state teams — are having a field day with this information.

Rearranging the Puzzle Pieces Doesn’t Guarantee Security

In an attempt to resolve this challenge, industry professionals are coining new terms and calling for new approaches. One I have seen promoted recently is “SecDevOps” rather than “DevSecOps.” With SecDevOps, they assert, security is first—conducted at the start of the project and maintained all the way through.

This approach isn’t new—it’s essentially a variant of shifting left, which for more than a decade has been an established mechanism in software testing for finding flaws and “failing faster.” In my experience, while failing earlier and faster with any software endeavor has considerable value, it is not automatically going to highlight all security challenges and enable their resolution.

It is just as important for DevSecOps teams to collaborate and work together, not only to support development and operations, but also to ensure security, compliance and governance are built into every piece of code.

Insight Is Preferable to Blind Interpretation

Unfortunately, achieving that collaboration productively comes with challenges. DevSecOps teams need rich, real-time visibility into code vulnerabilities, early, so they can act on that information and update code as it moves through the pipeline. To do that, they need actionable insight—not a motley assortment of data that’s open to interpretation.

In value stream management, we have seen firsthand while working with our clients that several techniques can be applied to eliminate vulnerabilities more quickly and effectively. All of these approaches hold value, whether a firm is seeking to deliver a new product to market or secure its current software pipeline.
- Amplify feedback loops. Continuous feedback loops—from DevSecOps tools, for example—give developers more detailed insight into their code’s vulnerability.
- Run security scans. Give testers the ability to run security scans on their code even before it is committed to identify security vulnerabilities as early as possible.
- Leverage reporting and analytics. Gaining early access to as much insight as possible makes teams and management more confident regarding swift action to resolve code deficiencies.
These approaches also support governance and compliance initiatives. As a bonus, they boost software quality, as well.

The Business Case for Built-In Security, Governance and Compliance

As mentioned earlier, these activities are integrally connected with the effort to eliminate code vulnerabilities. In case you are thinking, “This is obvious,” take a moment to reflect on this statistic: 60% of data breaches involved vulnerabilities for which a patch was available but not applied.

The sheer scope of the problem also underscores the lack of attention to security and governance—and any compliance requirements that accompany it.

Half of websites in production have high-risk vulnerabilities, and 82% of these are located in application code.

The high percentage of errors in source code suggests it was not checked for vulnerabilities during development, signaling that developers focused on app functionality and gave short thrift to security. This often means they don’t have a program for governance and compliance, either.

In my experience, a primary reason for these failures is that teams don’t have actionable information from the activities mentioned above, such as real-time feedback from DevSecOps tools. Developers need this insight when they are resolving sprint backlogs. Information relating to high-level security issues must be available so it can be addressed, with issues prioritized and resolved, and not left sitting in siloed DevSecOps tools.

In many ways, DevSecOps is in the same stage of transformation as DevOps was a decade ago. Teams are frustrated by needs they do not know how to meet, and they hope for fast resolution in the form of tools and solutions. As with virtually every other software challenge over time, there is no replacement for getting in the trenches and fixing the problem rather than placing strategic band-aids.

If you are not subject to compliance mandates and therefore dismiss the value of software governance, consider this: If your team misses a software vulnerability that results in a major data breach because you didn’t have the insight to identify it—or the governance to ensure it was addressed—your firm may not recover. The imperative for software security—and the governance that helps ensure it stays that way—should be sufficient for organizations to take vulnerabilities seriously.

Effectively applying the insight gleaned from software code reporting and analytics is the surest way to eliminate vulnerabilities. As an added benefit, the reporting and analytics that informs the software effort can also make the case to upper management for the value of launching future improvement initiatives.
August 27, 2021
Integrating z/OS Systems for Cross-channel Experiences

Integrating z/OS Systems to Enable a Seamless Cross-channel Customer Experience

Many industries where customer experience is the critical differentiator run on z/OS systems. That includes retail, financial services, transportation, hospitality, government, and more. As a result, integration of z/OS systems into any customer-oriented application or with front-end applications is essential.

Just how important is the issue? More than two-thirds of companies now primarily compete based on customer experience. That’s up from 36% ten years ago. Companies like Jet Blue and The Ritz-Carlton Hotel Company have historically been known for their exceptional customer service. And eyewear provider Warby Parker, widely appreciated for its customer experience, is known for a legendary example of above and beyond service when an executive returned a pair of glasses to the home of a customer who had left the glasses on an Acela train ride.

Beyond multi-channel to omni-channel

Many businesses offer multiple ways for customers to interact with their company. It is not unusual for a company to support interactions via the web, in-person, mobile, voice, text, and chat. That way, every customer can use their preferred method to ask questions, review account information, check on an order status, get information, search, place orders, and more.

What differentiates one company from another is when a business offers a seamless cross-channel customer experience. Often called omni-channel, a seamless cross-channel experience is a multi-channel approach to serving customers that offers an integrated and cohesive customer experience no matter how or where a customer reaches out.

We’ve all experienced the siloed approach that treats each channel separately. You’re doing something online such as placing an order, checking the status of a service request, or inquiring about your account. An issue occurs such as a phone line dropping, your mobile phone’s screen is too small to carry out the task, or you simply want to talk to someone in person. You switch from mobile to Web, or phone to in-store, and there is no connection or carryover between what you have already done and now. You need to reenter information, answer the same questions, and walk through the same steps.

In contrast, the interaction with a business that delivers a seamless cross-channel experience is much different. An agent on the phone knows you’ve had trouble placing an order online, the in-store representative is expecting you to drop off an item for repair, and when you log into your account online, you are taken to the part of the process you were at on your mobile device.

Integration is the key

Omni-channel customer experience seamlessly integrates the different communication channels that businesses use to communicate with customers. Customer demand for a seamless cross-channel experience is pushing businesses to change. The number of companies investing in an omni-channel customer experience has jumped from 20% in 2010 to more than 80% in 2020.

As a result, z/OS users are racing to adapt to the new realities of the omni-channel customer experience. Users expect that data and applications will be as readily available on mobile devices, the web, or via phones as they are on desktop clients.

Developing a seamless cross-channel user experience can mean a significant amount of new application coding. What’s needed is a way to easily transform proven applications and system-of-record data using modern APIs to accelerate the delivery of new services and meet changing customer expectations.

To tightly integrate z/OS systems for such efforts requires the embracement of modern application development methodologies. That includes providing developers with solutions that let them retain the decades of efforts that went into the core applications running on their z/OS systems while building new applications that tap into these systems.

Businesses must make available to their developers the commonly used open-source development, workflow automation, and CI/CD tools to the z/OS environment to accomplish this. Such a strategy will help businesses speed the development of new applications to meet changing demands of their customers. It allows a business to leverage the data and applications on its z/OS systems and create innovative new applications.

Developing new customer applications while retaining the core business functions, processes, and data on the z/OS systems ensures that all front-end access makes use of a single source of truth about the customer. There is only one record associated with each customer. Such integration of z/OS systems thus makes it much easier to keep all the channels aligned and lets businesses deliver the prized and highly desired seamless cross-channel customer experience.

July 14, 2021
Survey: Fixing Bugs Stealing Time from Development

A global survey of 950 developers published today finds more than a third (38%) of developers spend up to a quarter of their time fixing software bugs, with slightly more than a quarter (26%) spending up to half their time fixing bugs.

Conducted by the market research firm Propeller Insights on behalf of Rollbar, a provider of artificial intelligence (AI) tools to detect software errors, the report also notes that 88% of developers find traditional error monitoring tools are not meeting expectations.

Daniel Day, vice president of marketing at Rollbar, said the survey makes it apparent that continuing to rely on manual processes to surface errors in code is having a major downstream impact on both DevOps teams, in particular, and the business as a whole.

For example, nearly nine in 10 developers (89%) also noted that undetected errors take a big toll on the business. More than one-fourth (26%) of developers also said that their employers have lost a significant number of users due to errors in software. The same share (26%) said software errors damage their company’s reputation and its ability to attract investments, and nearly a fifth (18%) said that undetected software problems anger their company’s investors.

Nearly a third (32%) of developers said they spend up to 10 hours a week fixing bugs instead of writing code, while 16% said they spend up to 15 hours a week. Another 6% said they have to dedicate up to 20 hours a week fixing bugs instead of writing code.

More than half of developers (55%) said that if they didn’t have to spend so much time fixing bugs, they would have the time to build new features and functionality. Many of these errors are not addressed because current tools require them to manually respond to errors (39%); it takes too long to find all of the details they need to fix bugs and errors (36%); focus on system stability and not enough on code health (31%); make it difficult to detect errors (29%); and have an approach to error aggregation that is either too broad or too narrow (23%).

Nearly two-thirds of developers (62%) said they have found out about errors from users reporting through the application, while a quarter (25%) said that they have heard about errors from users sharing these issues on social media. Another 17% said media coverage clued them in about errors in their software, while more than a fifth (21%) said they heard about them from their CEO.

Nearly a third of the survey group (31%) said that manually responding to errors makes them feel frustrated, while more than a fifth (22%) said they feel overwhelmed when using manual processes to address errors in software. Nearly as many (17%) said it leads to burnout. More than a tenth (12%) said it elicits feelings of resentment, and 7% said it makes them want to quit their jobs.

Nearly two-thirds of all developers said they would rather do an unpleasant activity than fix errors, including pay bills (26%), go to the dentist (21%) and spend time with in-laws (20%).

Rollbar clearly has a vested interest in convincing developers to increase reliance on AI to surface errors in code. The productivity paradox holds that, the more application code developers write, the more time they spend fixing existing code than writing new code. Most developers have a lot better things to do with their time than manually combing through lines of code looking for those errors. In fact, the problem is, many of them simply don’t have the time required to catch all the issues before an application makes it into a production environment.

February 16, 2021
OverOps Partners With GitLab to Analyze Code Earlier

OverOps has allied with GitLab to integrate a tool that analyzes code at runtime to identify issues with a continuous integration/continuous delivery (CI/CD) platform.

Eric Mizell, vice president of solution engineering for OverOps, said the plugin for the GitLab CI/CD will make it easier to surface issues with code earlier in the DevOps pipeline. OverOps’ quality gates help determine if code is safe to promote and automatically blocks unstable releases from moving forward to production.

OverOps combines static and dynamic analysis of code as it executes by relying on machine learning algorithms to collect data. That analysis can be accessed either via dashboards based on open source project Grafana software or shared with other tools via an open application programming interface (API). It analyzes code at runtime to identify all new, increasing, resurfaced and critical errors in a release. OverOps then generates a code quality report that ranks issues in terms of potential to impact end users and application functionality.

According to a recent survey of more than 600 software development and delivery professionals conducted by OverOps, more than 50% of respondents spend a day or more per week troubleshooting code-related issues.

The survey also finds that nearly 25% of organizations experience critical/customer-impacting production issues on a daily or weekly basis.

The earlier code issues are detected the less expensive they are to fix. OverOps is making the case for making its tool part of the quality assurance gate within any CI/CD pipeline.

The paradox many organizations find themselves in is that as DevOps processes enable them to build and deploy applications they wind up spending a lot more time debugging those applications.

Eventually, developers wind up spending more time fixing existing application code than developing new applications. Tools such as OverOps are employing machine learning algorithms to reduce the amount of time spent discovering code issues, which should free up more time to write new code.

OverOps captures machine data about every error and exception at the moment it occurs, including details such as the value of all variables across the execution stack, the frequency and failure rate of each error, the classification of new and reintroduced errors and the associated release numbers for each event.

DevOps teams historically rely on log data to manually search for anomalies indicative of issues with code. Not only is OverOps faster, but the algorithms will also surface uncaught and swallowed exceptions that would otherwise be unavailable in log files.

There are a lot of aspects of DevOps that now can be better handled by machines than humans. That doesn’t mean humans will be replaced anytime soon. However, the bulk of time-consuming and monotonous DevOps tasks that exist today are eventually going to be performed by a machine faster and with greater precision. The challenge and opportunity now are identifying the tasks where machine learning algorithms can have the most impact sooner than later.

July 17, 2020