Cut costs down to 90% by going serverless and run everything on lambdas? Nothing keeps humming if it's not being used
Cutting down AWS cost by $150k per year simply by shutting things off
61–70 of 194 posts
Re: Cutting down AWS cost by $150k per year simply by shutting things off
#62It is unfortunate that cost management isn’t something most engineers keep an eye out for on a regular basis. Spinning up unnecessary resources, not cleaning up resources properly once not needed, writing inefficient code, etc. all quickly adds up to hundreds of thousands of dollars per month in big companies. I once found a “test” db cluster from an engineer who hadn’t worked in the company for 3 years. We were payi…
I found that the problem happens mostly when companies 1. Don't ask developers how much something costs, engineers love optimisation, getting as much as possible out of a system for cheap is great fun. 2. Lock down the UI, so devs can't even find out how much things cost. That's my current situation. Why block the billing dashboard, then expose it through billing dashboard tools that are not really any better, and in…
It's easy not to grant engineers access to the billing dashboard.
It's easy to put everything in the same aws account.
Inside Amazon, we're supposed to set up new aws accounts for every service and realm, so we know how much X service's beta environment is costing
Re: Cutting down AWS cost by $150k per year simply by shutting things off
#63It is unfortunate that cost management isn’t something most engineers keep an eye out for on a regular basis. Spinning up unnecessary resources, not cleaning up resources properly once not needed, writing inefficient code, etc. all quickly adds up to hundreds of thousands of dollars per month in big companies. I once found a “test” db cluster from an engineer who hadn’t worked in the company for 3 years. We were payi…
I think "engineer" isn't really the correct word to use for the artisans who build much of the tooling used by most companies. An engineer either wears a striped hat and drives a train, or, went to a credentialed school and passed a bunch of test and is allowed to sign documents that state "this thing, if built this way, won't collapse and kill people." It is expected that an engineer can predict with reasonable accu…
I’m calling BS on this. If this were true, we’d still be a ground species. Engineering has been and will always be about creating something electrical, mechanical, computerized, or all, that solves a problem. Understood or not. Engineers are not oracles. They can not predict whether a tower built in Italy will eventually begin to lean due to erosion. They can not predict that a steel beam rated for 300T of force would break at 180T. They can not predict a rogue developer removing a package from underneath their dependency tree.
You can give estimates all you want but you are still guessing.
If engineers were as you say they are, we would never have delays, we would never have traffic jams, we would never have crap software, we would never have flight.
Re: Cutting down AWS cost by $150k per year simply by shutting things off
#64Cutting down AWS cost by 90% by simply moving to hetzner.
Also, I've seen a lot of concern over blocked IPs, especially for lower-cost hosts. Is that an issue with Hetzner?
Re: Cutting down AWS cost by $150k per year simply by shutting things off
#65Re: Cutting down AWS cost by $150k per year simply by shutting things off
#66Earlier quoted context omitted.
The huge achievement of Amazon was designing a system and selling it to people where developers no longer had to pre-approve spending. Previously developers were hamstrung by purchase order requirements; it could take weeks to authorize a single computer. Now the pendulum has swung in the direction. Developers can spend unlimited amounts of company money without realizing, billed in arrears. And in many cases this is…
That's the whole ploy with Agile, isn't it? In the classical SDLC or Waterfall paradigm, everything was pre-approved and signed off, not just the cost or billing but even the software design itself. Any change in the process and the designers had to raise a change request. Agile changed all of that and now we know how bad things can get with that.
It basically helps keep things clean with decomposition and doesn't necessarily hamstring older devs as much while giving a good guideline for younger devs to work in. All things considered, it seems like not a bad system to me, and the team customizing the process to their own needs is nice as well.
There's a million ways for it to go wrong, but it's not too terrible on the whole I thinks. <3 :"))))
Re: Cutting down AWS cost by $150k per year simply by shutting things off
#67Cut costs down to 90% by going serverless and run everything on lambdas? Nothing keeps humming if it's not being used
We routinely see 10x savings when switching from RDS or Aurora. Especially if you start adding dev environments.
Re: Cutting down AWS cost by $150k per year simply by shutting things off
#68One small issue I have as a developer who can spin up just about anything on AWS is this: I have zero insight into the costs. Yes, my company could turn that on for me but it's rare that they do so it's nearly impossible to know if I did something that costs a lot of money (relatively or in general) without access to the cost explorer/billing dashboard. And before "well can look up what a t2.2xlarge costs and calcula…
billing transparency is very important. in the past, i had a case like this: dev accidentally enable backup policy for test database with no retention. finops think that db backup is important and ignore it. dev has no access to billing and have no idea what's creeping up the bill
I've asked, off-hand, a couple times for billing access but nothing has come of it. I don't want to seem pushy but also it feels like data I need to perform my job to the best of my ability (especially at a small company). I don't think it comes from a place of "We don't want to give Josh access" or secrecy as much as it not being a priority but I need to bring it up again.
Re: Cutting down AWS cost by $150k per year simply by shutting things off
#69> You go home. So you shut things down. Sorry for the rant, but this is usually wrong. The amount of people that just keeps their computer on is noticeable. And when I ask it's usually "just to avoid having to wait" or "I've always done that". I personally always hibernate my computer. When I turn it off it takes more time, but I'm already on the other side of the building so I don't care. When I turn it on it takes…
- I have a plex server running on it
- I can remote into it from my phone, this comes in handy a lot of the time.
- I can remote into it when traveling through my Fire stick using parsec, which means I don't have to carry a laptop with me everywhere I go ( I also setup my phone so I can use it as keyboard/mouse when I do this).
Regarding energy costs, it's negligible for the benefits it gives me
Re: Cutting down AWS cost by $150k per year simply by shutting things off
#70Looking forward to the kubernetes one - Most kubernetes clusters are designed for high availability, not necessarily for being able to quickly spin up/down and there’s often a lot of hidden complexity there (at least on aws).
hint: it's going to use the same platform. allow us having the ability to inject certain manifest into any eks cluster within the org.
- dependent services not coming up in the order you expect/want
- issues draining nodes due to crashlooping/erroring pods (can also be caused by dependent upstream services going down in wrong order)
- Persistent Volume retention/synchronization
- IAC not cooperating
- Configuration annoyances with deployments’ availability/replica settings
- Thundering herd types of problems
I can think of tons of things that can make this extraordinarily difficult. I’ve had many managers over the years pitch this idea of “rapidly deployable/destructable EKS clusters” and the projects always get killed due to the complexity around this. IMHO they simply aren’t really designed for this type of thing, however, I could be misunderstanding exactly what you’re trying to do.