When designing a CI or a CD workflow, you must decide how users will specify service configuration values for the microservices deployed on Kubernetes and identify who these users are.
Assume you are building a self-service platform for microservice deployments; thus, developers are considered the users. We will avoid burdening DevOps engineers or SREs with that, which slows down the software development process, and causes problems due to inevitable miscommunication.
So, you need to provide an interface for your developers to specify the configuration values. Let’s skip the secrets for now. There are two ways of doing this:
They track the values in a yaml file stored in a Git repository.
They choose the values from a dropdown list on a web interface.
For the text file option, it could be a configuration file already used by the developers. You can make a ConfigMap and mount it as a file. However, the developers will need to learn how to maintain ConfigMaps. The other option is providing a Helm chart with the values.yaml file and teaching them to track their configurations in it. It takes an argument and a healthy team discussion to choose one. However, there’s a problem with the text file-based approach called "user input." User input needs to be validated, right? The intuitive answer would be yes, and maybe it is a good idea. But it would be best if you kept it simple. The validation logic should be simple, and everyone should know that. It should be okay to mistype a name; the deployment will fail, and the Kubernetes CD engine will redeploy everything with the correction on the next Git push event. People will learn to do this surprisingly fast and will like it as they will stay in their IDE instead of going to a webpage.
Back to the web interface approach. The other input method is a graphical interface, which is probably a web interface nowadays. And you need to populate the list of possible values from somewhere. The question is, from where? And that is an important one. You can have a text file tracked in Git that the developers own. Your CI/CD engine will read that file to build a graphical list for your developers, and they will click to choose. The clicks will not be tracked in Git history. However, platforms like GitHub will store those choices in workflow execution history anyway, so be careful with that argument. Some might say it’s a good idea as no validation is needed; they will select from a list. Yes, mostly. But someone still needs to add that to the text file. At that point, another idea will come up and be even uglier. Someone will suggest populating the list from an API whenever possible, whether it be a list of releases from another Git repository or a list of database backups. That sounds logical until you realize that the number of releases tends to grow, and the number of DB backups tends to grow much faster. At some point, you will need to implement logic in your CI/CD engine to drop old values or filter them out. Not to mention that it is the slowest option, and the developers will be annoyed.
After many observations, we concluded. And we are opinionated on this: developers don’t like switching tools, which is why Backstage was created, for example. They will happily configure their software using text files, which they have been doing for ages. They don’t need web interfaces to pick a release tag or specify a backup name; they can type that in the IDE. Talk to them, be honest about sharing the options, and share your experience with us in the comments.
Secrets are even easier. Never use a secret store with Kubernetes. It is not secure and slows down the SDLC. We promise that investing 15 minutes in checking out https://github.com/bitnami-labs/sealed-secrets is a great idea.
Conclusion
GitOps helps to Keep It Simple, Stupid (KISS).
Comments