Deployment story – WIP

[marcellanz]

I'd be great to have a simple and pragmatic deployment story right from the beginning.

• embracing serverless
  • having just an account for any of the Cloud Providers.
  • no local tools to be installed.
• support things like devcontainer.
• compile! and deploy with nearly nothing to be installed locally
  • perhaps pulling docker images to build it?
  • mg deploy --repository https://github.com/mungotinae/shoppingcart-example/ --auth [email protected]
  • such a repository might have a "manifest" how to deploy.
• kind of self deployment.

[sleipnir]

Yes, I believe that this is possible. The proposed manifest approach is similar to that experienced in the most recent cloudstate-cli.
I don't know if it would be interesting to create a new tool (mg as in your example), or to have cloudstate-cli provide this functionality. What do you think?
I would trade Deploy for Run as the correct term, after all in a pure serveless environment it doesn't make much sense to deploy (there is no server :D).
The tool would have to know how to build the container image (should we support OCI images?) From the source code passed in the URI, it would also have to be able to communicate with the kubernetes api to create the deployment.
Will we do this in GO or Elixir? What model / format of manifest do you have in mind?

[sleipnir]

I'd be great to have a simple and pragmatic deployment story right from the beginning.

* embracing serverless
  
  * having just an account for any of the Cloud Providers.
  * no local tools to be installed.

* support things like `devcontainer`.

* compile! and deploy with nearly nothing to be installed locally
  
  * perhaps pulling docker images to build it?
  * `mg deploy --repository https://github.com/mungotinae/shoppingcart-example/ --auth [email protected]`
  * such a repository might have a "manifest" how to deploy.

* kind of self deployment.

• embracing serverless
  I totally agree

• having just an account for any of the Cloud Providers.
  I think we just need access to the kubernetes api. Once the user is logged into your cluster, I think we can access it transparently. Camel-K is a good reference on how to do this type of integration with different providers https://camel.apache.org/camel-k/latest/installation/installation.html

• no local tools to be installed. And compile! and deploy with nearly nothing to be installed locally
  To generate images from the source code, I believe that the terms that depend on some tool like Docker, Buildah, Podman, or any other. For JVM-based languages, we could use the Google jib that does not need the docker daemon installed.

• perhaps pulling docker images to build it?
  Maybe it's a good alternative, we will have to do a POC. We can create some basic images to facilitate the construction of different languages with their respective build tools. Can we be so opinionated as to eliminate dependence on a Dockerfile?

• support things like devcontainer.
  Ok. Cool. But I am completely layman in devcontainer

[marcellanz]

I got work 🙀