Live data from Hacker News

We reduced our server costs by moving away from AWS

levelup.gitconnected.com

71–80 of 355 posts

Re: We reduced our server costs by moving away from AWS

#71
post #59

Earlier quoted context omitted.

Yes. If you use and manage AWS resources as you would your own on-prem resources then you're not going to have a good time. As soon as you think you need EC2 instances you need to re-think your architecture. You're probably not using AWS most effectively.

What I don't understand is why anyone would spend, precious and expensive engineering resources on coding to a proprietary API owned by one of the largest companies on the planet to whom you are nothing. Ok so you save money on the monthly bill but what happens when Amazon decides they want to enter your market? What happens if they decide your service is too controversial and they kick you off? If you were deploying…

The alternatives are tremendously more expensive in both time and money (and I’m thinking engineer salaries etc. here, not just monthly service costs).

For most businesses the savings in money and time are worth the risks you pointed out here.

If those risks are too high for you (and fair enough if they are), you’ll pay one way or another to avoid them.

Re: We reduced our server costs by moving away from AWS

#72
post #59

They don't mention at all what services they were using (other than slight mention of S3) which makes it very hard to respond to this. If you are running everything on EC2 then you are going to have a bad time (especially if you aren't using reserved instances). AWS (IMHO) shines with the various services they provide (S3, Lambda, CloudFront, API Gateway, SQS< SES, to name a few). AWS is a game of trying to reduce yo…

Yes. If you use and manage AWS resources as you would your own on-prem resources then you're not going to have a good time. As soon as you think you need EC2 instances you need to re-think your architecture. You're probably not using AWS most effectively.

I think that statement about EC2 is a little too strong. You definitely shouldn't be managing individual EC2 instances in most cases, and you probably shouldn't be deploying directly to EC2. But if you're running EKS (Kubernetes) or ECS (non-k8s containers), then you're probably going to get more bang for your buck with EC2 nodes than Fargate nodes, especially if you have a large cluster.

Re: We reduced our server costs by moving away from AWS

#73

Earlier quoted context omitted.

In most businesses I've worked in: developer costs >> infrastructure costs An AWS large server is around $500/year, which is about 1-2 developer hours (with taxes, overhead, etc) at the cost scales last time I priced this out. That's crazy expensive in the absolute, but if it saves a couple of hours, it makes sense. PaaS providers cost even more. I've gone with those in the past, since it basically eliminated dev-ops…

1-2 developer hours?! Anyone looking to hire an ML guy for 250-500$/hr flat fee, hourly rate, no taxes, no healthcare, cancel any time... get in touch! For that money I'll gladly bark like a dog, walk on all fours and fetch your slippers.

[deleted]

Re: We reduced our server costs by moving away from AWS

#74

Earlier quoted context omitted.

> Yes, loooong time ago - to get your dedicated server might have taken a few hours to provision and the instant server access that AWS brought should not be discredited. At one point it took often days for a dedicated server to be set up. We also didn't have such nice provisioning tools. Now it just seems like cargo cult to use cloud providers as the only option. People just completely discount dedicated servers.

In most businesses I've worked in: developer costs >> infrastructure costs An AWS large server is around $500/year, which is about 1-2 developer hours (with taxes, overhead, etc) at the cost scales last time I priced this out. That's crazy expensive in the absolute, but if it saves a couple of hours, it makes sense. PaaS providers cost even more. I've gone with those in the past, since it basically eliminated dev-ops…

> In most businesses I've worked in: > >developer costs >> infrastructure costs

That's what we said at my first Kleiner company. All the time.

Pretty soon we had a $100k/mo server bill.

We were just webhosting. There was no need for any of it.

Re: We reduced our server costs by moving away from AWS

#75
They saved $800K on their AWS bill, but

    - may spend $250K on servers, replaced after 3 years becomes $83k/yr
    - may spend $120-250K on extra staff to maintain the infrastructure
    - may spend $15K for a cage in a DC
They still save $452K/yr overall (actual savings 1st year only $285K). It's still a savings for sure, but always keep TCO in mind.

The real fun comes later when you outgrow your cage and there's not enough space left in that DC, or they just have shitty service constantly knocking out your racks, and you have to consider splitting your infra between DCs (a huge rewrite) or moving DCs (a huge literal lift and shift). Have been part of both, it's... definitely a learning experience.

Re: We reduced our server costs by moving away from AWS

#76

Earlier quoted context omitted.

> Yes, loooong time ago - to get your dedicated server might have taken a few hours to provision and the instant server access that AWS brought should not be discredited. At one point it took often days for a dedicated server to be set up. We also didn't have such nice provisioning tools. Now it just seems like cargo cult to use cloud providers as the only option. People just completely discount dedicated servers.

In most businesses I've worked in: developer costs >> infrastructure costs An AWS large server is around $500/year, which is about 1-2 developer hours (with taxes, overhead, etc) at the cost scales last time I priced this out. That's crazy expensive in the absolute, but if it saves a couple of hours, it makes sense. PaaS providers cost even more. I've gone with those in the past, since it basically eliminated dev-ops…

developer costs >> infrastructure costs is a shallow way of looking at things.

You should be thinking of dev time as in _investment_ not a cost. Invest developer time into high value activities like creating robust services you own. Not into low value activities like coding against a dozen different proprietary, Amazon owned APIs that can change, go away, and become more expensive any time they feel like it.

Re: We reduced our server costs by moving away from AWS

#77

This is the Trillion Dollar Paradox described by Martin Casado. You’re crazy if you don’t start your business in the cloud, you’re crazy if you stay there. My new startup is focused on helping application owners repatriate their workloads into their own infrastructure. Our goal is to solve the network complexity challenges with a fully open network stack (open source software with all of the hardware options you woul…

> This is the Trillion Dollar Paradox described by Martin Casado. You’re crazy if you don’t start your business in the cloud, you’re crazy if you stay there.

That's not a paradox. You're not crazy in either case.

Starting in the cloud reduces costs for some strategies by removing necessary engineering. Starting in the cloud increases costs for other strategies by charging too much for commodity offerings.

It's relatively straightforward to make the choice as soon as you put a specific business in the crosshairs.

Edit: why is this downvoted?

Re: We reduced our server costs by moving away from AWS

#78
post #59

Earlier quoted context omitted.

Yes. If you use and manage AWS resources as you would your own on-prem resources then you're not going to have a good time. As soon as you think you need EC2 instances you need to re-think your architecture. You're probably not using AWS most effectively.

What I don't understand is why anyone would spend, precious and expensive engineering resources on coding to a proprietary API owned by one of the largest companies on the planet to whom you are nothing. Ok so you save money on the monthly bill but what happens when Amazon decides they want to enter your market? What happens if they decide your service is too controversial and they kick you off? If you were deploying…

I mean most of my projects are not massive, they cater to up to ~10K or so people. Running EC2 or dedicated server somewhere else would be a lot for me, a single developer, to take on myself. However using Lambda, API Gateway, CloudFront, SQS, DynamoDB, S3, and more (sometimes also with PlanetScale for my DB) is a really nice stack and the costs are tiny (I'm talking To run an equivalent stack myself would require significant effort (upfront and ongoing) and I'm not sure I could get the costs that low. Another great aspect of my stack is it's all scales on it's own without any intervention on my part.

What you are comfortable using is a sliding scale with some people thinking if you aren't hosting it in your own datacenter then you are crazy all the way up to "let's just use Firebase" (or similar). For me I've found that buying in fully can be very enjoyable and the risk is rather low (for me).

Re: We reduced our server costs by moving away from AWS

#79
I expect to see a great deal more of the "cheap and cheerful" AWS migration stories in the future. With the tanking of the market and (apparent) limits to growth being in the forefront, reducing expenses will become more important.

Before, it was easy to justify almost any expense with the "we just need to get 1% of this $100 billion market" and now it is "hunker down and do everything you can to be ramen-profitable, in order to survive and thrive".

Re: We reduced our server costs by moving away from AWS

#80
post #28

Earlier quoted context omitted.

Devs love being told to set up servers! And always do so well. After all, computer person is a fungible skill set. I mean, it is fungible enough that they can learn, but they'll probably make a lot of mistakes along the way and be less efficient.

Any developer that can't setup a server has fundamental gaps in their skillset.

On a trivial level I agree, but only on a trivial level. Most developers will not set up a server in the most secure, maintainable manner. They're going to miss important things:

- Disable password-based auth for ssh (require key-based auth) - Enable fail2ban or similar to slow down brute-force login attempts - Configure firewall - Install monitoring tools, antivirus, possibly backup daemons, etc - Setup a sane swapfile for your use case, and configure monitoring tools to alert when memory pressure gets too high - Setup disk mounts, configure monitoring tools to alert when disk space is low, and consider a cron job to automatically clean up tempfiles - Either set up automated updates (typically excluding kernel upgrades), or have a standard schedule for manually applying updates

...and probably other things that I'm forgetting because I'm a developer, and it has been years since I've been a sysadmin.

Post reply on HN