Working on various ADR, cleaning up some stuff

This commit is contained in:
2025-04-03 13:40:46 -04:00
parent 79213ba8d7
commit e6384da57e
17 changed files with 1382 additions and 28 deletions

View File

@@ -2,7 +2,7 @@
## Status
Draft
Proposal
## Context
@@ -31,30 +31,10 @@ This ADR will outline the approach taken to go from a LAMP project to be standal
## Decision
# Option 1 : Score spec
To simplify onboarding of existing projects, we decided to integrate with Score Spec for the following reasons :
# Custom Rust DSL
- It is a CNCF project, which helps a lot with adoption and community building
- It already supports important targets for us including docker-compose and k8s
- It provides a way to define the application's infrastructure at the correct level of abstraction for us to deploy it anywhere -- that is the goal of the score-spec project
- Once we evolve, we can simply have a score compatible provider that allows any project with a score spec to be deployed on the harmony stack
- Score was built with enterprise use-cases in mind : Humanitec platform engineering customers
## Consequences
### Positive
- Score Community is growing, using harmony will be very easy for them
### Negative
- Score is not that big yet, and mostly used by Humanitec's clients (I guess), which is a hard to penetrate environment
# Option 2 : Custom Rust DSL
We decided to develop a rust based DSL. Even though this means people will be afraid of "Rust", we believe the numerous advantages are worth the risk.
We decided to develop a rust based DSL. Even though this means people might be "afraid of Rust", we believe the numerous advantages are worth the risk.
The main selection criterias are :
@@ -76,3 +56,25 @@ The main selection criterias are :
- Lack of an existing community and ecosystem, which could slow down adoption.
- Increased maintenance overhead as the DSL needs to be updated and supported internally.
## Alternatives considered
### Score spec
We considered integrating with the score-spec project : https://github.com/score-spec/spec
The idea was to benefit from an existing community and ecosystem. The motivations to consider score were the following :
- It is a CNCF project, which helps a lot with adoption and community building
- It already supports important targets for us including docker-compose and k8s
- It provides a way to define the application's infrastructure at the correct level of abstraction for us to deploy it anywhere -- that is the goal of the score-spec project
- Once we evolve, we can simply have a score compatible provider that allows any project with a score spec to be deployed on the harmony stack
- Score was built with enterprise use-cases in mind : Humanitec platform engineering customers
Positive Consequences
- Score Community is growing, using harmony will be very easy for them
Negative Consequences
- Score is not that big yet, and mostly used by Humanitec's clients (I guess), which is a hard to penetrate environment