4 ms·
I kind of agree with the premise, which is essentially "don't overcomplicate things at the beginning" but the article seems to keep conflating requirements. Doe
by mjr00 3y ago
I kind of agree with the premise, which is essentially "don't overcomplicate things at the beginning" but the article seems to keep conflating requirements. Does your company have a 10-person devops team or are you a solo enterpreneur? Are you servicing 2 requests per second or do you need a 80-core, 128GB RAM box for hosting your service?
The reason many start with cloud is that most businesses quickly grow, or at least hope to quickly grow, to the point where they'll need it. Standardized cloud tooling helps onboard new developers more quickly. It drastically speeds up audits like SOC2 or ISO. Much easier scale-up/scale-down. etc etc
You also pretty quickly get to the point where your cloud costs are negligible compared to the rest of your business expenses. If you're employing 20 people and paying ~$200k/mo in salaries, is reducing your cloud bill of $2000 to $200 going to materially impact your business, especially given the opportunity cost of not doing other revenue-generating work?
- codegeek 3y ago"The reason many start with cloud is that most businesses quickly grow, or at least hope to quickly grow, to the point where they'll need it" And most don't. That's the point of the article.
- mjr00 3y agoMost don't, but you can get a t3.micro RDS database and EC2 instance for less than $20/month, to service those two requests per second you're getting. I would assume most startup founders in the US can afford this. If they can but consider it too unlikely they'll recoup these costs, you're getting into "hobby project" territory rather than business.
- erik_seaberg 3y agoThis. A single dedicated bare metal server sacrifices too much availability, in return for capacity that you probably don't need yet. Better to use a fraction of a few different servers.
- gadflyinyoureye 3y agoThis is true if you don’t follow best practices. That RDS instance should be in a private VPV. You should have a NAT bridge to your public VPC. That bridge is $35 a month. Then you need a public thing: be it EC2 or API Gateway or ALB with rules. That can more your total to $50/month. But it’s more secure than a Digital Ocean or Hetzner setup.
- mjr00 3y agoWell yes, if you start adding "best practices" that only apply to larger companies with threat models that are completely nonapplicable to your 0-revenue, 2-request/sec startup, you are going to have to pay more money. Adding the requirement of separate private/public VPCs linked by a NAT gateway when we're comparing to a single physical machine with everything running in a single host running Docker is nonsense.
- snoman 3y agoI think you’ve confused a couple of things. Your db should be in a private subnet as opposed to a VPC, and it’s never advised to have public access directly to your db. You also don’t need NAT for RDS instances as they shouldn’t be initiating outbound connections to the internet. If you do want to connect to your db from outside of AWS for ad hoc connections then you should be setting up a bastion host in the public subnet and you don’t need anything other than security group rules to configure communication between them - same goes for a web server (routing between public/private subnets are configured out of the box).