Granularity of the API

[srini1978]

Creating a thread for the other discussion I heard in the call.

**Some discussion items I heard **

1. We do not want to build an API that is complex and takes into account all the complexities of a software architecture. The API need not be in the same granularity level of the software architecture.
2. The API should be simple enough such that it can be called "repeatedly" for each of the individual software boundary components of the architecture.
3. The third discussion thread on granularity is : do we need separate energy API, carbon intensity API and embodied emissions API?

[srini1978]

My inputs on granularity

The customer should just be able to give the software boundary environment specs, usage specs and duration of the workload in an easy format and all the internal parameters should be abstracted away . This is the customer facing API and should front end all internal APIs.

To solve the granularity problem for now, we can look at the requirements to be given by Amadeus and frame the input parameters of the API accordingly. e.g Memory utilization, duration, CPU utilization, CPU duration , network utilization in GB, network utilization duration , processor family , storage size provisioned in GB, Hard disk type (SSD/HDD). In case they provide laptop details then we can exclude this for now as we decided in the v1 Scope that end user devices will be out of scope