Helm Charts Microservices

2
votes

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:

  1. Use a generic chart and pass different configuration using values.env.yaml for each microservice and then deploy this with a different release name.
  2. Create a chart for every single microservice no matter of they are similar in terms of configuration?
2
kubernetesmicroserviceskubernetes-helm

2 Answers

4
votes

This is an opinion question, so I'll answer with an opinion.

  1. 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.

    Downside: It will be harder to create you _helpers.tpl file for example. That file will grow rapidly and it could get confusing for people creating microservices understand it.

  2. Upside: Separation of your microservice as you scale to hundreds. Developers can work only on their microservice deployment.

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

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

1
votes

Like @Rico mentioned, this is an opinion question. Here is my opinion:

I think it is a good idea to start with one Chart that fits all. But when you have to add very specific stuff for only a few services with special requirements, you should create another Chart. This idea is pretty similar to Monolith first, when it comes to Microservices.

In my company we have one Chart for ~30 Services. They have very similar needs, therefore the template files aren't too complex and the _helpers file has only around 50 lines. We are very happy with this solution, because you only need a few lines of values.yaml to prepare your service for operation.