devopsy.kinsta.cloud

Tag: observability

How Engineers are Automating More with Less: Trends in DevOps Tooling

As the software delivery cycle becomes more complex, engineering teams face increased pressure to achieve more with fewer resources. DevOps tooling is undergoing a silent revolution to meet these quick wins. The old way of building complex and heavyweight pipelines and workflows is constantly changing, giving room for a more streamlined and seamless automation-first approach. This is where simplicity, modularity, and cost matter as much as functionality.

According to GitLab’s 2024 Global DevSecOps Survey, 64% of DevOps professionals say they need to consolidate their toolchains due to integration challenges, monitoring issues, and deployment delays. This toolchain is pushing engineering teams to adopt easy, integrated workflows that reduce friction and improve velocity.

At the heart of this, automation shouldn’t require massive overhead. Today, teams are adopting tools that give instant value, which include enabling faster iterations, reduced maintenance overhead, and scaling team capabilities. In this article, we’ll explore the key trends redefining DevOps automation from modular pipelines and developer-first tools to toolchain consolidation and the growing influence of AI, showing how teams are achieving more with less complexity.

The Rise of Efficiency-Driven Automation

In the past, DevOps automation often meant cobbling together CLI scripts, sprawling YAML files, and fragile CI/CD pipelines. While this DIY approach offered flexibility, it came at a cost, making onboarding difficult, building brittle, and tool upgrades a constant source of firefighting.

Today, automation is moving from complexity to clarity. Teams now search and adopt solutions that reduce friction from the start by providing logical defaults, user-friendly interfaces, and plug-and-play components that scale, rather than wiring tools together. This focus has moved from automating everything to automating the right things efficiently and effectively.

Here are four main trends that are driving this efficiency-driven automation mindset

1. Composable Pipelines Over Monolithic Workflows

Modern DevOps teams are currently moving away from the traditional way of implementing a monolithic CI/CD setup. Instead, they’re adopting more composable pipelines built with tools such as GitHub Actions, Dagger, and Temporal. With these tools, teams break down automation into simple and purpose-specific units, such as jobs for running tests in the staging environment, another for pushing to development, and one for sending out notifications.

For example, instead of managing a complex Jenkinsfile with over 500 lines, teams can create smaller steps that are easier to troubleshoot, reuse across repositories, and scale independently. This shift enhances maintainability and allows engineers to focus on shipping code instead of managing complex YAML.

2. Developer Experience Takes Center Stage

Modern automation tools are shifting towards enhancing developers’ experience, making the automation of engineering tasks simple, intuitive, user-friendly, and less error-prone.

In a non-complex environment, instead of logging into several servers individually or battling with Kubernetes for minor maintenance tasks, engineers can use CloudRay to centrally manage and execute Bash scripts across servers using predefined templates and schedules through a clean UI. For example, a team managing several VMs can automate daily security patches or log rotations across several servers without the need to SSH into each server.

Additionally, platforms like Railway and Qovery offer similar attributes that reduce repetitive configurations while still maintaining their flexibility and control. As a result, engineers spend less time troubleshooting CLI scripts and navigating YAML files. Rather, they focus on solving meaningful problems.

4. Event‑Driven and Pull‑Based Models

Engineers are shifting automation towards an event-driven and pull-based model. Tools like ArgoCD and Flux are getting adopted because they apply the GitOps principle to manage infrastructure. Engineers no longer rely on manual triggers or constant pulling. Instead, they’re adopting tools that react to Git event, which treats GitHub repositories as the single source of truth.

For example, using these tools, merging a PR can automatically trigger a deployment with the exact change history preserved in Git. Additionally, it can simplify rollback and collaboration by linking infrastructure updates to version control, thereby reducing drift and production errors.

5. Cost-Conscious and On-Demand Automation

Cost optimization is one of the key selling points in automation in modern times. With the rise in serverless and edge platforms, automation has become more cost-efficient. Tools such as AWS Lambda, Vercel Functions, and Cloudflare Workers enable the engineering team to trigger tasks only when necessary. This eliminates the need to keep CI/CD runners on all the time, thereby reducing costs while maintaining performance. This is mostly used for lightweight workflows, scheduled jobs, or bursty tasks where automation can scale down to zero when not in use, and spin up instantly when triggered.

The evolution of DevOps tooling is transforming how teams approach automation. Automation is not seen as a complex practice to maintain, but a lightweight system that works.

Consolidation of DevOps Tooling

As engineering teams become more aware of the overhead associated with tool expansion and integration, many of them are reconsidering their DevOps stacks. The trend is not about choosing a “do it all” tool, but about consolidating what matters and reducing cognitive load.

Platforms like GitHub Actions and GitLab CI are becoming the go-to for workflows orchestration, handling everything from integration to deployment. However, this alone doesn’t eliminate the need for niche tools. This “best-of-breed meets platform” strategy allows teams to simplify existing toolchains despite fulfilling unique operational requirements. By reducing unnecessary overlap, teams can reduce the number of dashboards to track, secrets to manage, and workflows to troubleshoot.

For example, some organizations can replace several tools with a combination of Terraform for infrastructure provisioning, GitHub Actions for CI/CD, or CloudRay for server maintenance automation tasks across VMs. This approach results in a smaller, more focused stack that’s easier to operate, onboard new team members, and maintain over time. Conclusively, tool adoption for automations is not about reducing the count; it’s about what is working and suitable for the current organizational needs.

AI and the Next Frontier

AI is re-shaping how teams approach DevOps. AI is not replacing engineers, but rather improving how they work. With the adoption of AI into various automation tools, we’re seeing early wins in areas of anomaly detection, test automation, and observability. Tools are now giving insights, generating test cases that previously took hours of manual effort to achieve.

Platforms are beginning to embed AI into their workflows. For example, GitHub Copilot can suggest YAML configurations for CI pipelines. Datadog and Dynatrace use machine learning to detect anomalous patterns before they become an incident. Even in infrastructure, AI is helping teams in predicting consumption, optimizing the use of resources, and reducing false alerts.

Aside from the traditional workflows, low-code and no-code automation is also gaining traction. Engineers are using drag-and-drop tools or simpler configuration files to trigger multi-step deployments, onboard services, or manage cloud resources. This allows non-DevOps teams to engage in automation without needing to write any code or use CLI tools.

Looking at the future, the trajectory is autonomous operations. We’re moving toward systems that not only watch but also act, self-healing infrastructure, pipelines that tune themselves, and bots that offer the next best step based on deployment history or mistake trends. While we’re not there yet, each step, whether through AI ideas or rule-based automation, pushes DevOps closer to that goal.

Wrapping Up

DevOps automation is heading into a fresh phase, focusing on keeping things simple, modular, and genuinely helpful for developers. Instead of struggling with overly complex pipelines or inflexible toolsets, teams are now creating leaner workflows that fit their specific requirements. With AI and event-driven approaches becoming more advanced, automation is getting not only quicker but also smarter. The future isn’t about doing more tasks. It’s about doing fewer things, but doing them much better.

August 28, 2025
Beyond the Firewall: Achieving True Observability in the Era of Hybrid Infrastructure

It’s 2025, and while DevOps teams focus 99% of their time on their code and databases, their applications increasingly rely on complex infrastructures that span private data centers, public cloud services, APIs, SaaS tools and networks they don’t own or control. User experience of modern apps is as dependent on the reliability of the internet as it is on the performance of your code.

Yet far too many organizations are relying on legacy observability tools built for a time when everything lived behind the firewall (usually in the cloud). These tools provide excellent insight into internal systems (code traces, event and logs, and infrastructure metrics) but fall short when problems occur in the “middle mile,” last-mile ISPs, or within third-party services your customers depend on.

This is a critical blind spot, and it’s putting reliability, performance and even brand trust at risk.

The Observability Gap

The average company experiences 72 internet disruptions per month, according to a 2025 Forrester Opportunity Snapshot. Moreover, of the companies surveyed, 42% note that those disruptions resulted in losses of over $500,000 in the month preceding the survey, adding up to over $6M annually.

Observability platforms are generally focused on application code and infrastructure (MELT – metrics, events, logs and code traces), which is critical for developer teams. If something goes wrong in your code, these platforms are needed to identify and resolve issues as well as to optimize performance and resource utilization. However, in the hybrid, distributed, service-oriented digital environment we operate in today, needs are fundamentally different.

Applications are now more often a collection of dozens of interdependent components and services that require reliable, performant connectivity. As an example, an average website requires hundreds of calls to dozens of providers to load a page: DNS, SSL, content servers, images stored on object storage, fonts, advertising components, tag management, tracking, video services, CDNs, etc.

Today’s incidents, whether an outage, a slow-loading application, or an app that is not accessible to some users, are most likely not due to a bug in application code or the cloud infrastructure it runs on but due to slow DNS resolution, an unresponsive API, latency or dropped packets between cloud services, or a peering issue between two ISPs halfway across the world – the list goes on. This is where traditional APM (application performance monitoring) tools end and where internet performance monitoring (IPM) begins.

True observability requires visibility into everything that can impact user experience. You can’t afford to ignore the components that your observability platform cannot monitor, or those that are not effective at monitoring.

What IPM Brings to the Table

IPM gives DevOps teams continuous, proactive visibility into how applications and services perform from the perspective of the end user. It’s actually doing more than tracing internal requests; it’s also measuring performance across the entire delivery chain, from the cloud to the CDN to the last-mile network, from the perspective of the user. This takes advantage of a network of thousands of agents deployed around the world. This approach gives teams a more holistic, birds-eye view of what’s going on, and like a GPS tracker, it can more quickly help teams map to the heart of issues as they happen in real time.

By integrating IPM into observability stacks, teams can accomplish a lot more, including: 1) Detecting issues before customers experience them and 2) Pinpointing whether the root cause lies within your infrastructure or an external dependency. Additionally, IPM can help reduce time-to-resolution by arming on-call engineers with precise, external telemetry and help build resilience by proactively monitoring internet routing changes, DNS resolution times, and synthetic transactions across geographies.

When something’s slow, knowing why, where and whether it’s in your control to fix it has never been more readily available or convenient.

From Defensive Firefighting to Offensive Prevention

By utilizing IPM, teams can make a shift from reactive to proactive observability. Rather than waiting for a fire, teams can proactively put them out before they even get started by detecting degraded performance trends or anomalies in any location, in real time. This approach often uncovers issues that would otherwise go undetected for hours (or only surface through a spike in help desk tickets or angry social media posts), which can save companies’ brand trust and millions of dollars in the long run.

Take the example of a leading eCommerce platform that integrated IPM into its workflow. One Monday morning, their site traffic appeared to drop significantly in parts of Asia. Their APM tools showed no errors, and cloud infrastructure metrics looked healthy. But IPM alerted the team of a regional DNS issue with a third-party provider, which prevented users from resolving their site domain.

Because of the quick insight, the DevOps team successfully rerouted traffic within minutes, minimizing lost revenue and preserving customer trust. Without IPM, that issue might have gone undiagnosed for hours, or worse, attributed to internal systems, wasting precious triage time.

Building an IPM-Ready Culture

For many DevOps teams, adding IPM means completing the big picture by adding a system that relies on synthetic monitoring, BGP, RUM and many internet-centric tests to ensure complete coverage of the internet stack and the analysis tools that provide the best view into a system: Dependency maps, experience scores, data exploration smartboards, etc.

But more than tools, it’s about mindset. Embracing IPM requires shifting the focus from system KPIs (like error rates, or CPU utilization) to user-centric metrics like experience level objectives with business goals in mind. It also involves treating the internet as mission-critical infrastructure, not a black box, and ensuring that performance metrics are shared across teams, not siloed in IT or networking. Observability teams become digital operations teams, ensuring every digital interaction that makes the business work.

What Does This Mean in the Long Run

At a time when hybrid infrastructure is the norm and internet dependencies are unavoidable, achieving true observability means embracing a broader view. The best DevOps teams of 2025 are those who understand that visibility must start with the user and include everything impacting their experience: Internal and external across the internet stack.

With internet performance monitoring, teams can eliminate critical blind spots, be better prepared to manage incidents and move confidently from reaction to prevention. Because when the next performance issue hits, it may not be coming from your code, but your customers will still expect you to solve it.

July 31, 2025
Observability 2.0: Much more than the Three Pillars
The digital panorama is a dynamic and ever-moving entity. Applications are no longer monolithic giants dwelling on predictable servers. Instead, they are complex webs of microservices, ephemeral serverless capabilities and containerized workloads, all operating across dispersed, multi-cloud environments. While this complexity fuels innovation and scalability, it also presents a formidable challenge: how do you truly understand what’s happening inside these complex structures? For years, the solution has been “observability,” often described by its “three pillars”: Metrics, Logs and Traces. These pillars have served us well, offering important information about system health. However, as structures grow in scale and dynamism, the limitations of this traditional method, which we can refer to as “Observability 1.0,” have become increasingly apparent.

The Loops in Observability 1.0’s Foundation

While individual metrics, logs and traces are indispensable, relying solely on them in isolation leads to several pain points:
- Data Silos: Metrics live in a single dashboard, logs in every other and traces in a third. Correlating a latency spike (metric) with specific error messages (logs) and a slow downstream carrier name (trace) will become a manual, time-consuming task, akin to a “swivel chair” workout.
- Reactive Nature: O11y 1.0 often tells you what went wrong after the fact. It’s remarkable for post-mortem evaluation; however, it is much less powerful at preventing troubles or predicting them before they impact users.
- Manual Correlation Pain: Engineers spend valuable time sifting through enormous quantities of data, trying to piece together coherent insights. This isn’t only inefficient but also prone to human errors and alert fatigue.
- Contextual Blind Spots: Raw telemetry, without proper context, may be overwhelming. Knowing a CPU is at 90% is less valuable than understanding why it is at 90% and which precise person motion triggered that load.
These limitations hinder mean time to resolution (MTTR) and mean time to detect (MTTD), directly impacting business outcomes and user experience.

Welcome to Observability 2.0: The Unified, Intelligent Evolution

Observability 2.0 isn’t just a step-wise update; it’s a fundamental shift in how we approach system understanding. It recognizes that in today’s complex environments, merely collecting data isn’t enough. We need to unify it, enrich it with context and apply intelligence to extract actionable insights.

At its core, Observability 2.0 moves towards:
1. Unified Telemetry: Imagine all of your systems’ “exhaust” – metrics, logs, strains and even custom events like deployment markers or commercial enterprise KPIs – flowing into a single, cohesive data. This extensive technique ensures that each piece of data is inherently associated with rich, high-cardinality metadata (e.g., customerId, deploymentId, featureFlagState). This eliminates silos, allowing for seamless correlation.
- The OpenTelemetry Revolution: OpenTelemetry is a critical enabler in this regard. As a vendor-neutral, open-source project, OTel presents standardized APIs, SDKs and collectors for instrumenting applications. This way, you can accumulate constant, tremendous telemetry records immediately and then export them to any OTel-supported backend, liberating you from vendor lock-in and paving the way for unified data.
1. AI/ML-Driven Insights: This is where Observability 2.0 truly shines. Artificial intelligence and system mastering are not simply buzzwords; they are actively transforming how we make sense of data.:
- Automated Anomaly Detection: Moving beyond inflexible, static thresholds, AI learns the everyday behavior styles of your systems. It can then stumble upon diffuse, complicated deviations or “unknown unknowns” that human eyes or simple logic might overlook, proactively alerting you to potential issues.
- Automated Root Cause Analysis: When an incident happens, AI algorithms can unexpectedly correlate disparate records factors across metrics, logs and traces, suggesting, in all likelihood, root causes much quicker than manual research. This can dramatically reduce MTTR.
- Predictive Capabilities: By analyzing previous developments and real-time information, AI can even forecast equipment failures before they occur, allowing for proactive interventions and preventing costly outages.
- Intelligent Alerting & Noise Reduction: AI helps reduce alert fatigue by correlating related alerts and suppressing redundant notifications, ensuring that engineering teams are only notified of business-critical events.
- Business Context and User Experience Focus: Observability 2.0 isn’t exclusive to SREs and DevOps engineers. It’s about connecting technical health without delay to business effects. By linking overall performance statistics (e.g., API latency) with enterprise metrics (e.g., conversion fees, customer satisfaction), teams can prioritize problems based on their actual effect on the bottom line.
Real-World Use Case for Observability 2.0

Use Case: Optimizing Cloud Costs Based on Real Usage
- Observability 1.0: Your month-to-month cloud invoice for serverless features seems high. You study ordinary invocation counts; however, it is tough to tell which functions are using prices or if they’re over-provisioned.
- Observability 2.0: By unifying invocation_count, memory_usage and duration metrics with custom business tags (e.g., customerTier, featureName), the platform can provide insights like “Processing images for premium customers consumed 30% more memory this week, leading to a 15% cost increase in the ImageResizer function.” AI can even suggest optimal memory configurations for functions based on historical usage patterns, enabling precise right-sizing and resulting in significant cost savings.
Embarking on Your Observability 2.0 Journey

Transitioning to Observability 2.0 isn’t an overnight process, but a strategic imperative. Here’s how to begin:
1. Assess Your Current Landscape: Understand your existing monitoring tools, data sources and most critical pain points.
2. Embrace Open Standards: Start integrating OpenTelemetry into your systems. This future-proofs your instrumentation and provides the strong foundation for unified telemetry.
3. Prioritize Rich Instrumentation: Think beyond simple metrics. Capture high-cardinality information and meaningful enterprise context with each log and trace.
4. Explore Unified Platforms: Look for observability platforms that provide a unified view, AI/ML-driven analytics and continuous visibility. Many leading carriers (e.g., Middleware, Honeycomb, Splunk Observability Cloud) are actively investing in those abilities. Open-source answers built on initiatives like ClickHouse or Apache Flink are also emerging.
5. Cultivate an Observability Culture: It’s not just about tools; it’s a mindset. Encourage developers to “shift left” observability, embedding it into their code and development practices from the start.
In a world where software programs define business success, having a comprehensive, proactive and intelligent understanding of your system is no longer a luxury; it is a necessity. Observability 2.0 is crucial for unlocking that expertise, empowering teams to transition from reactive firefighting to proactive trouble-solving, ensuring seamless user experiences and driving sustained innovation. The destiny of device intelligence is here; are you equipped to embody it?
July 25, 2025
Centreon Extends Monitoring Reach into Observability Realm

Centreon this week generally made available an open source agent for monitoring IT and operational technology (OT) environments that incorporates the open source OpenTelemetry agent for instrumenting applications that is being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

Raphaël Chauvel, chief product officer at Centreon, said now that the Centreon Monitoring Agent makes it possible to also collect log data using OpenTelemetry, with the next step being adding the ability to collect traces. Overall, the goal is to provide a unified platform for monitoring and observability that IT teams can flexibly apply as needed, he added.

Most IT teams will need to continuously monitor a set of pre-defined metrics, but they are also increasingly embracing observability platforms to gain access to analytics tools that make it simpler to troubleshoot applications. Rather than having to acquire, deploy and manage two separate platforms, Centreon is making a case for an integrated platform that, in addition to lowering total costs, also provides plug-ins for managing digital experiences, said Chauvel.

That’s especially critical as IT environments become increasingly more complex to manage and troubleshoot, he added.

At the core of the Centreon platform is a set of open source components for collecting data, transferring and normalizing it, and then accessing it via a user interface. That platform can be accessed as a software-as-a-service (SaaS) application or deployed in an on-premises IT environment to meet any sovereign cloud requirements. The company claims there are now more than 250,000 IT professionals contributing to that community.

It’s not clear to what degree IT teams have embraced observability, but as they increasingly unify the management of applications and IT infrastructure, the need becomes more apparent. The primary adoption issue has been both the cost of the observability platform and the developing of the skills required to analyze the data being collected. Fortunately, with the rise of artificial intelligence (AI), the level of expertise required to derive value from observability platforms continues to decline.

Regardless of approach, the overall stress level that IT teams experience every time there is an issue or outright outage should lessen as the amount of time required to investigate a problem is reduced. Historically, IT teams have spent weeks investigating issues that once discovered only take a few minutes to fix.

In the meantime, IT administrators in collaboration with DevOps engineers should be working toward defining a united approach to observability and monitoring. Observability, of course, has always been a core tenet of best DevOps practices, but the ability to achieve it has been at best uneven, largely because the cost of instrumenting applications and collecting the required telemetry data has been higher than many IT organizations could afford. However, with the rise of open source tools such as OpenTelemetry it is becoming more affordable to instrument a larger swath of the application portfolio. The challenge, as always, is determining which applications should be instrumented first based on total cost and their criticality to the organization.

July 17, 2025
7 Best Practices to Monitor Your Microservices
Microservices offer a lot of things; they increase performance, elasticity and resilience. Truth be told, though, if you don’t have a phenomenal monitoring strategy in place, they will become just a distributed nightmare at the touch of a button. Just imagine a significant incident that occurs in your system, and guess what? Your team is ill-equipped to guess which of your dozens (or hundreds!) of services is failing. Without solid monitoring, that’s the horror story.

So that’s where Middleware comes in to help the organizations properly monitor all the microservices in detail to get the proper insights.

Collecting data is not sufficient; it is collecting raw input and converting it into usable intelligence-driven input so that it prevents outages, diagnoses issues in minutes, not hours, and guarantees that applications will continually deliver. Ready to stop merely reacting and begin predicting? Let us get into the necessary best practices for mastering microservices monitoring.
1. The Trinity of Observability: Logs, Metrics and Traces
Effective monitoring isn’t a single thing; it’s a synergistic approach built on three foundational pillars. Neglect even one, and you’re flying blind.
- JavaScript
1. Standardize All: For Uniformity
Clarity and chaos do not go together. Standardize logging formats and metric levels consistently, and propagate tracing headers across every single service. Such uniformity is not a small treatment; it is the basis on which correlation, aggregation and effective troubleshooting are genuinely possible.
1. Proactive Alerting & Anomaly Detection
The first thing you want to avoid is outages being reported by your customers. They have been implemented based on alerting models with thresholds, including critical events like sudden spikes in errors, SLAs in latency, and exhaustion of resources. Even better is to use anomaly detection scenarios that intelligently flag patterns that are worth investigating and that often correspond to subtle degradations long before they turn into full-blown crises. You want the alerts not to be a surprise when they happen.
1. Health Checks & Readiness Probes
Shouldn’t send a request to the service that is not ready or is in distress. Proper health checks must have been implemented, such as a /health endpoint returning a service’s current operational status, and readiness probes must’ve been implemented. These are not Kubernetes features; these are key for any load balancer or service mesh capable of smart routing requests so that requests hit only fully initialized and healthy instances.
1. Detailed and Customisable Dashboards
Raw data makes no sense unless it shares some insights. Build user-friendly, extensively informative dashboards giving you a bird’s eye view over your whole microservices landscape. These dashboards should now serve as your team’s war room, showing key metrics, log trends and trace summaries for quick status checks and fast identification of hot spots. Make sure to design for action, not just for data gravy.
1. Continuous Performance Testing and Capacity Planning
Don’t wait until Black Friday to test where your limits are. Load and stress tests should be run regularly on your microservices. Knowing where they break provides some information about where the bottlenecks are when being tested vigorously. This data is extremely useful for forward planning regarding capacity when traffic can be expected to run up and put pressure on your infrastructure.
1. Automate, Automate & Automate: Consistency by Code
Bound to fail, manually set up: Anything that requires human attention should be automated regarding monitoring, agent deployment, alert rule creation and dashboard set up. Infrastructure as code (IaC) will be useful here as well. Automation gives consistency, decreases operational overhead and will also speed your adaptation to new monitoring strategies as your services keep evolving.

Conclusion: From Complexity to Clarity

Monitoring microservices is not a destination; it is an evolutionary journey. By embedding these best practices in the development and operations workflow, you will transform what could have been a complex distributed system into a fairly apparent and manageable ecosystem. The transition will carry you away from fighting fires reactively to proactive management, ensuring availability, performance and ultimately a delightful experience for your users.
July 3, 2025
IBM and DBmaestro Expand Strategic OEM Partnership to Deliver Enterprise-Grade Database DevOps and Observability

Orlando, FL, July 1, 2025 — IBM (NYSE: IBM) and DBmaestro, the leading enterprise-grade database DevOps platform, today announced the signing of a landmark OEM partnership agreement. This expansion will make DBmaestro’s advanced database DevSecOps and observability suite available through IBM’s solutions portfolio, empowering customers to achieve end-to-end DevOps automation, real-time database visibility, and unmatched agility, security, and innovation.

“DBmaestro’s platform will support and enhance IBM DevOps, including IBM DevOps Loop, IBM DevOps Deploy and IBM DevOps Velocity. Future integrations are planned with IBM Z, HashiCorp Vault, Terraform & Waypoint, Instana, and IBM ELM to fill a critical gap in database automation and observability for enterprise DevOps toolchains.”

“The expansion from reseller to a full OEM partnership marks a pivotal moment for enterprise DevOps,” said Gil Nizri, CEO of DBmaestro. “By integrating our leading enterprise-grade multi-database DevOps platform and observability suite into IBM’s powerful suite, we are enabling organizations to orchestrate flawless software delivery from application code to database deployments. Our joint solution empowers customers to accelerate innovation, reduce risk, and maintain the highest standards of security and compliance, all while gaining real-time visibility into their database processes.”

DBmaestro automates database deployments and schema changes, eliminates the bottleneck of manual database processes, and delivers full observability into every aspect of the database DevOps lifecycle. Its integration with IBM’s DevOps tools ensures that database changes are managed alongside application code, enabling standardized deployment pipelines, robust version control, error-free automation, and actionable insights through advanced monitoring and analytics. This unified approach delivers:

– Complete DevOps Harmony: Automates the entire software delivery lifecycle, including database releases and observability for full modernization and digital transformation.

– Faster Time to Market: Enables rapid, frequent, and reliable deployments.

– Fortified Security and Compliance: Implements robust controls and visibility to meet strict regulatory requirements.

– Enhanced Software Quality: Minimizes errors and inconsistencies through automation and real-time monitoring.

– End-to-End Observability: Provides comprehensive insights into database changes, performance, and compliance across environments.

– AI Powered Insights: Automatically identifies errors and proposes ad-hoc best practices for resolution

“IBM’s mission is to help enterprises deliver innovation at scale, securely and efficiently,” said James Hunter, Program Director at IBM DevOps Automation. “By embedding DBmaestro’s industry-leading database DevOps and observability suite into our ecosystem, we are removing one of the last barriers to true end-to-end DevOps. This partnership expansion empowers our customers to achieve faster, safer, and more reliable software delivery, with unprecedented transparency into their database operations.”

The OEM agreement allows IBM customers to leverage DBmaestro’s automation and observability as a native part of their DevOps toolchain, supporting hybrid and multi-cloud environments and streamlining complex database operations.

About DBmaestro:

DBmaestro is a leading provider of database release automation solutions, empowering organizations to deliver better software faster, while minimizing risks and errors. DBmaestro’s platform enables CI/CD for databases, regulatory compliance and DevOps observability, ensuring safe database deployments with zero downtime. www.dbmaestro.com.

Media Contact
Ben Gross
+972-50-8452086
beng@dbmaestro.com

July 1, 2025
New Relic Adds Support for Model Context Protocol to Observability Platform

New Relic this week added support for the Model Context Protocol (MCP) to its observability platform to surface insights into artificial intelligence (AI) agents and applications.

Originally developed by Anthropic, MCP is rapidly becoming a de facto application programming interface (API) for enabling interoperability between AI agents and other sources of data.

New Relic has now incorporated MCP with its application performance monitoring to surface insights into AI agents and applications alongside its ability to monitor and observe legacy applications.

Previously, New Relic had added an ability to observe large language models (LLMs), but via MCP it’s now able to extend the reach of that capability to AI agents and applications that access those LLMs. That capability makes it possible to visualize specific usage and patterns of the entire lifecycle of an MCP request, including invoked tools, call sequences and execution durations.

Additionally, DevOps teams can identify which prompts are being invoked and what choices were made by an AI agent along with surfacing latency, errors and other MCP performance issues.

New Relic AI Monitoring MCP support is now available in Python Agent version 10.13.0, with additional languages coming soon.

In general, New Relic reports it has seen a steady 30% growth in usage of its AI monitoring tools quarter-over-quarter for the past year. The company has also seen a 92% increase in the number of unique AI models being used. However, the ChatGPT models provided by OpenAI accounted for 86% of all the LLM tokens being generated.

Nic Benders, chief technical strategist for New Relic, said that level of activity suggests that OpenAI is well on its way to becoming a de facto standard, even as the number of AI models being made available continues to rapidly increase.

It’s not immediately clear why one LLM might be preferred over another but OpenAI, in addition to making a steady stream of investments, has successfully generated a significant amount of brand recognition. That helps make OpenAI one of the first platforms that most organizations are going to look to when building an AI application, said Benders.

However, there are use cases, such as coding, that lend themselves, for the moment at least, better to coding, he added.

Less clear is the degree to which the various AI models that are available will gain enough traction to warrant the ongoing level of investment required to sustain them. IT teams should carefully consider what foundations they want to build and deploy AI applications on for the long term, noted Benders.

Additionally, not every AI application requires the latest, and most expensive, LLM, said Benders. The cost of previous generations of AI models has declined considerably as more advanced models have become available. Many applications, however, may not require access to a more advanced model, especially when a previous generation will enable a developer to automate a task at a much lower cost.

Ultimately, observability platforms will play a critical role in enabling organizations to track which AI models are being used for which use cases. The challenge now is understanding not only which ones are gaining traction among application developers, but just as importantly, the symbiotic relationship that exists between AI models and the IT infrastructure upon which they depend.

June 13, 2025
Gearset Extends Reach of DevOps Platform for Salesforce Applications

Gearset has extended the scope of the observability of Salesforce applications it provides to include software developed using low-code Flex and object-oriented Apex programming tools.

Busayo Longe, a product manager for Gearset, said Flow is gaining more traction as a tool that is more widely employed to build Salesforce applications, while more complex applications are typically built using Apex.

Gearset, a provider of a DevOps platform for Salesforce applications, is now able to surface and analyze Flow and Apex errors in real time.

Unlike other applications where issues are surfaced using alerts generated via agents embedded in an application, the Salesforce platform generates automated error emails whenever there is a failure. It’s then up to the IT team managing these applications to investigate the root cause.

As a result, IT teams can find themselves being inundated with a high volume of hard-to-interpret messages that lack context about what went wrong, who was affected, or how urgent the issue is.

In addition to providing that context, Gearset errors can be filtered by type and further investigated using a set of visualization tools provided.

IT teams can also configure the automated error emails generated by the Salesforce platform to be automatically routed to Slack or Microsoft Teams messaging platforms if they prefer.

Finally, the alerts generated by Salesforce can also be customized to enable IT teams to only be notified when an issue exceeds a specific threshold.

In general, the need for observability will become much more pronounced as more organizations build and deploy artificial intelligence (AI) agents on the platform. As the interactions between AI agents increase, the chances that there will be issues that IT teams will need to investigate will only continue to increase, noted Longe.

The challenge is that a recent Gearset survey finds 69% of the IT teams managing Salesforce applications don’t have access to an observability platform. According to Gearset, IT teams that have access to an observability platform are 50% more likely to catch bugs within a day and 48% more likely to fix them within a day, compared to teams without these tools. On the plus side, 81% of respondents said they have adopted a continuous integration/continuous deployment (CI/CD) platform. In fact, Gearset claims it added 800 new customers in 2024, bringing its total customer count to 2,900 organizations.

It’s not clear who is building the bulk of the applications deployed on the Salesforce platform. While there are a large number of so-called citizen developers building applications using low-code tools, many enterprises also rely on professional developers to build these applications. As a result, the quality of the applications deployed on a Salesforce platform can vary widely. The one certain thing is that the pace at which organizations are building custom applications that are deployed on the Salesforce platform only continues to accelerate.

The challenge that arises is that the Salesforce platform is based on a proprietary, unique mix of programming languages, formats and metadata that require a separate set of DevOps tools and platforms to manage application development and deployment.

Regardless of who or how Salesforce applications are developed, the one certain thing is that it will eventually fall to a DevOps team to troubleshoot them whenever an issue arises.

June 13, 2025
From Noise to Narrative: Rethinking Observability for AI-Augmented DevOps Pipelines
Because DevOps teams deal with so much data, they may feel like they are drowning, but rarely find the insights they need. There is more observability data now than ever, yet it often stays separate, disorderly, inaccessible or confusing. As AI enters more organizations’ processes, observability moves from just monitoring to gathering early insight through meaningful narratives. It is not only about having new tools but also changing how development is done and organized. Supporting today’s DevOps — where AI is involved — requires developers to switch from seeing observability as a solely technical aspect to thinking of it as a way to explain what happens in the system: One that links unrelated incidents, highlights how each one is related, and warns users ahead of any failure.

The Telemetry Tsunami

Legacy monitoring was created for stable, predictable systems, including static servers, stable networks and well-known failure points. Nowadays, architectures made of ephemeral containers, dynamic microservices and AI-driven automation result in high-volume and high-velocity telemetry data that older monitoring systems cannot handle.

AI models add more factors to consider in analyzing systems – model drift, low data quality, inference delays and unclear ways AI decides make things difficult to observe. Logs and alerts are insufficient to make sense of what is happening in such systems. Observing these complex, AI-driven systems calls for tracing and feedback that can reveal valuable insights with a lot of noise around them. The result? As a result, most teams experience so much data that it’s hard to find the reason behind any performance, regression or security problems.

Observability as Narrative

Moving forward, DevOps teams need to treat observability as a way to construct coherent stories. DevOps teams should focus on building stories from the signals they gather that help explain what happened and what to do next. This shift involves three fundamental changes:

Correlated Context Over Raw Data: Systems should first add metadata like deployment IDs, feature flags, user behavior and model versions to metrics, traces and logs to describe their life cycle independently (refer to figure 1).

Declarative Telemetry Pipelines: Bringing AI/ML into the system will allow systems to describe their activities using words humans can easily understand. A pipeline should ensure that the effects of an AI model update on latency can be noted and followed, not simply added later on.

Semantic Layering with AI Assistance: Instead of being used only in the system, AI/ML can simplify understanding what is happening. With the help of AI/ML, observability tools are becoming easier for humans to understand.

Figure 1. The three pillars of observability that are essential in an AI-augmented DevOps pipeline.

From Dashboards to Dialogues

Most current observability tools rely solely on the user to interpret data. However, more practitioners are starting to wonder: Why can’t the system simply offer explanations? It all boils down to how observability tools combine AI to help sum up what’s happening, pinpoint regressions and provide possible explanations. With the help of AI, systems can now describe issues, indicate regression points and identify probable problems in the data. An AI-augmented observability system could tell you: “Starting at 12:06, service X saw a 30% increase in latency because many cold starts from model Y, which had just been redeployed recently. Service level objectives (SLOS) did not meet expectations by 12:12. Consider raising the pool size of warm data or re-adjusting the model’s time frame for batch processing”.

This is no longer science fiction but something that is becoming true. Several open-source and commercial solutions integrate machine learning into observability stacks to help find root causes, group anomalies and make suitable suggestions for resolving issues.

Designing for Explainability

AI models used in DevOps also require monitoring for issues, as they can perform worse than expected for reasons that might not be obvious in tests. Unlike standard software, changes in AI models can be challenging to detect until they appear in production. Sometimes, a model that looks good during testing can have problems in the real world, caused by small or unusual changes in the input data.

Explainability is key. AI observability must track:
- Input/output distributions over time
- Feature importance changes
- Data pipeline lineage
- Confidence scores and decision paths
When correlated with infrastructure and application data, this information will tell teams if the incident was caused by a system problem, an issue with the pipeline code, or faulty model behavior.

Practitioner-Centric Observability

For observability to progress, it must be designed for all system users, not just for central teams. This means that not only platform teams but also the mid-level workers responsible for trying to understand user complaints, triaging incidents, or fine-tuning production models need observability tools.

Some key principles include:
- Narrative-Driven Interfaces: Less reliance on dashboards; more chances to look at timelines, see how things are linked and get simple explanations from AI.
- Integrated Feedback Loops: Ability for engineers to fix, add notes to and correct system alerts so the information shown in the future gets better.
- Cross-Domain Visibility: Bringing together data about how applications are doing, how the systems are working and how well your AI is doing all together into one place to help you see your systems better.
Observability must evolve, so it is smarter than simply collecting more data. It will require the entire culture of the industry to change, not just new technology. People in the industry should start seeing observability as telling a story, where each log, trace and metric adds to how the system can be easily explained. This evolution means that your systems must be able to define themselves well, rather than simply based on how much data you can collect.
June 13, 2025
Zero-Trust, Full Stack: Embedding Cybersecurity Principles Into Site Reliability Engineering Culture

These days, with digital threats everywhere, cybersecurity must evolve beyond just being a perimeter measure. Given the rapid delivery of software and the transient nature of infrastructure, security must be built into DevOps. This shift presents both a challenge and an opportunity for site reliability engineers (SREs) to apply zero-trust principles everywhere, starting with infrastructure and services and extending to how developers operate.

Zero-Trust: Beyond the Buzzword

While zero-trust is often associated with network security, many people do not realize it encompasses much more. It involves rethinking how trust is managed in distributed computing. The key idea is to always verify a person’s identity, device status and intent before granting access to any system element — regardless of its location on the network. The principle is ‘never trust, always verify’. Although this concept is used in security, it is still not fully practiced in SRE, as prioritizing availability and performance has usually been more important than focusing on security and telemetry.

With their expertise in systems and automation, SREs have the skills to take zero-trust beyond firewalls and identity solutions (refer to Figure 1). Testing these principles in reliability goals increases teams’ power to reduce the blast radius, secure production environments and deal with incidents more effectively.

Figure 1: High-Level Zero-Trust System.

It includes regular risk assessment with the help of a central analytics engine. Access to data is prevented by default and is granted only after proper verification. After users have been granted access, they can carry out transactions according to the determined risks. It constantly updates its decisions using information from various sources, such as identity, access context, security alerts and the ongoing session’s information.

The Convergence of Reliability and Security

Reliability engineering today focuses on more than just preventing downtime. The challenge is managing complexity and risk with continuous deployment, increasing service meshes and expanding application programming interface (API) surfaces. Changes in how production environments are run typically outpace traditional information system security (InfoSec) boundaries.

SREs fill this space by working with security teams and ensuring that security as well as observability are integrated into development pipelines. In other words, it is ‘security as dependability’ — they ensure there are no unauthorized changes, remove old passwords and ensure that staff have enough access to sensitive systems.

Take, for example, the consequences of using a compromised API token. If zero-trust principles — including strict access rules, regular authentication and control over service identities — are not applied, someone could use that token to move from microservice to microservice. By adopting zero-trust, SRE teams must integrate authentication between services, trusted connections using transport layer security (TLS) and policy checks directly into their workflow.

Policy as Code: Scaling Trust in the Pipeline

One crucial factor supporting zero-trust in SRE is policy as code. Just like infrastructure as code simplifies system creation, policy as code offers a way to automatically set and keep security policies up to date. Enforcing policies dynamically during continuous integration and continuous deployment (CI/CD) steps allows teams to enhance security while continuing at the same speed. SREs should understand policies as helpful guardrails that help maintain secure and proper configuration, access and deployment. Having policies managed and checked like other code enables a team to grow and creates trust among everyone working remotely.

Telemetry, Observability and Security Context

The nervous system of SRE is telemetry. Thanks to logs, metrics and traces, observability platforms help teams spot out-of-the-ordinary events, anticipate problems and understand the cause of any issues. Security signals such as unsuccessful logins, suspicious ways of gaining access and domain name system (DNS) tunneling are often supervised by different security operations center (SOC) teams.

Making cybersecurity part of SRE culture involves having telemetry that supports security observability, bringing security-related events into the same observability systems as those for performance and reliability. A centralized view reduces the time to locate the issue and improves how incidents are handled as a team. In a zero-trust model, each deviation from normal is considered a possible security threat.

Operationalizing Zero-Trust: Practical Steps for SRE Teams

Building a zero-trust culture in SRE does not require organizations to change everything at once. They can start embedding these practices in everyday operations by doing the following:

Enforce Identity Everywhere: Use evanescent keys, workload identity and service mesh for mutual authentication.

Audit by Default: All system changes, attempts to access them and incidents of policy breaches should result in structured logs that both the SRE and security teams have access to.

Integrate Policy Engines: During CI/CD, implement policies to confirm that deployments meet security and setup rules.

Minimize Human Access: Use automation and ephemeral credentials to eliminate shell access or long-lived keys.

Simulate and Test: Treat security risks as another factor that could cause a failure. Using chaos engineering principles, you can simulate attacks and test how to respond to them.

We must remember that the central aspect of zero-trust in SRE is changing the team’s approach to cybersecurity, not only replacing tools. SREs should learn to consider security events as they would other threats to the system’s reliability. In case of an incident, a security-related view should be included in the postmortem, and blameless retrospectives should focus on breaches of trust boundaries. By tying zero-trust with the pursuit of site reliability, groups can create an environment where security is everyone’s responsibility instead of being kept apart. By following these steps, SREs will ensure the systems remain up, running and safe.

June 9, 2025