<p>Imagine I am developing an application microservices based. They will be deployed to kubernetes with Helm Package Manager. Some microservices ends having pretty similar YAML files configuration. Some others might be different in terms of YAML configuration. What is the best practice for this? I have a few options:</p>

<ol>
<li>Use a generic chart and pass different configuration using values.env.yaml for each microservice and then deploy this with a different release name. </li>
<li>Create a chart for every single microservice no matter of they are similar in terms of configuration?</li>
</ol>

Hugo Marcelo Del Negro
<p>This is an opinion question, so I'll answer with an opinion.</p>

<ol>
<li><p>Upside: You would have to change just a few values in your values.yaml depending on the microservice and it would be easier to maintain your values.yml. Your Helm charts repo may not grow as fast.</p>

<p>Downside: It will be harder to create you <code>_helpers.tpl</code> file for example. That file will grow rapidly and it could get confusing for people creating microservices understand it.</p></li>
<li><p>Upside: Separation of your microservice as you scale to hundreds. Developers can work only on their microservice deployment.</p>

<p>Downside: File spread, too many files everywhere, and your Helm charts repo can grow rapidly. Also, a risk of large code duplication.</p></li>
</ol>

<p>The more general practice is number 2 for the official Helm charts but then again every chart is for a very different application.</p>
