As organizations accelerate their cloud-native transformations, the relationship between DevOps and platform engineering has become critical to sustainable software delivery at scale. While DevOps provides the cultural framework and practices for continuous delivery, platform engineering creates the foundational infrastructure that enables these practices to scale effectively across the enterprise. Understanding how these disciplines complement each other is essential for IT leaders navigating modern software delivery challenges.

The current state: DevOps at scale

DevOps has fundamentally transformed how organizations deliver software. By breaking down silos between development and operations teams, implementing continuous integration and delivery pipelines, and embedding observability throughout the software lifecycle, enterprises have achieved deployment frequencies measured in minutes rather than months.

However, as organizations scale their DevOps initiatives, new challenges emerge. A recent analysis of enterprise DevOps implementations revealed consistent patterns: Teams operating at scale face increased cognitive load, infrastructure inconsistencies across teams, and compliance complexities that traditional DevOps practices struggle to address.

Consider a typical scenario: A financial services organization with more than 200 developers across 15 teams discovered that each team has implemented different continuous integration and delivery (CI/CD) pipelines, monitoring solutions, and security controls. The result is operational inefficiency, increased security risk, and developer frustration.

This complexity gap is where platform engineering enters the equation — not as a replacement for DevOps, but as its essential complement for enterprise-scale operations.

Understanding DevOps fundamentals

DevOps represents both a cultural shift and a set of technical practices designed to accelerate software delivery while maintaining reliability. At its core, DevOps encompasses:

• Continuous integration and delivery (CI/CD). Automated pipelines that move code from development through testing to production, reducing manual intervention and human error.
• Infrastructure as code (IaC). Programmatic infrastructure management that promotes consistency and repeatability across environments.
• Observability and monitoring. Comprehensive telemetry collection and analysis to understand system behavior and preempt issues before they affect users.
• Security integration (DevSecOps). Embedding security practices directly into the development pipeline, rather than treating security as a separate phase.
• Cross-functional collaboration. Breaking down organizational silos to create shared ownership of software delivery and operations.

These practices are consistently associated with stronger business outcomes. Organizations that invest in mature DevOps capabilities generally report faster delivery, higher quality, and more resilient systems — while also seeing more predictable, repeatable value delivery to customers. In short: better software delivery tends to correlate with better business performance.

Platform engineering: The infrastructure product approach

Platform engineering emerged from the recognition that infrastructure itself should be treated as a product. Rather than each development team solving the same infrastructure challenges independently, platform engineering provides standardized, self-service capabilities through internal developer platforms (IDPs).

Key characteristics of effective platform engineering include the following:

• Self-service infrastructure. Developers can provision environments, deploy services, and access tools through automated interfaces without requiring deep infrastructure expertise.
• Standardization with flexibility. Common patterns and best practices are encoded into the platform while still allowing teams the flexibility to meet specific requirements.
• Built-in compliance and security. Regulatory requirements and security controls are automatically enforced through the platform, reducing the compliance burden on individual teams.
• Developer experience focus. The platform is designed with developer productivity as a primary metric, reducing cognitive load and eliminating repetitive tasks.

Organizations with mature platform engineering practices see significant reductions in time spent on infrastructure management and improvements in deployment frequency compared to those without such platforms.

How DevOps and platform engineering complement each other

The relationship between DevOps and platform engineering is symbiotic. DevOps provides the practices and culture, while platform engineering provides the infrastructure and tooling that makes those practices sustainable at scale.

Consider how they reinforce each other across key dimensions:

• Automation evolution. Where DevOps automates individual pipelines and processes, platform engineering automates the creation and management of those pipelines themselves. This meta-automation enables organizations to maintain consistency while scaling rapidly.
• Observability at scale. Both disciplines prioritize visibility, but platform engineering helps to keep observability tools and practices standardized across the organization. This standardization can help reduce mean time to detection (MTTD).
• Cognitive load management. DevOps practices can inadvertently increase developer cognitive load as teams take on more operational responsibilities. Platform engineering addresses this by abstracting infrastructure complexity behind well-designed interfaces.
• Compliance and governance. Platform engineering enables DevOps teams to move fast while supporting compliance by embedding policies and controls directly into the platform layer.

Distinguishing between DevOps, SRE, and platform engineering

While DevOps, site reliability engineering (SRE), and platform engineering overlap, each has distinct focus areas that complement the others.

DevOps establishes the cultural foundation and practices for continuous delivery, emphasizing collaboration, automation, and rapid feedback loops across the entire software lifecycle.

SRE applies software engineering principles to operations challenges, focusing specifically on system reliability through error budgets, service-level objectives (SLOs), and automated incident response.

Platform engineering builds and maintains the internal platforms that enable both DevOps and SRE practices to function effectively at scale, providing the technical foundation for the entire engineering organization.

In mature organizations, these disciplines work in concert: SREs define reliability standards, platform engineers encode those standards into the platform, and DevOps practices help teams meet those standards while delivering features rapidly.

Implementation challenges and solutions

Organizations implementing DevOps and platform engineering face several common challenges:

• Cultural resistance. Traditional organizational structures often resist the collaborative model that DevOps requires. Success requires executive sponsorship and clear communication about the benefits of transformation.
• Tool proliferation. The cloud-native landscape includes thousands of tools and technologies. Platform engineering helps by curating and standardizing the toolchain, reducing decision fatigue and integration complexity.
• Security and compliance integration. Maintaining security in high-velocity environments requires fundamental shifts in approach. Successful organizations embed security checks directly into platforms and pipelines, making secure practices the path of least resistance.
• Measuring success. Organizations must establish clear metrics for both DevOps outcomes (deployment frequency, lead time, and MTTR) and platform effectiveness (developer satisfaction, platform adoption rate, and time to provision resources).

The role of AI and automation

AI is transforming both DevOps and platform engineering. Large language models (LLMs) now assist with code generation, documentation, and incident response. AI-powered observability platforms can predict and prevent issues before they affect users. In platform engineering, AI enables natural language interfaces for infrastructure management, making platforms more accessible to developers without deep technical expertise.

Organizations that integrate AI into their DevOps and platform engineering workflows can see faster documentation workflows, quicker incident investigation, and higher code quality due to AI-supported reviews.

Building a platform engineering practice

For organizations ready to implement platform engineering alongside their DevOps initiatives, consider this structured approach:

• Assess current state. Evaluate existing DevOps maturity, identify pain points, and understand where platform engineering can provide the most value.
• Define platform product vision. Treat the internal platform as a product with clear users (developers), requirements, and success metrics.
• Start with high-impact use cases. Begin with capabilities that address the most pressing developer pain points, such as environment provisioning or deployment automation.
• Measure and iterate. Continuously gather feedback from platform users and iterate based on actual usage patterns and developer needs.
• Scale gradually. Expand platform capabilities incrementally, helping each new feature to deliver measurable value before moving to the next.

Future outlook and continued evolution

The convergence of DevOps and platform engineering will accelerate as organizations embrace cloud-native architectures and AI-driven development. Key trends shaping the future include the following:

• GitOps adoption. Managing all infrastructure and application configuration through Git repositories provides auditability, rollback capabilities, and familiar workflows for developers.
• “Everything as code.” Beyond infrastructure, organizations are codifying policies, compliance rules, and operational procedures, enabling version control and automation across all aspects of IT.
• Developer experience as a competitive advantage. Organizations recognizing that developer productivity directly affects business outcomes are investing heavily in platform capabilities that improve developer experience.
• Serverless and edge computing. As computing models evolve, platform engineering must adapt to support new deployment patterns while maintaining consistency and control.

Practical recommendations for enterprise leaders

For IT leaders navigating the DevOps and platform engineering landscape, consider these actionable recommendations:

• Invest in both disciplines. DevOps and platform engineering are complementary, not competitive. Successful digital transformation requires both the cultural shift of DevOps and the technical foundation of platform engineering.
• Prioritize developer experience. Measure and optimize for developer productivity and satisfaction. Platforms that developers want to use drive adoption and deliver value.
• Establish clear metrics. Define success metrics for both DevOps practices and platform effectiveness. Track these metrics consistently and use them to drive continuous improvement.
• Build cross-functional teams. Platform teams should include diverse expertise, such as developers, operations engineers, security specialists, and product managers who understand user needs.
• Embrace incremental progress. Both DevOps transformation and platform engineering implementation are iterative journeys. Start small, demonstrate value, and scale based on success.

The path forward

The relationship between DevOps and platform engineering represents the natural evolution of software delivery practices in cloud-native enterprises. While DevOps provides the cultural foundation and practices for continuous delivery, platform engineering creates the scalable infrastructure that enables these practices to thrive across large, complex organizations.

For enterprises committed to digital transformation, the question isn’t whether to adopt DevOps or platform engineering, but how to implement both effectively. Organizations that successfully combine DevOps practices with robust internal platforms position themselves to deliver software faster, more reliably, and at scale — turning IT from a cost center into a competitive advantage.

The path forward requires a commitment to both cultural change and technical excellence. With proper implementation of DevOps practices supported by well-designed platforms, enterprises can achieve the agility, reliability, and innovation speed that modern markets demand.

The post DevOps and platform engineering: Building scalable software delivery in cloud-native enterprises appeared first on Dynatrace news.

With growing multicloud complexity and the need for organization-wide scalability, self-service and automation capabilities have become increasingly essential for developer productivity.

In response to this shift, platform engineering is rapidly growing in popularity. Many consider it an effective solution for improving efficiency and overall satisfaction for developers across a variety of organizations and industries.

The practice of platform engineering has evolved alongside the increasing complexity of cloud environments. Platform engineering is a practice that outlines how development teams build internal developer platforms (IDPs) to create self-service capabilities for software engineering teams. The result is a cloud-native approach to software delivery. A platform encompasses a set of tools, services, and infrastructure that enables developers to build, test, and deploy software applications. Platform engineers design and implement these platforms, as well as ensure their security, scalability, and reliability.

In what follows, we’ll cover the importance of platform engineering, the role of a platform engineer, and where the practice is heading in the future.

How does platform engineering work?

Platform engineering works by addressing common developer issues and streamlining software delivery to expedite the development processes. Self-service capabilities reduce complexity and allow developers to freely use the platform’s provided tools, workflows, services, and automation. As a result, developers can focus on the end product of the development process rather than its logistics and underlying infrastructure.

While self-service capabilities promote flexibility, platforms still help maintain compliance and synergy across development processes through centralized and predefined frameworks. Platforms provide a “paved road” for development teams, minimizing common obstacles and catering to needs to empower developers to easily navigate software delivery.

Platforms are an excellent way to scale development processes across an organization. As such, they’re typically most suitable for larger organizations but can also have their utility in smaller organizations. Maintaining coherence and compliance across multiple developers and teams may require a great deal of time and effort, especially without the aid of centralized infrastructure, toolchains, and templates. Fortunately, appropriately designed platforms provide these aids.

Why is platform engineering important?

With platform engineering, a development team can deliver a frictionless, self-service developer experience and provide maximum value with minimum overhead. Some of the primary advantages that the discipline provides include the following:

Accelerated software development

Platform engineering offers resources that foster efficiency, such as reusable components. These components are specific, predefined resources, such as libraries and templates, that are made available to all developers using the platform. Other aspects of the discipline — such as infrastructure as code, automation, and standardization — reduce extraneous manual processes to increase developer productivity.

Increased security

Secure coding practices are built into internal developer platforms (IDPs) from their inception. These practices include working with secrets and key management, vulnerability management and remediation, penetration testing, and OWASP. Platform engineering can automate many of these functions, making it easier to maintain a strong organizational security posture.

Reduced operational complexity

The self-service portals inherent to platform engineering greatly simplify operational processes. With these portals, developers do not need to rely on or coordinate with other teams that may not have the bandwidth to properly assist them. In turn, this reduced complexity fosters greater developer satisfaction and leads to less employee burnout.

Consistency in development processes

Platform-engineered, self-service portals involve standardized practices, which help to maintain consistency throughout the entire software delivery process. Centralized development practices, security protocols, and operational procedures make this consistency possible. In turn, consistency reduces errors, mean time to resolution, and silos, resulting in improved software quality and performance overall.

Scaling capabilities

Platform engineering offers scalability through its standardization and consistency. As a digital ecosystem expands, development teams must keep up with its evolution. The flexible and scalable nature of IDPs allows developers to seamlessly adapt and respond to these infrastructure changes.

“Platform engineering is increasingly becoming the focal point for organizations seeking to advance the maturity of their DevOps automation practices,” says Anita Schreiner, vice president of delivery at Dynatrace, in the 2023 DevOps Automation Pulse report. “This shift is accompanied by a rise in technical debt and coordination efforts among teams. Without a central and integrated platform, scaling automation to drive further impact becomes an insurmountable challenge.”

In response to these increasing demands, the report found that a staggering 54% of organizations are investing in platforms to enable easier integration of tools and collaboration between teams involved in automation projects.

Internal developer platforms

Internal developer platforms (IDPs) are the “platform” in platform engineering. Developers use IDPs to efficiently deliver software at scale. Most commonly, platforms consist of tools, templates, libraries, services, and other resources that developers can leverage to accelerate and streamline software delivery.

IDPs can also provide automated workflows that assist with repeatable tasks and boost developer productivity. Additionally, platform teams can bake security and compliance measures into IDPs. Through their centralized use, IDPs help ensure development processes are consistent and do not introduce vulnerabilities.

Platform teams are essentially product teams: their product is the IDP and their customers are internal developers. By treating the IDP as a product, platform teams are incentivized to create the best user experience possible, with the ultimate goal of achieving the highest user satisfaction. Platform teams thus strive to fine-tune all of the IDP’s components to best suit the developers using them.

Because needs vary greatly from organization to organization, there is no singular correct formula to create an effective IDP. IDPs may look and operate very differently across organizations. Ultimately, an effective IDP is specifically tailored to the developers using it, ensuring a frictionless delivery process and the utmost user satisfaction.

DevOps and the platform engineer role

In the world of DevOps, the role of platform engineers is relatively new. To better comprehend this role’s function, one must first understand how the discipline of platform engineering relates to DevOps as a whole.

DevOps methodology encourages collaboration between development and operations teams. To aid this collaboration, platform engineering offers DevOps teams a centralized platform for their tools and workflows. To some extent, the two practices complement each other. Like DevOps, successful platform engineering requires collaboration between development, security, and operations teams.

But beyond simply fostering collaboration, a central purpose of platform engineering is to support DevOps teams with tools, platforms, and workflows for effective software development. This realization has led to an increased organizational use of microservices to shift away from traditional product teams in favor of teams that apply platform engineering principles.

Platform engineering cannot stand alone, however. DevOps teams are still required because each application may require a unique DevOps pipeline. To attend to this need, platform teams provide the centralized infrastructure and tooling so DevOps teams may build their own pipelines independent of other teams.

The future of platform engineering

Platform engineering is at an evolutionary point as it matures alongside other DevOps practices. Overall, the future of the discipline entails working with product managers, designing based on internal development team requirements, and simplifying the DevOps process.

Platform engineers will see their purpose as creating infrastructure (as a product) to better understand the software delivery cycle’s requirements. Their metric of success will relate to how easily developers can self-service their requirements and own their code in production.

Platform engineering FAQs

What is the purpose of platform engineering?

Platform engineering is the creation and maintenance of internal developer platforms (IDPs) that offer self-service capabilities. Its core purpose is to provide software engineering teams with streamlined tools and workflows. This frees developers to focus on writing code and building features.

How is platform observability different from traditional infrastructure monitoring?

Traditional monitoring focuses on system health, including CPU, memory, and uptime. Platform observability adds visibility into developer usage patterns, CI/CD pipeline health, self-service adoption, compliance posture, and business impact.

Why is observability essential for platform engineering?

Because an internal development platform (IDP) touches every application and service, blind spots can stall deployments, reduce developer productivity, and delay releases. Observability ensures the platform actually accelerates development, rather than slowing it down.

What benefits do internal developer platforms (IDPs) offer to development teams?

IDPs reduce operational complexity and cognitive load by providing self-service access to standardized tools, services, and infrastructure. IDPs also ensure consistency, enforce security protocols, and accelerate software delivery while maintaining compliance across an organization.

When is an organization ready to implement platform engineering?

Organizations should consider implementing platform engineering and Internal Developer Platforms (IDPs) once their development teams grow beyond approximately 20-30 developers. At this scale, managing consistency, compliance, and infrastructure across multiple teams becomes increasingly complex without centralized aid. Before you implement a platform engineering program, it helps to assess existing infrastructure and finalize your budget.

What are the key roles within a platform engineering team?

• The Head of Platform Engineering is responsible for strategic oversight and resource allocation
• The Platform Product Manager defines the platform’s roadmap based on user feedback
• DevEx platform engineers focus on optimizing the developer experience
• Infrastructure platform engineers ensure the underlying infrastructure is robust and compliant

The post What is platform engineering? How does it work? appeared first on Dynatrace news.

For developers, the ultimate win is creating impactful features, shipping them quickly, and confidently implementing fixes when needed. Distributed tracing plays a critical role in achieving these goals. As a core component of observability, it provides the insights developers need to write better code, collaborate efficiently, and increase application reliability.

Developers know how challenging it can be to follow traces from beginning to end across multiple entities and data providers. Harder still is following those traces in context with metrics, logging data, security details, and real user experience data. Certain tools may provide visibility into small segments or isolated details. But developers often have to piece these clues together manually, which makes it difficult to extract meaningful and reliable results.

Dynatrace delivers distributed tracing with capabilities designed to streamline workflows. From understanding the impact of code changes to quickly resolving issues flagged in production, here’s how distributed tracing can help you increase developer velocity and deliver meaningful innovation throughout the software development lifecycle (SDLC).

Distributed tracing best practices key takeaways:

1. Visualize and understand your system. Distributed tracing plays a key role in uncovering the topology, interactions, and dependencies of your services.
2. Analyze and fix problems fast. Combine distributed tracing with AI analysis, context-driven querying, and collaboration tools.
3. Build better software with telemetry data in context. Unify telemetry data
4. Automate to ship better code faster. Use distributed tracing to automate and streamline workflows and set up intelligent alerts.

Visualize and understand your system

Before implementing changes or designing new features, it’s essential to have a clear understanding of your system’s current state. Without a clear picture of your current system, any change risks overlooking critical dependencies and misalignment with your architecture, whether in the cloud or on-premises. Distributed tracing plays a key role in uncovering the topology, interactions, and dependencies of your services, giving developers the visibility they need to make informed decisions.

Dynatrace Smartscape® technology automatically maps horizontal service relationships, offering real-time visualization of service connections and dependencies. This end-to-end view helps developers quickly understand how components interact within the overall system.

For a more granular understanding, inspecting individual traces allows you to focus on specific workflows or problematic behaviors. This depth of insight can help you plan better and identify challenges early, reducing surprises during later stages of development.

Trace example: Verifying service for “platinum” loyalty users

Say you’re a developer on an app called “AuthenticationService.” You can select a trace that lets you visualize its path through your system and examine each span’s properties to ensure “Platinum” loyalty users are being served effectively. While understanding the state of your system is important at each stage of the SDLC, it’s often one of the first steps in planning, requirements gathering, and designing changes.

In Dynatrace, you would open the Distributed Tracing app and enter a filter for the request attribute that indicates loyalty status. This filter returns a list of traces you can inspect individually to understand any bottlenecks or issues that could be impacting this specific subset of customers.

Analyze and fix problems fast using distributed tracing for developers

Identifying root causes in complex microservice-based architectures can be tough, but Dynatrace Davis® AI analyzes dependencies in real time, helping you quickly and confidently resolve issues.

But what if you want to visualize data outside of an individual problem occurrence? Some issues occur repeatedly in specific areas of a system, while others arise from application changes. Problems often span multiple teams, requiring collaboration to resolve effectively.

For broader insights, the Dynatrace Distributed Tracing app provides flexible access to raw trace data. You can filter by namespace, release version, or database calls, then Dynatrace automatically generates a DQL (Dynatrace Query Language) query so you can view results in notebooks or pin visuals to dashboards, which enable you to collaborate seamlessly with other teams. This approach is particularly useful during testing, deployment, and maintenance, where visibility into system behavior is critical.

This example shows a plot generated by a DQL query that indicates the number of database calls an application makes and how they perform over time.

Let’s assume you’re also interested in how your database queries are performing. To get an instant performance summary, you can easily add a table to your dashboard that summarizes the count, average, and percentiles of the durations of your database spans.

Build better software with telemetry data in context

Developers juggle many responsibilities, from testing and deploying code to maintaining stability. However, fragmented workflows and the endless search for the right information can often slow progress and create frustration, making it harder to meet deadlines and maintain a focus on innovation.

As a developer, how can you get the information you need without wasting time chasing down data and trying to understand all its upstream and downstream effects? The answer: distributed traces and telemetry data in context.

Flexible access to unified telemetry data is a game-changer for developers. With Dynatrace, you can seamlessly query multiple telemetry data sets and visualize the results in ways that align with your specific needs. This flexibility empowers you to connect the dots across complex workflows, analyze incidents within their broader context, and make data-driven decisions that support automation and enhance software quality.

The example below brings together spans and logs. Dynatrace automatically enriches every log with trace and span IDs, making it simple to track correlations among related data. With Dynatrace Query Language (DQL), you can dynamically combine spans and related log content on-the-fly.

To understand the impact of an error, you can chart which services and endpoints are emitting this log error.

As a developer, you can unlock deeper insights, linking operations to specific errors and enabling you to assess the scope and impact of incidents accurately. This gives you and your teams the ability to move beyond reactive problem-solving into proactive, intelligent development.

Use distributed tracing for developers to automate and ship better code faster

Automation is key to accelerating development while maintaining quality. By streamlining workflows, automating repetitive tasks, and setting up intelligent alerts, teams can proactively address issues and minimize manual effort.

For example, as a developer, you can use trace data to establish quality gates or set alerts for specific exceptions, ensuring you can quickly flag and resolve any recurring problems. This approach boosts efficiency and ensures that teams can consistently deliver high-performing, reliable code to production.

Assume you’ve been working on a bug that appeared as an exception in your traces. You want to check if the bug has been fixed and set up an alert to get a reminder if this particular bug comes back.

Let’s start by creating a metric based on this particular exception in the Dynatrace stream-processing data ingestion technology, OpenPipeline™. By creating a metric at ingestion using OpenPipeline’s centralized data handling and advanced data processing capabilities, you can continually monitor for evidence of the exception recurring.

You can use this extracted metric to visualize its frequency over time in a dashboard.

Finally, once you’ve set up a metric, you can use it to create an alert and send a notification to your system of choice (such as Slack, Teams, ServiceNow, and so on).

Increase reliability and automate more with distributed tracing best practices

As development responsibilities continue to expand in today’s complex environments, distributed tracing has emerged as a critical tool for developers throughout the entire software development lifecycle.

Applyin these distributed tracing best practices helps developers visualize systems, resolve issues quickly, and streamline workflows. By providing deep insights and context of upstream and downstream events, traces and spans give teams the data they need to automate tasks and deliver more reliable, higher-quality software faster and with greater confidence. The result allows you to focus on what matters most: creating impactful features.

Start integrating distributed tracing into one part of your workflow today and see how quickly it becomes indispensable to your development practice.

The post Distributed tracing best practices for the software development lifecycle appeared first on Dynatrace news.

Streamlining site reliability at scale can be daunting, particularly with large-scale AWS environments and architecture that rely on hundreds—or even thousands—of Amazon EC2 instances. However, you can simplify the process by automating guardians in the Site Reliability Guardian (SRG) to trigger whenever there are AWS tag changes, helping teams improve compliance and effectively manage system performance.

This step-by-step guide will show you how to configure your architecture to trigger guardians whenever EC2 tags are updated. Note that EC2 is an example; this guide can be made to work generically for tag changes on any AWS resource. By the end of this guide, you’ll be ready to automate guardians at scale and optimize Amazon EC2 management with ease.

Why automate guardians for AWS tag changes?

Before diving into the technical setup, here’s why automating guardians whenever EC2 tags change is beneficial for your organization:

• Greater efficiency: Automatically triggering guardians removes the need for manual intervention, saving time for DevOps or site reliability engineering (SRE) teams and allowing for more efficient resource management at scale.
• Better compliance: Automating guardians ensures critical policies and checks are consistently applied after changes across your architecture, improving security and compliance efforts.
• Cost optimization: Immediate responses to tag changes lead to informed decisions about scaling, shutting down unused instances, or fine-tuning resource efficiency.
• Proactive site reliability: Automated guardians can monitor the four golden signals, enabling proactive reliability measures.

Now, let’s get started with the setup!

Step 1: Create an API token

First, create an API token to integrate AWS services with Dynatrace for guardian automation.

1. Log into your Dynatrace tenant

Log in to your Dynatrace tenant and note the first part of the URL (for instance, “abc12345”), which is your tenant ID.

2. Access token settings

Press Ctrl + K or CMD + K and search for “Access Tokens” within Dynatrace.

3. Generate a new token

Create a new access token and assign it “bizevents.ingest” permissions.

4. Save the token

Copy and securely store the token, which looks like “dt0c01.*****.*****”. You’ll use this later during configuration.

Step 2: Create the EventBridge connection

Amazon EventBridge acts as the bridge between AWS and Dynatrace. Here’s how to set it up:

1. Navigate to Amazon EventBridge

Log in to your AWS Management Console and go to EventBridge > Connections.

2. Recreate the cURL command

You can use this cURL command as a reference to establish your connection:

curl -X POST \
'https://abc12345.live.dynatrace.com/api/v2/bizevents/ingest' \
-H 'Authorization: Api-Token dt0c01.*****.*****' \
-H 'Content-Type: application/cloudevent+json' \
-d '{…}'

3. Set the Authorization Method

Create a new EventBridge connection with the Authorization Method set to “API Key” and use the API token from Step 1 as the value (i.e., “Api-Token dt0c01.*****.****”).

Step 3: Define and configure EventBridge rules

EventBridge rules define the exact conditions for triggering guardians:

1. Specify the input template:

Create an input template to modify your event data:

{
  "specversion": "1.0",
  "id": "<id>",
  "source": "aws.<source>",
  "type": "ec2.tag.change",
  "time": "<time>",
  "aws.region": "<region>",
  "aws.eventbridge.rule.arn": "<aws.events.rule-arn>",
  "aws.resources": <resources>,
  "data": <detail>
}

2. Set the event pattern

Create a rule in EventBridge with the following event pattern:

{
  "source": ["aws.tag"],
  "detail-type": ["Tag Change on Resource"],
  "detail": {
    "service": ["ec2"],
    "resource-type": ["instance"]
  }
}

3. Apply targets and permissions

Assign targets and permissions to ensure successful data ingestion into Dynatrace. Use an IAM role to permit EventBridge to call your API destination.

The input transformer should be set as follows:

{"detail":"$.detail","id":"$.id","region":"$.region","resources":"$.resources","source":"$.source","time":"$.time"}

Step 4: Test tag changes on Amazon EC2 instances

To validate your configuration, perform the following:

1. Change a tag

Modify a tag by going to your Amazon EC2 instances in the AWS Management Console. For instance, update the “Environment” tag with a new value.

2. Verify event logging

Check the EventBridge console to ensure your tag change triggered the appropriate event.

3. Confirm data in Dynatrace

Within Dynatrace, press CMD/Ctrl + K and search for “Notebooks.” Create a new notebook and run the following query:

fetch bizevents | filter event.type == "ec2.tag.change"

If the query returns results, your configuration is working correctly.

Step 5: Set up the guardian

1. Create a new guardian

In Dynatrace, search for “Site Reliability Guardian” (`CMD/Ctrl + K`) and create a new guardian. For best practices, use the “Four Golden Signals” template.

2. Automate the workflow

Either on the overview page showing all guardians or on the analysis page of a selected guardian, click the Automate button. This will generate a workflow that triggers the guardian based on incoming bizevents (Business events). Configure the event type as `bizevent` and set the filter query to:

event.type == "ec2.tag.change"

3. Add a pause

To allow your systems to stabilize before triggering the guardian, add a “wait before” step. For example, set a delay of 600 seconds (10 minutes).

Example timeline:

• 06:59: Tag changed on EC2 instance.
• 07:00: EventBridge triggers the workflow.
• 07:10: Guardian is executed after 10-minute pause.

4. Save the workflow

Save your final workflow to activate the automation.

Step 6: Validate and monitor the setup

Perform end-to-end validation by changing an EC2 tag again. Confirm the following:

• The tag change event reaches Dynatrace.
• The workflow triggers the guardian.
• The guardian results appear in Dynatrace (e.g., heatmaps or relevant logs).

Run the following query in Dynatrace for additional monitoring:

fetch bizevents | filter event.type == "ec2.tag.change"

You should see log entries confirming the successful execution of your guardian process.

Achieve more with Site Reliability Guardian

In this blog, we highlighted the significant benefits of automating Site Reliability Guardian  triggers for Amazon EC2 changes. With automation, SRG helps engineering teams achieve efficiency, improved compliance, and cost optimization.

The post Enhance efficiency and compliance with automated AWS tag change triggers: A step-by-step guide appeared first on Dynatrace news.

In this blog post, we guide you through configuring a project to visualize real-time CI/CD build and release data for your Azure DevOps pipelines. The resulting visibility enhances collaboration with transparent data, increases productivity by automating monitoring tasks, and enables teams to detect issues proactively. With insights into your Azure DevOps pipelines, you can continuously improve processes, ensuring smoother and more reliable deployments over time.

A notebook version of the blog is also available on the Dynatrace GitHub repository. Download the AzureDevOps - Dynatrace Integration.json file and upload it to your Notebooks app in Dynatrace.

Prerequisites

Before we begin, ensure you have the following:

• Access to your Dynatrace Tenant and permission to create tokens.
• Your tenant ID, which can be found in your environment URL: https://<YOUR_TENANT_ID>.live.dynatrace.com/.
• A token with Ingest Logs v2 scope.
• A token with Write Settings scope.

Create webhooks in Azure DevOps

First, we need to create two service hooks subscriptions in Azure DevOps: one for Builds Completed and one for Release Deployment Completed.

1. Navigate to https://{orgName}/{project_name}/_settings/serviceHooks.
2. During the configuration, do not apply any filters.
3. In the settings page of the subscription, fill in the following fields:
   • URL: https://<YOUR_TENANT_ID>.live.dynatrace.com/api/v2/logs/ingest
   • HTTP Headers: Authorization: Api-token <YOUR_LOG_INGEST_TOKEN>
   • Ensure the text above is copied exactly, replacing only the token.
   • Change “Messages to send” and “Detailed Messages to send” to Text.

Add a new Grail logs bucket

Follow these steps to create a new logs bucket in Dynatrace. Note: This step is optional. You’re welcome to use an existing Grail logs bucket.

1. Open the Storage Management app in your tenant: Select CTRL/CMD + K and enter Storage.
2. Create a new bucket by selecting + in the top right corner.
3. Name the bucket azure_devops_logs.
4. Set the retention time as desired.
5. Set the bucket type to logs.

Configure OpenPipeline with log processing rules

Using OpenPipeline™, you can easily define a rule that routes all relevant log lines you created in the previous step into the bucket. This process also performs the necessary processing steps, such as renaming fields or transforming log data into dedicated events.

1. Open the OpenPipeline app and select Logs in the left pane.
2. Select the Pipelines tab and create a new one by selecting + Pipeline.
3. Name the new pipeline AzureDevOps.
4. Go to Dynamic Routing and create the following new rule:

matchesPhrase(eventType,"ms.vss-release.deployment-completed-event") OR matchesPhrase(eventType,"build.complete")

5. From the Pipeline dropdown, select “AzureDevOps”.
6. Return to your pipelines and open “AzureDevOps”.
7. Under the Storage section, add a new processor > Bucket assignment, set a name and select the azure_devops_logs bucket from the dropdown.

8. Next, open the Processing tab and define a couple of rules.
   1. First, create a new Rename Fields rule and call it “Rename Build Fields” where the left value is the new field name and the right value is the existing field name.

1. resource.buildNumber: buildNumber
2. resource.result: result

1. 2. Second, create another Rename Fields rule called “Rename Release Fields” where the left value is the new field name and the right value is the existing field name.

1. resource.stageName: stageName  
2. resource.project.name: projectName 
3. resource.deployment.release.name: releaseName 
4. releaseStatus:resource.environment.status: releaseStatus

Use the following sample data to verify your rules are working as expected.

Release event sample data:

{ 
       "timestamp": "2024-11-11T15:14:51.104000000-05:00", 
       "loglevel": "NONE", 
       "status": "NONE", 
       "createdDate": "2024-11-11T20:14:50.6300269Z", 
       "detailedMessage.text": "Deployment of release Release-946 on stage Staging succeeded. Time to deploy: 00:14:14.", 
       "dt.auth.origin": "dt0c01.YFMJ6LUO43SFFDW2SF7EW5YZ", 
       "eventType": "ms.vss-release.deployment-completed-event", 
       "id": "1862ab11-c0d4-451a-8b9b-0dfe7f517297", 
       "message.text": "Deployment of release Release-946 on stage Staging succeeded.", 
       "resource.environment.status": "succeeded", 
       "resource.project.name": "devlove-alpha", 
       "resource.stageName": "Staging", 
       "resource.deployment.release.name": "Release-946" 
    }

Create an Azure DevOps dashboard and visualize log data

Now that we have ingested the logs coming from AzureDevOps, let’s visualize the data to get better and quicker insights into our CICD pipelines.

1. Go to the AzureDevOps Git Repository and download the AzureDevOps Dashboard (on Logs).json file.
2. Within Dynatrace, open the Dashboards app and select Upload at the top left corner.
3. Upload the JSON file to start visualizing your Azure DevOps data.

Extract “release” and “build” events

Taking this a step further, we can convert the ingested log data to SDLC (Software Development Lifecycle) events in case we detect a new release or build and discard the related log line afterward.

This helps reduce the number of stored log data and supports further platform engineering use cases, such as calculating DORA metrics, automating development processes, or observing the health of your engineering pipeline.

Disclaimer: The following instructions extract Business events from log data. Once supported by OpenPipeline we propose to extract Software Development Lifecycle Events (SDLC events), which are the preferred way of storing the extracted information.

Note: You may need to request a Log Content Length (MaxContentLength_Bytes) increase depending on how many steps your Release Events have. The integration generates ingest costs for logs and metrics (according to your rate card), depending on how many build/release events you ingest.

1. In Dynatrace, open OpenPipeline:
   • Go to OpenPipeline > Logs > Pipelines > AzureDevOps.
   • Navigate to the Data Extraction section.
2. Next, create a Business Event Processor rule, for all build events, using the following parameters:
   • Name: Build Result
   • Matching condition: matchesPhrase(eventType,"build.complete")
   • Event type: field name eventType
   • Event provider: Change to Static String: AzureDevOps
   • Fields to extract: result, buildNumber, resource.reason

1. Finally, we use another Business Event Processor rule, to extract release events:
   • Name: Release Result
   • Matching condition: matchesPhrase(eventType,"ms.vss-release.deployment-completed-event")
   • Event type: field name eventType
   • Event provider: Change to Static String: AzureDevOps
   • Fields to extract: stageName, projectName, releaseName, releaseStatus, resource.deplyoment.startedOn, resource.deployment.completedOn

Extract Davis® AI events (optional)

Besides transforming the log line into SDLC events, you can also extract Davis events in case something goes wrong. These events can be used to create an alert or trigger a (remediation) workflow.

1. First, add an event if a build has failed. Add a new “Davis event” processor using the following data:
   • Name: Build Complete Failed
   • Matching condition: matchesPhrase(eventType,"build.complete”) AND result== “build”
   • Event description: Unable to generate build {buildNumber}

Note: You can change the event.type in case you want to increase the severity level.

2. Next, extract a Davis event if the deployment is rejected:
   • Name: Release deployment rejected
   • Matching condition: matchesPhrase(eventType,"ms.vss-release.deployment-completed-event”) AND releaseStatus== “rejected”
   • Event description: Unable to deploy release {releaseName}

Discard logs (optional)

Now that we have successfully converted the log event into a SDLC (Business) and a Davis event, you can disable the storage assignment rule. This will reduce the amount of data stored in Grail and help you saving some money (and consequently speeding up your log queries). Go to OpenPipeline > Logs > Pipelines > AzureDevOps.

1. Open the OpenPipeline app and select the pipeline we created before.
2. Select the tab Storage and change the matching condition to false.

Analyzing data

After deleting the logs events we need to adapt our dashboard to consume business instead of log data. To speed up things you can upload a ready-to-use dashboard into your environment:

1. Go to the AzureDevOps Git Repository and download the AzureDevOps Dashboard (on BizEvents).json file.
2. Within Dynatrace, open the Dashboards, select Upload at the top left corner, and select the JSON file.

Additionally, we recommend that you create a segment to filter all of your monitored entities across different apps.

1. Go to the Segments app and create a new segment by selecting + in the top right corner.
2. Rename the segment to AzureDevOps.
3. Select + Business events and add the following filter: event.provider = AzureDevOps
4. Select + Logs and add the following filter: dt.system.bucket = azure_devops_logs
5. Select Preview to validate the filters and Save once you’re done.

What’s next

By following these steps, you’ll be able to seamlessly integrate Azure DevOps with Dynatrace, enabling efficient log management and insightful data visualization.

Happy monitoring! 🚀

The post Insights into your Azure DevOps pipelines appeared first on Dynatrace news.

Traditional monitoring approaches often require manual scripting and integration to get alerted about production-threatening issues in pre-production environments.
Dynatrace Simple Workflows make this process automatic and frictionless—there is no additional cost for workflows. By offering a single trigger and a single task, you can rapidly set up an action (like Slack or email notifications) to detect specific exceptions in your services. This means fewer surprises when deploying to production and more time spent delivering valuable features.

Why manual alerting falls short

As your product and deployments scale horizontally and vertically, the sheer volume of data makes it impossible for teams to catch every error quickly using manual processes. Your teams want to iterate rapidly but face multiple hurdles:

• Increased complexity: Microservices and container-based apps generate massive logs and metrics.
• Unstructured overview: Manually scanning logs or waiting for someone to notice an error in staging is time-consuming.
• Siloed tooling: Stitching multiple tools and scripts together can create friction and decrease your deployment velocity.

As a result, minor issues in staging can slip into production, leading to potential downtime and a poor user experience. Developers need a way to quickly set up alerts for targeted pre-production exceptions without incurring steep costs or heavy overhead.

Introducing Dynatrace Simple Workflows for early alerting

Dynatrace Simple Workflows helps your team overcome the challenges of manual processes by offering easy, no-cost automation for single-step tasks.

Go to Workflows and start creating a new workflow. By default, the Simple Workflow will be selected to give you the most cost-effective experience.

You can select any trigger that’s available for standard workflows, including schedules, problem triggers, customer event triggers, or on-demand triggers.

After you’ve selected + Workflow, you can name your workflow and select a specific trigger.

Here, you can select a specific event or a timed trigger like a cronjob. Additionally, with an on-demand trigger, you can trigger the workflow through REST API from your CI/CD, scripts, or any other automation flows.

After specifying your trigger, you can select a specific action. This action will be executed each time an event occurs, a timer kicks in, or an on-demand request triggers the action. You can easily send Slack/email messages to your teams, create JIRA issues, or trigger PagerDuty alerts. 

Safeguard your pre-production environments.

Imagine you’re running a busy e-commerce platform composed of multiple containerized microservices running on Kubernetes. Each microservice is responsible for a specific and critical business function—managing user sessions, processing payment and authentication, and tracking inventory.

To orchestrate the different logging services, you use Fluent Bit to forward these logs to your centralized logging system, like Dynatrace.

Recently, in production, your team encountered an out-of-memory error exception that killed all the processes for Fluent Bit. This caused you to lose complete visibility of your containers’ logs, performance, and error data, and you could not tell if the system was down or not.

kubernetes.event.message": "Memory cgroup out of memory: Killed process 1146778 (fluent-bit) total-vm:952432kB, anon-rss:303872kB, file-rss:1108kB, shmem-rss:0kB, UID:1000 pgtables:1424kB oom_score_adj:-997",
kubernetes.event.reason": "OOMKilling",

The error message indicates that the Linux cgroup assigned to your Fluent Bit container has reached its memory limit. Because Kubernetes enforces memory constraints for each pod, the kernel OOM (OutOfMemory) killer forcibly terminates the Fluent Bit process once memory usage exceeds the threshold set in the container/pod specification.

You have fixed the error, and as a follow-up to your RCA documentation, you want to ensure you’re alerted of these errors early on staging, so you want to set up a quick alert on staging for your feature branch.

For this example, we go to Simple Workflows and select Trigger > Davis® event trigger to find these out-of-memory errors. You can learn more about event triggers in Dynatrace Documentation.

When Davis AI event triggers find these, we will set a simple Slack or Email notification for our team so the team can ensure the fix is working and other future changes are caught early.
If you ever need more advanced capabilities—like custom code, multi-step logic, or conditional tasks—you can seamlessly upgrade to standard workflows with just a few clicks.

This ensures you’re never locked into an overly complex or expensive solution before you’re ready. It’s as simple as that!

Deep dive into Simple Workflows

How Simple Workflows work:

• Simple Workflows provide core Dynatrace automation capabilities
• You can use any trigger type, problem-event triggers, schedule-based triggers, or external webhooks.
• They trigger a single, out-of-the-box action: for example, Sending a Slack Notification, Creating a Jira Issue, Sending an Email, or Executing an HTTP Request.
• Unlike multi-step workflows, these don’t consume workflow hours.

Limitations:

• You can’t add more than one task.
• JavaScript actions, task conditions, and options are not allowed.

What’s next for Workflows?

Looking ahead, Dynatrace aims to expand the usability of Simple Workflows with more out-of-the-box actions and deeper integrations.

Both simple and standard workflows will benefit from future improvements like:

• A growing catalog of out-of-the-box actions
• Introduction of draft workflows, enabling you to work on your workflows without impact until you’re satisfied with your changes
• Watch Workflows: Get notifications whenever a workflow fails, is updated, or throttled.

For now, Simple Workflows delivers a fast way for developers and SREs to receive automated alerts—exactly when needed—at no extra cost.

Ready to try Simple Workflows?

Check out the Simple Workflows documentation to explore more use cases. For advanced functionality—like multi-step actions or running JavaScript—it’s free to upgrade to a standard workflow and take advantage of the full Dynatrace AutomationEngine capabilities.

With Simple Workflows, you can quickly eliminate manual monitoring steps, reduce time-to-detection, and keep staging errors where they belong—out of production.

The post Create simple workflows to automate alerts during development appeared first on Dynatrace news.

The growing popularity of open source software presents new risks associated with vulnerable libraries. In response, organizations have adopted additional security tools, such as software composition analysis, that scan code libraries for vulnerabilities. These tools enable organizations to mitigate risk earlier in the software development lifecycle (SDLC).

Traditionally, companies tracked these vulnerabilities manually or sifted through volumes of code. Both approaches resulted in lost time and resources. To handle the increasing complexity of open source software, software composition analysis (SCA) has become an important tool. SCA scans software dependencies for security vulnerabilities with speed and reliability.

What is software composition analysis?

Software composition analysis is an application security methodology that tracks and analyzes open source software components. Fundamentally, SCA tools provide insight into open source license limitations and possible vulnerabilities in your projects. These tools help organizations stay abreast of critical tasks, including security, license compliance, and code quality, to minimize risk.

Software composition analysis provides three core capabilities:

1. Build a software bill of materials (SBOM) to establish a detailed inventory of your open source software packages.
2. Verify license compliance requirements by determining what open source software you’re using and where it originated.
3. Discover detailed information about key vulnerabilities in your source code and provide applicable remediation suggestions.

How does software composition analysis work?

SCA tools work by running scans on a code base and creating a vulnerability analysis. The analysis outputs an SBOM that lists software components and their respective licenses. In addition, the scan inspects files to find vulnerable third-party libraries and provides insight into open source dependencies. The technology then compares the SBOM with other vulnerability databases to pinpoint critical vulnerabilities. Finally, an SCA tool offers remediation suggestions to resolve harmful vulnerabilities. As part of the process, SCA provides a full analysis of open source project health metrics.

For example, an organization that needs to establish a comprehensive security and compliance baseline can use software composition analysis to attain baseline license compliance and reveal security vulnerabilities. As teams further develop their code, they can use SCA to maintain license compliances and ensure consistent security.

Why is software composition analysis important?

Software composition analysis is an essential practice for IT professionals tasked with securing complex software ecosystems. Modern software development relies heavily on open source components and third-party libraries, which bring efficiency and robustness to the development process. However, they also introduce unique security, compliance, and risk management challenges.

1. Identifying vulnerabilities:  

Open source components often have inherent vulnerabilities due to their wide usage and public availability of their source code. This makes them attractive targets for bad actors. Without SCA, organizations risk unknowingly deploying software with vulnerabilities and exposing their systems. SCA tools provide automated scans to identify known vulnerabilities in third-party components.

2. Ensuring license compliance:  

Understanding the legal implications of open source software is critical. Many open source licenses come with obligations that organizations must adhere to—like attribution requirements or restrictions on commercial use. Non-compliance can lead to legal disputes, fines, or even the need to re-engineer software. SCA tools help by automatically flagging license issues, ensuring organizations remain compliant.

3. Managing supply chain risks:  

Using external dependencies in software increases the likelihood of inheriting risks from upstream sources. Compromised dependencies can ripple through an organization’s entire software stack. SCA offers visibility into an SBOM, enabling teams to monitor which components are in use and quickly address risks when vulnerabilities are discovered.

By embedding SCA into their development and DevSecOps practices, IT professionals can proactively mitigate risks, maintain compliance, and safeguard their software supply chain. SCA isn’t just a tool—it’s a vital part of protecting modern software systems in an increasingly interconnected world.

The benefits of software composition analysis

Software composition analysis (SCA) offers invaluable benefits to developers and IT professionals committed to creating secure, high-quality software.

Enhanced security

One of SCA’s primary advantages is its ability to enhance software application security. SCA tools automatically scan your codebase to identify open source components and check them against known vulnerability databases.

License compliance

Open source components often come with specific licensing requirements that, if not adhered to, can lead to legal and financial repercussions. SCA tools help ensure compliance by analyzing the licenses of all components within your application, providing insights into potential intellectual property risks.

Improved development efficiency

By integrating SCA into the development lifecycle, teams can automate the vulnerability detection and license compliance process, freeing up valuable resources. This allows developers to focus more on building features and less on manual checks or patching insecure components.

Risk mitigation and quality assurance

SCA contributes to the overall quality assurance of software products. Organizations can ensure their applications are secure and reliable by effectively managing the risks associated with open source components.

The challenges of software composition analysis

Despite its advantages, SCA presents several challenges that must be addressed to utilize its full potential effectively.

1. Managing the volume of open source components

The exponential growth of open source components in software development has led to a significant challenge in cataloging and managing these components within applications. With thousands of new open source libraries being added daily, SCA tools must possess robust indexing and update capabilities to ensure that they provide accurate and up-to-date information.

2. Understanding license compliance

Open source software often comes with complex licensing terms, and noncompliance can lead to legal issues or intellectual property conflicts. Developers and IT professionals must carefully analyze and comply with these licenses, yet navigating the multitude of open source licenses remains daunting. SCA tools must be comprehensive and adept at identifying potential compliance risks.

3. Identifying vulnerabilities

A critical function of SCA is the detection of security vulnerabilities within open source components. However, the sheer volume of potential vulnerabilities makes it challenging to prioritize which issues need immediate attention. False positives can divert resources away from actual threats, necessitating an efficient system for triaging alerts.

4. Integration with CI/CD pipelines

For SCA to be effective, seamless integration into CI/CD pipelines is needed. The process requires careful planning and execution to ensure that SCA tools provide real-time insights without hindering development velocity.

How to implement SCA in your development pipeline

Understanding SCA

Software composition analysis is a methodical approach to managing open source components within a codebase. It identifies vulnerabilities and licensing issues, providing developers with a comprehensive overview of their software’s security posture.

Key steps in implementing SCA

1. Integration into CI/CD pipelines: This allows for real-time monitoring and identification of vulnerabilities as new code is committed.
2. Automated scanning and reporting: These tools analyze the codebase for known vulnerabilities against databases and immediately alert developers to potential risks.
3. Policy management and governance: SCA tools often provide governance features that allow teams to enforce dependency management policies, ensuring compliance with organizational standards and legal requirements.
4. Continuous monitoring and updates: The dynamics of software development mean that vulnerabilities can appear at any time. Continuous monitoring and regular updates to the SCA tool’s vulnerability database guarantee that your security measures stay ahead of emerging threats.

How security can “shift left” in a DevSecOps lifecycle

One of SCA’s major benefits is that security pros can implement it into the initial stages of the SDLC. Teams can test projects for vulnerabilities in the early stages of development before those issues reach the build stage. This saves overall production costs and valuable resources.

Moreover, IT pros can use SCA to gain a better understanding of the open source software the organization uses and to track licenses. Accordingly, SCA tools can streamline the license management process and enforce security and license policies across the different stages of the SDLC.

Finally, SCA tools bridge the gap between detection and remediation by showing the location of vulnerabilities, assessing their impact, and suggesting remediation actions.

But software composition analysis tools alone are not enough

Despite their benefits, SCA tools don’t cover the entire security surface area. For one, SCA tools primarily focus on pre-production environments. This means you’re unable to scan for vulnerabilities exposed in production.

Additionally, although software composition analysis provides remediation suggestions for critical vulnerabilities, it does not prioritize them. As a result, IT pros are left to determine which issue to address first based on the current vulnerabilities and risk priority order. With limited time and resources, it can be difficult for security teams to prioritize vulnerabilities without deeper analysis.

Lastly, SCA tools don’t provide information about which pending issues are the most critical to your business assets. They also provide no context surrounding a vulnerability’s point of origin.

How to pair SCA with runtime application security

Although software composition analysis tools are limited, you can enhance their value by pairing them with another layer of security at runtime.

The Dynatrace Software Intelligence Platform analyzes the full impact and risks of vulnerabilities, in context, at runtime. The Dynatrace Application Security module not only delivers remediation suggestions but also eliminates false positives, prioritizing which critical issues to address first. Dynatrace OneAgent automatically discovers vulnerabilities in both production and pre-production environments, capturing the entire range of possible issues.

By incorporating key contextual information surrounding software vulnerabilities into the Davis Security Score, Dynatrace allows you to filter and prioritize issues to determine which ones your team must remediate immediately. Dynatrace Application Security eliminates blind spots and proactively identifies critical production risks earlier in the process, all to ensure your organization’s SDLC runs seamlessly.

Software composition analysis FAQ

1. What is the difference between SCA and SAST? 

While both improve software security, SCA analyzes third-party and open source dependencies to find vulnerabilities and licensing information. On the other hand, SAST examines your proprietary code to detect flaws such as insecure coding practices or logic errors.

2. What are the benefits of using SCA tools?  

SCA tools provide several benefits, including:

• Automatically detecting open source vulnerabilities
• Ensuring compliance with licensing obligations
• Speeding up the identification of security risks in software
• Offering continuous monitoring for newly reported vulnerabilities

3. What industries require SCA?  

Any industry using open source software can benefit from SCA. However, industries like finance, healthcare, and government, which rely on software for highly sensitive processes, prioritize SCA to reduce security risks.

4. How often should I run SCA scans?  

SCA scans should be integrated throughout the software development lifecycle. Regular scans during development, testing, and maintenance phases are critical to identifying new risks as they emerge.

5. Can SCA help with compliance requirements?  

Yes, SCA helps organizations comply with legal standards and regulations, such as GDPR or intellectual property laws, by validating that open source component licenses align with business requirements.

6. What is the difference between SCA and DAST? 

While SCA examines your software’s dependencies for vulnerabilities, Dynamic Application Security Testing (DAST) tests your application dynamically in a runtime environment to find security weaknesses like injection attacks or misconfigurations.

7. What is an SCA vulnerability? 

An SCA vulnerability is a recognized weakness in third-party or open source components that attackers could exploit.

8. What is “composition” in software testing? 

Composition refers to understanding and managing all dependencies (libraries, frameworks, packages) your software relies on. This involves identifying their origin, versions, and known risks.

9. What is the purpose of SCA? 

The purpose of SCA is security, compliance, and efficiency. It ensures that vulnerabilities in dependencies are mitigated, license risks are addressed, and the software supply chain is safe.

10. How to do a SCA analysis? 

SCA is typically done using specialized tools. These tools automate scanning your dependencies, mapping them to known vulnerabilities, and providing actionable insights for remediation.

The post What is software composition analysis? appeared first on Dynatrace news.

Dynatrace introduced numerous powerful features to its Infrastructure & Operations app, addressing the emerging requirement for enhanced end-to-end infrastructure observability. The newly introduced Network devices and Details view within Hosts provide comprehensive health status information, relevant networking signals, and machine metrics—all analyzed and provided by the industry-leading combination of Dynatrace Grail™ data lakehouse and Davis^® AI.

These enhancements are designed to empower IT operations and SRE teams with more comprehensive visibility and increased efficiency at any time.

Let’s explore these exciting new features and see how they elevate infrastructure management.

^{Figure 1. Infrastructure & Operations app showing manual root cause and impact analysis}

Advanced filter components for powerful enterprise-grade search and visualization

One of the standout enhancements of the latest update is the improved filter components, designed to facilitate more complex and advanced searches across cloud, on-premises, or hybrid infrastructure hosting environments, including support for custom tags.

Whether you’re looking to zero in on specific hosts, operating system and application processes, or devices, the improved filters enable high-precision searches without sacrificing the operational performance of the Infrastructure & Operations app.

Specifically, background filter queries and visualizations have been optimized to ensure fast response times for complex and large enterprise datasets. A critical update that further enhances this experience is the increase in visual limits—now, up to 100,000 host elements can be displayed within the resulting filtered view.
You can interactively sort, filter, and reorder these host elements with no query delay. This means quicker access to insights, allowing IT teams to act faster during timely and critical incidents.
Whether you’re looking to swiftly review performance trends across thousands of cloud-native resources or your goal is to investigate a single component within your environment, Infrastructure & Operations provides the details you’re looking for. Speaking of single elements and resources brings us to the next enhancement:

Host detail view: Get the complete picture and deep dive into host health

The recently introduced host detail view has elevated manual health reviews and in-depth analysis to the next level. You can now explore related insights and AI-powered analytics within a single host detail view. This view offers DevOps and engineers metrics related to health, security status, service events, and service level objectives (SLOs), paired with quick access to drill deep into logs or process-level insights.

As shown in Figure 3, the host details view is accessible directly from the list of host resources in Infrastructure & Operations and from within the overview pane.

To increase efficiency and shorten operations cycles, the current filtered host detail view can be shared effortlessly by copying the URL in the browser’s address bar. Teams can share the current view via Teams, Slack, or any other messenger and include the current view and findings as part of a support ticket.

In cases where rich details of process and service level consumption are required, the host details provide you with a Processes page focused on utilization metrics and troubleshooting insights.

Technology-type tags can be added at the process and process group levels, splitting the technology tagging for hosts into main and sub-technologies. This simplifies filtering and automation efforts.

When deep monitoring is activated, drilling into the process detail view shows versioning and release information. Custom tags on the application level allow you to filter more easily while simultaneously enhancing automation capabilities.

A new feature makes it easier for IT teams managing large-scale environments to stay on top of every detail across any infrastructure or region. Now, with more granular insights into process performance and technology versions, teams can quickly review and detect anomalies, prioritize problems reported by Davis AI, and maintain SLOs and compliance—all in one place: Infrastructure & Operations.

Host networking metrics and visualization

Network performance bottlenecks are one of the most common troubleshooting challenges in large infrastructures. The new Host Detail view also introduces improved networking insights to streamline diagnostic efforts, including a summarized view of key network metrics, TCP packet transmission statistics, retransmit errors, and packet loss.

These metrics are critical for understanding network health on the application and host level, isolating issues related to network connectivity or connection outages.

This improvement directly helps DevOps and InfraOps teams by reducing the time spent identifying network-related issues in cross-functional efforts.

Network devices view: Extend end-to-end infrastructure observability

In the daily life of DevOps, InfraOps, or SRE, one of the most common routines and troubleshooting challenges in large infrastructures is staying ahead of network performance bottlenecks.

With SD-WAN appliances, firewalls, load balancers, routers, switches, and other network devices in place, this task is becoming quite challenging yet crucial.

Infrastructure & Operations features a newly introduced Networking Devices section, which provides networking visualizations to streamline these efforts within one place.

With extensions available for Cisco, Palo Alto, NetScaler, Juniper, F5, Fortinet, and HAProxy available within Dynatrace Hub, the Network devices section instantly provides value to teams. Existing, configured extensions provide metrics and Davis AI-powered analytics without additional configuration efforts. Networking devices and appliances not yet onboarded can swiftly be integrated via SNMP integration or technology-specific extensions, as highlighted above.

This new capability dramatically simplifies monitoring signals like ethernet interface availability status and network utilization metrics alongside hardware metrics and consumption. Dynatrace Davis AI plays an integral role in this newly introduced section by automatically identifying and raising problems that might otherwise go unnoticed. It enables IT teams to proactively manage network performance bottlenecks or outages quickly, potentially before these issues impact services and users.

Dynatrace: Powering the next level of end-to-end infrastructure observation

The continued integration of Grail™ data lakehouse and Davis AI into Infrastructure & Operations, alongside new features focusing on networking devices, show the Dynatrace commitment to providing IT teams with unmatched and holistic end-to-end infrastructure observability empowered by AI-driven insights.

Together, these technologies enhance the ability of DevOps and InfraOps teams to manage the growing complexity of modern IT environments within a single platform and with a single app—Dynatrace Infrastructure and Operations.

With AI-driven root cause analysis, IT teams no longer need to manually correlate logs, metrics, and traces. Instead, the platform autonomously identifies the root causes of issues, minimizing downtime and freeing up valuable time for more strategic initiatives.

Networking specialists or architects who desire to surface the corresponding log lines are provided with pre-filtered query views, offering service-specific log information and surrounding logs of related components.

Engineers, developers, and power users are provided with the all-new Logs app, which we introduced recently in our blog post Simplicity meets power: Introducing the all-new Dynatrace Logs app.

Beyond the two apps mentioned, Davis CoPilot integration supports novice Dynatrace users by translating questions from natural language into Dynatrace Query Language (DQL) when requests become more sophisticated

Kickstart the new era of AI-powered end-to-end infrastructure observation with Dynatrace today!

Discover how the new and enhanced Infrastructure & Operations app can transform your daily routines and troubleshoot workflows to drive better business outcomes.

Existing Dynatrace customers with licenses that include Infrastructure Observability have automatic access to the new app and all other features available with Dynatrace SaaS; you don’t need to take any action other than to start using Infrastructure & Operations and its features.

Explore the latest updates on the Dynatrace platform by starting a free trial or requesting a live demonstration and taking a custom-tailored tour.

The post Supercharge your end-to-end infrastructure and operations observability experience appeared first on Dynatrace news.

Today, development teams suffer from a lack of automation for time-consuming tasks, the absence of standardization due to an overabundance of tool options, and insufficiently mature DevSecOps processes. This leads to frustrating bottlenecks for developers attempting to build and deliver software. For multinational enterprises, the cost of all that toil, complexity, and frustration multiplies exponentially due to the size of those organizations. In such contexts, platform engineering offers a compelling solution to enable business competitiveness in a manner that significantly enhances the developer experience. A central element of platform engineering teams is a robust Internal Developer Platform (IDP), which encompasses a set of tools, services, and infrastructure that enables developers to build, test, and deploy software applications.

Treating an Internal Developer Platform (IDP) as a product is an emerging paradigm within platform engineering communities. Similar to the observability desired for a request being processed by your digital services, it’s necessary to comprehend the metrics, traces, logs, and events associated with a code change from development through to production. The end-to-end observability of the engineering process becomes essential when building software under product safety legislation, such as medical devices. It’s nearly as crucial as the final product itself when high-frequency releases are critical to the business.

This blog post focuses on pipeline observability as a method for monitoring the software delivery capabilities of an organization’s IDP. This process begins when the developer merges a code change and ends when it is running in a production environment. In other words, pipeline observability encompasses Continuous Integration (CI) and includes Continuous Delivery (CD), as depicted in the following image.

Unlocked use cases

Gaining insights into your pipelines and applying the power of Dynatrace analytics and automation unlocks numerous use cases:

• Make data-driven improvements: Invest in those software delivery capabilities that provide the most significant payoff. To make the right decision, pipeline KPIs can reveal areas for improvement, protect your long-term investment in development, and present stakeholders with the benefits of sustained funding.
• Automate delivery processes: Ideally, an improvement entails introducing automation to eliminate manual tasks, foster collaboration, or speed up processes.
• Ensure pipeline compliance/governance: By obtaining an end-to-end view of the pipeline activities that a code change progresses through, you can identify blind spots that require monitoring and ensure compliance across the entire organization.

Software Development Lifecycle (SDLC) events

The Software Development Lifecycle (SDLC) is similar to the DevSecOps loop as it outlines the various phases a product idea undergoes before it is released into production. These phases must be aligned with security best practices, as discussed in A Beginner`s Guide to DevOps. While the lifecycle starts with a ticket specifying a new product idea, an actual code change often triggers various automated tasks kicking off the next phase. These automation tasks process the code change to build a deployable and create new artifacts accompanying the change throughout the delivery process.

In Dynatrace, examples of such tasks and resulting artifacts include the following, visualized in the below diagram:

• Plan: A ticket for enhancing a platform service is created in Jira.
• Code: The branch for the new feature in a GitHub repository is merged into the main branch.
• Build: GitHub builds the code changes and creates a deployable image.
• Test: Playwright executes end-to-end tests.
• Release:
  • The image is published on Harbor, and the Helm Chart is updated.
  • BlackDuck performs a security and vulnerability check, returning a scan result.
• Deploy:
  • ArgoCD deploys the Helm Chart in a development environment.
  • Synthetic HTTP monitors are executed in the hardening stage.
  • An automation updates a GitOps repository to roll out the artifact to production
• Operate: FlagD switches a feature flag from OFF to ON.

Given these examples, which are a subset of many others, crucial information about a software change and the related component is generated before monitoring begins. Consequently, Dynatrace defines the semantics of essential data points and stores them in a normalized manner. For instance, the Git commit, ticket ID, artifact version, release version, deployment stage, etc., are data points that require special attention. When the semantics of this metadata are well-defined, you can build insightful analytics and robust automation.

The specification defines the new event type SDLC_EVENT, which covers the event category for pipeline and task events. A pipeline can be the parent of multiple tasks to group the resulting events logically. A task event, however, represents the state of a single lifecycle activity like a build, test, deployment, scan, etc. Dynatrace Documentation maintains a list of events, which will grow as we unlock new use cases.

Defining an event standard succeeds through adoption within the ecosystem. This is why we’re aligned with open source initiatives and compatible with the CI/CD specification in OpenTelemetry driven by the CD Foundation. Consequently, your efforts into OpenTelemetry for pipeline observability will be natively supported by Dynatrace.

Generic SDLC event ingest endpoint

Dynatrace introduced a generic SDLC event ingest endpoint that enables data ingestion directly from any third-party CI/CD tool. While this endpoint accepts any JSON payload and adds default properties of the SDLC specification,  OpenPipeline™ is leveraged to process vendor-specific data and extract those properties defined by the specification. GitHub and ArgoCD are the first two tools to receive an OpenPipeline configuration.

The endpoint, together with OpenPipeline, opens a range of use cases, such as:

• Pipeline anomaly visualization on custom dashboards tailored within Dynatrace.
• In-depth analysis of delivery tasks using tools like Notebooks.
• Automated release validation using Dynatrace Site Reliability Guardian.
• Contextualization of third-party CI/CD activities with Dynatrace monitored entities.

Stay tuned

Currently, the API allows for the configuration of an event processing pipeline. Support for managing configuration in the OpenPipline app is a high priority. This will be accompanied by the above-mentioned GitHub and ArgoCD configurations and others to follow.

In some cases, a CI/CD tool’s log line contains important data points that, on their own, eliminate the need to additionally send an event to Dynatrace. Therefore, we’re working on a log processor to automatically extract relevant metadata and generate SDLC events from log lines.

Lastly, we’re working on a ready-made dashboard for the DORA metrics based on GitHub and ArgoCD metadata.

What’s next

• Explore: See the analytics sample in our documentation, which is executable in the playground environment.
• Adopt: Identify your most critical pipelines and make them visible. In other words, leverage the available event ingest endpoint and send pipeline activities to Dynatrace. In many cases, this is possible by leveraging webhook capabilities.
• Fine-tune: Perform data normalization by creating an OpenPipeline configuration that extracts properties according to the SDLC specification.

The post Observability throughout the software development lifecycle increases delivery performance appeared first on Dynatrace news.

In response to the scale and complexity of modern cloud-native technology, organizations are increasingly reliant on automation to properly manage their infrastructure and workflows. DevOps automation eliminates extraneous manual processes, enabling DevOps teams to develop, test, deliver, deploy, and execute other key processes at scale. Automation thus contributes to accelerated productivity and innovation across the organization.

Automation can be particularly powerful when applied to DevOps workflows. According to the Dynatrace 2023 DevOps Automation Pulse report, an average of 56% of end-to-end DevOps processes are automated across organizations of all kinds.

However, despite the rising popularity of DevOps automation, the maturity levels of that automation vary from organization to organization. These discrepancies can be a result of toolchain complexity (with 53% of organizations struggling in this area), siloed teams (46%), lack of resources (44%), cultural resistance (41%), and more.

Understanding exactly where an organization’s automation maturity stands is key to advancing to the next level. Armed with this knowledge, organizations can systematically address their weaknesses and specifically determine how to improve these areas. For this reason, teams need a comprehensive evaluation to assess their implementation of numerous facets of DevOps automation.

The DevOps Automation Assessment is a tool to help organizations holistically evaluate their automation maturity and make informed strides toward the next level of DevOps maturity.

How the DevOps automation assessment works

The DevOps automation assessment consists of 24 questions across the following four key areas of DevOps:

• Automation governance: The automation governance section deals with overarching, organization-wide automation practices. It addresses the extent to which an organization prioritizes automation efforts, including budgets, ROI models, standardized best practices, and more.
• Development & delivery automation: This section addresses the extent to which an organization automates processes within the software development lifecycle (SDLC), including deployment strategies, configuration approaches, and more.
• Operations automation: The operations section addresses the level of automation organizations use in maintaining and managing existing software. It explores infrastructure provisioning, incident management, problem remediation, and other key practices.
• Security automation: The final section addresses how much automation an organization uses when mitigating vulnerabilities and threats. It includes questions relating to vulnerability prioritization, attack detection and response, application testing, and other central aspects of security.

This comprehensive assessment provides maturity levels for each of these four areas, offering a nuanced understanding of where an organization’s automation maturity stands. Since teams from one functional area to another may be siloed, a respondent who is not knowledgeable on the automation practices of a certain area can still obtain insights by answering the questions that pertain to their team’s responsibilities.

Scoring

The questions are both quantitative and qualitative, each one addressing key determinants of DevOps automation maturity. Examples of qualitative questions include: How is automation created at your organization? What deployment strategies does your organization use? By contrast, the quantitative questions include: What proportion of time do software engineering and development teams spend writing automation scripts? How long do you estimate it takes to remediate a problem within one of your production applications?

The tool assigns every response to a question a unique point value. Based on the total for each section, the assessment determines and displays an organization’s maturity levels in the four key areas.

The maturity levels

The DevOps Automation Assessment evaluates each of the four key areas according to the following four maturity levels.

• Foundational: Foundational is the most basic level of automation maturity. At this level, automation practices are either non-existent or elementary, and not adding significant value to DevOps practices. Organizations at this maturity level should aim to build a strong automation foundation, define automation principles, and lay the groundwork for a more mature automation framework.
• Standardized: At the standardized level, automation has become more integrated into key DevOps processes. This includes expediting workflows, ensuring consistency, and reducing manual effort to a modest degree. The goal of organizations at this maturity level should be to achieve a higher level of automation integration and synergy between different stages of the DevOps lifecycle.
• Advanced: Once an organization’s automation maturity reaches the advanced level, its automation practices are integrated across the SDLC and assist greatly in scaling and executing DevOps processes. Organizations at this maturity level should strive to improve operational excellence by adopting AI analysis into their automation-driven practices.
• Intelligent: To reach the intelligent level, automation must be wholly reliable, sophisticated, and ingrained within organizational culture. At this level, organizations are leveraging artificial intelligence and machine learning (AI/ML) to bolster their automation practices. The goal of organizations at this maturity level should be to achieve higher levels of efficiency, agility, and innovation through intelligent, AI-driven automation practices.

The tool calculates a separate DevOps maturity level for each of the four individual sections (governance, development & delivery, operations, and security). For example, a respondent could hypothetically receive a foundational ranking for automation governance, advanced for development & delivery, intelligent for operations, and standardized for security.

Next steps: Using the results to advance DevOps automation maturity

While it is helpful to understand an organization’s automation maturity level in key DevOps areas, the information is only useful if teams can leverage it for improvement. Even at the highest level of automation maturity, there is always room to continually improve automation practices and capabilities as underlying technologies and the teams that use them evolve.

But how exactly can an organization advance its automation maturity to the next level? The DevOps Automation Pulse provides ample guidance and actionable steps for every level of automation maturity. For example, to progress from standardized to advanced, the report recommends that organizations implement a single source of reliable observability data to prioritize alerts continuously and automatically. Or, to progress from advanced to intelligent, the report encourages organizations to introduce AI/ML to assist continuous and automatic security processes, including vulnerability detection, investigation, assignments, remediation verification, and alert prioritization.

What’s more, teams can advance workflow automation further by adopting unified observability and log data collection, along with different forms of AI (predictive, causal, generative) for automated analysis. All of these recommendations and more in addition to the latest insights on the current state of DevOps automation are available in the DevOps Automation Pulse.

Start the journey toward greater DevOps automation

With consumer demands for quality and speed at unprecedented levels, DevOps automation is essential in organizations of all sizes and sectors. An organization’s automation maturity level may often be the determining factor in whether it pulls ahead of or falls behind the competition.

Once at a mature level, organizations with automated workflows, repeatable tasks, and other DevOps processes can not only exponentially accelerate business growth but also improve employee satisfaction and productivity. The first step toward achieving these benefits is understanding exactly where an organization’s current automation maturity level stands. This knowledge empowers teams to embrace an informed and systematic approach to further mature their organization’s automation maturity.

The post The State of DevOps Automation assessment: How automated are you? appeared first on Dynatrace news.

DevOps and platform engineering are essential disciplines that provide immense value in the realm of cloud-native technology and software delivery. However, these practices cannot stand alone. Rather, they must be bolstered by additional technological investments to ensure reliability, security, and efficiency. One of these key investments includes observability.

Observability of applications and infrastructure serves as a critical foundation for DevOps and platform engineering, offering a comprehensive view into system performance and behavior. It goes beyond traditional monitoring—metrics, logs, and traces—to encompass topology mapping, code-level details, and user experience metrics that provide real-time insights. This real-time awareness enables teams to rapidly detect and resolve issues: both indispensable capabilities for maintaining the agility and reliability that are central to DevOps and platform engineering processes.

Moreover, observability is the launchpad for maturing DevOps and platform engineering postures. Recent research found that 71% of organizations actively use observability data and insights to drive automation decisions and improvements in DevOps workflows. The technology has also enabled 78% of organizations to automate release validation and 74% of organizations to identify bottlenecks and automate delivery pipelines.

Observability and DevSecOps: Shifting left

Observability empowers teams to embrace a shift-left approach. The deep visibility and insights that observability provides allow teams to take proactive measures early in the software development life cycle (SDLC).

Shifting left is an approach that includes software quality, performance, and security testing as a part of the SDLC. These practices ensure optimal software functioning and the quick resolution of issues before they proliferate. This practice has become integral to DevSecOps, which fosters a culture of shared responsibility where all stakeholders play a role in maintaining the integrity of the software and infrastructure.

Without observability, a DevSecOps approach becomes increasingly difficult to execute. A lack of insights and visibility into a digital environment leads to inefficient management and resolution of vulnerabilities, attacks, and threats. Conversely, with observability providing a clear explanation of the root cause or origin of security issues, teams can immediately begin addressing issues. Ultimately, observability-powered insights preserve resources and enable DevSecOps at scale.

Observability and platform engineering: Unlock DevOps efficiency

Platform engineering teams also benefit immensely from observability. Beyond simply monitoring infrastructure health and diagnosing issues, observability can assist platform engineers by providing key insights for capacity management, performance optimization, compliance, and other critical aspects of platform maintenance and provisioning.

For example, an observability solution can track and analyze usage data to help engineers understand how and when to scale resources based on system demand. Incorporating observability into software delivery practices enables platform engineering and DevSecOps teams alike to execute high-importance tasks and responsibilities with confidence.

However, observability remains only one piece of the puzzle when it comes to ensuring the success of both DevSecOps and platform engineering.

The role of AI in DevSecOps

When integrated into DevSecOps, artificial intelligence (AI) helps teams transform data into an actionable asset for automating workflows across development, security, and operations. Combining causal AI with machine learning-based algorithms analyzes vast datasets in real-time and provides practitioners with precise answers driven by root cause analysis.

This capability is monumental for DevSecOps teams. AI helps provide in-depth context around system issues, anomalies, and other events instead of merely identifying them. Without this level of context, datasets become exponentially difficult to analyze and use for any effective or efficient DevSecOps processes. Causal AI also bolsters DevSecOps by allowing for early anomaly and vulnerability detection, rapid issue resolution, and system performance optimization.

Informed by past performances, predictive AI paired with observability forecasts future system needs and offers predictive insights. This fosters a proactive approach to system health and maintenance. These capabilities enable technical teams to minimize disruptions, cyberattacks, and downtime by identifying potential issues before they escalate.

AI strengthens the “Sec” in DevSecOps by not only offering continuous real-time insights into system vulnerabilities but also providing intelligence and answers regarding future potential vulnerabilities.

The role of AI in platform engineering

For platform engineers, AI creates an environment where its capabilities converge harmoniously with observability and security.

AI-driven insights optimize resource allocation, bolster internal developer platform scalability, and introduce autonomous operations for platform engineers. Autonomous operations can adapt to changing circumstances within an environment and automatically self-adjust and execute necessary workflows. For example, AI enables intelligent resource allocation for the optimal scaling of platform infrastructure without the need for any human intervention.

Automated rollbacks or rollouts based on observability data also become a reality with AI.  These automated actions enhance system reliability and overall platform resilience. The introduction of AI in platform engineering marks a new horizon for the discipline, enhancing its efficiency, efficacy, and security like never before.

Observability, security, and AI: Better together

Together, the synergy of observability, security, and AI redefines DevOps and platform engineering. These three capabilities are a recipe for accelerating software delivery and fortifying tech stacks and applications against emerging security challenges. This combination is essential for organizations that are navigating the complex terrain of modern software development and infrastructure management.

Observability, security, and AI play a crucial role in strengthening DevSecOps and platform engineering. Each component offers myriad benefits, including accelerating software delivery, enhancing software resilience, reducing manual tasks, improving developer productivity and satisfaction, and more.

Dynatrace offers a unified solution containing each of these key ingredients for DevSecOps and platform engineering success. With end-to-end observability powered by hypermodal AI and built-in security analytics and security protection, the Dynatrace platform empowers organizations with the capabilities they need to unlock agility, efficiency, and scale.

The post How observability, application security, and AI enhance DevOps and platform engineering maturity appeared first on Dynatrace news.

Lest readers believe that business digital transformation has fallen out of fashion, recent data suggests that digital transformation initiatives are still high on the agenda for today’s leaders.

According to a recent Thomson Reuters survey, nearly 50% of C-level executives said that business digital transformation was their top priority over the next 18 months, followed by reducing costs (44%) and increasing customer satisfaction (44%). Business digital transformation and modernization are enduring objectives, despite the rise of generative AI as a priority over the past year.

That’s why, according to a LinkedIn article, business digital transformation is no longer a nice-to-have.

In fact, business digital transformation may now be mandatory for organizations to survive and thrive in increasingly volatile and competitive macro-economic environments:

“If you consider the pre-covid [sic] era, digital transformation was a bonus,” the article argues. “Now, however, with the way the pandemic has caused a major disruption in businesses on a global level, digital transformation has become a thing of necessity.”

Not surprisingly, business digital transformation is also a growing market.

According to Markets and Markets, for example, the digital transformation market is projected to grow at a compound annual growth rate of 19.1%, from $521.5 billion in 2021 to $127.5 billion in 2026.

Digitally transformed organizations are expected to contribute to more than half of the GDP by 2023, accounting for $53.3 trillion. And according to Statista, $2.4 trillion will be spent on digital transformation in 2024.

Which technology trends are fueling business digital transformation? AI and DevOps, of course

The C suite is also betting on certain technology trends to drive the next chapter of digital transformation: artificial intelligence and DevOps.

Generative AI benefits from a composite AI approach

According to the Thomson Reuters survey, nearly 40% of respondents say they are using generative AI* to fuel business digital transformation.

While generative AI has received much of the attention since 2022 for enabling innovation and efficiency, various forms of AI—generative, causal**, and predictive AI***—will work together to automate processes, introduce innovation, and other activities in service of digital transformation.

According to IDC, AI technology will be inserted into the processes and products of at least 90% of new enterprise apps by 2025. And according to S&P Global’s 2023 Global Trends, 69% of surveyed organizations have at least one AI project in production, while 28% are achieving enterprise scale.

DevOps maturity follows business digital transformation

DevOps methodology—which brings development and ITOps teams together—also forwards digital transformation.

By bringing developers and IT operations teams together, teams can collaborate to accelerate software development times, increase workflow efficiency, automate manual tasks, and create higher-quality software. DevOps can also reduce human error throughout the software deployment process.

For one Dynatrace customer, a hardware and software provider, introducing automation into DevOps processes was a game-changer.

In the past, administrative tasks bogged down the developers at this Dynatrace customer, so they spent only 20% of their time writing software to meet their digital transformation goals. Today, with a greater focus on DevOps and developer observability, engineers spend 70%-75% of their time writing code and increasing product innovation. It has effectively flipped its time spent on manual and administrative tasks vs. its strategic software development efforts.

Another Dynatrace customer, a federal agency, used DevOps automation to reduce mean time to repair (MTTR) so teams could resolve issues before they affected users or compromised systems.

Business digital transformation at the intersection of AI and DevOps

In 2024, the C suite clearly has its eye on AI and DevOps as core enabling technology trends for business digital transformation. Ultimately, these tech trends can elevate organizations’ competitive advantage and accelerate modernization.

Today, they are paving the way for greater automation, more strategic and high-quality product development, and less error-prone activity. And of course, these goals overlap with the objectives of digital transformation, including product innovation, cost optimization, and risk mitigation.

Ultimately, buisness digital transformation, AI, and DevOps are interwoven. Each trend is enabling the others, and forward-leaning organizations are steering their modernization efforts in accordance with this notion.

For more on DevOps automation, check out our “DevOps automation is becoming a strategic imperative.”

And for more on digital transformation, check out “Master your digital transformation.”

________________________

*Generative AI—artificial intelligence that generates content, such as text, programming code, images, audio, videos, and more.

**Causal AI is an AI technique that identifies the precise cause and effect of events or behavior.

***Predictive AI uses machine learning, data analysis, statistical models, and AI methods to predict anomalies, identify patterns, and create forecasts about future events.

The post Why business digital transformation is still a key C-level priority today appeared first on Dynatrace news.

If cloud-native technologies and containers are on your radar, you’ve likely encountered Docker and Kubernetes and might be wondering how they relate to each other. Is it Kubernetes vs Docker or Kubernetes and Docker—or both?

What is the difference between Kubernetes and Docker?

Docker is a suite of software development tools for creating, sharing and running individual containers; Kubernetes is a system for operating containerized applications at scale.

Think of containers as standardized packaging for microservices with all the needed application code and dependencies inside. Creating these containers is the domain of Docker. A container can run anywhere, on a laptop, in the cloud, on local servers, and even on edge devices.

A modern application consists of many containers. Operating them in production is the job of Kubernetes. Since containers are easy to replicate, applications can auto-scale: expand or contract processing capacities to match user demands.

Docker and Kubernetes are mostly complementary technologies—Kubernetes and Docker. However, Docker also provides a system for operating containerized applications at scale, called Docker Swarm—Kubernetes vs Docker Swarm. Let’s unpack the ways Kubernetes and Docker complement each other and how they compete.

What is Docker?

Just as people use Xerox as shorthand for paper copies and say “Google” instead of internet search, Docker has become synonymous with containers. Docker is more than containers, though.

Docker is a suite of tools for developers to build, share, run and orchestrate containerized apps.

How does Docker work?

In Docker’s client-server architecture, the client talks to the daemon, which is responsible for building, running, and distributing Docker containers. While the Docker client and daemon can run on the same system, users can also connect a Docker client to a remote Docker daemon.

Developer tools for building container images

Docker Build creates a container image, the blueprint for a container, including everything needed to run an application – the application code, binaries, scripts, dependencies, configuration, environment variables, and so on. Docker Compose is a tool for defining and running multi-container applications. These tools integrate tightly with code repositories (such as GitHub) and continuous integration and continuous delivery (CI/CD) pipeline tools (such as Jenkins).

Sharing images

Docker Hub is a registry service provided by Docker for finding and sharing container images with your team or the public. Docker Hub is similar in functionality to GitHub.

Running containers

Docker Engine is a container runtime that runs in almost any environment: Mac and Windows PCs, Linux, and Windows servers, the cloud, and on edge devices. Docker Engine is built on top containerd, the leading open source container runtime, a project of the Cloud Native Computing Foundation (CNCF).

Built-in container orchestration

Docker Swarm manages a cluster of Docker Engines (typically on different nodes) called a swarm. Here the overlap with Kubernetes begins.

What is Kubernetes?

Kubernetes is an open source container orchestration platform for managing, automating, and scaling containerized applications. Kubernetes is the de facto standard for container orchestration because of its greater flexibility and capacity to scale, although Docker Swarm is also an orchestration tool.

How does Kubernetes work?

A Kubernetes cluster is made up of nodes that run on containerized applications. Every cluster has at least one worker node. The worker node hosts the pods, while the control plane manages the worker nodes and pods in the cluster.

What is Kubernetes used for?

Organizations use Kubernetes to automate the deployment and management of containerized applications. Rather than individually managing each container in a cluster, a DevOps team can instead tell Kubernetes how to allocate the necessary resources in advance.

Where Kubernetes and the Docker suite intersect is at container orchestration. So when people talk about Kubernetes vs. Docker, what they really mean is Kubernetes vs. Docker Swarm.

Benefits of using Kubernetes and Docker

When used together, Kubernetes and Docker containers can provide several benefits for organizations that want to deploy and manage containerized applications at scale.

Some of the key benefits of using include:

• Scalability: Kubernetes can scale containerized applications up or down as needed, ensuring they always have the resources they need to perform optimally. This is helpful for applications that experience a boost in traffic or demand.
• High availability: Kubernetes can ensure that containerized applications are highly available by automatically restarting containers that fail or are terminated. This can keep applications running smoothly and prevent downtime.
• Portability: Docker containers are portable, meaning they can be easily moved from one environment to another. This makes it easy to deploy containerized applications across different infrastructures, such as on-premises servers, public cloud providers, or hybrid environments.
• Security: Kubernetes can secure containerized applications by providing role-based access control, network isolation, and container image scanning. This can help to protect applications from unauthorized access, malicious attacks, and data breaches.
• Ease of use: Kubernetes can automate the deployment, scaling, and management of containerized applications. This can save organizations time and resources, and it can also help to reduce the risk of human error.
• Reduce costs: By automating the deployment and management of containerized applications, Kubernetes and Docker can help organizations reduce IT operations costs.
• Improve agility: Kubernetes and Docker can help organizations to be more agile by making it easier to deploy new features and updates to applications.
• Increase innovation: Kubernetes and Docker can help organizations to innovate more quickly by providing a platform that is easy to use and scalable.

Use cases for Kubernetes and Docker

When used in tandem, Kubernetes and Docker create a dynamic duo that unlocks a myriad of possibilities for seamless and scalable application deployment.

Here are a few use cases for using Kubernetes and Docker together:

• Deploying and managing microservices applications: Microservices applications are made up of small, independent components that can be easily scaled and deployed. Each microservice can be containerized using Docker, and Kubernetes can manage the deployment and scaling of these services independently. This allows for better maintainability, scalability, and fault isolation.
• Dynamic scaling: Together, Kubernetes and Docker enable dynamic scaling of applications. Kubernetes can automatically adjust the number of application instances based on demand. When traffic spikes, new containers can be spun up to handle the load, and when the load decreases, excess containers can be scaled down. This elasticity ensures efficient resource utilization and cost savings.
• Running containerized applications on edge devices: Kubernetes can be used to run containerized applications on edge devices, ensuring that they’re always available and up to date. Docker has redefined how applications are packaged and isolated. Docker eliminates the “it works on my machine” dilemma by encapsulating an application and its dependencies within a standardized container. This consistency ensures the application runs the same way across development, testing, and production environments.
• Continuous integration and continuous delivery (CI/CD): The combination of Docker and Kubernetes streamlines CI/CD pipelines. Docker images can be integrated into the CI/CD process, ensuring consistent testing and deployment. Kubernetes automates the deployment process, reducing manual intervention and accelerating the time to market for new features.
• Cloud-native applications: Docker and Kubernetes are cloud-agnostic, making it easier to deploy applications across different cloud providers or hybrid environments. This flexibility allows organizations to choose the most suitable infrastructure while avoiding vendor lock-in.

What are the challenges of container orchestration?

Although Docker Swarm and Kubernetes both approach container orchestration a little differently, they face the same challenges. A modern application can consist of dozens to hundreds of containerized microservices that need to work together smoothly. They run on multiple host machines, called nodes. Connected nodes are known as a cluster.
Hold this thought for a minute and visualize all these containers and nodes in your mind. It becomes immediately clear there must be a number of mechanisms in place to coordinate such a distributed system. These mechanisms are often compared to a conductor directing an orchestra to perform elaborate symphonies and juicy operas for our enjoyment. Trust me, orchestrating containers is more like herding cats than working with disciplined musicians (some claim it’s like herding Schrödinger’s cats). Here are some of the tasks orchestration platforms are challenged to perform.

Container deployment

In the simplest terms, this means to retrieve a container image from the repository and deploy it on a node. However, an orchestration platform does much more than this: it enables automatic re-creation of failed containers, rolling deployments to avoid downtime for the end-users, as well as managing the entire container lifecycle.

Scaling

This is one of the most important tasks an orchestration platform performs. The “scheduler” determines the placement of new containers so compute resources are used most efficiently. Containers can be replicated or deleted on the fly to meet varying end-user traffic.

Networking

The containerized services need to find and talk to each other in a secure manner, which isn’t a trivial task given the dynamic nature of containers. In addition, some services, like the front-end, need to be exposed to end-users, and a load balancer is required to distribute traffic across multiple nodes.

Observability

An orchestration platform needs to expose data about its internal states and activities in the form of logs, events, metrics, or transaction traces. This is essential for operators to understand the health and behavior of the container infrastructure as well as the applications running in it.

Security

Security is a growing area of concern for managing containers. An orchestration platform has various mechanisms built in to prevent vulnerabilities such as secure container deployment pipelines, encrypted network traffic, secret stores and more. However, these mechanisms alone are not sufficient, but require a comprehensive DevSecOps approach.

With these challenges in mind, let’s take a closer look at the differences between Kubernetes and Docker Swarm.

Kubernetes vs Docker Swarm

Both Docker Swarm and Kubernetes are production-grade container orchestration platforms, although they have different strengths.
Docker Swarm, also referred to as Docker in swarm mode, is the easiest orchestrator to deploy and manage. It can be a good choice for an organization just getting started with using containers in production. Swarm solidly covers 80% of all use cases with 20% of Kubernetes’ complexity.

A swarm is made up of one or more nodes, which are physical or virtual machines running in Docker Engine.

Swarm seamlessly integrates with the rest of the Docker tool suite, such as Docker Compose and Docker CLI, providing a familiar user experience with a flat learning curve. As you would expect from a Docker tool, Swarm runs anywhere Docker does and it’s considered secure by default and easier to troubleshoot than Kubernetes.

Kubernetes, or K8s for short, is the orchestration platform of choice for 88% of organizations. Initially developed by Google, it’s now available in many distributions and widely supported by all public cloud vendors. Amazon Elastic Kubernetes Service, Microsoft Azure Kubernetes Service, and Google Kubernetes Platform each offer their own managed Kubernetes service. Other popular distributions include Red Hat OpenShift, Rancher/SUSE, VMWare Tanzu, IBM Cloud Kubernetes Services. Such broad support avoids vendor lock-in and allows DevOps teams to focus on their own product rather than struggling with infrastructure idiosyncrasies.

The true power of Kubernetes comes with its almost limitless scalability, configurability, and rich technology ecosystem including many open-source frameworks for monitoring, management, and security.

Docker and Kubernetes: Better together

Simply put, the Docker suite and Kubernetes are technologies with different scopes. You can use Docker without Kubernetes and vice versa, however they work well together.

From the perspective of a software development cycle, Docker’s home turf is development. This includes configuring, building, and distributing containers using CI/CD pipelines and DockerHub as an image registry. On the other hand, Kubernetes shines in operations, allowing you to use your existing Docker containers while tackling the complexities of deployment, networking, scaling, and monitoring.

Although Docker Swarm is an alternative in this domain, Kubernetes is the best choice when it comes to orchestrating large distributed applications with hundreds of connected microservices including databases, secrets, and external dependencies.

How does advanced observability benefit Kubernetes and Docker Swarm?

Whether you’re using Kubernetes or Docker Swarm, or both, managing clusters at scale comes with unique challenges, particularly when it comes to observability. Application teams and Kubernetes/Swarm platform operators alike depend on detailed monitoring data. Here are some examples.

Kubernetes provides some very basic monitoring capabilities, like event logs and CPU loads for example. However, there’s a growing number of open-standard and open-source technologies available to augment Kubernetes’ built-in features. Some frequently used observability tools include: Promtail, Fluentbit and Fluentd for logs; Prometheus for metrics; and OpenTelemetry for traces, to name a few.

Dynatrace integrates with all these tools and more, and adds its own high-fidelity data to create a single real-time entity model. This unique capability enables Dynatrace to provide advanced analytics, AI-powered root-cause-analysis and intelligent automation, providing application teams and platform operators a unified view on the full technology stack.

The post Kubernetes vs Docker: What’s the difference? appeared first on Dynatrace news.

In the previous blog post of this series, we discussed the crucial role of Dynatrace as an orchestrator that steps in to stop the testing phase in case of any errors. Additionally, Dynatrace equips SREs and application teams with valuable insights powered by Davis^® AI. In this blog post of the series, we will explore the use of Site Reliability Guardian (SRG) in more detail.

SRG is a potent tool that automates the analysis of release impacts, ensuring validation of service availability, performance, and capacity objectives throughout the application ecosystem by examining the effect of advanced test suites executed earlier in the testing phase.

Validation stage overview

The validation stage is a crucial step in the CI/CD (Continuous Integration/Continuous Deployment) process. It involves carefully examining the test results from the previous testing phase. The main goal of this stage is to identify and address any issues or problems that were detected. Doing so reduces the risk of production disruptions and instills confidence in both SREs (Site Reliability Engineers) and end-users. Depending on the outcome of the examination, the build is either approved for deployment to the production environment or rejected.

Challenges of the validation stage

In the Validation phase, SREs face specific challenges that significantly slow down the CI/CD pipeline. Foremost among these is the complexity associated with data gathering and analysis. The burgeoning reliance on cloud technology stacks amplifies this challenge, creating hurdles due to budgetary constraints, time limitations, and the potential risk of human errors. Additionally, another pivotal challenge arises from the time spent on issue identification. Both SREs and application teams invest substantial time and effort in locating and rectifying software glitches within their local environments. These prolonged processes not only strain resources but also introduce delays within the CI/CD pipeline, hampering the timely release of new features to end-users.

Mitigate challenges with Dynatrace

With the support of Dynatrace Grail™, AutomationEngine, and the Site Reliability Guardian, SREs and application teams are assisted in making informed release decisions by utilizing telemetry observability and other insights. Additionally, the Visual Resolution Path within generated problem reports helps in reproducing issues in their environments. The Visual Resolution Path offers a chronological overview of events detected by Dynatrace across all components linked to the underlying issue. It incorporates the automatic discovery of newly generated compute resources and any static resources that are in play. This view seamlessly correlates crucial events across all affected components, eliminating the manual effort of sifting through various monitoring tools for infrastructure, process, or service metrics. As a result, businesses and SREs can redirect their manual diagnostic efforts toward fostering innovation.

1. Configure an action for the Site Reliability Guardian in the workflow. The action should focus on validating the guardian’s adherence to the application ecosystem’s specific objectives (SLOs). Additionally, align the action’s validation window with the timeframe derived from the recently completed test events.
   
2. As the action begins, the Site Reliability Guardian (SRG) evaluates the set objective by analyzing the telemetry data produced during advanced test runs. At the same time, SRG uses DAVIS_EVENTS to identify any potential problems which could result in one of two outcomes.
   
   Outcome #1: Build promotion
   Once the newly developed code is in line with the objectives outlined in the Guardian—and assuming that Davis AI doesn’t generate any new events—the SRG  action activates the successful path in the workflow. This path includes a JavaScript action called promote_jenkins_build, which triggers an API call to approve the build being considered, leading to the promotion of the build deployment to production.
   
   Outcome #2: Build rejection
   If Davis AI generates any issue events related to the wider application ecosystem or if any of the objectives configured from the defined guardian are not met, the build rejection workflow is automatically initiated. This triggers the disapprove_jenkins_build  JavaScript action, which leads to the rejection of the build.
   
   Moreover, by utilizing helpful service analysis tools such as Response Time Hotspots and Outliers, SREs can easily identify the root cause of any issues and save considerable time that would otherwise be spent on debugging or taking necessary actions.  SREs can also make use of the Visual Resolution Path to recreate the issues on their setup or identify the events for different components that led to the issue. In both scenarios, a Slack message is sent to the SREs and the impacted app team, capturing the build promotion or rejection.The telemetry data’s automated analytics, powered by SRG and Davis AI, simplify the process of promoting builds. This approach effectively tackles the challenges that come with complex application ecosystems. Additionally, the integration of service tools and Visual Resolution Path helps to identify and fix issues more quickly, resulting in an improved mean time to repair (MTTR).

Validation in the platform engineering context

Dynatrace—essential within the realm of platform engineering—streamlines the validation process, providing critical insights into performance metrics and automating the identification of build failures. By leveraging SRG and Visual Resolution Path, along with Davis AI causal analysis, development teams can quickly pinpoint issues, and further rectify them ensuring a fail-smart approach. The integration of service analysis tools further enhances the validation phase by automating code-level inspections and facilitating timely resolutions. Through these orchestrated efforts, platform engineering promotes a collaborative environment, enabling more efficient validation cycles and fostering continuous enhancement in software quality and delivery.

In conclusion, the integration of Dynatrace observability provides several advantages for SREs and DevOps, enabling them to enhance the key DORA metrics:

• Deployment Frequency: Improved deployment rate through faster and more informed decision-making. SREs gain visibility into each stage, allowing them to build faster and promptly address issues using the Dynatrace feature set.
• Change Lead Time: Enhanced efficiency across stages with Dynatrace observability and security tools, leading to quicker postmortems and fewer interruption calls for SREs.
• Change Failure Rate: Reduction in incidents and rollbacks achieved by utilizing “Configuration Change” events or deployment and annotation events in Dynatrace. This enables SREs to allocate their time more effectively to proactively address actual issues instead of debugging underlying problems.
• Time to restore service: While these proactive approaches can help improve Deployment Frequency and Change Lead Time, telemetry observability data with Dynatrace AI causation engine Davis AI can aid in improving Time to restore service.

In addition, Dynatrace can leverage the events and telemetry data that it receives during the Continuous Integration/Continuous Deployment (CI/CD) pipeline to construct dashboards. By using JavaScript and DQL, these dashboards can help generate reports on the current DORA metrics. This method can be expanded to gain a better understanding of the SRG executions, enabling us to pinpoint the responsible guardians and the SLOs managed by various teams and identify any instances of failure. Addressing such failures can lead to improvements and further enhance the DORA metrics. Below is a sample dashboard that provides insights into DORA and SRG execution.

In the next blog post, we’ll discuss the integration of security modules into the DevOps process with the aim of achieving DevSecOps. Additionally, we’ ll explore the incorporation of Chaos Engineering during the testing stage to enhance the overall reliability of the DevSecOps cycle. We’ll ensure that these efforts don’t affect the Time to Restore Service turnaround build time and examine how we can improve the fifth key DORA metric, Reliability.

What’s next?

Curious to see how it all works? Contact us to schedule a demo and we’ll walk you through the various workflows, JavaScript tasks, and the dashboards discussed in this blog series.

If you’re an existing Dynatrace Managed customer looking to upgrade to Dynatrace SaaS, see How to start your journey to Dynatrace SaaS.

The post Automate CI/CD pipelines with Dynatrace: Part 4, Validation stage appeared first on Dynatrace news.

In today’s fast-paced IT environments, speed matters. Organizations must ensure their digital infrastructure functions optimally and that they deliver software deployments and updates rapidly and consistently. But to meet demands and stay ahead of competitors, teams are under pressure to accelerate releases as much as possible. Verifying releases using systematic quality gates is a crucial practice to speed up the pace of deployments without sacrificing quality.

What are quality gates?

Quality gates are checkpoints that require deliverables to meet specific, measurable success criteria before progressing to the next development stage. They help foster confidence and consistency throughout the entire software development lifecycle (SDLC).

Organizations can customize quality gate criteria to validate technical service-level objectives (SLOs) and business goals, ensuring early detection and resolution of code deficiencies. Automating quality gates is ideal, as it minimizes manually checking and validating key metrics throughout the SDLC. Ultimately, quality gates safeguard code viability as it advances through the delivery pipeline.

Benefits of quality gates

Quality gates provide several advantages to organizations, including the following:

• Optimized software performance: Quality gates assess code at different SDLC stages and ensure that only high-quality code progresses. This mechanism significantly boosts the likelihood of optimal functioning upon deployment. By actively monitoring metrics such as error rate, success rate, and CPU load, quality gates instill confidence in teams during software releases.
• Fewer expensive fixes. Introducing well-defined quality gates at regular checkpoints prevents the escalation of issues as software advances through the pipeline. Early identification and resolution of potential deficiencies conserves resources and mitigates the need for expensive fixes later in the SDLC.
• Continuous, informed improvement: Quality gates provide consistent feedback on key metrics. This steady input empowers teams to proactively address issues, which fosters continuous learning from the outset of the SDLC. This approach supports innovation, ambitious SLOs, DevOps scalability, and competitiveness.

Quality gates examples in Dynatrace

Quality gates hold much promise for organizations looking to release better software faster. But how do they function in practice? The following are specific examples that demonstrate quality gates in action:

Security gates

Security gates ensure code meets key security requirements defined by development and security stakeholders. In this example, we will focus on ensuring releases do not have any known vulnerabilities. In this context, before the gorouter service deploys, security gates defined in Dynatrace’s Site Reliability Guardian (SRG) validate whether the latest version of the software has introduced a vulnerability.

In this scenario, the gorouter service must meet specific key metrics relating to the following three security areas:

• New vulnerabilities: The newly detected high-profile vulnerabilities in the environment. For each of these areas, the software receives a score from one to 10. Depending on the score thresholds for each SLO, the software will either “fail” or “pass” the gate.
• Open vulnerability on process group: The total number of currently high-profile vulnerabilities related to a process group.
• Open vulnerabilities: The total number of currently open high-profile vulnerabilities in the environment.
• Vulnerability score: The highest vulnerability risk score for a process group.

To view a more in-depth breakdown of these key metrics and their thresholds, simply scroll down to the bottom:

For every new build, the SRG assigns a score for each of these SLO areas. Considering the above scores, this version of software would not pass through the security gates, and the deployment process for the gorouter service would be stalled. If even one of the key metrics receives a failing score —as it did on the open vulnerability on process group — the software cannot progress further. Adjustments must be made accordingly.

Quality gates after load/performance testing

Teams can use quality gates to evaluate performance metrics. Consider “Easytravel,” a customer-facing application used by a travel agency. Before a new version of the application is deployed, the software is subject to a series of load tests that evaluate capacity and performance under a series of simulated traffic and application demands.

Quality gates consider these metrics and determine if their values fulfill specific SLO requirements. The gates thus allow the application version to pass through if the software meets the criteria and halts the progression if not. Several tools can be used to collect metrics in load/performance testing. In this example, test results are gathered from K6, Gremlin, NeoLoad, and Dynatrace synthetics.

Per the figures above, SRG evaluates Easytravel metrics from all of these tools in one place. This way, the travel agency can easily streamline, organize, and consolidate their quality gates and metric evaluation process. The agency can also efficiently compare the newest version of Easytravel against previous versions of the software with regression testing facilitated by SRG.

The new version of the Easytravel app has passed the load/performance testing quality gates. Although there were a handful of “warnings” for the K6 metrics — this means that the metrics are close to the “failure” threshold — none of the metrics failed to meet the SLO entirely. As a result, this version of Easytravel passes through this set of quality gates and is one step closer to deployment.

Quality gates to validate the “four golden signals”

The “four golden signals” represent the most crucial metrics of a customer-facing system’s performance. These metrics are latency, traffic, errors, and saturation, all of which must be key considerations when curating user experience. Teams can use quality gates to track and evaluate such metrics. Let’s review how a quality gate can function for each of the four golden signals using the same Easytravel application. Below is a sample SRG dashboard for these signals:

• Latency
  • Latency refers to the amount of time that data takes to transfer from one point to another within a system. In the context of Easytravel, one can measure the speed at which a specific page of the application responds after a user clicks on it.
    • The passing threshold is anything below 50 ms.
      The warning threshold is 50-60 ms.
      The failure threshold is anything above 60ms.
  • In this scenario, the response time for the latest software version is 44 ms, thus, it passes through the latency quality gate.

Teams take a similar approach for the other three signals. In this example, unlike latency, the remaining three signals did not receive a “pass.” SLOs for saturation were not met, and thus, this specific build of Easytravel temporarily halts. In terms of errors and traffic, these SLOs did not receive a failing score but are close enough to the failure threshold to trigger a warning.

What’s next

Quality gates are only as effective as the tools that enable them. Dynatrace’s Site Reliability Guardian provides a platform for in-depth analysis and validation of service availability, performance, and capacity objectives throughout your entire digital environment. Equipped with these capabilities, Site Reliability Guardian can help you implement high-performing quality gates.

The post What are quality gates? How to use quality gates to deliver better software at speed and scale appeared first on Dynatrace news.

Closed-loop remediation is an IT operations process that detects issues or incidents, takes corrective actions, and verifies that the remediation action was successful. Ideally, this all occurs without human intervention.

“Closed loop” refers to the continuous feedback loop in which the system takes actions — based on monitoring and analysis — and verifies the results to ensure complete problem remediation. Closed-loop remediation is vital to effective and reliable incident management because it ensures that organizations can consistently monitor any issue until it’s fully resolved.

How closed-loop remediation works

Closed-loop remediation uses a multi-step process that goes beyond simple problem remediation. This process identifies issues, notifies teams, and verifies solution efficacy continuously until it can confirm that the original incident is remediated.

Closed-loop remediation comprises the following stages:

• Stage 1: Triage
  • Observability: First, an observability platform detects an issue by analyzing all the telemetry data from across multicloud environments and determining incident severity.
  • Ownership: Next, the platform must determine the teams or individuals responsible for managing the incident and assign ownership to them.
  • Ticket creation: Using the ticketing tool of choice, the platform creates a ticket outlining the problem details and the incident’s impact.
  • Targeted notification: Responsible parties are automatically notified that an incident has occurred.
• Stage 2: Remediate
  • Root cause analysis: The observability platform should be able to pinpoint the incident’s root cause.
  • Automated response: Root cause identification triggers remediation workflows automatically based on the type of incident. Or, to take it one step further, the platform integrates with a tool such as Ansible to trigger remediation runbooks.
  • Deployment: Once the platform has determined the most viable solution, it triggers deployment into the environment. The goal is to either improve or restore the system to its optimally functioning state.
• Stage 3: Validate
  • Observability: After solution deployment, the observability platform scans the environment to determine its efficacy in resolving the issue. If the problem is fully remediated, the platform validates the solution to be effective and resolves the ticket.
  • Closing the loop (or not): In the event of a successful solution, the platform informs the appropriate teams and closes the loop. If the solution is unsuccessful, the platform notifies the relevant teams of the persisting issue. The cycle restarts and further escalation ensues until arrival at a successful solution.

Benefits of closed-loop remediation

Beyond significantly reducing mean time to detect and mean time to resolution (MTTR), closed-loop remediation offers significant benefits, including the following:

Improved incident backlogs. Incident backlogs collect data on and record all unresolved issues. Closed loop remediation compiles important holistic data into incident backlogs, enabling teams to prioritize, monitor, organize, and analyze issues at scale. These capabilities improve resource allocation and communication among teams, breaking silos.

Improved change failure and escalation rates. Change failure rate represents the proportion of system changes that have failed to meet their intended objectives. It is also a key metric for organizations looking to improve their DevOps performance. Through the automated verification within closed-loop remediation, teams can easily determine their own change failure rate. The verification process provides teams with information regarding which kinds of system modifications are most effective, improving change failure rate over the long run.

The same concept holds true for incident escalation rate. This metric represents the proportion of system incidents resolved by escalating to a higher level of support. By continuously monitoring and verifying closed-loop remediation, teams can expect to reduce both their change failure and incident escalation rates.

Greater developer productivity. Developers often spend excessive time finding and managing solutions to incidents that arise within production environments. This time could be better spent innovating; closed–loop remediation frees up developers’ time, resources, and energy. It also facilitates workflow optimization by automating responses to specific events that trigger predefined remediation actions. Since this automation largely removes manual intervention, developers have greater bandwidth for innovation.

Auto-remediation examples

The following examples illustrate how closed-loop remediation works and its benefits.

Example #1: Stabilizing streaming load times

Consider a movie streaming application that experiences performance degradation, resulting in slow load times. The observability platform detects the anomaly and determines the root cause of the problem: increased traffic during peak usage hours, resulting in a server overload. The platform automatically creates an incident ticket that details the severity and potential impact of the issue and sends the ticket to the relevant teams. The system automatically triggers a remediation workflow that provisions additional resources to meet increased capacity requirements. After the scaling action, the platform validates the action’s efficacy by analyzing performance metrics to ensure that load times are back to normal. If successful, the system closes the loop and notifies teams. If the issue persists, it notifies the responsible teams who may need to do additional triaging to address the incident. Either way, the system updates the ticket to reflect the status of the issue.

Example #2: Prioritizing and remediating application vulnerabilities

An organization has an application that accesses confidential customer information. The organization’s observability and security platform identifies several vulnerabilities that have the potential to allow bad actors to access and leak proprietary information. However, only some of these vulnerabilities are exploitable; others are of lesser importance. The organization’s observability and security platform triages the numerous vulnerabilities and determines which ones to prioritize based on runtime context, such as adjacency to the internet or data sources. The system automatically generates tickets for critical vulnerabilities with all relevant information and assigns them to the responsible team for remediation.

Once fixes have been implemented and deployed, the platform scans for vulnerabilities once more and determines whether the vulnerabilities are still present. If the relevant vulnerabilities have been eliminated, then the fixes are validated: the system closes the loop and updates the ticket. If the platform determines that the vulnerabilities have not been eliminated, it updates the tickets to initiate further investigation. The process repeats it implements until an effective solution.

Example #3: Kafka disk resizing

A banking company has a Kafka event streaming broker whose disk usage is nearing critical levels, threatening potential disruptions or service degradation. The observability platform detects this issue as disk usage meets a predefined threshold and determines the root cause to be low disk space. Upon detection, the platform triggers an automated alert. The system executes an automated remediation workflow that dynamically adjusts the disk size by adding space or redistributing partitions. On completing these actions, the observability platform confirms that the remediation effort was successful, closes the loop, and notifies teams. If not, the platform restarts the process so teams can explore other remediation options.

To complete the cycle, platforms must be strong enough to accurately verify that remediation actions are indeed fulfilling their intended purposes. It is best practice to trigger actions to notification tools that indicate the success or failure of the remediation action.

Implementing closed-loop remediation with unified observability

At the foundation of any closed-loop remediation practice is a unified approach to observability that can fully monitor end-to-end DevOps processes. Moreover, an observability platform that harnesses AI for root-cause analysis will greatly expedite the entire remediation process, as it can quickly and intelligently determine the source of an issue without human intervention. Likewise, the observability platform can then notify the right teams and trigger automated workflows to take the appropriate remediation action.

Closed-loop remediation reduces MTTR and helps ensure a smooth, reliable customer experience. Dynatrace helps organizations realize these benefits through its unified platform that drives and optimizes auto-remediation. AutomationEngine enables DevOps teams to automate custom remediation workflows facilitated by continuous, real-time insights and precise answers. To validate the efficacy of such workflows on DevOps SLOs, Site Reliability Guardian (SRG) provides automated change impact analysis for new software versions. As such, SRG plays a crucial role in “closing the loop” of remediation workflows. SRG offers specific validation results against custom-defined SLOs for software updates across various systems. The result: teams can make more informed release decisions.

Equipped with these tools, along with unified observability, AI-driven analysis, and automation technology, Dynatrace offers all the elements necessary to optimize your closed-loop remediation practice.

The post Why unified observability is an essential auto-remediation best practice appeared first on Dynatrace news.

In the last blog post of this series, we delved into how Dynatrace, functioning as a deploy-stage orchestrator, solves the challenges confronted by Site Reliability Engineers (SREs) during the early of automating CI/CD processes. Having laid the foundation during the deployment stage, we’ll now explore the benefits of Dynatrace visibility and orchestration during the testing phase.

The testing stage plays a crucial role in ensuring the quality of newly built code through the execution of automated test cases. Testing includes integration tests, which assess whether the code functions as intended when interacting with other services and application functionalities. It can also include performance testing to determine if the application can effectively handle the demands of the production environment.

Mitigate challenges during the testing stage

Like the build stage, the testing stage is time-sensitive and can consume a significant amount of time for execution, in turn creating a substantial waiting period for SREs to determine the success or failure of tests and the need for retesting. This slow feedback and time spent rerunning tests can hinder the overall software deployment process.

To mitigate these challenges, building upon the groundwork established during the deploy phase, Dynatrace can effectively pinpoint any issues encountered during testing. Moreover, by configuring alert notifications through native features such as ownership and alerting profiles, teams can receive prompt alerts in the event of failures. This proactive strategy significantly minimizes wait times and empowers SREs to redirect their focus toward innovative endeavors.

The steps outlined below show you how to achieve such a proactive solution.

1. Pass annotation events to Dynatrace, leveraging the Ingest events API, at the beginning and end of each test. These events provide additional context to the Davis^® AI causation engine in case of issues and function as logic operators for the execution of advanced testing, such as soak, integration, or chaos engineering.
2. Integrate performance test tools with Dynatrace by adding headers to HTTP requests. Further, harness request attributes and telemetry data gathered from requests to gain insights into the requests.
3. (Optional) Set web request naming rules using the earlier configured request attributes to facilitate easy identification of requests across different releases or test suites.
   
4. During the execution of tests, the telemetry data generated by the newly built code is transmitted to Grail through OneAgent.
   The data is examined and can fall into one of the below two categories:

   If there are errors in the telemetry data

   If there are errors in the telemetry data, the task immediately marks the stage as problematic and triggers the process to stop the ongoing job. The stop_the_build task utilizes the CI/CD API (in this case, Jenkins) to halt the build. This task also retrieves additional job metadata to include in the generated message.

   In tandem with stopping the job, another task in the workflow, send_load_test_failure, is triggered: a Slack message is dispatched to the team responsible for initiating the job. The immediate alerting mechanism ensures that SREs are promptly informed about test errors, thereby circumventing the high wait times.

   If there are no errors and the outcome is successful

   If there are no errors reported in the data, the pipeline job will proceed to conduct integration and reliability tests, which will be validated in the final validation stage by the Site Reliability Guardian (SRG). During this phase, SRG will validate the test coverage to assess the impact of the newly introduced code and determine its suitability for promotion to the production environment.

Optional best practices

Optionally, the following best practices are recommended to achieve the most effective outcomes.

• During the testing stage, generate on-demand synthetic monitors to monitor the performance of the application as experienced by your end users in different geolocations.
• Generate SLOs, leveraging the Dynatrace API, that will be validated in the next stage to determine if the build should be rejected or promoted to production.

Test stage orchestration in a platform engineering context

Dynatrace, integral to platform engineering, offers invaluable visibility into test results and accelerates the test cycle by swiftly identifying and resolving underlying issues. Utilizing service tools like response hotspots and distributed traces, along with Davis causal AI, dev teams can achieve fast turnarounds in the event of test failures. Dynatrace root cause analysis enhances collaboration, providing a comprehensive solution for optimizing testing phases so that they allow for a more agile and productive development cycle, fostering a culture of continuous improvement and accelerating overall software delivery.

Also, to optimize the workflow for both SREs and application teams, leverage Dynatrace dashboard capabilities to expand your data visibility. This allows for easy comparisons of telemetry data across different releases and enables the utilization of service tools for in-depth analysis, ultimately contributing to service optimization.

Conclusion

In conclusion, this blog post examined how Dynatrace capabilities and telemetry data can enhance the success of the testing stage. In the next blog post in this series, we delve deeper into how Dynatrace can further streamline the promotion of new code to production.

The post Automate CI/CD pipelines with Dynatrace: Part 3, Testing stage appeared first on Dynatrace news.

In the previous installment of this blog series, we explored how to set up Dynatrace as a build-stage orchestrator to effectively address the challenges faced by Site Reliability Engineers (SREs). In this blog post, we’ll transition to the next pipeline stage, the Deploy stage, and examine the visibility advantages that Dynatrace provides during this critical phase.

Deploy stage

In the deployment stage, the application code is typically deployed in an environment that mirrors the production environment. This step is crucial as this environment is used for the final validation and testing phase before the code is released into production. This stage ensures the code meets the required quality standards before it goes live.

Configuration drift

Configuration drift is a challenge in the deployment stage. Configuration drift occurs when a staging environment’s configuration deviates from the production environment. Such deviations often result from undocumented or un-versioned environmental changes, potentially causing unexpected behavior and production outages upon deployment.

Even when the staging environment closely mirrors the production environment, achieving a complete replication of all potential scenarios, such as simulating extremely high traffic volumes to assess software performance, remains challenging. This can lead to a lack of insight into how the code will behave when exposed to heavy traffic.

Creating a staging environment that faithfully replicates the production setup is crucial to effectively addressing such challenges. Furthermore, augmenting test coverage to mirror the scenarios encountered in production is imperative. These strategies can play a vital role in the early detection of issues, helping you identify potential performance bottlenecks and application issues during deployment for staging. With this approach, you gain increased confidence that a release will succeed when promoted to the production environment.

Leverage OneAgent functionality

Ingesting configuration changes into Dynatrace through the events API call and utilizing OneAgent^® to detect configuration changes for supported technologies help maintain close alignment between your staging and production environments. This approach effectively combats configuration drift. Furthermore, the Dynatrace Davis^® AI engine can accurately identify whether such changes have resulted in any issues and allows you to roll back configurations if necessary.

By harnessing OneAgent native features, the generated telemetry data can be effectively combined with Davis AI prediction and forecasting capabilities. This enables the prediction of trends that might not have been thoroughly tested due to variations in different environments. This proactive approach proves instrumental in anticipating and mitigating potential performance issues before they result in adverse impacts.

Combat configuration drift

Dynatrace actively tracks modifications to the standard configuration files of supported technologies. Whenever a change is detected, Dynatrace automatically generates a Deployment change event for the corresponding process and the host on which the process runs. The predefined set of files monitored for configuration alterations is maintained within ruxitagentproc.conf. In the event of any incidents stemming from these configuration adjustments, Davis AI utilizes the Deployment change data to pinpoint potential root causes.

As an illustration, in the screenshot below, when a modification was made to the nginx.conf file, Dynatrace promptly detected the configuration change and reported it as a Deployment change event. In this specific instance, the misconfiguration of nginx led to a critical issue where nginx crashed and could not restart, prompting an alert from Dynatrace. Davis AI efficiently identified the deployment change as the potential root cause for the malfunctioning of nginx.

By harnessing these deployment events, SREs can effectively track all configuration changes that have occurred over a specified time. This capability empowers them to replicate the staging environment to match the production setup, proactively combating configuration drift.

Although Dynatrace can detect configuration changes, the best practice is to systematically ingest a configuration change or deployment change event each time the team modifies a configuration file. This approach ensures proper record-keeping and assists in achieving consistency between the staging and production environments, effectively mitigating configuration drift.

Predictive traffic analysis

Deploying OneAgent within the staging environment facilitates the availability of telemetry data for analysis by Davis AI. Davis AI can leverage this data to enable predictive analysis. This enables a scenario where—even if test cases can’t replicate identical traffic to production due to various limitations—predictive analysis can offer insights into the capacity of the new build to withstand production-level loads.

To illustrate this concept, consider the scenario below. During testing with limited generated traffic, Davis AI predictive analysis offered valuable insights into how Elastic Book Storage (EBS) might perform and how the rate of Input/Output Operations Per Second (IOPs) might change under heavier traffic load.

Other proven strategies

We recommend following best practices to achieve the most effective observability outcomes.

• At the onset of the deployment stage, send a deployment event to Dynatrace notifying it about the new deployment. These deployment events are important as they provide additional context to the Davis AI causation engine, aiding in evaluating deployment quality.
• To further aid with postmortem analysis, use the DT_TAGS metatag to clearly distinguish between different build and service requests.
• Additionally, consider using the DT_CUSTOM_PROP environment variable to include extra metadata about the build, providing valuable information for monitoring and analysis.

The framework outlined above provides a comprehensive view of the deployment process and facilitates comparisons across different releases. For instance, in the animation below, we utilized deployment events and DT_TAGS to assess the quality of releases and capture golden signals across various builds. This approach can be a valuable resource for developers in understanding underlying issues and identifying opportunities for enhancements.

Deploy stage orchestration in a platform engineering context

Deployment events automatically identified by OneAgent or manually triggered by app owners play a pivotal role in ensuring consistency across all environments. When issues are detected, causal AI determines if the problem is linked to deployment changes. This contributes significantly to increased productivity for development teams, as they spend less time troubleshooting and identifying discrepancies across environments. Additionally, the integration of predictive analysis, fueled by Davis AI, instills confidence in developers that their application’s behavior will withstand the anticipated load, including potentially high traffic.

Dynatrace as a deploy-stage orchestrator

You’ll find all the Jenkins pipeline and other scripts you need to set up Dynatrace as a deploy-stage orchestrator, including the referenced dashboard, in thisGit repository.

What’s next?

This blog post delved into how Dynatrace capabilities and telemetry data from a staging environment can effectively align staging with the production setup. In the next blog post in this series, we’ll further explore how Dynatrace can aid in streamlining the testing phase within an SRE pipeline.

The post Automate CI/CD pipelines with Dynatrace: Part 2, Deploy stage appeared first on Dynatrace news.

In the first blog post of this series, we explored how the Dynatrace^® observability and security platform boosts the reliability of Site Reliability Engineers (SRE) CI/CD pipelines and enhances their ability to focus on innovation. This blog post guides you through configuring Dynatrace to automate CI/CD processes to achieve these objectives.

Dynatrace observability architecture can be classified into three layers:

1. Orchestration (Dynatrace)
2. CI/CD toolset (Jenkins / Chef / Puppet / Bamboo, etc.)
3. Infrastructure layer (Kubernetes Cluster, GCP, Standalone server, etc.)

A conventional pipeline has the following stages:

1. Build
2. Deploy
3. Test
4. Validation

Now, let’s explore the challenges that arise in the different stages of the pipeline and examine how the role of Dynatrace as the orchestrator can contribute to overcoming these challenges. In this blog post, we’ll focus on the first stage of the pipeline, the Build stage.

Build stage

The build stage involves pulling the latest code, compiling it, and ensuring its proper functionality by running feature tests.

Mitigate challenges

While the application is building, you might see compilation problems that necessitate debugging, and there might be considerable delay before the root causes of such issues are identified. The build process must be restarted once a solution is identified and deployed. A high rate of build failures indicates that the team is investing significant time into diagnosing and rectifying issues. This waiting and problem-solving can hinder your overall software development process.

Enhancing visibility during the build stage can help identify compilation and integration errors earlier in the development cycle. This proactive approach reduces wait times and allows SREs to redirect their efforts toward innovation.

Leverage Dynatrace features

The instrumentation flow currently operates as follows:

1. After code commits, a GitHub action is employed to trigger the workflow, utilizing the workflow API. Within this workflow, a designated task, powered by JavaScript, initiates the build stage of the pipeline job, commencing a new build. The below screenshot shows the code initiating the Jenkins job.
   
2. During the job pipeline execution, logs are extracted and pushed to Grail. Log reading can be facilitated by installing OneAgent or employing a log ingestion system to ingest the logs into Dynatrace. Subsequently, a workflow DQL task named look_for_build_errors will scrutinize the build stage for errors.
3. Based on the outcome of the log analysis, one of two paths is pursued:
   1. If build errors are detected
      Should the job logs reveal errors, the task promptly flags the build as erroneous and initiates the process to halt the ongoing job. The task stop_the_jenkins_job leverages the CI/CD API (in this case, Jenkins) to stop the build, as indicated in the output from step 2. This task also extracts additional job metadata to incorporate in the generated alert.
      
      In tandem with stopping the job, another task in the workflow, send_alert_to_team, activates, sending a Slack message to the team responsible for initiating the job. The immediate alerting mechanism ensures that SREs are promptly informed about build errors, thereby circumventing high wait times.
      
   2. If no errors are detected
      If no errors are identified, the workflow seamlessly advances the job to the Deploy stage. As a good practice, we recommend that you incorporate a workflow with a JavaScript task that periodically retrieves job details and ingests them as business events to enhance visibility into the pipeline stages and provide insights into current trends.
      Above is a sample JavaScript workflow that extracts data from the Jenkins pipeline via API calls and the dashboard capturing current trends.The Jenkins Build Stage Insights dashboard provides visualizations of the build stages represented as business events.

Build stage orchestration in a platform engineering context

In the realm of platform engineering, the focus is on relieving the cognitive burden on development teams and boosting their efficiency by offering predefined pathways, essentially treating the development platform as a product. 

With build-log monitoring and the initiation of diverse workflows within Dynatrace based on log outcomes, automation is now a reality for many development teams. Furthermore, the insights gained from the build stage provide SREs and app teams with valuable information for optimizing existing pipelines and areas for improvement. 

What’s next

Now, it should be clear how Dynatrace orchestration can be introduced early in the pipeline process and how it can significantly decrease wait times during the build stage by notifying the teams of any errors during the application build process.

In the next blog post in this series, we’ll delve into how this orchestration further aids SRE teams in addressing the challenges encountered during the Deploy stage.

All the resources you need to set up Dynatrace as a build-stage orchestrator

In the meantime, you’ll find all the resources you need to set up Dynatrace as a build-stage orchestrator (workflows, JavaScript tasks, and the referenced dashboard) in this Git repository.

The post Automate CI/CD pipelines with Dynatrace: Part 1, Build stage appeared first on Dynatrace news.

Golden Paths for rapid product development

Modern software development aims to streamline development and delivery processes to ensure fast releases to the market without violating quality and security standards. DevOps practices have been established in the last decade to accomplish this goal and deal with the dynamics of modern, cloud-native software architectures. To bring these practices to life within an organization at scale, the discipline of platform engineering has gained popularity. From a high-level point of view, platform engineering aims to:

• Reduce the cognitive load on development teams.
• Improve reliability and resiliency of products that rely on platform capabilities.
• Accelerate product development and delivery by reusing and sharing platform tools and knowledge.
• Reduce risk of security, regulatory, and functional issues in products and services.
• Enable cost-effective and productive use of services.

While it takes multiple capabilities to achieve these goals, implementing “Golden Path” templates is a fundamental ingredient. The Cloud Native Computing Foundation defines a Golden Path as a “templated composition of well-integrated code and capabilities for rapid project development.” Simply put, a Golden Path is a self-service template for common tasks that allows for autonomy while providing guardrails that safeguard production environments.

Imagine that instead of development teams fending for themselves amidst a sea of tools and infrastructure, well-defined and enterprise-wide templates are provided for the development of all new product services. Such a template should contain a get-started tutorial, sample source-code framework, policy guardrails, CI/CD pipeline, infrastructure-as-code templates, and reference documentation. This approach helps you quickly integrate best practices within your organization and provides cloneable artifacts for rapid product development.

No developer is left in the dark to fend for themselves, Golden Paths light the way.

Ensure governance across your organization

While Golden Paths are key to bringing DevOps best practices to development teams, distributing them is challenging. This challenge is partially addressed by internal development platforms (IDP), which have been adopted by many, but not all, organizations.

Consequently, Dynatrace provides templates in the context they are needed—with or without the internal use of an IDP. This ensures governance across your organization with the proper templates in the right place. At the same time, this does not restrict you from managing them in your IDP, as explained below.

Leverage opinionated, self-service, and optional templates

The latest enhancements of the Site Reliability Guardian have introduced opinionated Golden Path templates. For now, they concentrate on Kubernetes, host, and security objectives but they will grow to cover even more reliability, performance, and security aspects. These templates enable development teams to instantiate a guardian for automating release validation in a self-service manner. Along the journey, monitored entities can be selected to provide the context to fetch the right data from Dynatrace Grail™.

After completing this two-step process, a ready-to-use guardian is created. It’s possible to add new objectives if needed or to tailor the objectives and their thresholds.

Allow for flexibility

Custom query variables are available to fine-tune guardian objectives and maintain flexibility in fetching data from Grail. An example of such a variable is the version number of a service. In many cases, you want to retrieve the logs, metrics, or traces of a particular version, which is unknown upfront. Consequently, the custom variable version can be defined in the DQL query, which retrieves its value before executing.

Custom query variables can be defined by starting with the $ sign followed by the variable name in the DQL query editor of a guardian objective. An overlay component then helps you add this variable and define the default value in the context of the guardian.

While a variable will fall back to its default if no value is provided, there are three ways of ingesting the value:

1. When triggering a guardian validation from within the UI by selecting the Validate button, set a value for the configured variables using the Set variables option.
2. The Site Reliability Guardian workflow action allows you to set a variable value. In this case, it is possible to consume data from the triggering event or a previous workflow action using Jinja expressions.
3. If a workflow is used to automate the validation process, the workflow trigger event can provide automatically mapped properties to variables. Therefore, the properties must be within the execution_context property, as shown below. Given this example, the version number 0.1.0 is set where the variable $version is defined.

Since variables provide important context for validation, you can view validation-result values over time. The following screenshots depict the version number associated with the last 10 validation results.

Integrate with existing internal developer platforms

If you have an internal developer platform that serves as a central product engineering hub, you need Golden Path templates incorporated there so that you can scale out the platform for use by different teams. With Dynatrace, this can be achieved by extracting an instantiated template using Dynatrace Configuration as Code or cloning it from our public repository. This declarative format of a template, consisting of a guardian and workflow configuration, as depicted by the sample below, can then be added to the template repository managed and distributed by an IDP.

What’s next?

Site Reliability Guardian is built to ensure and maintain reliability and resiliency of products by leveraging automated release validations. Therefore, Golden Path templates in a self-service manner are offered for platform engineers to enable development teams to get started easily. The next enhancements of the Site Reliability Guardian will bring Davis® AI even closer to the Site Reliability Guardian by recommending relevant objectives and baselines for comparison.

• The new functionality has already been released and is available for your use. If you’re using the Site Reliability Guardian already, update to the latest version. Otherwise, navigate to Dynatrace Hub and install it from there.
• If the Site Reliability Guardian is new to you and you’re curious about it, go to Dynatrace Discovery and explore its capabilities in a playground environment.

We’d love to hear your feedback about Site Reliability Guardian. Let us know your thoughts or share your ideas about further improvements.

The post Ensure safe and secure releases at scale by providing Golden Paths appeared first on Dynatrace news.

In the realm of SRE, time and effort allocation planning are crucial factors that involve a delicate balance between operational management and project improvements. This intricate allocation strategy can be categorized into two main domains. In this blog post, we’ll delve deeper into these categories to gain a comprehensive understanding of their significance and the challenges they present.

Planned effort

Site Reliability Engineering (SRE) effort and time allocation planning typically fall into two domains:

• Operations Management (50%)
  Operations Management includes on-call responsibilities, post-mortem assessments, addressing other interruptions, and buffer time. These tasks collectively ensure uninterrupted production service.
• Process Improvements (50%)
  The allocation for process improvements is devoted to automation and continuous improvement SREs help to ensure that systems are scalable, reliable, and efficient. This improves the current project and paves the way for future innovation.

Reality

In practice, while both these categories have equal attention, project improvements hold paramount importance for business outcomes. SREs invest significant effort in enhancing software reliability, scalability, and dependability. Regrettably, recent reports indicate that SREs spend a substantial portion of their time addressing build issues and managing production incidents. This challenge escalates with the growing complexity of cloud systems and organizational aspirations for digital transformation, often leaving minimal time for substantial project improvements. Consequently, organizations grapple with various issues that impact software reliability.

Process Improvements

Organizations are strategically integrating observability into the initial stages of their release processes to tackle these challenges. As they embark on this initiative, SREs are tasked with identifying an observability solution that aligns seamlessly with their application teams and seamlessly integrates with their existing toolset.

Outcome

Dynatrace plays a pivotal role in this endeavor by empowering application teams through its seamless integration. The Dynatrace integration leverages native features and events that pass through the pipeline. Events serve as logic operators that can trigger or stop subsequent tasks within the pipeline. Additionally, the Site Reliability Guardian serves as the governing entity, making decisions on whether to proceed or halt a specific build based on observable telemetry data supplied by OneAgent during the CI/CD pipeline process.  This proactive strategy significantly enhances the chances of success for SREs, providing them with more time to focus on substantial project improvements (50%) and broaden the buffer zone (30%). This empowers them to spearhead innovations that ensure the business is prepared for future expansions.

Integrate DevSecOps with Dynatrace

Software delivery is structured around CI/CD pipelines, which play a critical role in the SRE process and represent the first step toward effective automation. Automated CI/CD pipelines greatly reduce the occurrence of manual errors. They provide continuous feedback to developers and enable rapid product iterations. Elevating the efficiency of release pipelines is one key to producing high-quality software; it mitigates the need for post-incident analyses and on-call duties for the SRE team. It also returns valuable time back to the SRE team.

A few avenues for elevating CI/CD pipelines are:

• Enhancing the extent of automated test coverage during the testing phase.
• Embracing the tenets of DevOps and DevSecOps methodologies anchored in engineering principles.
• Identifying and automating the validation of business/application Service Level Objectives (SLOs) during release cycles.
• Streamlining the CI/CD process to ensure optimal efficiency.

To realize these goals, SRE teams can seamlessly follow a three-step process within their Dynatrace environment:

1. Commencement (optional): If desired, initiate a Dynatrace workflow task to establish a connection with the DevOps tool using HTTP. This step is only necessary if you intend to control the build creation process through Dynatrace.
2. Push events: Configure your DevOps tool to dispatch deployment events at the inception of the deployment process. Additionally, introduce annotation events to notify Dynatrace of the progress within your testing phase. These events serve as logical operators that dictate the course of the release process.
3. Automated validation and progression: Depending on the configuration of your tasks, Site Reliability Guardian (SRG) validation can be automatically activated to promote or disapprove the advancement of a build towards production.

This integration leads to complete automation with end-to-end pipeline visibility, thereby reducing the heavy lifting of release management for SRE teams and empowering them to focus on innovation, which catalyzes organizational growth.

Designing systems for reliability

Engineering teams must extend their focus beyond functional and load tests to instill assurance in the software release process via automated cycles. The rationale is that, during actual production, variables can induce outcomes that are different from those predicted in standardized tests. Thus, more comprehensive testing becomes essential to embrace unpredictability and mirror real-world conditions. These practices are commonly known as “chaos engineering.”

By embracing chaos engineering practices, development teams cultivate a higher degree of confidence in the robustness of their applications within specific production scenarios. However, the very nature of chaos engineering introduces a challenge: identifying the responsible service when a failure occurs. This is where Dynatrace Davis AI comes into play, leveraging telemetry data from your services. Davis AI automatically establishes a baseline of each service’s behavior, learned during the development and functional testing phases, and subsequently identifies the underlying causes of failures, thereby eliminating the uncertainty of the root cause and “war room” scenarios.

To illustrate, a CI/CD pipeline setup has a functional test phase followed by a chaos-engineering test. The chaos engineering test was structured to randomly slow down a Docker container and, thereby, a critical service for the application. During this phase, Davis AI automatically identifies that a key business request has breached its automated baseline due to a significant Mongo database slowdown. Moreover, Davis AI identifies the reason behind the slowdown and pinpoints the exact query that caused the problem.

With Davis AI’s contextual capabilities, embracing chaos engineering and making application code robust and better prepared for production deployments is easy.

Reduce operations overhead

Ideally, no bugs are reported once software is deployed to production. However, this is highly unlikely. Therefore, it’s important to have a process in place to minimize downtime in the event of a failure.

Davis AI assists with automated root cause analysis, providing details of the underlying services, traces, logs, and user sessions that caused the failure. This can save SRE teams from the time and effort of debugging or a war room scenario. By identifying the exact code or trace that causes a failure, Davis AI helps teams fix problems quickly and significantly reduces MTTR. In addition, if you configure an automated remediation workflow, Dynatrace invokes it and restores applications with virtually no downtime.

In the above screenshot, one of the requests in the application reports errors. Davis AI identifies that this anomaly was reported in the newer releases. Davis AI captures and relays the details of previous and current builds to the remediation workflow. The remediation workflow uses this information to roll back the build, leaving Davis AI to automatically validate and close detected problems.

Dynatrace Observability empowers the SRE team, propelling them towards LowOps/NoOps. This allows them to prioritize innovation, strategic goals, and minimize downtime while optimizing the delivery of perfect software. In our next blog post in this series, we’ll delve into the step-by-step process of automating the release pipeline using Dynatrace best practices.

The post Accelerate and empower Site Reliability Engineering with Dynatrace observability appeared first on Dynatrace news.

SLOs cover a wide range of monitoring options for different applications. This article explores SLOs for service performance. If you’re new to SLOs and want to learn more about them, how they’re used, and best practices, see the additional resources listed at the end of this article.

According to the Google Site Reliability Engineering (SRE) handbook, monitoring the four golden signals is crucial in delivering high-performing software solutions. These signals (latency, traffic, errors, and saturation) provide a solid means of proactively monitoring operative systems via SLOs and tracking business success.

How to measure performance

SLOs are based on service-level indicators (SLIs), which are used to track performance against pre-defined service-level agreements (SLAs).

While this connection might sound simple, finding the right metrics to measure the needed SLIs takes time and effort. Moreover, after selecting an SLI, complex metric expressions might be required to extract and interpret the result and come to the right conclusions and decisions.

SLOs, as a measure of service quality, can track the related availability, reliability, and performance. Hence, service performance is one key indicator for defining and monitoring service-side objectives. Performance typically addresses response times or latency aspects and contributes to the four golden signals.

Generally, response times measure the total duration of receiving, processing, and completing a request. Among other measures, response times significantly contribute to evaluating frictionless and satisfying user experiences and hence are included in calculating the Application Performance Index (Apdex). Proactively monitoring these indicators is vital to achieving the expected and desired performance.

Service-performance template

Latency is often described as the time a request takes to be served. This is what Dynatrace captures as response time. An excellent way to establish an SLO based on latency is to have a certain percentage of all service requests returned within a selected time frame of, for example, 300 ms. Once the SLI metric is defined, an SLO can be created based on the ratio of high-performing partitions (time intervals) compared to all partitions.

To simplify the process, Dynatrace provides dedicated templates for SLO creation via the SLO Wizard. One template explicitly targets service performance monitoring.

The service performance SLO depicts the ratio of the count of partitions (time intervals) rated as “fast” compared to the total count of all partitions. The respective metric expression looks like this:

((builtin:service.response.time:avg:partition("latency",value("good",lt(10000))):splitBy():count:default(0))/(builtin:service.response.time:avg:splitBy():count)*(100)):default(100,always)

How to use and interpret the template

Looking back to the provided metric expression, different metric transformations, such as avg, partition, splitBy, lt, count, and default, are used to calculate the numerator and denominator to compute the SLO’s service performance status.

Partition Operator

An important operator is represented via the so-called partition transformation.

The partition transformation separates the time series into equally sized time intervals over the timeframe. The longer the timeframe, the larger the timeslots. Therefore, the SLO evaluation’s precision depends on the evaluation length (=query) period.

Functionality-wise, it adds another dimension based on the selected criteria, such as “good” or “bad,” by considering the input parameter, such as lt (lower than) 10000us. After calculating the ratio between good and overall timeslots the desired percentage value for the performance SLO is returned.

Note: The partition operation adds an additional dimension to the timeseries. This requires the usage of splitBy or merge commands to align the numerator and denominator accordingly.

A further pre-requisite to using the partition operator effectively is shown in the aggregation requirement. An aggregation operator processes the datapoints of the single partitions, influencing whether they’re counted as good or bad. Typical and recommended aggregations are the avg (average) or percentile(N^th) function. While avg applies the arithmetic means, the percentile(N^th) aggregation can help by removing large outliers, due to calculating the N^th percentile of the given data points. These two aggregation transformations can be exchanged based on the desired outcome. Using the percentile(90) aggregation in the described example results in only counting partitions where 90% of all datapoints depict a faster response time than 10000 us (0,01 seconds).

Further details about the partition syntax can be found in the documentation.

The partition operator requires a threshold for dividing the timeslots into “good” and “bad”. The latency command provides a means of estimating service-performance values. lt() represents “lower-than,” followed by an integer value indicating the microseconds used for the threshold.

Default Operator

While the splitBy and count operator, as standard operators for metrics, remove the different dimensions via aggregation and return the amount of datapoints, the default() operator helps in case of data gaps within the given time series.

The default operator replaces null values in the payload with the specified value. In the example above, the default operator replaces null values with 0, in order to ensure that only values matching the latency criterion are considered for the SLO status calculation. However, in cases where there is no traffic on the selected service, this does not mean that performance is bad. This possibility is covered by adding default(100, always) at the end, which ensures that “no traffic” situations are not counted as bad performance.

Increasing the precision of service-performance SLOs

The service-performance SLOs described are based on built-in metrics, which are captured, calculated, and provided out-of-the-box by Dynatrace. For higher precision (for example, smaller time slots of good and bad samples), custom-calculated metrics can create specific time series for the numerator.

NOTE: When combining calculated service metrics with built-in metrics, the muted request option for excluding muted requests in the calculated service metric is advised, as the built-in metric applies it by default.

Set up your first service-performance SLO

The SLO templates are available to all users and can be applied via the SLO wizard. To create an SLO, select the Add SLO button on the relevant service page or via the SLO application.

As soon as the SLO is created, it can be monitored and visualized via a dashboard. By applying alerting capabilities, a notification can be sent as soon as the service level objective is at risk of being violated.

To get more information about how SLOs can be created and support you in reaching your business goals, please have a look at the resources below:

• Service level objective examples: 5 SLO examples for faster, more reliable apps
• Lessons learned from enterprise service-level objective management
• SLOs done right: how DevOps teams can build better service-level objectives

The post Maximize user experience with out-of-the-box service-performance SLOs appeared first on Dynatrace news.

Developers are increasingly responsible for ensuring the quality and security of code throughout the software lifecycle. Traditional tools and approaches, however, only allow debugging in pre-production environments. Debugging in production often requires shutting down services. This can disrupt the users of the running application, slow down the application’s performance, or even crash it altogether.

Developer-first observability

Adding Rookout to the Dynatrace platform will provide developers with increased code-level observability of Kubernetes-hosted production environments. This will also add interactivity and control to troubleshooting and debugging in production, drastically reduce the need to replicate issues in pre-production environments and improve collaboration across development, IT, and security teams.

As Shahar Fogel, CEO at Rookout, said, “Our mission is to make debugging easy and fast for developers with state-of-the-art quality and a simple experience. We believe integrating Rookout into the Dynatrace platform and leveraging the artificial intelligence and automation capabilities Dynatrace is known for will accelerate this mission. This will also create a new standard for how engineers use developer-first, cloud-native observability to improve productivity by enabling them to spend less time on manual activities and more time delivering business value.”

Observability and security continue to converge

“Development teams are increasingly expected to incorporate observability and security capabilities into their solutions (shift-left) as well as perform testing, quality, and performance evaluation in production environments (shift right),” said Bernd Greifeneder, CTO at Dynatrace. “We believe acquiring Rookout will accelerate this process by providing our customers with developer-observability solutions that scale from a developer’s integrated development environment, or IDE, and are designed to enable their organizations to meet enterprise governance requirements. Our experience is that Rookout enables developers to troubleshoot and debug issues in production significantly faster than traditional tools and approaches, dramatically reducing the time they spend on maintenance activities.”

Closing of the proposed transaction is subject to customary closing conditions and is expected to occur later in the company’s second quarter, which ends on September 30, 2023. The proposed transaction will not have a material impact on Dynatrace’s fiscal year 2024 financials and will be funded from cash on hand.

The post Dynatrace to acquire Rookout to deliver code debugging in production environments appeared first on Dynatrace news.

In the world of DevOps and SRE, DevOps automation answers the undeniable need for efficiency and scalability. Though the industry champions observability as a vital component, it’s become clear that teams need more than data on dashboards to overcome persistent DevOps challenges. DevOps teams need automation that goes beyond passive observations. They need event-driven automation that not only responds to events and triggers but also analyzes and interprets the context to deliver precise and proactive actions. This evolution in automation, referred to as answer-driven automation, empowers teams to address complex issues in real time, optimize workflows, and enhance overall operational efficiency.

In this blog, we will dive into the transformative power of answer-driven automation. We will also explore the evolution of DevOps automation and the significance of data-driven answers in unlocking streamlined, automated DevOps and SRE processes.

The evolution of DevOps automation

Since the concept of DevOps emerged around 2007 and 2008 in response to pain points with Agile development, DevOps automation has been continuously evolving.

Business process automation

Business process automation is the foundation for improving operational efficiency. From automating email communications and backup scheduling to streamlining invoicing and billing processes, organizations have embraced automation to save time and reduce manual effort. These initial automation endeavors paved the way for greater advancements, leading to the next evolution of event-driven automation.

Event-driven automation

Event-driven automation represents a significant leap forward. It harnesses real-time responsiveness to specific rules or events, revolutionizing business operations.

For example, consider an e-commerce website that automatically sends personalized discount codes to customers who abandon their shopping carts. This event-driven automation triggers the action of sending the discount code only when the customer abandons the cart, minimizing revenue loss and increasing conversion rates.

In the realm of cybersecurity, event-driven automation plays a crucial role in threat detection and response. A team can configure its observability platform to detect specific events, such as malicious user requests that could be part of a SQL injection attack or suspicious login attempts. When the platform identifies these events, event-driven automation can automatically trigger actions like blocking IP addresses, initiating incident response protocols, and sending alerts to security or development teams. This proactive approach strengthens the organization’s defense against cyber threats and reduces the time to detect and mitigate potential breaches.

But even the event-driven approach leaves gaps that greater detail and context could fill in. With greater detail and context, organizations can make—and automate—more nuanced decisions with greater impact to operations, security, and the business.

Answer-driven automation

With the advent of AI in operations (AIOps), DevOps teams have an opportunity to apply a more intelligent and comprehensive approach to automation driven by AI. Combining precise, causal AI-powered answers —derived from observability, security, and business data— with predictive AI and automation provides a feedback loop that makes the automation more intelligent and business-value-oriented. This is what answer-driven automation is all about.

Let’s examine a few examples of answer-driven automation using AI and context.

DevOps automation example #1: Online shopping

It has been more than 25 years since Bill Gates coined the phrase “context is king,” yet its relevance persists. Consider the aforementioned scenario of cart abandonment, where the user receives an automated email with a discount code. While this initial step may seem promising, crucial pieces of information (the context) surrounding the transaction remain missing. The absence of these details hampers decision-making. Questions arise, such as the following:

• How substantial is the shopping cart?
• How popular is the product?
• How long has it been lingering in the cart?
• Are there any existing discounts on the product?
• What is the current inventory level?
• Has the user purchased this product before?

Imagine having an AI engine that comprehends the complete context of the transaction and intelligently determines whether to send a discount code—and which one to send. This would propel event-driven automation to new heights. Full contextual awareness helps the AI engine make informed decisions. This revolutionizes the online shopping experience and leads to better conversions and enhanced user satisfaction.

DevOps automation example #2: Threat detection and response

Let’s build on the previous example. While resorting to IP address blocking as a defense measure may seem tempting, it could potentially be an excessive reaction, especially when the true intent behind the event remains unknown. This is where answer-driven automation comes into play. The AI engine becomes your trusted ally, observing the user request behavior within the application. It goes beyond surface-level observations, diving deep into the intricate details to determine outcomes, including the following:

• Is there an exploitable vulnerability?
• Does it constitute a zero-day vulnerability?
• How critical is the vulnerability?
• How adjacent is the vulnerability to the data source?
• Was the user input indeed malicious?

Armed with these precise answers, you gain a crystal-clear understanding of the situation.

The real power lies in the subsequent actions that answer-driven automation triggers. Answer-driven DevOps automation goes beyond creating tickets and extends to executing workflows designed to extract ownership information and then route the ticket to the responsible teams. This seamless handoff ensures that the right team diligently addresses the root cause of the problem, allowing teams to efficiently resolve them. Answer-driven automation mitigates alert storms and significantly reduces the number of false positives. As a result, it saves critical developer time and expedites the mean time to resolution (MTTR). Combining answer-driven automation and comprehensive threat detection and response provides a robust defense mechanism against potential threats. The combination empowers organizations to identify the true nature of events swiftly, take well-informed actions, and proactively address vulnerabilities.

DevOps automation example #3: Progressive delivery

In software development and delivery, if an organization uses feature flags to control feature releases, the marriage of observability data and answer-driven automation becomes a formidable force. Observability data provides a treasure trove of performance, stability, and user experience metrics encompassing error rates, response times, and user engagement. This rich dataset is the foundation for an answer-driven automation solution to work its magic using AI.

With swift precision, an answer-driven automation solution that uses causal AI can transform these metrics into invaluable insights. Such a solution can automatically analyze the impact of newly introduced features or changes facilitated through feature flags. For instance, in the case of poor performance, you can seamlessly toggle a feature flag and mitigate any detrimental effects. Conversely, if the feedback is overwhelmingly positive, you can dynamically expand the feature’s exposure to a wider group of users and unleash its full potential. In this way, answer-driven automation orchestrates the seamless delivery of new features to users while effectively minimizing the impact of potential downtime or negative user experiences.

This powerful synergy between observability data, causal AI insights, and answer-driven automation empowers organizations to embrace progressive delivery with unwavering confidence. It enables them to adapt to user feedback swiftly, fine-tune feature releases, and deliver exceptional user experiences, all while maintaining control and minimizing disruption.

DevOps automation example #4: Intelligent incident management and remediation

We’ve witnessed the power of event-driven automation in generating alerts, creating incident tickets, and executing runbooks to drive remediation efforts. While this level of automation is undeniably beneficial, today’s IT leaders aspire for even greater capabilities. Here, answer-driven automation enables organizations to harness the potential of answers from observability data to achieve self-healing, proactive management.

Consider an event-driven automation system designed for incident management. When a server experiences an outage, the system promptly triggers an alert and initiates actions like restarting a server or redirecting traffic to a redundant server. While this reactive approach effectively restores services, it does not address the underlying cause, which results in recurring incidents.

In contrast, answer-driven automation takes incident management to a new level. Using advanced causal AI and context-aware decision-making, it identifies the root cause behind server failures. The system analyzes performance patterns and historical data to uncover the specific software bug or resource constraint causing the issue.

Thus, in addition to generating alerts and incident tickets, the system can trigger predefined workflows or specific runbooks to deploy software patches and automatically scale up or down resources when necessary. But it doesn’t stop there. Based on all the contextual information, the system can provide predictive answers to auto-scale infrastructure and anticipate future capacity demands, effectively reducing cost, carbon footprint, and downtime. All these actions aim to avert future incidents. And finally, with an observability platform, you can effectively “close the loop” and ensure that any remediation actions fix the issue by continually observing and evaluating SLOs and business objectives. Answer-driven automation holds transformative power within the realm of remediation.

DevOps automation example #5: Safeguarding production

Imagine having the ability to instantly validate the impact of any change to a production application and receive real-time feedback. Change impact analysis is an indispensable process for effectively managing changes within an organization’s infrastructure and applications. It entails evaluating the potential consequences and risks associated with both planned and unplanned changes, ensuring smooth and successful operations.

Let’s consider a scenario where a software development team oversees the deployment of updates to a microservices-based application. Suppose a development team is working on a new feature for a specific service. They intend to roll it out to the production environment. However, they don’t have a comprehensive understanding of the intricate dependencies between the services or the potential impact of the change on the overall system.

To mitigate this uncertainty, the developers can harness causal AI to understand how the change will affect other services. They can also see how the change can affect critical objectives like SLOs and golden signals, such as traffic, latency, saturation, and error rate. This automated validation equips developers with the necessary knowledge to make informed decisions about the deployment, or even prompt them to consider a rollback if necessary. Precise answers derived from causal AI —coupled with answer-driven automation— eliminate the need for guesswork and result in a more reliable, resilient production system.

Answer-driven automation: The new frontier in DevOps automation

The use cases for answer-driven automation are as varied as the DevOps environments they can help to automate. Observability, causal AI, and predictive AI form the basis for enabling answer-driven automation. The Dynatrace platform’s unique approach to delivering precise answers —through root cause analysis from the Davis AI Engine— and intelligent automation can help your organization scale to new heights. By uniting broad, deep observability with precise security analytics capabilities in a single platform to automate DevOps, teams can deliver better, more secure software faster.

Now with AutomationEngine and Workflows, Dynatrace empowers organizations to build, customize, and deploy workflows to help teams realize the full potential of answer-driven automation.

The post DevOps automation: From event-driven automation to answer-driven automation [with causal AI] appeared first on Dynatrace news.