Increased Agility with Pipeline Feedback Scoping

Post

As businesses continue to look for ways to be more competitive and innovative, many turn to increased agility as an answer. What do companies mean by business agility? Business agility, as pictured below, is about the granularity of the overall software solution and the deployment frequency of that solution. An improvement in agility is achieved by strong, actionable, and immediate feedback cycles. This was the goal of the first iteration of Instana’s Pipeline Feedback. Pipeline Feedback™ helps users progress forward in the agile quadrant using application release tracking and analysis.

Word Image 332

Instana is now enhancing Pipeline Feedback with a new scoping capability that makes it even easier for businesses to increase agility. Pipeline feedback scoping enables teams to personalize the marker for their specific needs. Scoping is particularly useful for SREs, DevOps, operations, and development organizations because it is a toolkit that reduces the noise of their complex systems by focusing solely on the needed information. For application development and deployment teams it illustrates, in real time, the quality of the new software releases they care about. DevOps, SREs, and Developers receive immediate feedback about the health and quality of new releases.

This blog is the first in a series of three posts that will describe the new Pipeline Feedback scoping capability. This first post provides background information and describes the three types of release marker scopes. The second post has some examples of applying these scopes in practice. And, lastly, the third post will discuss the Application PerspectiveI and integrations that are provided.

Pipeline Feedback Background

Pipeline Feedback eliminates a lot of deployment anxiety that comes with the fear of dealing with unexpected problems right after an application or service update. It does this by providing end-to-end visibility of each release and their impact on application or infrastructure health. For example, without the context of when a release happened, it’s challenging to understand whether a latency spike indicates a problem or is an effect of the deployment process. This information can indicate if the release led to a degradation in performance, which helps to decide on whether to rollback to a previous version or identify a specific problem to be resolved.

The concept of a release is central to Pipeline Feedback, but what is a release? A release is a defined moment in time when a change occurred to the application or the services that make up the application. A Release Marker is an indicator in a chart or list of when the change for a release has completed and becomes available to the users. Each release marker has a name and a time associated with it. The figure below shows a single release marker (the rocket ship) in the Releases swim lane. Because the time window is wide in time there are two release markers that overlap on the chart and they occurred five minutes apart: release-A#848 and releases-B-#848. Using the release marker, it is easy to compare the behavior prior to the release and after the release. This enables users of Instana to easily visualize, identify, and correlate issues that may have occurred due to releases.

Word Image 333

Release markers are generated automatically when the deployment tool makes the Application PerspectiveI call to Instana as a new release is deployed. Pipeline feedback provides several tool integrations to make this easy.

The Available Pipeline Feedback Scope Types

There are three approaches to assign a Pipeline Feedback scope. Many organizations are at different maturity levels in their pursuit of business agility and this variety allows them to apply one or more scopes based on what maturity level they are at. Another reason to have different scopes is to allow for them to be applied in different ways, such as for a cross-cutting service or specific to an application.

The three approaches are: global marker, service marker, and application marker. The global marker approach is the simplest because it has a global scope. This is where a global release marker is spread across all the monitored applications, services, and infrastructure. The service marker approach is where release markers only apply to one or more specified services. The application marker approach applies to a collection of services that make up a microservices application and as they are defined by an Application Perspective (i.e., an application perspective marker).

The image below is a diagram of a monitored environment. It is used to explain the ways in which the different scope approaches differ. This example environment consists of:

  • Two applications made up of two services each. These applications are represented by the two application dashboards shown in purple.
  • There are three service dashboards, highlighted in yellow, related to the applications with the inventory service being shared by both.
  • The fourth service, Search, is not part of either application. This brings the number of service dashboards to four.
  • Each service has a single endpoint that is monitored so there are four endpoint dashboards highlighted in orange.

The edges shown between the dashboards are how users navigate to other dashboards, such as moving from an application dashboard to a service in that application, and then to an endpoint of that service.

Word Image 334

In order to best determine the right scoping approach for each scenario we need to compare them based on:

  1. what types of organization the approach best applies to;
  2. what the various dashboards display;
  3. the data that is shown; and
  4. example Application PerspectiveI usage.

The dashboards of interest are: Application Perspectives, services, endpoints, and infrastructure views where appropriate.

Global Marker

The global marker is the simplest to understand because it is displayed everywhere in the tool: on all dashboards, including infrastructure. It was originally the only release marker scope available and it is backwards compatible with the new scoping capability. The global marker has a single visibility rule: show it on all dashboards. You can see in the example monitored environment below that global marker is shown on each and every dashboard.

Word Image 335

The global marker Application PerspectiveI example for this is:

curl --location --request POST https://<YOUR_INSTANA_HOST>/api/releases \
--header 'Content-Type: application/json' \
--header 'Authorization: apiToken <YOUR_API_TOKEN>' \
--data "{
   \"start\": $(date +%s000),
   \"name\": \"global-marker-#1\"
}"

The global marker is helpful when one or more of the following items is true: an organization is small, there are infrequent releases where the application is updated all at once, there is a small number of services, or the marker information needs to be known globally.

Just like in the first iteration of Pipeline Feedback, whenever a global marker is assigned there is a global release notification that pops-up where you can perform the following two optional actions:

  • Focus time to release: Changes the selected timeframe so that the new release is in view while the current window-size of the timeframe stays unchanged so that metrics before and after the release are easily compared.
  • Follow release live: Enables the Live Mode so that effects of the release are immediately visible in all dashboards or charts.

An example global notification is shown below. It only occurs for a global marker so it is not shown for a service or application marker.

Word Image 336

The global marker scope does have some limitations. For example, if there are many releases in a short period of time then the release markers will overlap; and if services are released independently then a global marker for each service will have too many markers to properly visualize. Additionally, if the release marker is only relevant to a subset of the services it causes noise on all the other dashboards. The service marker approach overcomes many of these limitations.

Service Marker

With the service marker approach, each service can have its own release marker that is independent of other services and only shown on that service’s related service and endpoint dashboards.

A service marker has the following visibility rules so that it shows up on the Application Perspective, Service, and Endpoint dashboards:

  • The service dashboard shows the markers that are assigned to it. The Search service is the simple case since it isn’t part of any application. It has its own service marker shown which is SM #5. So even services which aren’t part of an application can have a service marker.
  • The endpoint dashboards will always have the same service markers as its service and the endpoint dashboards below reflect this.
  • Several services can be assigned the same service marker. For example, the Discount and Inventory service both have the same service marker SM #2.
  • An application perspective will show the union of all the service markers for the services that are part of the application perspective. An application is made up of a collection of services so the release markers for those services are shown in the applications they are part of. The release marker for the common Inventory service is shown in the applications it is part of. So the Shipping application only shows the service marker SM #2 because all of its services have that marker. The ReturnItem application shows both the SM #2 and SM #4 release markers since its services have different markers.

The service marker does not show up on infrastructure dashboards.

Word Image 337

The Release Application PerspectiveI makes assigning the same marker to a group of services very easy. The example service marker Application PerspectiveI code is:

curl --location --request POST https://<YOUR_INSTANA_HOST>/api/releases \
--header 'Content-Type: application/json' \
--header 'Authorization: apiToken <YOUR_API_TOKEN>' \
--data "{
   \"start\": $(date +%s000),
   \"name\": \"service-marker-#2\",
   \"services\": [
     {
       \"name\": \"discount-service\"
     },
     {
       \"name\": \"inventory-service\"
     }
   ]
}"
curl --location --request POST https://<YOUR_INSTANA_HOST>/api/releases \
--header 'Content-Type: application/json' \
--header 'Authorization: apiToken <YOUR_API_TOKEN>' \
--data "{
   \"start\": $(date +%s000),
   \"name\": \"service-marker-#4\",
   \"services\": [
     {
       \"name\": \"credit-service\"
     }
   ]
}"

The service marker is helpful when one or more of the following items is true: it is assigned for cross-cutting services that are used by several applications, the organization is small, there is a small number of services, releases are infrequent, the organization is not leveraging the power of Application Perspectives (do they know what they are missing?), or services are released independently of each other.

Depending on the use case, a service marker can have some limitations. The major challenge is that it can be too narrow because it applies to a single service. There are some maintenance actions needed if a new service is added because it must be added to the list of services to create a marker for. Some limitations may arise from the high level nature of a service, where assigning the same service marker may not be appropriate, such as:

  • When multiple versions of the same service co-exist (e.g., a canary release);
  • Different environments have the same service name (e.g., Staging and Production environments); and
  • Different technologies have the same service name (e.g., an HTTP service and a database service with the name “Inventory”).

In these situations it is necessary to further qualify the services that the marker should apply to. So what is needed is a middle ground approach between the service marker and the global marker. That is the reason to have an Application Perspective marker.

Application Perspective Marker

An Application Perspective (Application Perspective) is a logical grouping of calls, endpoints, or services based on a query that you specify. Application Perspectives allow you to construct views and dashboards that you are interested in. These perspectives can include multiple services or, alternatively, the same service can be included in many Application Perspectives.

Application Perspectives have troubleshooting capabilities built in so they are the first place to look when users have an application issue. An Application Perspective has a context and that context follows the user around as you navigate the product while troubleshooting an issue. For example, when a user starts from an Application Perspective dashboard and navigates to a service dashboard or an endpoint dashboard within the Application Perspective, the Application Perspective context follows them. This is shown in the figure below where the application name is in the breadcrumb at the top of the page. If the user jumps to Unbounded Analytics then this Application Perspective context will also follow.

Word Image 338

Alternatively, if a user goes directly to a service there is no Application Perspective context. In that case the page breadcrumb does not include an application (as shown below).

Word Image 339

The application context is important to remember because the Application Perspective marker visibility rules honor it as illustrated in the picture below. Those rules are:

  • An Application Perspective dashboard shows the Application Perspective markers that are assigned to it, independent of other applications. For example, application marker Application PerspectiveM #6 is set on the Shopping application while application marker Application PerspectiveM #7 is set on the ReturnItem application.
  • Service dashboards will show application markers when the service dashboard has an application context.
  • Service dashboards always show service markers whether there is or is not an application context.
  • Endpoint dashboards behave like service dashboards.
  • Several Application Perspectives can have the same application marker.
  • If a service is added to an Application Perspective then the next application marker assignment will automatically assign that application marker to the service.

An application marker does not show up on infrastructure dashboards.

The application markers are only visible in the context of the Application Perspective they were set on. For example, Application PerspectiveM #6 marker is set on the Shopping application which means it is only visible in the context of that application. So, if the user starts at the Shopping application dashboard and then moves to the Discount service or Get /find endpoint, the Application PerspectiveM #6 marker will be shown. However, if the user bypassed the Shopping application and went straight to the Discount service or Get /find endpoint then that Application PerspectiveM#6 marker would not be seen.

The Inventory service is shared by both the Shopping and ReturnItem applications. Since the application marker is tied to the application context, the application marker that is shown depends on whether the user navigated within the Shopping or ReturnItem application: you would see Application PerspectiveM #6 if starting from the Shopping application or Application PerspectiveM #7 from the ReturnItem application. At no time would the user see both Application PerspectiveM #6 or Application PerspectiveM #7. The application marker that is shown for the common Inventory service is selected based on the application context.

Word Image 340

The Release Application PerspectiveI makes assigning the same application marker to multiple applications easy. The example application marker Application PerspectiveI code is:

curl --location --request POST https://<YOUR_INSTANA_HOST>/api/releases \
--header 'Content-Type: application/json' \
--header 'Authorization: apiToken <YOUR_API_TOKEN>' \
--data "{
   \"start\": $(date +%s000),
   \"name\": \"application-marker-#6\",
   \"applications\": [
     {
       \"name\": \"Shopping application\"
     }
   ]
}"
curl --location --request POST https://<YOUR_INSTANA_HOST>/api/releases \
--header 'Content-Type: application/json' \
--header 'Authorization: apiToken <YOUR_API_TOKEN>' \
--data "{
   \"start\": $(date +%s000),
   \"name\": \"application-marker-#7\",
   \"applications\": [
     {
       \"name\": \"ReturnItem application\"
     }
   ]
}"

The application marker is helpful when one or more of the following items is true: the organization is large so a global or pure service marker approach is too noisy; delivery or development teams are responsible for one (or more) microservice applications; the power of Application Perspectives is used to analyze the monitored applications from different points of view; there is a large number of services; releases can be frequent and made up of a partial set of the services.

An application marker does have some limitations but this is also its strength: the application marker is only shown in a single application perspective because its scope is limited by intent. This can be overcome by assigning the same release marker to several relevant Application Perspectives at once.

Distinguishing between what is Modeled and what is Shown

It is important to distinguish between the data collected for an Application Perspective and the data that is shown in its dashboard. The three settings that determine what data is collected for an Application Perspective are shown below and it defines the services that are part of the Application Perspective.:

Word Image 341

This is contrasted with the two options for what is shown on the Application Perspective dashboard: “Inbound calls” and “All Calls”. The ‘Inbound calls’ option is for client-like monitoring while “All calls” is useful for drilling down during root cause analysis. “Inbound calls” shows what services make up the Application Perspective based on the call information collected while the “All Calls” option shows all of the services that have calls as part of that business transaction.

If you want to know what services are part of the Application Perspective, click on the “Services” tab of the Application Perspective dashboard and select “Inbound calls” as the viewing option. Those are the services that form the Application Perspective.

The diagram below highlights this where the Discount and Inventory services form the Shopping application: the dashboards in the dotted line box form the Application Perspective (the endpoint dashboards aren’t shown for clarity). Those services will show the application marker because they are part of the application that had Application PerspectiveM #6 assigned. Both Discount and Inventory make calls to other services (i.e., User, Sales, Warehouse) which in turn call other services (i.e., History). When the “All Calls” viewing option is selected all of these services will be seen in the Shopping application dashboard. These other services may be visible in the “All Calls” view but they don’t have the application marker assigned because they are not part of the Shopping application.


Word Image 342

Summary

The three types of release markers have been discussed and are now part of the Pipeline Feedback toolbox. There are many ways in which they can be applied. The next blog post will illustrate how to apply those tools through several examples.

Play with Instana’s APM Observability Sandbox

Announcement, Developer, Product, Thought Leadership
At Instana, we recently improved the installation process for our self-hosted customers. Instana’s self-hosted platform now utilizes a fully Docker based installation process. In a previous blog post, Lessons Learned From Dockerizing...
|
Featured
An ever-increasing number of System architectures and deployment strategies depend on Kubernetes-based environments. Kubernetes (also known as k8s) is an orchestration platform and abstract layer for containerized applications and services. As such,...
|
Announcement, Developer, Product, Thought Leadership
To be successful in Observability, you must have the ability to observe the behavior of a system and derive its health state from it. But deriving the health state of any given...
|

Start your FREE TRIAL today!

As the leading provider of Automatic Application Performance Monitoring (APM) solutions for microservices, Instana has developed the automatic monitoring and AI-based analysis DevOps needs to manage the performance of modern applications. Instana is the only APM solution that automatically discovers, maps and visualizes microservice applications without continuous additional engineering. Customers using Instana achieve operational excellence and deliver better software faster. Visit https://www.instana.com to learn more.