Hi Jodie, nice points I believe the the resistance comes from lack of transparency within the organisation.
Im sure your DevOps team also deploys the infrastructure in an automated fashion hence have the config as code stored in a repo.
If you had visilibility to the repository better yet their story boards or wikis etc someone from the other silo could look into.
Sometimes a Dev who is enthusiastic to talk servers are looked down as they are speaking out of their turn or sth. I love it when devs take full ownership and devops works better if everyone works for it.
I love the fact that all my changes can be trailed via either code history or pipeline logs, or last resort cloud peoviders logs. Takes away the lets blame the infra/environment element out.
Communication is key but I also wonder why application's infrastructure is maintained and provosioned by one team but configuration is provided by another? Seems like a bad practice to begin with.
How is this real DevOps besides from a name change?
How is this real DevOps besides from a name change?
It wasn't, which was only one part of the problem. There was an issue with sysadmins/ops/SRE getting stretched thin, with DevOps itself splintered and not at all prioritized by the organization. I ended up filling part of that gap (mostly CI/CD), but was still under-resourced.
A lot of things could have been solved via more transparency, and by others sharing ownership. Eg. deconstructing responsibility silos; this entire issue could have been resolved sooner if the first developer had access to the right logs. Instead they had arbitrary logs and 1/4 of the picture. So it can be summarized as a lack/poor implementation of (real) DevOps.
I could have titled this "Why We Need Dedicated DevOps," haha.
I currently work in a company where they are practicing something called "embedded" DevOps where each product team has a dedicated DevOps resource (Im one of those) and there is also a central DevOps/ProdOps team that handles practice level stuff and help out the embbeded engineers as needed.
It has been working pretty well so far.
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.
Hi Jodie, nice points I believe the the resistance comes from lack of transparency within the organisation.
Im sure your DevOps team also deploys the infrastructure in an automated fashion hence have the config as code stored in a repo.
If you had visilibility to the repository better yet their story boards or wikis etc someone from the other silo could look into.
Sometimes a Dev who is enthusiastic to talk servers are looked down as they are speaking out of their turn or sth. I love it when devs take full ownership and devops works better if everyone works for it.
I love the fact that all my changes can be trailed via either code history or pipeline logs, or last resort cloud peoviders logs. Takes away the lets blame the infra/environment element out.
Communication is key but I also wonder why application's infrastructure is maintained and provosioned by one team but configuration is provided by another? Seems like a bad practice to begin with.
How is this real DevOps besides from a name change?
It wasn't, which was only one part of the problem. There was an issue with sysadmins/ops/SRE getting stretched thin, with DevOps itself splintered and not at all prioritized by the organization. I ended up filling part of that gap (mostly CI/CD), but was still under-resourced.
A lot of things could have been solved via more transparency, and by others sharing ownership. Eg. deconstructing responsibility silos; this entire issue could have been resolved sooner if the first developer had access to the right logs. Instead they had arbitrary logs and 1/4 of the picture. So it can be summarized as a lack/poor implementation of (real) DevOps.
I could have titled this "Why We Need Dedicated DevOps," haha.
I currently work in a company where they are practicing something called "embedded" DevOps where each product team has a dedicated DevOps resource (Im one of those) and there is also a central DevOps/ProdOps team that handles practice level stuff and help out the embbeded engineers as needed.
It has been working pretty well so far.