undefined | Better HN

0 pointspaulgb3y ago0 comments

> but should work the same at the infrastructure layer in a year

It's been my experience. For example, I've had periodic data fetching jobs last for years without giving them any thought. In some cases I've gone back years later and found them still chugging away, obediently putting data where I told them to years earlier. The one exception I can think of is when Lambda EOL'd Python 2.7, but that happened about 12 years after Python 3's initial release.

I've found the same to be true of web services. I have one that's been running continuously for 5+ years that I actually forgot about until just now.

> wheeze

Why?

0 comments

presentation3y ago

Agreed, my company focuses on writing business logic that actually provides value to our customers, spends roughly 0 time configuring web infrastructure, and everything just works, our cloud costs are dirt cheap (especially when compared to cost of labor), the performance is better than if we had used a traditional server since code is being run on servers very near our users rather than a fixed location, and we save time, stress and money by not needing to hire cynical, behind the times sysadmins like deckard1.

Maybe that wouldn’t be the case if my company wasn’t a B2B SaaS that isn’t constrained by being the scaling concerns of a mass market consumer web app (specifically one that couldn’t scale via smart caching policies, which honestly is a minority of use cases), but for our use case it makes plenty of sense.

If you’re worried about cost overruns from auto scaling, you just set a billing limit and deal with it when you get close. Anyway the code we push to serverless is literally just the business logic we would have written anyway so there’s virtually no platform lock-in. And honestly my serverless costs are so cheap that it’ll be a long while before we bother touching them.

j / k navigate · click thread line to collapse