
Category: Blogs
-

Snyk Adds Second ASPM Tool to Portfolio
Today, Snyk made available an edition of its application security posture management (ASPM) tool for assessing application risks that provides more context into how code has been written and its role within the application environment.
Manoj Nair, chief product officer for Snyk, said Snyk AppRisk Pro leverages artificial intelligence (AI) and machine learning to provide deeper insights into how applications have been constructed. Snyk AppRisk Pro, for example, can trace insecure portions of deployed applications all the way back to the specific code components.
Armed with those insights it then becomes simpler for DevSecOps teams to prioritize their remediation efforts, said Nair.
Snyk originally released Snyk AppRisk late last year and subsequently acquired Helios, a provider of tools for collecting security data from runtime environments via integrations with third-party tools and platforms from Dynatrace, SentinelOne and Sysdig, last January. That capability has now been integrated into Snyk AppRisk Pro.

In addition, Snyk AppRisk Pro also adds the ability to scan for secrets in code that cybercriminals might later discover.
Snyk Working With Google
Snyk has been working closely with Google to apply AI to DevSecOps. Most recently, Snyk announced its support for Gemini Code Assist, a tool for generating code using the Gemini large language model (LLM) created by Google. The integration with Snyk helps identify security vulnerabilities in code before applications are deployed. That’s critical because LLMs are trained using examples of code of varying quality from across the Web. As more code is created using generative AI tools, the probability of vulnerabilities in that code is high because the code used to train an LLM is often flawed. In effect, DevSecOps teams need tools that use AI models to identify vulnerabilities created by other AI models.
Hopefully, as generative AI continues to advance the overall quality of the generated code will continue to improve. The next generation of LLMs is being trained using code that has been vetted for quality. That’s crucial because most of the issues that cybersecurity teams usually need to resolve start with mistakes made by developers that cybersecurity teams then need to convince developers to allocate time to fix. Thanks to the rise of DevSecOps best practices, the overall security of software supply chains is improving. The simpler it becomes for developers to identify issues as they write code the more secure applications will become.
Of course, writing more secure code is only one element of the overall equation. DevSecOps teams will also need to continue to scan code after it’s been added to a build and as updates are made to applications already deployed in production environments. It’s now only a matter of time before more stringent regulations are implemented that will require organizations to attain and maintain higher levels of application security.
The challenge, as always, is modernizing legacy DevOps workflows that typically were designed to build and deploy code as fast as possible rather than ensuring application security requirements are being met.
-

Spotify to Provide Opinionated Instance of Backstage IDP
Spotify today announced it is making commercially available an instance of its internal developer portal (IDP) based on the open source Backstage platform the company earlier contributed to the Cloud Native Computing Foundation (CNCF).
Pia Nilsson, senior director of engineering for Spotify, said Spotify Portal for Backstage, available as a private beta today, provides platform engineering teams with low-code/no-code framework for setting up an IDP.
In addition, Spotify is now making enterprise support available for organizations that adopted Backstage, along with additional plug-ins that simplify integrations with tools and platforms from third-party vendors such as New Relic, Atlassian, Snyk and Datadog.
Finally, Spotify is adding capabilities to manage hackathons and surface usage insights. A forthcoming plug-in also promises to make it possible to add data entities to a software catalog residing in Backstage.

Backstage has been gaining traction as an IDP mainly because it provides an extensible framework for centralizing the management of developer environments.
Spotify Portal Implementation
Some organizations have found it challenging to build and deploy Backstage. So Spotify is now making available a more opinionated Spotify Portal implementation that is simpler to deploy, configure and manage using templates, noted Nilsson.
As applications have become more challenging to build there is more focus on improving developer productivity. At the same time, IDPs enable platform engineering teams to streamline the number of tools being employed in a way that serves to reduce the total cost of software development.
Many developers want to add tools as they best see fit, so DevOps teams need to find a way to strike a balance between reducing the cognitive load developers encounter and what could become an overly heavy-handed approach to centralizing DevOps workflows. If talented developers start heading for the exits because they don’t like the experience being provided, IT leaders will find it difficult to replace them.
Giving DevOps Teams More time
The hope is that IDPs, when used within the context of platform engineering, will give developers more time to focus on writing business logic. However, application development is as much art as it is science. Just because developers have more time it does not necessarily follow that the insights and inspiration needed to write code automatically ensue. IDPs and platform engineering, at the very least, however, create the opportunity for developers to write more business logic faster. The degree to which that occurs naturally varies from one organization to the next.
Each organization will need to decide to what degree to embrace platform engineering, but regardless of their level of commitment IDPs can play a critical role in making it simpler to onboard developers to new projects, noted Nillson. In addition, an IDP makes it simpler for DevOps teams to track metrics such as the rate at which code is being updated, she said.
IDPs, of course, are not necessarily ideal but with the rise of Backstage there is clearly now more standardization, as DevOps teams continue to seek to eliminate as much friction as possible.
-

Five Great DevOps Job Opportunities
DevOps.com provides a weekly DevOps jobs report through which opportunities for DevOps professionals are highlighted to better serve our audience.
Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained so when one DevOps professional takes on a new role it tends to create an opportunity for others. We’re also committed to providing additional insights into the state of the DevOps job market.
These five job postings are selected based on the hiring company, the vertical industry segment and naturally, the pay scale offered.
In the meantime, for your consideration.
Springer Nature Group’s Scientific American
New York City/Washington D.C.
Director of DevOps
$170,000 to $210,000CareerBuilder.com
HRL Laboratories
Malibu, CA
Senior DevOps Engineer
$145,745 to $186,688Indeed.com
CAST.ERA
Arlington, VA
DevOps Engineer
$130,000 to $150,000Dice.com
VetsEZ
Remote
Lead DevOps Engineer
$100,000 to $125,000LinkedIn
GE Digital
Remote
Senior DevOps Engineer
$96,000 to $144,000Photo by Scott Graham on Unsplash
-

Copado Applies Generative AI to Salesforce Application Testing
Copado today made generally available a generative artificial intelligence (AI) tool to automate testing of applications built for Salesforce software-as-a-service (SaaS) application environments.
Announced at a Salesforce World Tour event in New York, Test Copilot is based on an instance of the ChatGPT generative AI platform developed by OpenAI. Dubbed CopadoGPT, that platform is being embedded across the company’s DevOps platform to accelerate the building and deployment of custom applications on Salesforce’s various platforms. Test Copilot can also translate a recorded user session into a functional test script. Existing test scripts that need to be modified can also be pasted into the prompt.
David Brooks, senior vice president of evangelism for Copado, said Test Copilot will make it simpler to create tests that ultimately improve the quality of the applications being deployed. Test Copilot via a prompt can also convert existing tests, Selenium tests, or results from Copado Explorer into a reusable, maintainable robotic test. Test Copilot can also create test cases for application programming interfaces (APIs) to supplement user interface (UI) and end-to-end testing processes.

Test Copilot is an extension of Copado Explorer, a test automation platform the company launched last month. Its goal is to simplify testing custom applications more thoroughly, said Brooks. The “Holy Grail” is to reduce the technical debt any IT organization accumulates by ensuring that issues are resolved before applications are deployed, he said.
Eventually, the cost of iterating updates to applications will drop to the point where organizations can continuously update applications, both before and after deployment, noted Brooks.
It’s not clear what impact generative AI will have on testing and DevOps workflows. However, the level of toil most software engineering teams encounter is about to be sharply reduced. The challenge is to find the best way to operationalize generative AI platforms that are probabilistic. Not every prompt is going to generate the exact same output, so embedding generative AI across a team of software engineers working on the same application remains challenging.
Generative AI will also make it easier for stakeholders outside of the DevOps teams to participate in application testing. In effect generative AI will make it simpler to push testing responsibilities even further left beyond developers, noted Brooks.
In the meantime, however, DevOps teams should be identifying tasks that AI tools will soon automate. The way applications are built and deployed is about to fundamentally change, especially as more advanced reasoning capabilities are embedded into LLMs. In time, DevOps teams will find themselves invoking LLMs that have been trained to automate a range of complex tasks. Exactly how those advances will impact the way DevOps teams are structured remains to be seen but certainly, software engineering will never been the same again.
Photo credit: Joe William on Unsplash
-

IBM Confirms: It’s Buying HashiCorp
In the hybrid-cloud world, we all knew that HashiCorp, makers of the popular infrastructure as code (IaC) tool Terraform, was looking to be acquired.
We also knew that switching Terraform’s open source Mozilla license for the Business Source License (BSL 1.1) had left plenty of unhappy Terraform developers and partners in its wake. Those open source users created a Terraform fork called OpenTofu. OpenTofu took off quickly, causing lawyers to get involved.
But that kerfuffle didn’t stop IBM from announcing it was buying HashiCorp for a cool $35 per share, a deal adding up to a premium value of $6.4 billion.
IBM chairman and CEO Arvind Krishna announced the acquisition in a Q1 financial call. Krishna remarked, “As generative AI continues to evolve, the complexities in tech strategies have significantly increased. HashiCorp’s stellar record in simplifying this modern infrastructure sprawl makes them an ideal addition to IBM’s hybrid cloud vision.”
The HashiCorp acquisition fits neatly with IBM’s 2019 acquisition of Linux and cloud power Red Hat. From a technical viewpoint, Ansible and Terraform are well-suited to work together. IBM clearly hopes that HashiCorp Terraform and Vault, its secret and encryption manager, will help strengthen its hybrid cloud and DevOps efforts.
HashiCorp’s co-founder and CTO Armon Dadgar is enthusiastic about joining forces with IBM. “This merger is not just a growth trajectory for HashiCorp but a gateway to bring advanced cloud solutions to a broader audience, accelerating innovation and enterprise efficiency in cloud management.”
HashiCorp’s CEO, Dave McJannet, agreed. “IBM’s leadership and rich history in hybrid cloud innovations make it the perfect home for HashiCorp as we step into a vigorous phase of our growth.” IBM sources say that McJannet will report to Rob Thomas, IBM’s senior VP in charge of software.
The Industry Responds
“According to our research, more than six tools are used by organizations to support cloud computing and automation. The combination of IBM, Red Hat, and potentially HashiCorp product portfolios suggests changes in cloud computing and the overall automation landscape,” said Paul Nashawaty, a practice lead at The Futurum Group. “It is an alliance of seasoned professionals that goes beyond a simple technology merger to give organizations the tools and insights they need to manage the complex web of modern IT with efficiency and foresight.”
While HashiCorp’s licensing move seems to have paid out for HashiCorp’s investors, IBM’s investors don’t seem so keen on the deal. In early after-market trading, IBM’s shares declined. Even before the BSL 1.1 changeover appeared, HashiCorp’s revenue growth had been slowing.
It should be noted that while IBM’s earnings were lackluster in most areas, the financial call called out positive news in software. Krishna and CFO Jim Kavanaugh credited Red Hat, especially its OpenShift hybrid cloud platform and its Ansible DevOps platform, for this growth. Kavanaugh said, “Both offerings also continued to take market share this quarter.” Specifically, Red Hat’s revenues grew 11% year-over-year, with OpenShift growing over 40%.
Setting the business aspects aside for now, it’s an open question what this will mean for Terraform and OpenTofu. Will IBM return Terraform to its open-source roots? Will IBM, a top Linux Foundation member, try to unite the warring sides? Stay tuned. It’s going to be a bumpy ride.
Photo credit: Hamid Roshaan on Unsplash.
-

Embrace Adds Support for OpenTelemetry to Instrument Mobile Applications
Embrace revealed today it is adding support for open source OpenTelemetry agent software to its software development kits (SDKs) that enable observability of iOS and Android applications.
Andrew Tunall, head of product for Embrace, said that as more DevOps teams standardize on OpenTelemetry to collect telemetry data from applications, there is a growing requirement for observability platforms to support it.
DevOps teams can now use the Embrace SDKs to export telemetry data from mobile applications to any backend observability platform that supports OpenTelemetry, he added. Initially, Embrace is providing support for logs and traces, with support for metrics to soon follow.
Embrace developed an observability platform initially designed specifically for engineering teams working on mobile applications. Now many of those teams are collaborating with DevOps teams as more organizations take a mobile-first approach to application development, noted Tunall. Embrace customers include Adidas Runtastic, Cameo, GOAT, Hatch, Ibotta, Marriott, The New York Times, Warby Parker, Yahoo! and Wildlife Studios.
OpenTelemetry Gaining Traction
Being advanced under the auspices of the Cloud Native Computing Foundation (CNCF), OpenTelemetry defines an instrumentation format that makes it simpler to centrally manage the collection metrics, logs and traces using open source software. It is gaining traction as more DevOps teams look to rationalize the amount of commercial agent software they need to deploy, update and manage.

Too many organizations, however, are still relying on legacy real user monitoring (RUM), error and bug tracking, and crash reporting tools to manage mobile applications that don’t provide the level of insight required to identify the root cause of a performance issue said Tunall. Observability platforms, in contrast, make it possible for DevOps teams to collect telemetry data they can query versus tracking a few simplistic metrics, he added. In the case of Embrace, the data includes signals such as crashes, errors, application not responding (ANRs), performance traces, memory issues and full user sessions.
Cost-Efficient to Centralize the Management of Applications
Mobile applications require that capability because they can be especially challenging to troubleshoot when, for example, trying to account for network latency as DevOps teams seek to achieve and maintain specific service levels to ensure a high-quality application experience is consistently delivered, noted Tunall. Most end users are not especially forgiving whenever they experience an issue because it’s often relatively trivial for them to switch to another application, he added.
It’s not clear to what degree teams that were once dedicated to managing mobile applications are being folded into DevOps teams but just about every organization that builds software now supports at least one or more mobile applications. While mobile applications have unique requirements, it’s ultimately going to be more cost-efficient to centralize the management of applications regardless of what platform they run on.
In the meantime, DevOps teams should expect the overall size of the mobile application portfolio to only continue to grow. The challenge now is melding the tools currently used to manage those applications with the DevOps platforms currently being used to manage every other type of application.
-

AIOps Success Requires Synthetic Internet Telemetry Data
Any form of artificial intelligence (AI) is only as good as the data used to train it. If organizations expect to effectively apply AI to IT operations (ITOps) they need to collect as much telemetry data as possible.
IT teams frequently discover that their AIOps platform was been trained on a narrow base of telemetry data. It might have been collected from, for example, a DevOps platform that lacks complete visibility into the distributed computing environment where their application runs. In the absence of the synthetic telemetry data collected from an Internet performance monitoring (IPM) platform to collect that telemetry data, it’s simply not likely the machine learning algorithms that are at the core of any AIOps platform are going to surface the best recommendations for optimizing application experiences.
The challenge is the probabilistic nature of AI. The relevancy of the recommendations that surface is determined by the quality of the data that has been exposed to the AI model. Real user data, for example, may be sparse or non-existent. Of course, if telemetry data was never shared with the AI model in the first place, it’s extremely unlikely that the AI’s recommendations will to better application experiences.
Gaining Visibility Using Synthetic Data
IT teams need to be certain the data used to train the AI model reflects the production environments where applications are deployed. Otherwise, no matter how advanced an AI model may be, garbage in still equals garbage out. Before any IT team adopts an AIOps platform, it needs to know the data provenance of the underlying AI model. If the pool of AI training data is limited, the recommendations generated will be, too. IT teams are not going to put their faith in AIOps platforms that are advising them to take specific actions based on partial or incomplete data. Nor should they.
Instead, the teams will assume that every output needs to be verified before the next step in a process is allowed to proceed. After all, the only thing worse than being wrong when it comes to IT and AI is to be wrong at catastrophic scale. Of course, continuing to manage IT sequentially arguably defeats the purpose of investing in an AIOps platform that is supposed to manage tasks in parallel.
Given the dependency modern applications have on Internet services, any effort to apply AI to IT management that doesn’t include synthetic Internet telemetry data will lead to a suboptimal outcome. By including this type of telemetry, the insights being surfaced to DevOps teams will enable them to ensure key performance indicators (KPIs) are attained and maintained.
Multiple AI Models
There’s not likely to be one AI model to rule them all. In many cases, networking, security, and other IT service management (ITSM) platforms will have already applied AI to the telemetry data they collect in real time. The output from those AI models will then be shared with AIOps platforms to automate a series of tasks on an end-to-end basis that previously would require IT teams to orchestrate workflows across multiple islands of automation.
DevOps teams, as a result, need to evaluate the efficacy of what will soon be a network of AI models. There are so many, each of which is or will be designed to automate specific tasks, such as analyzing Internet traffic to identify the source of bottlenecks that might only intermittently impact an application. Armed with insights, it then becomes possible for the AIOps platform to consistently generate useful recommendations that DevOps teams can trust. Then they can let the tools automatically apply the suggestion to how, for example, Internet traffic should be rerouted to maintain service level objectives (SLOs).
Realizing the Promise of AI
As AIOps platforms improve, they can substantially reduce much of the toil that DevOps teams regularly encounter. Teams can spend weeks trying to determine the root cause of an issue that, once discovered, might take a few minutes to fix. The challenge is that the source of the issue often has little to do with anything the DevOps team has immediate control over, as is the case when, for example, latency created by an Internet service adversely impacts application performance. However, those insights should enable DevOps teams to send support requests that better pinpoint the exact source of an Internet service issue that their provider should be able to resolve faster. Just as importantly, the DevOps team can move onto issues that they have more direct control over.
Much of the stress that any DevOps team experiences stems from not knowing the real cause of issue that despite their best efforts continues to generate a series of ongoing alerts. AIOps promises to reduce that stress by making it simpler to first correlate causation and, secondly, automate remediation. That promise, however, will never be fully realized if the data being relied on to train the AI model doesn’t provide enough of the picture required to make a truly informed decision.
-

Five Great DevOps Jobs Opportunities
DevOps.com is providing a weekly DevOps jobs report through which opportunities for DevOps professionals are highlighted as part of an effort to better serve our audience.
Our goal in these challenging economic times is to make it just that much easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained so when one DevOps professional takes on a new role it tends to create an opportunity for others.
The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and naturally, the pay scale offered.
We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration.
LinkedIn
Visa
Senior Director of DevOps Engineering
Bellevue, WA
$173,400 to 271,000SimplyHired.com
Publicis Sapient
Dallas
DevOps Architect – Kubernetes
$140,000 to $180,000Indeed.com
UBS
New York City
Software Engineer – DevOps
$135,000 to $165,000Dice.com
NBC Universal
Englewood, NJ
Manager for DevOps Monitoring and Control
$130,000 to $170,000CareerBuilder.com
BAE Systems
Nashua, NH
Software Engineering Tools DevOps Administrator
$112,142 to $191,070
