Problems of huge enterprises such as Google, may not be the same as problems of another Company. At the end of the day, we are engineers and our job is to find the right solution for a given problem. Solutions that work at Google aren't necessarily the best solutions for a startup. So, IMO whether or not you use a secrets management server should depend on the requirements of your specific project
I personally have trouble believing Gregory's claims that a large number of projects use .env files in Production deployments. Like Gregory, I do not have data to back up my beliefs either; anecdotally, I've been working with production systems for almost 9 years now, worked with a variety of stacks and deployment environments all the way from index.php on Apache on a 5$ DO VPS to many Node/Go microservices on a massive K8s cluster. Save for a few junior devs erroneously committing .env files into the source repo, I don't remember anyone ever using dotenv for setting environment variables in Production. That said, I don't doubt that there is probably someone out there thinking using .env files in a public-facing system is an okay thing to do (in a very small number of cases, it might even be okay); IMO this says more about someone's lack of knowledge on the matter than the merits of a system. .env files are supposed to represent Environment Variables, on a production system these are supposed to come from the OS/Environment.
A big portion of Mahmoud's post is just arguing the point about files... While I agree that files in and of themselves aren't a problem, the post fails to even acknowledge the supposed problems proposed by Greg in his post. I agree with other commenters that a blog post should be more about your content rather than just arguing against someone else's.
Lastly, both authors (Mahmoud and Gregory) come off really defensive and somewhat arrogant. A little humility goes a long way, fellas; you don't have to be right every time, and even if you are right it doesn't hurt to see things from the other person's perspective.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Here's my $0.02 on the whole conversation.
Problems of huge enterprises such as Google, may not be the same as problems of another Company. At the end of the day, we are engineers and our job is to find the right solution for a given problem. Solutions that work at Google aren't necessarily the best solutions for a startup. So, IMO whether or not you use a secrets management server should depend on the requirements of your specific project
I personally have trouble believing Gregory's claims that a large number of projects use
.envfiles in Production deployments. Like Gregory, I do not have data to back up my beliefs either; anecdotally, I've been working with production systems for almost 9 years now, worked with a variety of stacks and deployment environments all the way fromindex.phpon Apache on a 5$ DO VPS to many Node/Go microservices on a massive K8s cluster. Save for a few junior devs erroneously committing.envfiles into the source repo, I don't remember anyone ever usingdotenvfor setting environment variables in Production. That said, I don't doubt that there is probably someone out there thinking using.envfiles in a public-facing system is an okay thing to do (in a very small number of cases, it might even be okay); IMO this says more about someone's lack of knowledge on the matter than the merits of a system..envfiles are supposed to represent Environment Variables, on a production system these are supposed to come from the OS/Environment.A big portion of Mahmoud's post is just arguing the point about files... While I agree that files in and of themselves aren't a problem, the post fails to even acknowledge the supposed problems proposed by Greg in his post. I agree with other commenters that a blog post should be more about your content rather than just arguing against someone else's.
Lastly, both authors (Mahmoud and Gregory) come off really defensive and somewhat arrogant. A little humility goes a long way, fellas; you don't have to be right every time, and even if you are right it doesn't hurt to see things from the other person's perspective.