[Project Sustainability Calculator - Project Sustainability Calculator] API Review

[azure-sdk]

New API Review meeting has been requested.

Service Name: Project Sustainability Calculator - Project Sustainability Calculator
Review Created By: Shruti Wasnik
Review Date: 01/29/2025 09:00 AM PT
Release Plan: 1532
PR: Project Sustainability Calculator data plane typespec
Hero Scenarios Link: Not Provided
Core Concepts Doc Link: Not Provided

Description:

Detailed meeting information and documents provided can be accessed here
For more information that will help prepare you for this review, the requirements, and office hours, visit the documentation here

[mikekistler]

AI generated notes from API Review 1/29/25

Generated by AI. Be sure to check for accuracy.

Project Sustainability Calculator Overview

Subhajit introduced the Project Sustainability Calculator, an API service designed to estimate carbon emissions and other greenhouse gases. The service will be deployed on customer subscriptions and integrated with their existing business applications.

• Service Introduction: Subhajit explained that the Project Sustainability Calculator is an API service developed by the Microsoft Cloud for Sustainability team. The service is designed to estimate carbon emissions and other greenhouse gases based on activity data provided by the customer.
• Deployment Model: The service will be deployed on the customer's Azure subscription using a managed on behalf of approach. This means all underlying Azure resources will be deployed on the customer's subscription, allowing them to integrate the service with their existing business applications.
• Functionality: The API service processes activity data, such as business travel, to compute the carbon emissions generated. The service is stateless, meaning it does not store any data and processes each request independently, returning the computed emissions data to the customer.
• Integration: The service can be integrated with the customer's existing business applications or line of business applications. It uses Azure Front Door to manage incoming requests and reads configuration data from a storage account, ensuring a seamless integration with the customer's infrastructure.

Data Plane and Control Plane Separation

Subhajit and Speaker 1 discussed the separation of the data plane and control plane, with Subhajit explaining that the data plane is offloaded to the customer's side to avoid hosting costs and utilize Azure metering for consumption and cost usage.

• Separation Rationale: Subhajit explained that the data plane is separated from the control plane to offload hosting costs to the customer. This approach allows the service to use Azure metering for consumption and cost usage, reducing the cost burden on Microsoft.
• Customer Deployment: All resources for the data plane are deployed on the customer's Azure subscription. This model ensures that the customer incurs the hosting costs, and the service can leverage Azure's standard metering for billing purposes.
• Productization Strategy: Subhajit mentioned that the decision to separate the data plane was based on the productization strategy. By offloading the data plane to the customer, the service avoids the need for metering and other requirements associated with hosting the data plane on Microsoft's infrastructure.
• Cost Considerations: Speaker 1 inquired about the reasons for separating the data plane, and Subhajit clarified that the primary reason was to avoid the hosting costs associated with deploying the data plane on Microsoft's infrastructure. This approach also aligns with the service's productization strategy.

API Service Design and Functionality

Subhajit explained the design and functionality of the API service, including its stateless nature, the use of Azure Front Door, and the process of computing carbon emissions based on activity data.

• Stateless Design: Subhajit described the API service as stateless, meaning it does not store any data. Each request is processed independently, and the service returns the computed emissions data to the customer without retaining any information.
• Azure Front Door: The service uses Azure Front Door to manage incoming requests. This ensures that the service can handle a large number of requests efficiently and provides a secure and scalable entry point for the API service.
• Activity Data Processing: The API service processes activity data, such as business travel, to compute the carbon emissions generated. Customers provide the necessary parameters, and the service calculates the emissions based on the provided data.
• Configuration Data: The service reads configuration data from a storage account. This data includes information about calculation models, classifications, and units, which are used to process the activity data and compute the emissions.

Review of Type Spec and SDK

Shruti and Subhajit sought feedback on the type spec and SDK they created for the data plane, mentioning that certain checks were failing and they had questions about the implementation.

• Type Spec Creation: Shruti mentioned that they created the type spec and SDK for the data plane based on references from the PM. They sought feedback on the artifacts and wanted to understand the next steps for SDK onboarding.
• Implementation Questions: Shruti and Subhajit had questions about the implementation of the type spec and SDK. They mentioned that certain checks were failing and sought answers to these issues during the meeting.

Adherence to Azure Rest API Guidelines

Johan and Ted pointed out that the current API design does not adhere to Azure's Rest API guidelines, highlighting issues such as pagination, URL structures, and non-standard error models. They recommended using the Azure-specific library for TypeSpec to ensure compliance.

• Guideline Adherence: Johan and Ted highlighted that the current API design does not adhere to Azure's Rest API guidelines. They pointed out issues such as pagination, URL structures, and non-standard error models that need to be addressed.
• TypeSpec Library: Ted recommended using the Azure-specific library for TypeSpec to ensure compliance with Azure guidelines. This approach would simplify the API design and ensure it adheres to the required standards.
• API Design Issues: Johan mentioned that the current API design includes custom pagination responses and non-standard URL structures. These issues need to be resolved to align with Azure's Rest API guidelines.
• Standardization: Johan emphasized the importance of following Azure's Rest API guidelines, even for non-mandatory recommendations. He suggested that any deviations from the guidelines should be well-justified and motivated.

Next Steps and Action Items

Subhajit and Shruti agreed to revisit the API definitions and use the Azure TypeSpec library to ensure compliance with Azure guidelines. They will also attend TypeSpec office hours for further assistance and clarification.

• Revisiting API Definitions: Subhajit and Shruti agreed to revisit the API definitions to ensure they comply with Azure's Rest API guidelines. They will use the Azure TypeSpec library to define the API and make necessary adjustments to their implementation.
• TypeSpec Office Hours: Subhajit and Shruti will attend TypeSpec office hours to seek further assistance and clarification on their implementation. This will help them address any issues and ensure their API design aligns with Azure guidelines.
• Implementation Adjustments: Subhajit and Shruti will make necessary adjustments to their implementation based on the feedback received during the meeting. They will ensure that their API design adheres to Azure's Rest API guidelines and addresses any identified issues.

Follow-up tasks

• API Service Overview: Prepare and share a detailed presentation on the API service, including its purpose, customer use cases, and problem-solving capabilities. (Subhajit)
• Type Spec Review: Review the type spec and SDK artifacts created for the project sustainability calculator and provide feedback. (Jeffrey)
• API Design Guidelines: Revisit the API definitions to ensure they adhere to Azure Rest API guidelines and make necessary modifications. (Shruti, Subhajit)
• Type Spec Office Hours: Attend Type Spec office hours to clarify any doubts and ensure the API design follows Azure guidelines. (Shruti)
• Data Plane Type Spec: Merge the data plane type specs into the main branch and ensure validation checks are performed. (Shruti)
• Type Spec Library Usage: Use the appropriate Azure Type Spec libraries to define the API and ensure compliance with Azure guidelines. (Shruti)
• Configuration Data APIs: Review and possibly modify the configuration data APIs to align with Azure's standard list operations. (Shruti)

[azure-sdk]

New API Review meeting has been requested.

Service Name: Project Sustainability Calculator - Project Sustainability Calculator
Review Created By: Shruti Wasnik
Review Date: 03/27/2025 08:00 AM PT
Release Plan: 1532
PR:
Hero Scenarios Link: Not Provided
Core Concepts Doc Link: Not Provided

Description: Adding a PR raised against the private repo

https://github.com/Azure/azure-rest-api-specs-pr/pull/20743/

Detailed meeting information and documents provided can be accessed here
For more information that will help prepare you for this review, the requirements, and office hours, visit the documentation here

[azure-sdk]

Meeting updated by Shruti Wasnik

Service Name: Project Sustainability Calculator - Project Sustainability Calculator
Review Created By: Shruti Wasnik
Review Date: 03/27/2025 08:00 AM PT
Release Plan: 1532
PR: #33012
Hero Scenarios Link: Not Provided
Core Concepts Doc Link: Not Provided

Description: Adding a PR raised against the private repo

https://github.com/Azure/azure-rest-api-specs-pr/pull/20743/

Detailed meeting information and documents provided can be accessed here
For more information that will help prepare you for this review, the requirements, and office hours, visit the documentation here