A Freelance DevOps doing container stuff and automating unhealthy amounts of software.
Need something automated or containerized? Feel free to hit me up :)
To be honest, it depends. For small teams maybe you group by cluster, bigger teams in a microservice architecture maybe group by namespace.
In the last few projects I was part in, I noticed that it mostly goes the way of "namespace per team" until the restrictions and waiting times are so annoying that teams get their own clusters.
Locking down teams to their own namespace goes right until they want to deploy infrastructure things like s3 storages, databases and other things of the like themselves. Then it doesn't work as great anymore and ops teams as an external dependency slow things down too much.
Very valid reasons Raphael! Do you think we could add freedom to inject infra-level chaos (disk, node, network - typical experiments with blast radius enough to "impact" other dev groups on different namespaces) to that list, considering chaos is increasingly appearing in a dev's checklist today as much it continues to be an SRE pursuit?
Thank you Raphael. It appears that teams or individuals manage themselves within a namespace while they are small or during early dev stages.. mostly stateless applications.
A Freelance DevOps doing container stuff and automating unhealthy amounts of software.
Need something automated or containerized? Feel free to hit me up :)
I am inclined to agree. For small teams it probably has no instantly apparent value as compared to having/building more features.
I haven't seen much chaos engineering done as of yet, but I do think it can be a vital component in SRE and training.
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.
To be honest, it depends. For small teams maybe you group by cluster, bigger teams in a microservice architecture maybe group by namespace.
In the last few projects I was part in, I noticed that it mostly goes the way of "namespace per team" until the restrictions and waiting times are so annoying that teams get their own clusters.
Locking down teams to their own namespace goes right until they want to deploy infrastructure things like s3 storages, databases and other things of the like themselves. Then it doesn't work as great anymore and ops teams as an external dependency slow things down too much.
Very valid reasons Raphael! Do you think we could add
freedom to inject infra-level chaos(disk, node, network - typical experiments with blast radius enough to "impact" other dev groups on different namespaces) to that list, considering chaos is increasingly appearing in a dev's checklist today as much it continues to be an SRE pursuit?Thank you Raphael. It appears that teams or individuals manage themselves within a namespace while they are small or during early dev stages.. mostly stateless applications.
I am inclined to agree. For small teams it probably has no instantly apparent value as compared to having/building more features.
I haven't seen much chaos engineering done as of yet, but I do think it can be a vital component in SRE and training.