Jean-Gabriel Gill-Couture
fe42ebd347
Add an Architecture Decision Record (ADR) outlining the approach to integrate LAMP projects into Harmony's automated delivery pipeline using either Score Spec or a custom Rust DSL. A decision will have to be made between the two in the short term to decide which we will implement first. The ADR details the benefits and consequences of each option, focusing on providing a seamless transition for developers while leveraging Harmony's enterprise-grade features.
4.1 KiB
Architecture Decision Record: Interactive project setup for automated delivery pipeline of various codebases
Status
Draft
Context
Many categories of developers, of which we will focus on LAMP (Linux Apache, MySQL, PHP) developers at first, are underserved by modern delivery tools.
Most of these projects are developed with a small team, small budget, but still are mission critical to their users.
We believe that Harmony, with its end-to-end infrastructure orchestration approach, enables relatively easy integration for this category of projects in a modern delivery pipeline that is opinionated enough that the development team is not overwhelmed by choices, but also flexible enough to allow them to deploy their application according to their habits. This inclues local development, managed dedicated servers, virtualized environments, manual dashboards like CPanel, cloud providers, etc.
To enable this, we need to provide an easy way for developers to step on to the harmony pipeline without disrupting their workflow.
This ADR will outline the approach taken to go from a LAMP project to be standalone, to a LAMP project using harmony that can benefit from all the enterprise grade features of our opinionated delivery pipeline including :
- Automated environment provisionning (local, staging, uat, prod)
- Infrastructure optimized for the delivery stage
- Production with automated backups
- Automated domain names for early stages, configured domain name for production
- SSL certificates
- Secret management
- SSO integration
- IDP, IDS security
- Monitoring, logging
- Artifact registry
- Automated deployment and rollback
- Dependency management (databases, configuration, scripts)
Decision
Option 1 : Score spec
To simplify onboarding of existing projects, we decided to integrate with Score Spec for the following reasons :
- 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.
The main selection criterias are :
- Robustness : the application/infrastructure definition should not be fragile to typos or versioning. Rusts robust dependency management (cargo) and type safety are best in class for robustness
- Flexibility : Writing the definition in a standard programming language empowers users to easily leverage the internals of harmony to adapt the code to their needs.
- Extensibility : Once again, a standard programming language enables easily importing a configuration, or multiple configurations, create reusable bits, and build upon the different components to really take control over a complex multi-project deployment without going crazy because of a typo in a yaml definition that changed 4 years ago
Consequences
Positive
- Complete control over the syntax and semantics of the DSL, tailored specifically to our needs.
- Potential for better performance optimizations as we can implement exactly what is required without additional abstractions.
Negative
- Higher initial development cost due to building a new language from scratch.
- Steeper learning curve for developers who need to use the DSL.
- 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.