Me: Are you writing data to the disk?
Them: No
Me: Are you sure?
Them: Maybe a little
Me: The disk on that machine is full
Them: Actually I'm writing gigabytes of duplicated data to a random location, use some of it and delete none of it
Me:
Them:

Makes you wanna punch a dev.

That's not a dev.
That's a waste.

@Root Yup, in general devs that can't look outside of their little puddle and consider the infrastructure around them tend to be a waste.

The only devs I've found that are conscientious and consider efficiency are either well-known open source devs, or devs who learned C.

Devops tendencies help too.

@waitwhat your nickname also adds to the story 😂👍🏼

@jthm never a coincidence 🙃

Docker really helps with this. Allows you to keep better tabs on how much data the container is writing and to where.

Unless of course they write tons inside the container, to the ephemeral disk so to say. If so then fuck them, send them to a docker 101 tutorial 😀

@Froot you guessed right. It was the latter. 🤦‍♂️

@waitwhat fuck!

@waitwhat But just reroll all the containers. Call it a scheduled something-something. If their data is gone then... oh sry, go learn how docker works! 😀

Another cool thing to check is to look at their image histories to see if they copied private keys in there at some point. Easy enough mistake to make if you don't know how docker works and that it remembers everything in layers

@Froot he was also reluctant to assign resource requests and limits to containers "because it's complicated".

@waitwhat isn't that the ops side of it? I might be wrong but as I understand it, a dev throws an image "over the fence" to ops and ops just runs it "somewhere" with all the needed ports and env variables mapped. The dev side only has to worry about the image's internals (the app) being fine and the ops has to only worry about deploying it. Along with resource limits, scaling, redundacy and such

@Froot in general you're right, but I spent a lot for time as devops trying to educate devs to consider their surrounding services, underlying infrastructure and what happens when you write gigabytes of data to the disk "just because". Devs who only thinks about their code will have a hard time during integration and deployment. Mostly because I'll set their desk on fire.

@waitwhat Ah, makes sense