Comment by horsawlarway | Hacker News Reader

Comment by horsawlarway | Hacker News Reader

I'm slowly coming to the complete opposite opinion you seem to have.

I've worked almost entirely for companies that run services in various cloud infrastructures - Azure/Heroku/Aws/GCP/Other.

I recently started a tiny 1 man dev shop in my spare time. Given my experience with cloud services it seemed like a no brainer to throw something up in the cloud and run with it.

Except after a few months I realized I'm in an industry that's not going to see drastic and unplanned demand (I'm not selling ads, and I don't need to drive eyeballs to my site to generate revenue).

So while in theory the scaling aspect of the cloud sounds nice, the reality was simple - I was overpaying for EVERYTHING.

I reduced costs by nearly 90% by throwing several of my old personal machines at the problem and hosting things myself.

So long story short - Cost. I'm happy to exchange some scaling and some uptime in favor of cutting costs. Backups are still offsite, so if my place burns I'm just out on uptime. The product supports offline, so while no one is thrilled if I lose power, my customers can still use the product.

Basically - cost, Cost, COST. I have sunk costs in old hardware, it's dumb to rent an asset I already own.

There might well be a point when I scale into a point where the cloud makes sense. That day is not today.

What's the time trade-off?

I've been drawing out my plans lately for a hobby project, all 100% on AWS.

Being able to spin up my entire infrastructure with Terraform, build out images with Packer, setup rules for off-site backups, ensure everything is secure to the level I want it, etc. - It takes me next to no time at all.

I can't imagine buying hardware, ensuring my home is setup with proper Internet, configuring everything here, and then still needing off-site backups anyway.

Now, keep in mind - I'm definitely coming in from a Millennial point of view. My entire career was built on cloud. I've never touched hardware apart from building a computer back when I was 15 or something. I understand virtual.

But being able to build up and tear down an entire setup, having it completely self-restore in minutes. Can't beat that.

Napkin math has me at ~$50/mo: Full VPC, private/public isolated subnets, secure NACLs and security groups, infinitely extendable block storage and flat-file storage, near-instant backups with syncing to a different continent, 5 servers, DNS configurations, etc.

All depends what you're doing too - of course. But for me, just the trade-off of working with what I know and not needing to leave my cafe of choice, still not breaking the bank - and if I do, having instant tear down and restore. Bam.

I'm not going to say that there aren't advantages, but when you start doing anything non-trivial with system configuration you'll find that the "infrastructure as code" approach also involves a large amount of work. Having done plenty of both in my career I don't think it's fair to say that IaC is at all less time consuming than traditional system administration. The advantages it comes with can also pretty easily come out to a wash if you don't plan around to some extent.

I guess what I'm saying is that, just like "cloud means cost savings" doesn't necessarily pan out, "cloud means time savings" also doesn't necessarily pan out. The best strategy continues to depend on your strengths, the application, etc.

You can do IaC for bare metal home servers as well. And thats coming from a 90s kid. We run a few physical servers for a college society with proxmox on top, and all of our VMs are codified in Ansible

Do you think automation doesn't exist with on-prem? The vSphere terraform provider is very mature.

https://www.terraform.io/docs/providers/vsphere/index.html

You can build your own machine images with packer, and actually have more control by building them from scratch (ISO) rather than being locked into a selection of base AMIs.

https://www.packer.io/docs/builders/vmware/

You can launch HA kubernetes clusters with cluster API. vSphere, openstack and even bare metal pxe all have providers

https://cluster-api.sigs.k8s.io/user/quick-start.html

Cloud native is not just for the public cloud!

> You can launch HA kubernetes clusters with cluster API. vSphere, openstack and even bare metal pxe all have providers

I've been looking for a decent solution for pxe and cluster-api. I've not pushed the button on any as I feel like they're all a little immature. Admittedly I've not had time to set up any in a test env yet. Any recommendations?

>Being able to spin up my entire infrastructure with Terraform, build out images with Packer, setup rules for off-site backups, ensure everything is secure to the level I want it, etc. - It takes me next to no time at all.

Interesting. For me, that equation is the opposite. Learning cloud technologies takes a long time. It depends a lot on what skillset you already have.

What kind of setup did you have for 5 servers at $50/mo on AWS? Interested to know - our EC2 instances that are about 1/4 as powerful as a laptop cost $60+/mo

If you have a small hobby project you could use AWS Lightsail[0] which has starting prices of $3.50/mo

https://aws.amazon.com/lightsail/pricing/?opdp1=pricing

Thanks! Aware of Lightsail - But I'm experienced with AWS so have no trouble with, and prefer, the full feature set. I would've gone with Digital Ocean, otherwise.

Out of curiosity, what you're missing at Digital Ocean? It seems it has all the basics (VMs, managed DBs, storage, load balancers) and for a better price than the bigger clouds.

I find it quite easy to mix services from multiple providers. For example add SQS or S3 from Amazon and Elasticsearch from elastic.co if your cloud doesn't have the products. The latency kills mostly just the connection from a web app to its database.

The biggest drawback is multiple invoices, but I think it's manageable.

Certainly nothing powerful :-) I can get away with t3.nano and t3.micro for what I'm doing at the moment. But the beauty of cloud, is that I can scale up when I eventually need it.

5x t3.nano will be ~$25/mo 5x t3.micro will be ~$50/mo

All of my AMIs are EBS optimized and require a minimum of 8GB for the root drive (Although they only use ~1.6GB. Not bothering to hack around this to save a buck.) So that'll be 40GB EBS block storage. Plus I want ~20GB spread across 3 of the machines.

So EBS should be ~$6/mo.

I only need the volumes of those last 3, the others are good to go with their base AMI or user-data init script. So I only need snapshot backups of ~20GB. Being priced incrementally and having minimal changes, I'll only be charged ~$1/mo for that + off-site another $1/mo

So, currently experimenting with the t3.nano - Cost is ~$36/mo. One of these servers will be used as a personal VPN, and I expect ~75GB/mo coming from my laptop. So bandwidth charges at $9/mo.

Total $45/mo - For what I have planned now, at least.

That's exactly the reason I gave up on AWS, I need an accountant to do the math every month :D

Now I rent a 4GB Linux box for 5$/m with no Dockers or whatsoever and happy that it just works

I also hate this complexity with a passion. I love cloud, but pricing can be a real nightmare.

I don't use AWS specifically but when I needed to know the price of some cloud service or group of services I spin up the service (or services) in a brand new project and let it run for 24 hours under similar working environment to see the impact, then after checking the results (the breakdown of each service's price in that day) I just close the project entirely, no left overs.

So I tend to successfully avoid these strange, terribly organized, cloud-specific, service-specific calculator where I can easily forget one aspect of the service that might cost a lot of money absolutely randomly.

Obviously it is a bad strategy if things are expected to reach $200/month and/or you do 'price evaluation' frequently, but otherwise it is stupid easy. I barely spent $50 each year doing this (small company and sporadic system changes)

But the best part is that the final daily price of your system is as precise as it can possibly be and that is worth something.

And if you went with reserved instances, what does it come out to? I guess that it is fair to assume that you will need at least this level of compute power for at least a year, right?

No idea. Generally reserved instances will give you 30-75% off though, I believe.

This is for a hobby project, so no way I'm committing to that, haha.

I'm also building the architecture so that I can easily completely destroy it and restore it from backups very quickly.

So, depending what I do with it, may be destroying it regularly and just bringing online when I want it.

Cool - I should give the micro instances another shot - I wonder how big of a Postgres database they will be able to handle.

Consider bare metal at eg hetzner.de - they do everything that is hardware related, but still the cost is way lower than aws.

I'm a Millennial as well but I started out on hardware.

You're not missing anything. There are still some use cases for on-prem hardware or for not building out on a single cloud provider but they're getting harder and harder to justify. The main use case I can see for running your own hardware is if you need massive egress. There comes a point where it can make sense to run it yourself, I luckily work at places with large enough margins to still leverage cloud solutions for this though.

Some guys don't know how to build things out on the cloud and are stuck in their way. When I was getting into the industry the old guys were still stuck on bare metal vs VMs. You should know how that went, most apps migrated to VMs no problem and a few apps stuck to bare metal for their own reasons.

A lot of small/mid size companies don't have the manpower to properly move an app to the cloud. Sometimes products/companies have enough steam to build an app and barely support it but not quite enough to keep it competitive and current. Basically, it can be easy to get a profitable company/app started with a couple amateurs building the product. It can get very expensive when you need professionals. A lot of places don't have the margins to support a robust team of professionals.

These companies don't always lack the foresight, sometimes it's impossible to get some breathing room to see the big picture or to get project funding instead of just upkeep funding. It can be expensive migrating something to AWS/Azure/etc and not just money but also manpower.

> Backups are still offsite, so if my place burns I'm just out on uptime

There are plenty of exceptions, but I generally find uptime is given way too much consideration for the value it gives. Most companies up to the national level generally only require about 12 hours a day of uptime from most of their software, more than that is a nice to have, but the company won't collapse if you turn off the servers overnight because no one is working anyway. Even a whole day outage of a critical system can just mean that work has to be delayed for a day and everyone has to work a bit harder the next day. Then as you move down the scale of importance outages can be much longer before people will even notice.

I've seen plenty of "5 nines" style requirements put forth but few that truly need it and even fewer that have considered the costs imposed by it.

Yeah, I find the constant focus on ~100% uptime a bit crazy.

I used to work for one of Australia's largest bookmakers and we would regularly switch off the datacenter overnight to do some work on the servers. It didn't seem to impact the growth of that business one bit. There were times of course where uptime equalled cash, it just wasn't all the time.

For my personal hobby projects, I would actually rather have downtime than a surprise bill if something gets popular.

> I reduced costs by nearly 90% by throwing several of my old personal machines at the problem and hosting things myself.

This is what's pulling me back toward semi-static websites. Do most of the write traffic on premises and push the results to the cloud.

Only part of your application that needs to be always-on. If you treat the entire thing that way, it'll cost you. I've seen a couple of read-mostly applications that are so divorced from this fact that the paths that should be the cheapest are some of the most expensive, and the ones that happen at the speed of human interaction (eg, editing things) are fast. They are in effect backward and inside-out.

IMHO the optionality the cloud gives you is the main value at the low-end. You can play around with different architectures, mixing and matching managed services with no commitment. When you need to scale you can always switch to on-prem, and with the benefit of having a working system to base your hardware requirements on. Of course this migration has costs too, but if this is your strategy you can minimize cloud-specific dependencies and leverage automation that can be used in both environments (eg. ansible).

I pay for one virtual private server instance. I used to colocate several machines but vps is just as good for smaller setups.

Reply on news.ycombinator.com