devopsy.kinsta.cloud

Tag: SolarWinds

SolarWinds Adds Service Management Platform to Portfolio

SolarWinds has added a service management capability to its portfolio as part of an effort to make it simpler for IT teams to align support services with specific functions.

At the same time, SolarWinds has updated its SQL Sentry observability tool for databases and DataOps workflows to add query-level wait statistics along with a revamped web portal and dashboard for tracking the overall health of a database environment.

SolarWinds Enterprise Service Management (ESM) makes it possible for IT teams to manage IT services based on the ticketing systems, knowledge bases, service portals and request catalogs available for specific departments such as marketing or human resources.

Kevin Kline, senior staff technical marketing manager for SolarWinds, said that as IT management continues to evolve, there is a greater need to streamline and optimize workflows based on the insight from observability platforms. As a result, there is now a need to apply observability more broadly to include database platforms alongside DevOps and other IT workflows, he noted.

The overall goal is to eliminate the blame game that results when IT platforms are managed in a more siloed fashion, added Kline.

Most IT teams are still relying on monitoring tools to track a set of predefined metrics in the hope that an alert will enable them to proactively address an issue before it leads to a major disruption. However, as IT environments become more complex, there is a growing need for observability platforms so IT teams can launch queries and surface issues that predefined metrics aren’t likely to identify. Initially, observability platforms were embraced by DevOps teams, but it’s rapidly becoming apparent that this capability needs to be applied to every IT process. In effect, organizations are on the cusp of democratizing observability, noted Kline.

Achieving that goal will also become simpler thanks to the rise of machine learning algorithms capable of predicting issues and generative artificial intelligence (AI) tools that will make it simpler to craft queries.

In the meantime, there is already no shortage of observability platforms, but the SolarWinds approach is different in that, in addition to DevOps workflows, the company has integrated its platform with multiple database platforms to provide a more comprehensive approach, said Kline.

It’s not clear just yet how observability platforms might impact the way IT teams are structured, but the need for specialists such as database administrators (DBAs) isn’t likely to go away anytime soon, noted Kline. Instead, the level of collaboration across various IT teams should substantially improve.

In the meantime, IT teams might be well-advised to define an observability strategy today before multiple teams start implementing approaches that might be optimized for a relatively narrow range of use cases. After all, trying to reconcile insights generated by multiple observability platforms may very well defeat the purpose of investing in observability in the first place.

September 25, 2023
Observability Leaders: The Mighty Minority Holding Their Own Against Outages
The job of IT teams has become much harder thanks to the new realities of hybrid IT, with workflows occurring across on-premises and cloud-based networks and applications. Yet so much rests on your ability to respond to these challenges, all while managing the expectations of your customers and the health of your bottom line. With the growing complexity of ecosystems comes the need for better visibility, both into specific systems and across your entire stack.

Observability solutions address this by providing visibility across your network, infrastructure, systems, application, database, digital experience and log monitoring.

In other words, observability enhances your ability to observe your digital ecosystem with more transparency, more effective detection and more intelligent insights. Take, for example, the very timely and pressing issue of outages. On average, the typical business experiences nine brownouts or outages every month, lasting roughly twelve hours each and averaging $13.7M annually, according to new research we conducted at SolarWinds.

Over the course of the year, that can add up to nearly 1,300 hours, with outages chipping away at your organization’s productivity, reputation and competitive edge.

It’s not enough to monitor for these outages and address them once they take down your systems. Repeated or prolonged outages signify a gap in the enterprise’s ability to comprehensively monitor and understand its network’s internal state and performance. A robust observability strategy can preemptively detect anomalies and potential issues—before they become full-blown outages.

According to new data from the 2023 IT Trends Survey released this month by SolarWinds, companies who’ve embraced observability tend to not only lead in detecting, remediating and preventing outages—they’re experiencing better business and IT outcomes, too.

The technology professionals surveyed shared how observability is helping them achieve better performance, compliance and resilience in digital environments—and how you can follow their lead.

Observability Drives Better Business Outcomes

The observability leaders surveyed were 300% more likely to say their organization is doing extremely well with growing revenue and 250% more likely to say the same about their organization’s speed of innovation. Interestingly, they also reported a better employee experience: They were 388% more likely to rate their organization as doing “extremely well” with employee experience and also reported fewer and smaller skill gaps on their teams.

So, how does embracing observability actually translate into better business outcomes? According to the data, observability leaders are…
- Investing in top priorities: Data shows organizations using observability solutions to support the priorities most critical to their growth and success: Improve their customer experience (96%), enable faster innovation (71%), reduce time spent solving (71%) and detecting (60%) issues and increase operational efficiency (55%).
- More automated and integrated: Observability leaders embracing automation and investing in tools that provide enhanced efficiency are 214% more likely to say they are doing extremely well with operational efficiency, 750% more likely to say they are doing extremely well with auto-remediation of complex alerts and 300% better at automatically collecting background diagnostic data for IT support staff.
- Ahead on IT: The data found that those ahead of the curve on observability are also leading by huge margins when it comes to monitoring, detecting and resolving issues that could otherwise bring the business to a screeching halt. When it comes to IT, they are 233% better at auto-escalation of tickets, 213% better at auto-remediation of simple alerts and 36% better at settling alert levels based on historical behavior.
How to Reap Observability Benefits in Your Organization

All told, observability adoption is still in its early days. Only 1% of enterprises are already up and running using observability tools on a regular basis, while another third are undergoing the implementation process.

That’s good news for other businesses who are ready to reap the rewards—it’s not too late to be an observability pioneer.

If you’re interested in bringing observability to your own organization, start by addressing a few important factors that can help you sidestep challenges—such as the accelerating pace of change in technology (72%) or insufficient budget (58%)—that might otherwise obfuscate your observability opportunities:
- Make sure your observability solutions are appropriate for multi-cloud environments: Multi-cloud environments have become standard for many companies because of the many upsides, but they can be challenging for IT teams to manage. Strategically accelerate your organization’s cloud migration with an observability solution designed for complex hybrid and multi-cloud environments to save a lot of headaches down the road.
- Give your teams autonomy—and build toward autonomous operations: Observability brings your enterprise a step closer to autonomous operations. Autonomous operations, where IT systems can govern themselves, providing a proactive approach to addressing issues, rather than reactive, won’t replace your human teams but rather free up their time and brainpower to support the business and drive innovation.
- Don’t ignore the database: Databases represent the most difficult ecosystems to observe, tune, manage and scale. They require significant computing power, tend to be memory-intensive and likely make up the bulk of your organization’s cloud spending. Tasks crucial to the health and functionality of your business—including troubleshooting, root cause analysis and remediation—simply cannot happen without full, transparent observability across the numerous resources a database needs to engage to do its job.
Observability helps balance competing priorities and demystify application requirements while increasing your overall DevOps agility, efficiency and speed to market. Observability not only fosters transparency and collaboration but also encourages a system of ongoing review, which benefits the organization, IT teams and—crucially—your customers.
September 22, 2023
Survey Surfaces Major Observability Challenges

A recent survey found the biggest obstacles to observability were the pace of technology change, IT blind spots and the complexity of modern applications. The survey polled 300 IT professionals to identify the biggest challenges they faced in achieving observability. The accelerating pace of technology change (72%) topped the list, followed by IT blind spots and the growing complexity of modern applications (58% each), and lack of funding (52%).

The survey, conducted by SolarWinds, also found the typical enterprise suffered nine brownouts or outages every month, each of which lasted around twelve hours. The full cost of outages and brownouts averaged $13.7M annually for these enterprises, according to the SolarWinds report.

Jeff Stewart, field CTO and vice president, global solutions engineering at SolarWinds, said the survey makes it clear that a lack of observability is having a material impact on businesses. Organizations are now moving beyond monitoring predefined metrics to embrace observability platforms that make it simpler to investigate the root cause of issues that adversely impact businesses; these businesses are more dependent on IT than ever, he added.

In fact, the primary reason organizations are investing in observability is to improve their customer experience (96%), enable faster innovation (71%), reduce time spent solving (71%) and detecting (60%) issues and improve operational efficiency (55%), the survey found.

While it’s still early days as far as achieving observability is concerned, a lot of progress is starting to be made as organizations realize that complex IT environments require a different management approach. IT teams can no longer afford to navigate multiple monitoring tools in what often turns out to be a vain effort to prevent brownouts and downtime, noted Stewart.

In addition, many IT teams are becoming increasingly aware that the telemetry data collected via an observability platform provides the foundation for infusing IT operations with artificial intelligence (AI) capabilities, he added. The ultimate Holy Grail is to one day achieve autonomous operations, noted Stewart.

There is, of course, no shortage of observability platforms, but Stewart contends that providers of monitoring tools such as SolarWinds are in the best position to help IT teams make the observability transition. Rather than ripping and replacing a monitoring platform, a more seamless transition that results in less disruption is preferable, he noted.

Regardless of approach, observability platforms that enable IT teams to launch queries across complex distributed computing environments are becoming a necessity. Distributed computing environments often have more dependencies than IT teams can manually track. It’s only a matter of time before the most talented DevOps professionals start to migrate to organizations that provide them with the management tools and platforms required to succeed. Otherwise, the stress of managing a complex IT environment will only result in higher rates of burnout among DevOps professionals.

It may be a while before observability platforms are pervasively employed across IT environments, but as it becomes clear that brownouts and downtimes result in a decline in revenue, business leaders will understand what’s required to maximize profits. In many cases, the answer will be an observability platform that surfaces the insights needed to proactively manage modern IT environments.

September 20, 2023
Transforming Observability

Walking into an unfamiliar operations center some time ago, I immediately noticed database error alerts racing down the primary monitor faster than a Matrix screensaver morphs letters. Strangely, no one seemed particularly excited about it. The situation was a head-turner for me, coming as I did from the “everything must balance” banking world.

A senior ops tech quickly explained that airline reservation systems are highly optimized for speed and volume, sacrificing nearly everything else to meet peaks. “No worries; the agents just hit Enter again. Retry logic just slows us down,” they told me. The lesson here was removing constraints can profoundly change a system, much as Dr. Eliyahu Goldratt described in his game-changing Theory of Constraints.

Today, cloud-native architecture, multi-cloud and hybrid cloud platforms, dynamic infrastructure-as-code (IaC), DevOps and our ability to store boundless amounts of data each change or remove constraints in their own way. Observability could be on this list, but I think observability’s transformation is still happening right in front of us.

Observability and OpenTelemetry

Through open source OpenTelemetry (OTel), highly competitive vendors collaborate to shift their offerings up the value chain by supplementing and replacing once highly-prized proprietary agents, interfaces and data specs. There’s no better example of removing a constraint than making these once proprietary agents with an open solution that will have profound effects across the industry.

OTel is a thriving ecosystem of 11 tech companies participating on various boards and committees that also collaborates and integrates with open source projects such as Jaeger, Kubernetes, Prometheus and OpenMetrics. Over 20 observability companies natively support and provide OTel distributions. OTel continues to mature, reaching stability 1.0 release in 2021 and announcing its roadmap for metrics specifications in 2022.

OTel-native support represents a significant commitment from vendors because it means rearchitecting products to distribute data via OpenTelemetry Protocol (OTLP) rather than using OTel SDKs and Collectors frontend internal interfaces. With SolarWinds’ October 2022 announcement, I suspect they will also join the ranks of companies supporting OTel natively in their commercial offerings.

Digital transformation, product and technology leaders see value in observability because of its potential to measure digital experiences and measure the performance of business and digital services. To do this requires observability to meet three significant challenges.

First, observability must effectively cross the complex boundaries of microservices, containers, cloud and traditional applications, multiple cloud providers, database sources, SaaS services, infrastructure and internal and external APIs. Today’s challenge is far beyond the central aggregation of large volumes of log data and suppressing non-essential alerts.

Most enterprise architectures look eerily similar to a breadboard wiring project with applications, systems and data sources crisscrossing each other, representing the various pathways and interfaces across systems. Virtually any of these elements could contribute to the degradation of a digital experience, and observability must operate across these elements whether they live in our tightly controlled data centers or are distributed in microservices, cloud services or third-party interfaces.

With this breadth and depth of visibility, we also need context to match and correlate what appears to be disconnected information and sources. Open source enthusiast Chris Engelbert describes this challenge well:

“The data correlation, the knowledge of how the infrastructure and services are deployed, as well as the dependency tree of applications, services and (eventually) hardware, must be taken into account when providing hard evidence of what is going on in your system.”

Following the Silver Thread

With context and dependencies, observability can allow us to see what software developers call the “silver thread,” the ability to collect the components of systems involved in measuring an experience or triaging a performance issue. Then we can follow the pathway, or silver thread, across all the components, whatever or wherever they are, to find constraints or bottlenecks. For example, a particular API’s poor performance may be due to the location and traversal necessary to reach a needed data source rather than an issue in that API’s microservice or application.

In summary, observability is invaluable to monitoring, operating and triaging modern applications and cloud infrastructure. The adoption and maturation of OpenTelemetry will deliver many benefits, including the removal (or, at least, greater transparency) of traditional boundary constraints. And with the context to understand and follow the silver thread, observability transforms beyond operations to measure digitally delivered business services and experiences.

October 19, 2022
Supply Chain Security: Has the Next SolarWinds Already Happened?

More than two years after the now-infamous hack of the firm SolarWinds, the incident is very much in the foreground of conversations about cybersecurity defense, threat detection and incident response. As evidence of that: The SolarWinds incident was the subject of five separate talks and panels at the recent RSA conference in San Francisco. Dozens more talks addressed issues related to supply chain security that–directly or indirectly–invoked the SolarWinds incident.

That’s because the SolarWinds attack raises important—if not existential—questions for both software development and DevOps teams and the companies running the software. First: If sophisticated cybercriminals can insert malicious backdoors directly into application code from reputable developers, what organization can afford to blindly trust software? Second: If it is now the responsibility of software teams to spot sophisticated, methodical compromises of their development pipelines, what is the best and most reliable means of doing that? Finally, if it is also now the job of software consumers to monitor for—and detect—compromised binaries from otherwise reputable vendors (like SolarWinds), how should they go about doing that given ongoing staffing and technology constraints?

The answers to these questions are matters of debate within DevOps, software development and information security communities. What is beyond debate is that the SolarWinds incident was not a fluke. In the months since that attack, attackers—both criminal and nation-state-backed—have leveraged software supply chain security blindspots to target development organizations as means of gaining access to sensitive IT environments. While we haven’t yet heard of another incident of the scale or importance of SolarWinds, it is entirely reasonable to assume that the next SolarWinds-caliber compromise could already be unfolding, but has yet to be discovered and/or publicly acknowledged.

Software Supply Chain Security Weaknesses

SunBurst, the malicious implant in SolarWinds software, endures as a topic of interest and conversation for information security professionals and for DevOps and development organizations precisely because of the ways it exposed glaring weaknesses in the security of development organizations and software supply chains. As noted in my analysis of the hack in December 2020 and FireEye’s analysis of the same compromise, the SolarWinds hackers gained access to the company’s development environment months before they actually launched their attack. During that time, they closely studied the underlying source code and mimicked SolarWinds style and nomenclature as they added malicious code and integrated it into the SolarWinds Orion application via a compromise of the company’s build system.

Though carefully planned and conducted, the SolarWinds attack wasn’t foolproof. The attackers left clues, such as their additions of native Windows functions, use of cryptography, compression and more. The attackers obfuscated these using compression and Base64 encoding designed to fool simple threat hunting rules that looked for their plaintext variants and other suspicious strings. Still, the obfuscation repeated throughout the implanted code was enough to send up a red flag to anyone who bothered to look closely. That left the attack open to discovery.

The problem is this: Very few software publishers have the staff, expertise or tooling to comb through massive codebases to spot a handful of sketchy obfuscated strings or analyze large binaries for deviant behaviors before deploying them. As evidence of this, ReversingLabs sponsored a survey of more than 300 IT professionals at software-driven enterprises. It found that 87% were aware that software tampering, like what occurred in the SolarWinds attack, could lead to enterprise security breaches. About 40% of those surveyed said CI/CD toolchain exposures posed a risk to their organization. Still, barely a third of respondents (37%) said they had the means to detect such software-tampering attacks.

Threats to Software Development Organizations Grow

Attackers are aware of this weakness within the software development pipeline, which is why threats to development organizations are metastasizing. Just in the last year alone, we have seen a series of attacks on development infrastructure and software supply chains. In one April 2021 incident, attackers were successful in pushing malicious, unreviewed code directly to the PHP main branch, ultimately resulting in a compromised, formal version of PHP being pushed to all PHP websites. That same month, there was a breach at the firm CodeCov, which involved unauthorized access to and modifications of the company’s Bash Uploader script. An investigation of that incident ultimately concluded that the alteration of a single line of code in that script by an unauthorized third party enabled the attackers to (potentially) export information stored in the users’ continuous integration (CI) environments.

More recently, ReversingLabs observed proof-of-concept and “white hat” activities testing so-called “dependency confusion” attacks, in which attackers set up malicious packages in public repositories like GitHub that squat on the names of private, non-public repositories and sport high version numbers. Misconfigurations in package management systems can result in these malicious components being imported in lieu of the legitimate, privately managed namesakes. As ReversingLabs found, a number of malicious modules discovered on the npm platform were used to target German technology, manufacturing and entertainment firms. It was later revealed to be the work of a white hat firm conducting red team exercises on behalf of those firms. Red team exercises aside, RversingLabs research also detected other, malicious packages in npm, as well as similar attacks targeting Ruby Gems and Python Package Index (PyPi).

And that doesn’t even count issues like the Travis CI flaw that exposed (potentially) millions of credentials to developers’ accounts on GitHub, Amazon Web Services and Docker Hub. Lapses like that can fuel supply chain attacks, giving malign actors the ability to insert malicious code into otherwise legitimate open source or proprietary code repositories. After reading such headlines, and without the means to check code intent, how can developers trust their software to update? And how can they do so while at the same time being forced to frequently update their dependencies to reduce or eliminate critical software vulnerabilities?

Dev Teams Need New Tools

For software development organizations struggling to meet delivery deadlines and satisfy customer expectations, reorienting to address amorphous software supply chain threats and attacks is a bridge too far. The same is true for enterprises struggling to staff security teams and simply keep on top of targeted phishing attacks or threats to public-facing IT assets. Too often, these entities only find religion about software supply chain attacks after they have occurred.

What software development organizations need is a way to secure the CI/CD pipelines and release packages, ensuring that their software builds are free of code tampering and other supply chain risks introduced through build systems. That should include the ability to detect compromises by monitoring for malicious software changes and enforcing security controls and failure conditions on software build processes to ensure that you can release your code with confidence.

On the customer end, organizations need a way to detect malicious behaviors and unauthorized software changes in compiled binaries before they are released into production, while also monitoring for risks like exposed secrets or exploitable software vulnerabilities that might lurk in compiled code.

September 2, 2022
SolarWinds Unveils Unified Observability Platform

SolarWinds this week launched an observability platform that makes available a range of tools and technologies that the company has developed and acquired via a common user interface.

Rohini Kasturi, chief product officer for SolarWinds, said the SolarWinds Hybrid Cloud Observability platform also makes an observability platform affordable for a much wider range of organizations.

The platform also makes it easier to discover, map, and understand dependencies in ways that make it easier to achieve and maintain service level objectives, he added.

The SolarWinds Hybrid Cloud Observability is a suite of tools made available via multiple tiers that make it simpler to automatically discover the root cause of an IT issue in addition to making it easier to manage configuration, reporting, and planning tasks across cloud computing and on-premises IT environments, said Kasturi.

As IT teams increasingly distinguish between merely monitoring IT environments and achieving observability that allows them to proactively surface anomalies using machine learning algorithms and other forms of data science, the level of depth and insight that can be applied to managing IT is increasing dramatically. In fact, observability is quickly becoming table stakes for any provider of IT management tools, noted Kasturi.

There is, of course, no shortage of observability platforms. The SolarWinds Hybrid Cloud Observability is designed to be deployed alongside existing monitoring tools rather than requiring IT teams to rip and replace the tools they already employ, said Kasturi.

It’s not clear to what degree IT organizations are embracing observability. As a core tenet of best DevOps practices, observability has always been a goal. However, even the most advanced DevOps teams have thus far achieved little more than continuous monitoring of IT environments that are based on a set of pre-defined metrics. An observability platform not only surfaces anomalies but also enables DevOps teams to launch queries across logs, metrics and distributed traces to identify the root cause of a performance issue before it becomes a major disruption.

The biggest challenge, however, may not be the technology as much as it is simply understanding what queries to launch. As IT environments become more complex thanks in part to the rise of microservices-based applications, the number of potential permutations that might impact a highly dynamic IT environment is increasingly beyond the ability of any IT team to manually track. It’s already apparent that many of the legacy monitoring tools that DevOps teams rely on today will need to be rationalized in favor of tools infused with machine learning algorithms capable of discerning patterns across a complex IT environment.

In the meantime, IT teams will need to spend a considerable amount of time experimenting with observability platforms in the months ahead. After all, applications don’t magically instrument themselves. However, once IT teams do find a way to aggregate the logs, metrics and traces that can be collected from one application environment, it does become easier to define a set of best practices that can eventually be more widely applied.

April 22, 2022
Welcome to the New Field of Software Supply Chain Management

Supply chain management is the newest ‘shiny object’ in both the DevOps and DevSecOps communities. But what does it mean in relation to software development?

Historically, supply chain management is a commerce term that refers to tracking the logistics of goods and services moving between producer and consumer. This would include the storage and flow of raw materials with a focus on the channels that support the process.

When we look at this concept from the perspective of software development, we will soon see that it is a new form of software configuration management. Yes, the new SCM is … SCM. The core of supply chain management is the process of controlling changes in software. The new SCM expands those old practices to include all ‘raw materials’ which we manage as part of our software build and package steps. For instance, when companies purchase and download open source libraries used in their in-house software. Supply chain management includes the interrogation of these ‘raw materials’ as well as all of the internal code and libraries. We will soon be hearing more about software bill of materials (SBOM) reports and difference reports, as they are critical for understanding the objects that flow through the software we create.

The software supply chain or software configuration management practice hasn’t been talked about much until recently. This area of expertise has never been ‘sexy.’ That is, until the SolarWinds supply chain hack. The SolarWinds hack was a hard lesson to learn, but it taught us to take a closer look at how we consume our raw materials and to be more serious about how we build and package our software.

According to FireEye, the firm that discovered the backdoor supply chain hack:

“SolarWinds.Orion.Core.BusinessLayer.dll is a SolarWinds digitally-signed component of the Orion software framework that contains a backdoor that communicates via HTTP to third-party servers. We are tracking the Trojanized version of this SolarWinds Orion plug-in as SUNBURST.”

It was obvious, something went very wrong with the creation of that .dll. I don’t pretend to fully understand how this breach occurred. But I do understand the build process and have been talking about the potential for these types of breaches for over 25 years.

There have always been big security gaps and vulnerabilities in our most basic software development practice—the compile/link process. Most build processes are imperatively defined using an Ant, Make or Maven script. Each time the build runs, it rebuilds all the binaries, even if the corresponding source code has not changed.

This is a problem. Instead, we need a build that is incremental. Incremental builds are difficult to script because they need more advanced logic. Most developers are not given adequate time to create a better build process, one that only rebuilds the changes. This means it is next to impossible to audit why a binary was recompiled because they are always recompiled. If we only recompiled the binaries that had corresponding code updates, we could more carefully audit the code and make sure that only approved coding updates were included.

This may not have caused the SolarWinds attack, but it could have. Once hackers have gotten past the firewall they can find the build directory, read through the build scripts and identify the perfect piece of code to update with their bad function. The next time the build runs, a ‘clean all’ recompiles everything and, like dark magic, a SUNBURST is created.

In our not-too-distant past, the developer community had tools that controlled software builds beyond what an imperative script could do. OpenMake Software, for example, provided a build automation solution called Meister that ensured that incremental builds were easy. As part of the build, it generated SBOM reports and differences reports allowing teams to easily audit and compare the actual source changes to confirm that only approved code updates were included. Another example was Rational Software’s ClearCase which used a program called ClearMake. ClearMake used a process called ‘winkin’ to reuse ‘derived’ objects that had not changed. This process created an incremental build that could be easily audited.

I realize that I am simplifying the overall problem, but it is a good example of the basic supply chain best practices and how potentially vulnerable our processes are.

The time to carefully think about how we manage our raw materials and overall supply chain is now. I’m guessing that most monolithic practices will not change much; it is too costly and impactful to rewrite hundreds of CI pipelines. But that does not mean we can’t solve the supply chain puzzle as we shift into cloud-native development in a microservice architecture.

In a microservices architecture, we need to begin thinking about what the supply chain looks like. How do we track raw materials that are in the form of hundreds of small ‘bounded context’ functions? The good news is there is an emerging microservice catalog market that can become part of the supply chain solution. A microservices catalog can track versions of services to versions of their consuming applications. Your new SBOM report will have two levels: First, an SBOM for the microservice. Second, aggregated data at an application level. Remember, in this new architecture a full build is not done.

It’s important to understand that microservices are naturally incremental and are independently built, packaged and deployed. Managing these small services opens the door to more closely auditing their source code before they are released.

As we shift from monolithic development to microservices, we have an opportunity to incorporate supply chain and configuration management best practices. This includes being able to carefully audit the code before a release is done. And remember, we must do this as fast as possible. It sounds like a big task, but it’s well worth the effort. Collectively, we will find the answers as we explore new ways to manage our DevOps pipeline and incorporate configuration management and DevSecOps principles.

October 18, 2021
SolarWinds Unveils Revamped APM Platform

SolarWinds is unifying its various application performance management (APM) tools within a single suite accessed via a software-as-a-service (SaaS) platform.

Denny LeCompte, senior vice president for products at SolarWinds, said the APM Integrated Experience offering combines the company’s AppOptics, Loggly and Pingdom tools to collect metrics, traces and logs along with real user monitoring capabilities and tools to simulate application traffic.

APM Integrated Experience also provides access to a landing page that identifies what has changed in an IT environment over the previous week and highlights which of those changes might become an issue. As most IT professionals well understand, most IT issues can be traced directly back to a recent change made to an IT environment that was previously running as intended.

Other capabilities include advanced search tools and the ability to inspect lists and maps for hosts, containers and plugins for web servers and databases. In addition, APM Integrated Experience is integrated with both Amazon Web Services (AWS) and the Microsoft Azure cloud.

LeCompte said the goal is to make it less expensive for the average IT organization to broadly instrument applications using an agent developed by SolarWinds that can automatically be installed.

Ultimately, the goal is to enable organizations to better manage their software supply chains, LeCompte added. Of course, SolarWinds is at the heart of the software supply chain breach that involved its Orion network management software. That software runs on-premises. In comparison, APM Integrated Experience is a SaaS platform that is more secure. In fact, LeCompte said, IT professionals that manage software supply chains are generally sympathetic to the challenge the company currently faces. Most of those organizations have dealt with similar software supply chain issues, albeit on a smaller scale, LeCompte added.

In general, LeCompte said it’s apparent most organizations need access to an APM platform that costs substantially less than rival platforms and still delivers 90% of the capabilities they require. In many cases, IT organizations are paying for extra capabilities that only very high-end enterprises require, LeCompte noted. In fact, one of the primary reasons APM platforms are not as widely employed is most organizations have found rival APM platforms simply too expensive to deploy, said LeCompte.

LeCompte declined to speculate whether there is a meaningful difference between what has been historically known as monitoring and so-called observability platforms that have emerged in recent months. Regardless of approach, however, it’s clear as distributed IT environments become more diverse and complex, the number of organizations that need more visibility into their application environment is steadily increasing, said LeCompte.

Of course, with the rise of microservices-based applications, that level of IT complexity is only going to increase. As applications grow and expand, the number of dependencies between microservices starts to increase. Understanding how an issue with one microservice is impacting a distributed computing environment will undoubtedly require more instrumentation. The challenge, going forward, will be determining how best to achieve that goal at a reasonable cost.

February 25, 2021
SolarWinds Strengthens AppOptics APM Platform

SolarWinds today updated its AppOptics application performance management (APM) platform by adding both service- and trace-level root cause analysis capabilities.

Jim Hansen, vice president of products, application management for SolarWinds, said the goal is to provide most of the same capabilities any IT organization would find in an APM platform that would cost 10 times more than AppOptics.

That’s critical at a time when thanks to the rise of microservices-based applications based on containers more IT organizations are discovering they need to apply APM platforms more broadly, added Hansen. Previously, IT teams tended to reserve usage of APM platforms to their most mission-critical applications because of the costs involved. However, as SolarWinds moves to drive the cost of accessing an APM platform delivered via a software-as-a-service (SaaS) application, Hansen noted APM platforms are becoming more affordable.

The service-level root cause analysis module is also designed to more accessible to the average IT administrator by reducing the number of steps and clicks required to identify the specific performance problem or issue. A complementary AppOptics trace-level root cause analysis then makes it possible to drill down into application metrics all the way down to specific lines of code and transactions. The goal is to make APM platforms more accessible to IT generalists, said Hansen.

Those service- and trace-level root analysis features are available both in the core platform as well as a free AppOptics Dev Edition tool that SolarWinds makes available for developers.

While AppOptics is the core APM platform provided by SolarWinds, the company also makes available a Loggly log management platform and Pingdom performance monitoring tools for websites. Collectively, those platforms make it easier to manage IT environments that are becoming increasingly complex to manage, said Hansen.

In general, Hansen said IT organizations are starting to converge application and infrastructure management, especially if they have embraced best DevOps processes. In some cases, one member of a DevOps team is managing both, while other organizations are having teams of IT professionals collaborate around the same APM platform.

At the same time, Hansen noted IT organizations want to be able to employ the same APM platform to manage both monolithic and microservices-based applications versus having to acquire separate APM platforms for both types of applications.

It’s too early to say to what degree SolarWinds might be able to usurp rival providers of APM platforms that have been available for more than two decades. However, Hansen noted that in terms of market penetration, fewer than 10% of IT organizations have standardized on an APM platform.

As organizations transition to microservices-based applications, APM platforms become a necessity. The overall IT environment is simply becoming too complex to manually monitor and manage. At the same time, businesses are starting to have a greater appreciation for how dependent digital processes are on software. The issue now isn’t so much whether those organizations need an APM platform as much as it is figuring out which APM platform can they afford.

— Mike Vizard

February 18, 2020
Survey Finds Much Room for APM Improvement

A survey of 317 application owners, developers and support team professionals in the U.S. and Canada published by SolarWinds finds that while reliance on application performance management (APM) tools is widespread, most IT teams are still relying on these tools to react to events rather than to proactively improve application experience and performance.

The survey finds 9 out of 10 IT professionals are making use of APM tools that are either deployed on-premises or accessed via a software-as-a-service (SaaS) platform. Nearly 8 in 10 respondents spend less than 10% of their time proactively optimizing their environments, according to the results.

In fact, the biggest APM challenges identified by survey respondents were lack of training for personnel (57%), followed by a lack of awareness of what APM solutions are currently offered (44%) and confusion over which APM solution best fits their needs (42%).

Jim Hansen, vice president of products for application management for SolarWinds, said some of those challenges stem from the fact that there are too many APM tools to deploy and master. Survey respondents are employing a mix of database monitoring (64%), application monitoring (63%) and infrastructure monitoring (61%).

IT management is further being complicated by the adoption of a wide variety of application architectures. According to the survey results, organizations are applying APM tools to manage monolithic (traditional on-prem) app development architectures (59%), N-tier service-oriented architectures (40%) and microservices-based applications (39%).

Hansen said as organizations increasingly move away from monolithic applications, the need for a more proactive approach to APM across the full stack will become more apparent. The level of dependencies between microservices especially will drive organizations toward APM platforms capable of correlating events across both applications and the underlying infrastructure on which they depend, he noted.

Less clear is to what degree IT teams are comfortable using the analytics surfaced by APM tools to automate the remediation of any given issue. According to the survey results 84% of respondents are confident in their ability to successfully manage application and infrastructure performance, with 40% reporting they are most comfortable from a confidence perspective to use APM tools to troubleshoot application performance issues. The top three insights survey respondents said they gain from APM tools are the ability to prevent application outages (73%), the ability to prevent app slowdown related to performance and/or capacity (63%) and the ability to improve user/customer experience (62%).

In terms of areas for improvement, survey respondents identified improving their current skillset/ability to track impact across key business metrics (31%), followed closely by the need to improve their current skillset/ability to troubleshoot application issues (30%). The ability to improve the performance of application code and manage/ensure/improve end-user performance tied at 29%, respectively.

Of course, troubleshooting an existing issue is one thing. Proactively using APM tools to prevent issues from occurring represents a more advanced approach to managing IT in keeping with best DevOps practices. It will be interesting to see how much the adoption of N-tier and microservices applications will foster further adoption of best DevOps practices.

Most organizations today have embraced DevOps practices to varying degrees. However, as IT becomes more complex to manage in the age of the hybrid cloud it’s now only a matter of time before legacy approaches to managing IT as simply no longer practical to employ.

— Mike Vizard

February 4, 2020