Ariadne Conill’s Post

View profile for Ariadne Conill, graphic

Container security and shenanigans at Edera

If there was anything I could teach developers and devops practitioners it is that memory is *never* free. So many times have I encountered programs which wasted dozens of GB of RAM which, with a little bit of effort to use appropriate primitives (such as using an actual filesystem as a backing store rather than shoving it all in an in-memory FS) could be highly memory efficient. Data structures also matter, for example a flattened graph contains the same information as an unflattened one, but in a fraction of the amount of nodes, and also can be iterated more quickly in many cases. But flattened graphs are also effectively immutable, so their appropriateness is very dependent on the application in question.

View profile for Fernando Villalba, graphic

Principal Engineer @ Civo

Engineer 1: “The (java) application is leaking memory and crashing every few days, we need to fix that” Engineer 2: “Don’t worry about memory, it’s cheap, we can always buy more” This was a real exchange of two developers in a place I worked at. The app in question always ballooned in memory usage and got killed by OOM every few days, causing downtime. It never got fixed, engineers and management kept pushing features instead. This is one reason why it’s important to set Service Level Objectives (SLOs), if you trespass the limits, you have to fix what’s causing them, you can’t just push for new features. In other words, SLOs can help give you time to address technical debt.

Mohammed Al Sahaf

Samsung Pay Technical Product Manager && (Caddy Server Dev || Software Engineer || CS Student) && FinTech && Payment Gateway && Merchant Acquiring / Digital Payments

6mo

I believe it's taught from the top. I had a Java 2 professor who said on multiply occasions "if you need more memory for speed, use more memory; memory is cheap". Students internalize that through their career unless it's broken by experience.

Like
Reply
Dennis Camera

I re-engineer digital systems.

6mo

It's not limited to memory. I've overheard similar discussions of developers on e.g. dependencies or the complexity of DB queries. it's the sys admin being too complicated, because they don't want to install every dependency which exists on this planet on the server, or the DB server being too slow, it's everything but never the developer.

See more comments

To view or add a comment, sign in

Explore topics