<p>I'm fairly new to Kubernetes and only got started with an example project to learn everything. I'm currently running one .NET microservice which needs a MongoDB as a database. The microservice is packed into a Docker Image and I've created a single Helm chart to properly deploy my microservice and the required MongoDB.</p>
<p>Now I've thought about versioning and discovered one big problem with this approach: I can't just install multiple versions of that helm chart to support running multiple versions of the same microservice because that way each microservice gets its own database which is obviously not what I want.</p>
<p>Does this mean I have to create two helm charts for my microservice? So one <code>api</code> chart containing my .NET service and one <code>db</code> chart containing the MongoDB? That way I can deploy the MongoDB once and have multiple versions of my .NET service pointing to this single instance. However, that way I don't have a single Helm chart per microservice but multiple ones, which increases deployment overhead I'm guessing.</p>
<p>Is this how it's been done? Or is there something I'm missing? All clues that point me in the right direction are very welcome!</p>

<p>I would recommend one chart per service.  The place where helm dependencies work well is where you have a service that embeds/hides specific single other parts. And as @christopher said if your .NET service and MongoDB have different lifecycles, they shouldn't be packaged together in the same helm chart.</p>
<p>The most basic way to use Helm is by having a single chart that holds a single application. The single chart will contain all the resources needed by your application such as deployments, services etc.</p>
<p><a href="https://codefresh.io/docs/docs/new-helm/helm-best-practices/#chart-versions-and-appversions" rel="nofollow noreferrer">Chart versions and appVersions</a></p>
<blockquote>
<p>The version of the chart itself (version field in Chart.yaml).   The
version of the application contained in the chart (appVersion field in
Chart.yaml).   These are unrelated and can be bumped up in any manner
that you see fit. You can sync them together or have them increase
independently. There is no right or wrong practice here as long as you
stick into one.</p>
</blockquote>
<p>An important point here is that you need to adopt a policy in your team on what a “chart change” means.</p>
<p>Helm does not enforce chart version changes. You can deploy a different chart with the same version as the previous one. So, if this is something that you want to do, you need to make sure that all teams are on the same page for versioning practices.</p>
<p>On the plus side, this workflow allows you to individually version charts and applications and is very flexible for companies with teams that manage separately the charts from the application source code.</p>
<p><a href="https://codefresh.io/docs/docs/new-helm/helm-best-practices/#umbrella-charts" rel="nofollow noreferrer">Umbrella charts</a></p>
<p>However, you can also create a chart with dependencies to other charts called umbrella chart.</p>
<blockquote>
<p>They are completely external using the <code>requirements.yaml</code>  file. Using this strategy is optional and can
work well in several organizations. Again, there is no definitive
answer on right and wrong here, it depends on your team process.</p>
</blockquote>
<p>Take a look: <a href="https://itnext.io/helm-3-umbrella-charts-standalone-chart-image-tags-an-alternative-approach-78a218d74e2d" rel="nofollow noreferrer">umrella-charts-example</a>.</p>
<blockquote>
<p>In other words, a collection of software elements that each have their
own individual charts but, for whatever reason (e.g. design choices,
ease of deployability, versioning complexities), must be installed or
upgraded as a since atomic unit</p>
<p>An umbrella chart references the version of the Helm chart itself and
not the underlying version of the container image. This means that any
change to the image version will result in chart modifications to the
individual component charts.</p>
</blockquote>
<p><strong>What to take into account when deciding on an option</strong></p>
<p>There are two dimensions to take into account:</p>
<ul>
<li><strong>Team structure</strong>: You have to ask yourself questions like: do you have small autonomous teams that are responsible for each service? Do you have developers who have
knowledge of DevOps?</li>
<li><strong>Dependencies and reproducibility:</strong> You have to ask yourself questions like: How different are the dependencies for each service? What is the risk that a change to one
service will break another? How do you reproduce the conditions of a
specific development?</li>
</ul>
<p>Read more in useful article: <a href="https://insights.project-a.com/whats-the-best-way-to-manage-helm-charts-1cbf2614ec40" rel="nofollow noreferrer">helm-managing-microservices</a>.</p>
<p>Speaking about versioning of microservices for backward compatibility, see  <a href="https://stackoverflow.com/questions/33202053/product-versioning-microservices">Product Versioning Microservices</a>, in general  <a href="http://semver.org/" rel="nofollow noreferrer">Semantic Versioning</a>  is generaly adviced.</p>
<p>In the broader sense - there should be an agreed phase-out roadmap for major versions, that is communicated to API consumers (together with SLAs). This is why tracking who uses your APIs is important. Take a look on this useful <a href="https://walkingtreetech.medium.com/versioning-management-in-microservices-8221ec592499" rel="nofollow noreferrer">article about versioning management</a>.</p>
<p>See example tool for tracking microservice versions-  <a href="https://www.deployhub.com/microservice-version/" rel="nofollow noreferrer">DeployHub</a>.</p>
