cmg-ws202425

Cloud-native Microservices mit Go - WS 2024/25

Green Compute Load Shifting (GCLS)

Functional Requirements

1. Consumers can create new computation jobs. A container image along with a set of environment variables defines the computation job.

2. Consumers can get the results of a compute job. The result consists of the state, the standard output produced by the job, and an estimate of the amount of CO2 equivalent that has been been emitted while executing the job.

3. Providers can offer computing capabilities and run assigned jobs

4. Jobs are scheduled to minimize runtime and carbon footprint

Quality Requirements - Functional Suitability

Functional Correctness

The error margin for estimating carbon emission shall be \frac{+}{-} 10\%

Functional Appropriateness

In each week, the system shall reduce the carbon emissions of running compute jobs by at least 50\% compared to running the jobs in the client region

Quality Requirements - Performance Efficiency

Time behavior

95\% of all backend requests that originate from a user must be handled in less than 50 ms

Capacity

The system must be able to handle up to 10000 jobs per day.

Resource utilization

• The CPU and Memory consumption of all jobs running on a worker must not exceed 50\% of the available resources of that worker.

• The overall cloud provider costs must not exceed the value of the obtained Google Cloud Education Credits

Quality Requirements - Compatibility

Interoperability

The system must support Docker container images that are available on the docker hub

Quality Requirements - Reliability

Availability

In each 24h timeframe, the request success rate must be at least 95\%

Fault tolerance

The system must not reject requests in case the carbon intensity provider is temporarily not available.

Quality Requirements - Security

Authenticity

All inter service communication must be authenticated and authorized (Zero Trust)

Confidentiality

• Compute Consumers and Compute Providers must ony be able to access job information assigned to them

Quality Requirements - Maintainability

Reusability

Cross cutting concerns shall be implemented consistently in all services

Testability

• The business code must be testable in isolation
• The unit test coverage of the business code must be at least 80\%

Quality Requirements - Flexibility

Replaceability

• The cloud provider must be replaceable without changing the business code
• The carbon intensity provider must be replaceable without redeploying more than one service

Boundary Conditions - Architecure

1. The predefined microservices architecture must be followed (see next slides)
2. All services/clients must be implemented using the Go Programming Language
3. Each microservice needs to adhere to the ports & adapters structure
4. All services need to be stateless
5. All synchronous communication shall be handled using REST APIs
6. APIs shall be idempotent, breaking changes shall be avoided
7. Each service shall be containerized

Boundary Conditions - Development

1. A single monorepo shall be used for all code https://gitty.informatik.hs-mannheim.de/steger/cmg-ws202425.git
2. All Infrastructure shall be defined as code (IaC) using terraform
3. All features must be implemented in short lived feature branches
4. The usage of 3rd party packages (other than from the Go standard library) must be approved
5. All PRs must be reviewed by at least one other team member before a feature branch can be merged to main
6. All tests must be passed before a feature branch can be merged to main

Boundary Conditions - Security

1. JWTs shall be used for all requests originating from a client
2. basic auth shall be used for all other communication
3. secrets must not be stored in the repository

Boundary Conditions - Deployment

1. The entrire system shall be deployed to the Google cloud platform. The gcp project id is cmg-ws202425.
2. The overall provider costs must not exceed the value of the obtained Google Cloud Education Credits
3. All services shall be deployed to a CaaS or PaaS offering in a single GCP cloud environment
4. Each service has its own CI/CD pipeline
5. Deployments are done independetly for each service with zero downtime (Rolling updates)

Boundary Conditions - Operations

1. All logs shall be written to standard output
2. Business, Application, and Infrastructure level metrics shall be collected by prometheus.
3. All requests shall be traced using jaeger
4. each service must provide health probes for readiness and liveness
5. each service must terminate upon receiving the SIGTERM signal within 2 seconds.