91–100 of 109 posts
When I pay for cloud infrastructure myself, my first stop is Hetzner because they combine low prices with good service. I do see some complaints on HN occasionally about Hetzner, so do some research. I have never had problems myself with them.
I worked at Google for a while ten years ago, so out of nostalgia I sometimes use GCP but I watch my spend.
37 Signals is living proof nobody needs a public cloud. And from my own experience, basically what all cloud providers are relying on is ops being lazy. Set up some decent hardware in a good data center, set up a good platform on top of it, automate the hell out of it and with all current open source software you can run everything by yourself. At least, that's something I am currently actively researching because ou…
To be fair, 37 signals still has terabytes of data in S3 according to DHH... So I don't know if it's fair to say that they're cloudless...
I help big companies reduce their cloud costs. Frequently I recommend moving Postgres and Kubernetes to on-prem. When you’re spending over $1 million per year on either of those then you’ll save a lot of money by moving to on-prem. The ideal cloud lifecycle is to iterate quickly on the cloud while you find product market fit, then when you know what you need start moving to on-prem to save money. I don’t think you’ll…
Is one million really the point where on prem becomes cheaper? I would think it’s much more like 10 million. Between having to pay server engineers and regional distribution and power costs I’d think it adds up to far more than 1 million. Where am I doing my math wrong?
Earlier quoted context omitted.
Simple, sure, but AWS still charges insane rates. I can get 60k IOPS on a nanode at $5/mo rate. You actually get a random amount between 20k-60k depending on the type of machine they provision your nanode on. You want 60k IOPS on AWS? Be prepared to pay like 4-5k/mo. Want multiple systems with it so you can cluster a reasonably performance database? Pay for each and you need to special request the ability to go past…
These high costs are Amazon's way of telling you that you aren't architecting for the cloud. In my ~10 years doing cloud infrastrcuture on AWS I've never worked at a company had to purchase dedicated IOPS or vCPU.
Changing something for the sake of changing something is meaningless. If whatever works for you works - you're fine, don't change a thing. Though, I'd comment that you don't need to go all-in in AWS, you can use EC2 instances the same way as bare metal servers from Hetzner and get some cool benefits, if you need them (and ok with 10x+ extra costs) - easy backup/snapshots, migrations, better server access and manageme…
If you really want to use AWS, AWS Lightsail is the service to look into.
- Lower chance of fatal bugs/downtime - More reliable load balancing - Proven backup startegies - Not having to learn everything
I've spent 7 years at a "unicorn" and the first five years we used Digital Ocean VPSs for everything. My main takeaways are that the smaller providers don't have "real" load balancing and that you absolutely should not manage your own databases or logging/metrics, it's a pain in the ass unless you have a team for it. I spent countless hours on learning infrastructure instead of building the product. It worked out in the end, but we would have gotten there much quicker if we'd paid the premium.
If I did it again I'd still use VPSs, but with one of the big players and pay for dbs and observability.
37 Signals is living proof nobody needs a public cloud. And from my own experience, basically what all cloud providers are relying on is ops being lazy. Set up some decent hardware in a good data center, set up a good platform on top of it, automate the hell out of it and with all current open source software you can run everything by yourself. At least, that's something I am currently actively researching because ou…
> And from my own experience, basically what all cloud providers are relying on is ops being lazy. This makes no sense to me, I've worked jobs where the app was hosted entirely on perm and jobs where it's hosted in AWS. By far the AWS shops required more work. There's so many more limitations, random footguns, arbitrary rate limits, capacity issues, having to do "cost optimization" because it happens that what is sim…
That's what I mean with that.
Funny thing is that you can easily do that on your own hardware using a solution such as KubeDB just as well these days, after you get through the pain of getting Kubernetes on bare metal operational.
> I'm keeping things simple, so I've got mostly Go services, pg + caching, and a svelte webapp. I deployed my Go services on a low-ish end bare metal provider, and for now it is fine. Deployments are triggered via scripts, and so far so good. Is it sexy, using all the latest and greatest tech? No, its just simple shell scripts. But it works? Don't change a thing. This is perfect. > Am I wrong to think that I could pr…
Exactly this. The only thing unmentioned, but that you should be aware of, is the effort to deploy this stack from scratch. You can assume the DB survives, or doesn't, but the ability to go from zero to a running deployment from a recent restore is probably the only thing you need to really worry about. If you can get that to be less than hour, or ideally a few minutes, then you're golden. Don't be afraid to add CDN/…
Being able to automatically build production from a recent snapshot is a profoundly important point.
When we bootstrapped on the cheap we would always maintain a production infrastructure at one company and a test infrastructure at another with a relatively low TTL dns infrastructure hosted at a third party like dnsmadeeasy. Backups would be pushed to the second site. We then would “build our demo” from the backup data (stripping PII at runtime). But the demo served as a second clone production infrastructure. If the primary went down, it was always a quick restore and scale up at the secondary location with recent backups!
Worked really well, but you needed to make sure it was automated or it would blow up.
Definitely cheap and works like a charm.
I’m sure that’s over complicated for a lot of people, but it’s really just a few scripts and a couple of days to set up, and you can be up and rolling with a working system in the time it takes to change DNS.