Sorry about the crappy title, this is half-baked at best. We've been dancing around this when talking about some current tasks and future developments. Especially for the buildservice, I think we are mostly in agreement that we don't want users to think about "containers", "images", "k8s", "harbor" etc. But where do we draw the line? And what do we call the different concepts/components? This task is meant to be a conversation-starter.
Moving the brainstorming here for easy collab: https://docs.google.com/document/d/1sqo6YGRn9u-S7V0y9m07cYKA84vQlKa-7_F8p7eg80Y/edit
For inspiration, let's see how Heroku does it.
In Heroku, theres is the "process" concept. Processes correspond to well... mostly actual unix processes. These can be defined in the Procfile (the 'special' web process being inferred if the Procfile is absent). In terms of deployments, the unit is called a "Dyno" which they say are lightweight Linux containers, where 1 process = 1 dyno.
- heroku ps will give you the number of dynos that are executing
- heroku logs lets you view an aggregated list of log messages from all dynos across all process types
- Dynos can be scaled, including web dynos
- Users can exec into dynos
Etc.
The Dynos are managed by the Dyno Manager, which smells like k8s or some other orchestration engine. All of this is abstracted, as are builds, images, etc. Builds happen underneath deployments. Deployments are preceded by creating the app:
When you create an app, a git remote called heroku is also created and associated with your local git repository. Git remotes are versions of your repository that live on other servers. You deploy your app by pushing its code to that special Heroku-hosted remote associated with your app.