Skip to main content

Usage Scenarios and Examples

This section provides practical applications of vizOps in real-world scenarios. Each example illustrates how the tool can be used to solve specific problems, validate architecture, or provide insights during development and testing. Whether you're a developer, QA engineer, or software architect, these use cases demonstrate how vizOps can integrate seamlessly into your workflow and enhance your understanding of your microservices architecture.

5.1 Visualizing a Simple Microservices System​

Purpose​

To demonstrate how vizOps automatically detects services and visualizes interactions in a small microservices setup.

Scenario​

A developer has a project with three microservices:

  • API Gateway
  • User Service
  • Order Service

They want to see a high-level overview of the interactions between these services to ensure that dependencies are configured correctly.

Steps​

Setup​

  1. Add vizOps Agent Dependency

    • For each microservice, add the vizOps agent dependency to the pom.xml file: 
      <!-- Add the vizOps agent as a dependency -->
      <dependency>
          <groupId>io.vizops</groupId>
          <artifactId>vizops-agent</artifactId>
          <version>1.0.0</version>
      </dependency>

  2. Configure API Key

    • Create a vizops-config.properties file in the root directory of each microservice and add your API key: vizops.api.key=YOUR_API_KEY
Running the Agent​
  1. Analyze Each Service
    • In the root directory of each microservice, run: mvn vizops:analyze
    • Repeat this step for the API Gateway, User Service, and Order Service.
Viewing the Visualization​

  1. Access the Dashboard

  2. Navigate to the Services Tab

    • Click on the Services tab to view the high-level overview.

  3. Expected Output

    • You should see a diagram with three nodes representing the API Gateway, User Service, and Order Service.
    • Arrows indicate dependencies between the services, such as API calls from the API Gateway to the User Service and Order Service.

    [[Insert mockup diagram of the simple microservices visualization here]]

Outcome​

The developer can visually verify that the interactions between services match the intended design and that there are no missing dependencies. This ensures that the microservices communicate as expected, reducing the risk of integration issues.

5.2 Detecting and Resolving Contract Violations​

Purpose​

To show how vizOps can detect API contract violations during the development cycle and help developers resolve them before deployment.

Scenario​

A developer modifies the User Service's API by changing the response schema. However, the Order Service still relies on the old response format, which would cause runtime errors if deployed.

Steps​

Initial Run​

  1. Modify the User Service

    • Change the response schema of an API endpoint in the User Service.

  2. Run vizOps Analysis

    • In the User Service root directory, run: mvn vizops:analyze

  3. Agent Detection

    • The vizOps agent detects a contract violation due to the change in the API.
Viewing the Violation​

  1. Access the Dashboard

  2. Navigate to the Contracts Tab

    • Click on the Contracts tab to view API contracts and their statuses.

  3. Expected Output

    • A warning message appears indicating that the Order Service's expected response schema does not match the new schema provided by the User Service.
    • The specific endpoint and mismatch details are highlighted.

    [[Insert mockup of the contract violation warning in the dashboard]]

Resolving the Issue​

  1. Update the Order Service

    • Modify the Order Service to align with the new response format from the User Service.

  2. Run vizOps Analysis on Order Service

    • In the Order Service root directory, run: mvn vizops:analyze

  3. Re-Verify

    • The vizOps agent re-analyzes the Order Service, and the previous warning should now be resolved.
Confirming Resolution​

  1. Refresh the Dashboard

    • Return to the Contracts tab on the vizOps dashboard.

  2. Expected Outcome

    • The warning message regarding the contract violation should no longer appear.
    • Both services are now in sync regarding the API contract.

Outcome​

By using vizOps, the developer catches and resolves the issue early in the development process, preventing a costly bug from reaching production. This ensures smooth communication between services and maintains system reliability.

5.3 Tracking System Evolution Over Time​

Purpose​

To illustrate how vizOps can track and visualize changes in system architecture over multiple iterations, providing historical context for architectural decisions.

Scenario​

An architect wants to see how the addition of a new service—Payment Service—has impacted the overall system architecture and dependency graph.

Steps​

Initial State​

  1. Baseline Analysis

    • Ensure that the API Gateway, User Service, and Order Service have been analyzed with vizOps.
    • This serves as the initial baseline in the vizOps dashboard.

  2. Capture Baseline

    • In the dashboard, label this state as "Baseline - Before Payment Service".
Introducing the New Service​

  1. Add Payment Service

    • Develop and integrate the new Payment Service into the project.

  2. Add vizOps Dependency and Configuration

    • Add the vizOps agent dependency to the Payment Service pom.xml.
    • Configure the vizops-config.properties file with your API key.

  3. Run vizOps Analysis

    • In the Payment Service root directory, run: mvn vizops:analyze

  4. Re-Analyze Existing Services

    • Optional: Re-run the vizOps agent on the API Gateway and Order Service if they have been updated to interact with the Payment Service.
Viewing the Evolution​

  1. Access the Timeline View

    • In the vizOps dashboard, navigate to the Timeline or History tab.

  2. Select Timeframes

    • Compare the architecture at "Baseline - Before Payment Service" and the current state.

  3. Expected Output

    • The initial diagram shows three services.
    • The updated diagram includes the Payment Service with connections to the API Gateway and Order Service.

    [[Insert mockup of the architecture before and after adding the Payment Service]]

Outcome​

The architect can visually confirm how the system evolved and assess whether the new service has introduced any unintended dependencies. This historical context aids in making informed architectural decisions and understanding the impact of changes over time.

5.4 Impact Analysis of a Service Modification​

Purpose​

To show how vizOps helps perform an impact analysis when a developer modifies an existing service, ensuring that the change does not introduce unexpected side effects.

Scenario​

A developer plans to refactor the User Service, which is a core microservice. They want to understand which other services will be impacted by these changes.

Steps​

Viewing Dependencies​

  1. Access the Impact Analysis Tab

    • Open the vizOps dashboard and navigate to the Impact Analysis tab.

  2. Select the User Service

    • Choose User Service from the list of services.

  3. Expected Output

    • A graph displays all direct and indirect dependencies of the User Service.
    • Services like API Gateway and Order Service that interact with the User Service are highlighted.

    [[Insert mockup of the impact analysis graph showing dependencies of the User Service]]

Analyzing Impact​

  1. Review Direct Dependencies

    • Identify services that make direct API calls to the User Service.

  2. Review Indirect Dependencies

    • Look for services that may be indirectly affected due to shared data or cascading calls.
Validating Changes​

  1. Proceed with Refactoring

    • Make the necessary changes to the User Service codebase.

  2. Run vizOps Analysis

    • After refactoring, run: mvn vizops:analyze

  3. Check for Issues

    • The vizOps agent will detect any new contract violations or broken dependencies resulting from the changes.

  4. Review Dashboard

    • Return to the Impact Analysis and Contracts tabs to verify that no new issues have been introduced.

Outcome​

The developer can confidently proceed with the refactoring, knowing the impact on the system. By identifying affected services beforehand, they reduce the risk of breaking downstream services and can coordinate with other team members if necessary.

General Guidelines​

  • Self-Contained Scenarios: Each example is designed to be self-contained, allowing you to focus on specific features of vizOps.
  • Step-by-Step Instructions: Follow the detailed steps to replicate the scenarios in your own environment.
  • Visual Aids: Mockups and diagrams are provided to help you visualize expected outputs.
  • Real-World Applications: These scenarios reflect common challenges in microservices development and show how vizOps can address them effectively.

Feel free to explore these examples and adapt them to your own projects. As vizOps continues to evolve, additional use cases and advanced features will be documented to enhance your experience.