9 ms·
AWS is complexity-as-a-service. This is why, as a one-man company, I went baremetal[1]. One flat price, screaming fast performance, and massive scalability if y
by igammarays 5y ago
AWS is complexity-as-a-service. This is why, as a one-man company, I went baremetal[1]. One flat price, screaming fast performance, and massive scalability if you get a beefy enough machine[2]. I don't have time to fiddle with k8s, try to figure out AWS billing/performance tradeoffs, or deal with untraceable performance issues due to noisy neighbours and VM overhead. My disaster recovery plan is a simple DB dump script to S3, and I know I can get another baremetal server up and running in less than 20 minutes.
[1] with IBM Cloud 1 year free startup credits
[2] Let's Encrypt and StackOverflow run their entire databases on a single beefy baremetal machine. https://letsencrypt.org/2021/01/21/next-gen-database-servers.html https://letsencrypt.org/2021/01/21/next-gen-database-servers...
- pibefision 5y ago+1 also it's easy to use Docker containers and Traeffik as reverse proxy to manage many services.
- tomerbd 5y agoWhich scripting or which infra do you use for automatic installation/configuration of your server?
- chrisandchris 5y agoNot OP, but I did the same and I use - Ansible for the low-level stuff (like network, mounts, iSCSI, configuration files) - Terraform for high-level stuff (like DB users) In my case, as I have several services that use a lot of RAM running, I couldn‘t afford The Cloud but can easily afford a colocation. I don‘t mind the maintenance (it‘s a couple hours each month) and I don‘t care much if services are down a few hours. If you need something running 24/7 with 99.9%, colocation will be more expensive just because of the human you need.
- candiddevmike 5y agoWhy wouldn't you use Ansible for the high level stuff? It can easily manage DBs and you wouldn't need another tool.
- nijave 5y agoNot sure about op but you have to put forth quite a bit of effort to get declarative infra with Ansible. Some of it is declarative out of the box but a lot is imperative. The main difference, if I revoke a DB privilege, I have to add a line to Ansible with a REVOKE in most cases versus Terraform you just delete the config line and the tool realizes during its diff stage and performs the removal change (it's stateful and declarative)
- tomerbd 5y agoDoes terraform has any drifts for example if I remove a db from terraform is it going to.remove the db from prod? Can I trust it's always the same or do I have to do cleanups?
- chrisandchris 5y agoTerraform is declarative, meaning: The stuff you write into the terraform files (TF) is exactly the stuff you get configured. Example: you add a new database and a database user to the TF files, run terraform plan & apply, you do have the database and user configured. You remove the user and run plan & apply, terraform does remove the user. It goes the other way too: if you add additional port rules to a network security group (e.g. in AWS) by hand, terraform will remove them when plan & apply because they are not defined in the TF files. So in conclusion: for your declared state, there will be no drift.
- chrisandchris 5y agoAs nijave said, the declarative style is the difference. I can read a terraform file and already know the exact state my system will have.
- igammarays 5y agoLaravel Forge
- arbuge 5y agoFrom that Let's Encrypt article: "We have a number of replicas of the database active at any given time, and we direct some read operations to replica database servers to reduce load on the primary."
- genewitch 5y agoMaybe they run reporting on the read replicas because those can take a long time.
- icecap12 5y agoThe comment on "complexity-as-a-service" resonates. IMHO, it's primarily because they want to make a product out of everything, including stuff companies build to manage their own AWS implementations. Instead of a simple list of products, its a complex list, with lots of nuances per each service offering. The other day, I was giving a high level summary of cloud technology to an intern; there was a point where I couldn't even find the AWS service I was telling her about from the product list, which annoyed me. Maybe that's more a comment about the marketing site though, but still, when your product catalog gets that big, its hard to avoid ridiculous levels of complexity.
- StreamBright 5y agoWhat is blocking you from using just EC2?
- count 5y agoA year of free startup credits, I'd guess.
- ufmace 5y agoI tend to agree with this. AWS etc is nice if your scale is big enough that you need to run a big cloud of dozens of servers with complex interconnections for security etc. If a single plain old server with database etc on it will do the job fine, much better to stick with that.
- Daishiman 5y agoNo? A bare metal Postgres install needs optimization, and a working backup and restore plan (you did test your backups, right?). That's half a day of work lost to get your system set up. Now your app keeps serious data and you want a read replica. How long does that take? Now you need a separate development environment. Here you go again, adding a few hours of work. Then you need to update your database version. Gotta read the changelog and make sure you did everything right, and do it in a reaonsable change window. You just racked up several day's worth of work, and for a DB instance with a similar amount of infra work done, the RDS solution is way cheaper and easier to provision. If your time is worth money, there's no reason to go bare metal.
- ufmace 5y agoI still disagree and say yes. Why does my bare metal Postgres install need optimization? My sites mostly doesn't get much traffic, and it runs fine as-is. It'd be silly to try and optimize it without being able to measure what's actually slow. Backup systems should also be set up according to desired reliability. I have a 10-line bash script that pulls a DB dump, zips it, and sends it to S3. Under 5 minutes to install, including setting up a new AWS role and keypair for it, just have to add in some Ansible commands I already have set up, and set a cron job to run once a day. Read replicas are nice for some applications, but not needed for any of my current ones. I probably wouldn't want to set one up on bare-metal admittedly, but I'm not worrying about it until I need it. I don't see a need for a separate cloud deployment for a development environment for my current application either. Would be nice if I had multiple developers and testers working on it, but I don't now. Never needed to update the DB version, and the traffic is low enough that I don't need to really care about keeping reasonable change windows if I did. So nope, 10 minutes of work for a low-traffic application. Meanwhile, a AWS RDS setup is easy to start, but then you have to muck with security groups, VPCs, permissions, etc to get it working right. That's not necessarily easy if you don't already make use of that stuff.
- FpUser 5y agoOn bare metal as well. Not a trace of doubt.
- EthOptimist 5y agoIt also seems more feasible with concurrency focused languages such as Go which have become more popular in recent years
- FpUser 5y agoI do not see anything less feasible doing it with threads / forks. Asynchronous IO like in Go I think is useful in a sense that if some of the networked responders are temporarily slow then they will not hold fast ones and would not accumulate threads. If however it is disk / database, then by immediately switching to a next method this strategy will let internal async tasks piling up indefinitely and saturating resource pools of OS just as well. So those "concurrency focused" languages are not a silver bullet and one has to understand internal mechanics to properly manage requests lifecycle.
- shreddit 5y agoTheir config costs around 230,000$, which i think is impressive for a single server
- lifeplusplus 5y agoWhat's your exact stack.. just ssh and bash script?