Feature Request: Recommendation/guidance on developer experience

[alecor191]

Is your feature request related to a problem? Please describe.
Scenario: Developer works on a microservice M locally. This microservice has dependencies to other microservices D1..Dn. And D1..Dn have dependencies to other microservices etc. In total there are 300+ microservices running in the cluster.

The developer would like to debug her microservice, tweak the code, test out the changes quickly etc. (IOW have a productive inner loop development experience). Let's also say that for certain scenarios mocking all dependencies is not convenient.

What are recommended ways to develop a Container App in the above scenario? How do customers of Container Apps productively develop/debug/test their services (in non-trivially small environments)?

Describe the solution you'd like.
What we have today is the ability to run/debug/test a microservice locally with all dependencies, by allowing it to connect to other microservices hosted in an AKS cluster (using kubectl port-forward). This is not possible in Container Apps, as no access to K8S API is available.

Describe alternatives you've considered.
Options we tried:

• Using Dapr locally, i.e. have a local K8S cluster, deploy Dapr, deploy services to the local cluster...however, this is too cumbersome for a large cluster with many microservices.
• Mocking: essentially remove dependencies from other microservices during local development. This works fine for certain scenarios, but not so great for work related to dependency interactions.
• Deploy the container app to Azure Container Apps after "every" change. This was very unproductive as updating a Container App can take >1min.

Additional context.
None.

[andrewweston]

👍

[BigMorty]

The team would like to see this improved as well, it is on our list to investigate. Sorry I can't give you a timeframe at this time.

[marcindulak]

Developer (local and operational) experience has been mentioned several times, e.g. #193 #182 #103. Maybe it's worth creating a meta-issue to manage the feedback and provide an overview, and pin it to the repo?

[rickbatka]

If a full-blown local development environment isn't on the near-term horizon, perhaps the team could enable Telepresence or MS's "Bridge to Kubernetes" to replace a pod in the underlying k8s cluster with a local container under development?

This workflow has worked great for me in the past with vanilla k8s clusters where local setup / mocking is cumbersome or difficult for some reason.

Container Apps is a great solution for running simplified multi-container apps in production, but without a development story it's hard to recommend.