I know it's not in fashion, but I will suggest that renting physical servers is a very good and under-appreciated compromise. As an example, 45€/month gets you a 6-core AMD with 64GB of RAM and NVMe SSDs at Hetzner. That's a lot of computing power!
Virtualized offerings perform significantly worse (see my 2019 experiments: https://jan.rychter.com/enblog/cloud-server-cpu-performance-...) and cost more. The difference is that you can "scale on demand", which I found not to be necessary, at least in my case. And if I do need to scale, I can still do that, it's just that getting new servers takes hours instead of seconds. Well, I don't need to scale in seconds.
In my case, my entire monthly bill for the full production environment and a duplicate staging/standby environment is constant, simple, predictable, very low compared to what I'd need to pay AWS, and I still have a lot of performance headroom to grow.
One thing worth noting is that I treat physical servers just like virtual ones: everything is managed through ansible and I can recreate everything from scratch. In fact, I do use another "devcloud" environment at Digital Ocean, and that one is spun up using terraform, before being passed on to ansible that does the rest of the setup.
I really don't understand why the industry seems to have lost sight of this. It's really common to see super complicated, incredibly expensive, but highly scalable cloud deployments for problems that can be trivially solved with one or two dedicated servers. Even the mere suggestion of renting a dedicated server provokes scorn from devops teams. The overall difference in cost when taking into account all of the complexity, feature-lag and general ceremony must be at least 10x and maybe even closer to 100x. It's madness.
The allure of our industry to mime FAANG leaders might be one of the reasons we're at this stage. Most products could be safely run on simpler setups.
I suspect that VendorOps and complex tools like kubernetes are favored by complexity merchants which have arisen in the past decade. It looks great on resume and gives tech leaders a false sense of achievement.
Meanwhile Stackoverflow, which is arguably more important than most startups, is chugging along on dedicated machines.
Software development and related things are known to have fantastic often free online resources for autodidacts.
It seems like the trend in this space is to jump directly to the highest layer of abstraction. Skipping the fundamentals and point to $buzzword tools, libraries and products.
You see glimpses of this in different forms. One is social media threads which ask stuff like “How much of X do I need to know to learn Y?” Where X is a fundamental, possibly very stable technology or field and Y is some tool du jour or straight up a product or service.
"complexity merchants" - I love this term. It aptly describes beneficiaries of earlier IT fads. Remember UML? Remember WS-*? One could come up with a long list of technologies that were a bonanza for billing consultant hours but no so great for getting to solutions.
To be fair - J2EE (and its associated technologies like SOAP, XML) is a bit like alcohol. It is great when used in moderation, but gives you headaches when used excessively.
XML is great - if you don't believe it, then you might be interested in the pains of parsing JSON: http://seriot.ch/projects/parsing_json.html
And don't get me started on YAML...
The dedicated server deployments I worked on at smallish software companies 10+ years ago wound up being really annoying. I enjoy sysadmin type stuff and this idea has tempted me, but I think it’s a false economy in most cases.
The incremental cost of being on a cloud is totally worth it to me to have managed databases, automatic snapshots, hosted load balancers, plug and play block storage etc.
I want to worry about whether our product is good, not about middle of the night hardware failures, spinning up a new server and having it not work right because there was no incentive to use configuration management with a single box, having a single runaway task cause OOM or full disk and break everything instead of just that task’s VM, fear of restarting a machine that has been up 1000 days etc.
100%. There are definitely cases where managing your own dedicated server infra (not hardware, just the software part) makes sense.
For me, the allure of the cloud is not some FAANG scalability fad when its not required, but automatic OS patching, automatic load balancing, NAT services, centralized, analyzable logs, database services that I don't have to manage, out of the box rolling upgrades to services, managing crypto-keys and secrets, and of course, object storage. (These are all the things we use in our startup)
I'd go on a limb and say dedicated servers may be very viable/cost effective when we reach a certain scale, instead of the other way round. For the moment, the cloud expenses are worth it for my startup.
The key is to use some kind of config management, even for a single box. The problem you need to solve is basically to separate your configurations from the system default and make it easy to bring the system into a known good state.
I do think there's something in there about the immediacy of a replacement if a currently-live box falls over. Rough rule of thumb says it's hours for a physical box, minutes for a VM, seconds for a k8s container, a hopefully smaller number of seconds for a serverless cold start. Each of those has ergonomics different enough that it might matter even with config management that rhymes across the options.
How so? You should still be doing those things with cloud deployment anyway. The alternative is (the pretty terribly named) "click ops" where devops folks have to fiddle with some cloud UI settings to make production changes or go through wizards to attempt to replicate an environment.
If you are doing your environment config as code it ultimately shouldn't matter if your target is a dedicated server, a vm or some cloud specific setup configured via an api.
But most cloud deployments have config management too. Using Ansible/Terraform/Kubernetes on bare metal isn't much different than using Ansible/Terraform/Kubernetes in the cloud.
yes, or Puppet, Aviary, Shell, CFEngine, Salt, Capistrano, etc...
Doesn't really matter which one, the point is that you have one that can build you a new box or bring a misbehaving box back to a know good state by simply running a command.
Aaand that's why k8s seems like a good step in the right direction. It has all - okay, absolutely not all, but a good number of the important ones - of these concepts "built-in".
Sure, the actual pile of Go(o) that drives it can be improved (and it is indeed improving).
That said, the hard truth is that your approach is the correct one, almost all businesses (startups!) overbuild instead of focusing on providing value, identifying the actual niche, etc. (Yes, there's also the demand side of this, as the VC money inflated startups overbuild they want to depend on 3rd parties that can take the load, scale with them, SLAs and whatnot must be advertised.)
> k8s seems like a good step in the right direction
Kubernetes is fantastic! Whenever I see a potentially competing business start using Kubernetes, I am immediately relieved, as I know I don't have to worry about them anymore. They are about to disappear in a pile of unsolvable technical problems, trying to fix issues that can't be traced down in a tech stack of unbelievable complexity and working around limitations imposed by a system designed for businesses with traffic two-three orders of magnitude larger. Also, their COGS will be way higher than mine, which means they will need to price their product higher, unless they are just burning through VC money (in which case they are a flash in the pan).
k8s is almost the polar opposite of this idea for most companies. At minimum, a half dozen daemons spread across multiple hosts for.. what? Making the easy things built-in and everything else much more complex than it needs to be?
(I haven't used it in a few years, when I tried to deploy OpenStack with it, so if this is outdated, please, correct me!)
Ansible is imperative, it can work toward a static state, and that's it. If it runs into a problem it throws up its SSH connection, and cries tons of python errors, and gives up forever. Even with its inventory it's far from declarative.
k8s is a bunch of control loops that try to make progress toward their declared state. Failure is not a problem, it'll retry. It'll constantly check its own state, it has a nice API to report it, and thanks to a lot of reified concepts it's harder to have strange clashes between deployed components. (Whereas integrating multiple playbooks with Ansible is ... not trivial.)
Yes, ... and? Those are much more "standardized" than whatever else any team cooks up. (And k8s along with Go is steadily improving, so I don't see this as "let's use WordPress because its the platform that has the most answers on StackOverflow".)
And even if k8s puts on too many legacy-ness, there are upcoming slimmer manifestations of the core ideas. (Eg. https://github.com/aurae-runtime/aurae )
You need to solve a bunch of SRE/DevOps problem, fearless deploys, rollbacks, canary rollout, blue/green deployment, HA/LB, backups, dev environments, supporting multiple teams, yadda-yadda.
So of course you can implement a minimal complexity solution or you can use something "off the shelf".
k8s is complexity and some of it is definitely unneeded for your situation, but it's also rather general, flexible, well supported, etc.
> you’re suggesting that people use a “simpler” non “standard” implementation?
What I suggested is that if k8s the project/software gets too big to fail, then folks can switch to an alternative. Luckily the k8s concepts and API is open source, so they can be implemented in other projects, and I gave such an example to illustrate that picking k8s is not an Oracle-like vendor lock-in.
I think there's a lot of room to bring the best of both worlds together. Some are moving on this already, for example Hetzner Cloud load balancers can also have dedicated servers as targets.
If you've got your configuration properly automated, nothing prevent you from redeploying your bare-metal nodes every weeks. The opposite can actually also be true, it may become risky at some point to reboot a VM with a high uptime.
I'm completely clueless about any server administration beyond a LAMP stack on a single machine serving a few dozen people
I always hear about all the great stuff you get practically for free from cloud providers. Is that stuff actually that easy to set up and use? Any time I tried to set up my LAMP stack on a cloud service it was such a confusing and frightening process that I ended up giving up. I'm wondering if I just need to push a little harder and I'll get to Cloud Heaven
It's a mixed bag. It's more standardised, so once you know how to set up one app, you can mostly just repeat it multiple times as needed. Even for custom things, I can't remember the last time I started a CloudFormation stack from scratch - it's mostly copy&customise.
Being able to say "I want a clustered MySQL here with this kind of specs" is much better (time-wise) than doing it on your own. The updates are also nicely wrapped up in the system, so I'm just saying "apply the latest update" rather than manually ensuring failovers/restarts happen in the right order.
So you pay to simplify things, but the gain from that simplification only kicks in with larger projects. If you have something in a single server that you can restart while your users get an error page, it may not be worth it.
The big problem for server operations is not the damned servers but all of the infrastructure you need to keep them running, like power cooling network/storage and internet connectivity.
The cloud is not easy but damn trying to get cooling and power efficiency of an small server room anywhere near the efficiency levels most big data-center publish is next to impossible as is multi vendor internet connectivity.
With the cloud all of that kind of goes away as it's managed by whatever data-center operator that cloud is running on but what people forget is that that is also true for old fashioned colocation services which is often offering a better cost/value then cloud.
And while it's definitely harder to manage stuff like AWS or Azure because it bleeds a lot of abstractions small scall vpc providers hide from you or that you dont really get with a single home server, it's not hard on the scale of having to run a couple of racks worth of vmware servers with SAN based storage.
I think the problem is configuration. Every thing that has its own configuration is basically a new language you must be able to speak perfectly. Configuration languages are not statically typed so when you make an error it typically does not tell you you made a mistake, and where, and thy it is a mistake.
With Cloud stuff you have more configuration to do because it is about configuring virtual servers etc. Instead of carrying the PC in a box to your room you must "configure it" to make it available.
Laravel Forge + Digital Ocean (or Hetzner, your own machine, Vultr ...) is a pretty good solution. You can up & downgrade as you see fit or spin up a new server in a few min (any specs you need, from scratch or using an image of one of your existing machines, it installs what you need and you can of course add whatever is still missing).
DO databases have backups you can configure to your liking, store them on DO Spaces (like S3). DB user management is easy. There's also cache servers for Redis.
You can add a load balancer and connect it to your various web servers.
I think it took me about 30 min to setup 2x web servers, a DB server, cache server, load balancer, a storage server and connect them all as needed using a few simple forms. Can't really beat that.
By your own estimate -- how confident do you feel that these servers and services are secure? "Setting up" web servers to perform their function is rather easy, in my experience. Ensuring those servers can withstand standard-issue hacking attempts, not so much, especially within just 30 minutes.
The added value of these types of service, I think, is that they're fairly well set up with their provisioning script. You're paying for this service after all and if it appears they can be easily compromised "by default" then ... there would be many problems.
If you have any more info or opinions then please do share.
I'm no expert on Linux security but what I've seen when provisioning a VPS from anybody is a system with the base OS installed and that's it. SSH on port 22. Root account active. Accounts not needing a private key to login. No firewall. Known vulnerabilities in base packages unpatched.
Lots of articles around the internet about hardening a Linux server, the ones I've tried take a bit more than 30 min to follow the steps, a lot longer if I'm trying to actually learn and understand what each thing is doing, why it's important, what the underlying vulnerability is, and how I might need to customize some settings for my particular use case.
As someone who also runs a Laravel site on DO (but doesn't use Forge so can't comment on whether it handles any additional security configurations) buying a cheap DO droplet is very much handling your own infrastructure, it comes with reasonable enough defaults for most people out of the box but if you're expecting any decent amount of traffic it definitely needs to be hardened a little more. Also other administrative tasks like adding swap space if you're like me and trying to get as much performance as possible from as little spend as possible.
a bash script that auto installs everything will do. It has to be maintained though. You also lock down and harden the server. Running a stable OS helps.
I've run a few debian servers for years with little issues. Set up auto-update (very easy) for security updates. There's really little to go wrong.
I'm sure you can find example setup scripts online (configure autoupdates, firewall, applications, etc.), should be a matter of running 'curl $URL' and then 'chmod +x $FILE' and 'bash $FILE'. I didn't need configuration management (I do use my provider's backup service which is important I guess).
Totally, though I think in a fast paced/under-resourced environment incentives matter, and ephemeral cloud vms incentive admins to use configuration management, whereas it's easy to take a shortcut in the moment and quickly manually install something/edit config on a rarely-changing dedicated host.
Obviously the same can be said for long running VMs, and this can be solved by having a disciplined team, but I think it's generally more likely in an environment with a single long running dedicated machine.
This here is the trick. I like to do blue/green deployments. This workflow forces you to script (and implicitly test ) the full server+application deployment. With everything scripted, it just becomes a matter of deciding to rebuild a new machine every week/month/n-deploys which makes you comfortable. Plus, you get a hot spare for free.
> The incremental cost of being on a cloud is totally worth it to me to have managed databases, automatic snapshots, hosted load balancers, plug and play block storage etc.
> With booked daily backup or the backup included in the type of server, all data is backed up daily and retained for a maximum of 14 days. Recovery of backups (Restore) is possible via the konsoleH administration interface.
But i get the impression that the databases on managed servers are intended for use by apps running on that server, so there isn't really a concept of failover.
EC2 or on-premise you need monitoring to detect issues before they become issues.
A single drive on a single server failing should never cause a production outage.
A lot of configuration issues can be tracked down to self-contained deployments. Does that font file or JRE really need to be installed on the whole server or can you bundle it into your deployment.
Our deployments use on-premise and EC2 targets. The deployment script isn't different, only the IP for the host is.
Now, I will say if I can use S3 for something I 100% will. There is not an on-premise alternative for it with the same feature set.
HackerNews went down because two SSDs in a mirror went down at the same time. This was due to a hours on SSD bug. While Raid-Z2 works, and provides great reliability, two-servers replicated, both with raid-z2 and a nightly offsite backup and as long as you are testing your backups it's a solid plan.
What about simply running k8s on metal? You wouldn’t be able to auto-scale (unless you automated buying and selling the hardware provision from the DS) but it would be nice.
What PaaS providers / platforms do you like? I want to move some personal shell scripted boxes to PaaS, but dropped the idea with the decline of Heroku. Tried Dokku and struggled, but it seems like I should give it another try.
I'd love if you jumped into our Discord/Slack and brought up some of the issues you were seeing so we can at least make the experience better for others using Dokku. Feel free to hit me up there (my nick is `savant`).
Thank you for the kind words and I'll check out your Discord when I next take a pass at it.
Let me preface and say that I'm an application dev with only a working knowledge of Docker. I'm not super skilled at infra and the application I struggled with has peculiar deployment parameters: It's a Python app that at build-time parses several gigs of static HTML crawls to populate a Postgres database that's static after being built. A Flask web app then serves against that database. The HTML parsing evolves fast and so the populated DB data should be bundled as part of the application image(s).
IIRC, I struggled with structuring Dockerfiles when the DB wasn't persistent but instead just another transient part of the app, but it seemed surmountable. The bigger issue seemed to be how to avoid pulling gigs of rarely changed data from S3 for each build when ideally it'd be cached, especially in a way that behaved sanely across DigitalOcean and my local environment. I presume the right Docker image layer caching would address the issue, but I pretty rapidly reached the end of my knowledge and patience.
Dokku's DX does seem great for people doing normal things. :)
I’m in a weird position where I work with both extremely large enterprises and very small startups and not much in between. The enterprises in my area lean towards Azure so it’s still my cloud provider of choice. I haven’t had occasion to look for PaaS providers outside of the major cloud vendors yet. On the startup side, most of these companies want to be cloud first so it’s much easier to start them the right way and avoid the legacy mess that most enterprises deal with today.
Anything of note between the two which you found favorable? I am early-days into designing a Dokku backed system. Dokku has a lot going for it that makes it appealing to me, but happy to learn what I am missing.
The only problem with this is I don’t want something running on my own server that I barely understand. I’d rather use say fly.io that way if there is a problem I can get support from them.
In addition to what has already been said in the other comments, devs have an incentive to push cloud tech against the interest of their employers so they can put the experience in their resume, since cloud tech is seen as more specialized and in higher regard and as such a dev experienced in it commands a higher salary.
Plus who doesn't want to play with the newest, coolest toy on another's dime?
In my experience it's often the other way around. CTO/mgmt/HR would rather swallow the perf/cost hit of Cloud because it makes auditing, compliance, support, dr, security, training and hiring easier. Not to mention it usually provides much more flexibility during the PMF stage of a startup (where product roadmap, team talent/bandwidth and execution speed are often much more important drivers than the raw perf/cost ratio of your infra).
There's definitely an argument to move (some) stuff off cloud later in the journey when flexibility (or dealing with flux/pivoting) becomes less of a primary driver and scale/cost start dominating.
"It's insane not to start your startup on the Cloud and even more so to stay on it" paraphrasing something I think I've read on HN some time ago.
But I agree, it's best to treat the Cloud as an intermediate solution and once you stabilize and a clearer picture about requirements is available move at least partially to on-prem (especially the more expensive stuff like compute, storage is I think fine)
I wonder if there is any honest research into the TCO of cloud vs on-prem. In my team we pay ~100k/month for gcp, management doesn't seem to care, since the whole company is on gcp. But they also didn't care when it was on prem and was using hundreds of servers.
Realistically RDD is a very sane strategy for employees. When I read my company's job ads a few years ago I had serious doubts if I would get hired by them because my resume didn't have the buzzwords they wanted. Since then I always sprinkle in some new tech with each new project, not because it makes sense for the company, but for my resume and future employability.
If you're ever trying to get big enterprise contracts, the kind of scalability, compliance and disaster recovery that providers like AWS/Azure enable are now just table stakes.
Sure, you can get something working on Hetzner but be prepared to answer a lot more questions.
Yes fair point though I doubt some of these super distributed, scalable apps are able to properly execute a disaster recovery... And just because all the serverless components scale "infinitely" doesn't mean the patchwork stitching them together is.
Agreed on your last point of enterprise asking for this which again is just sad that these business "requirements" dictate how to architect and host your software when another way might be the much better one
I run a self-funded SaaS business, so I only deal with real problems, not imaginary ones.
Disaster recovery is a very real problem. Which is why I test it regularly. In a scorched-earth scenario, I can be up and running on a secondary (staging) system or a terraformed cloud system in less than an hour. For my business, that is enough.
We went through a growth boom, and like all of them before, it meant there were lots of inexperienced people being handed lots of money and urgent expectations. It’s a recipe for cargo culting and exploitative marketing.
But growth is slowing and money is getting more expensive, so we’ll slow down and start to re-learn the old lessons with exciting new variations. (Like Here: managing bare metal scaling and with containers and orchestration)
And the whole cycle will repeat in the next boom. That’s our industry for now.
A lot of its the buzz. 'Cloud Hosting' is something everyone thinks they need, despite not grasping why, or that the chances are they arent getting cloud hosting at all, just a VPS.
A solid dedicated server is 99% of the time far more useful than a crippled VPS on shared hardware but it obviously comes at an increased cost if you dont need all the resources they provide.
I think it might be due to the incentives - the costs are borne by the company (thus irrelevant to the employee), however putting new cool technologies on their CV is very relevant to the employee.
Yes - but stupid yearnings to "do what all the cool kids are doing now" are at least as strong in those who would normally be referred to as "managers", vs. "employees".
Good point - and in the case of managers there's also the "nobody got fired for buying IBM" effect:
outcome A) huge microservices/cloud spend goes wrong, well at least you were following best practices, these things happen, what can you do.
outcome B) you went with a Hetzner server and something went wrong, well you are a fool and should have gone with microservices, enjoy looking for a new job.
Thus encouraging managers to choose microservices/cloud. It might not be the right decision for the company, but it's the right decision for the manager, and it's the manager making the decision.
Yeah that's the problem. It's not just a "devs are idiots, they should think of their company and not be obsessed with their CV" - not having worked with the latest trendy tech has a very real cost for developers.
(As does being a consultant wanting an extension and writing software that works, as I found out the hard way.)
> I really don't understand why the industry seems to have lost sight of this.
There's a disconnect between founders and everyone else.
Founders believe they're going to >10x every year.
Reality is that they're 90% likely to fail.
90% of the time - you're fine failing on whatever.
Some % of the 10% of the time you succeed you're still fine without the cloud - at least for several years of success, plenty of time to switch if ever necessary.
Even if you 10x every year, going from year 1 to year 2 you switch from renting two 6-core servers to renting two 64 core servers, in year 3 you rent 20 servers, in year 4 you are renting a small room of racks in a colo space and add a server every other day (or you continue renting servers, if that's your style). Out of all the problems that arise from 10x-ing your organisation every year, this is a really minor one.
would prefer to spend 20-30-50 USD and get a managed deployment infrastructure with rollback, blue/green deployment, github integration and so. this setup can last a long time.
I think one of the reasons is that people confuse physical servers with manual administration. As I said, I do not do manual administration. Nothing ever gets configured on any server by hand. All administration is through ansible.
I only have one ansible setup, and it can work both for virtualized servers and physical ones. No difference. The only difference is that virtualized servers need to be set up with terraform first, and physical ones need to be ordered first and their IPs entered into a configuration file (inventory).
Of course, I am also careful to avoid becoming dependent on many other cloud services. For example, I use VpnCloud (https://github.com/dswd/vpncloud) for communication between the servers. As a side benefit, this also gives me the flexibility to switch to any infrastructure provider at any time.
My main point was that while virtualized offerings do have their uses, there is a (huge) gap between a $10/month hobby VPS and a company with exploding-growth B2C business. Most new businesses actually fall into that gap: you do not expect hockey-stick exponential growth in a profitable B2B SaaS. That's where you should question the usual default choice of "use AWS". I care about my COGS and my margins, so I look at this choice very carefully.
I'll be the counter opinion for this. Let's say you're Sprocket Masters, and you have to run two front ends (a Sprocket Sales site and a Sprocket Repair site) and a backend connecting them. But ultimately your sprockets are made in your factory on-site, and the majority of your staff is related to the manufacture of sprockets.
You're not a software company, fundamentally you make and sell Sprockets.
The opinions here would be hire a big eng/IT staff to "buy and maintain servers" (PaaS is bad) and then likely "write a bunch of code yourself" (SaaS is bad) or whatever is currently popular here (last thread here it was "Pushing PHP over SFTP without Git, and you're silly if you need more" lol)
But I believe businesses should do One Thing Well and avoid trying to compete (doing it manually) for things outside of their core competency. In this case, I would definitely think Sprocket Masters should not attempt to manage their own hardware and should rely on a provider to handle scaling, security, uptime, compliance, and all the little details. I also think their software should be bog-standard with as little in-house as possible. They're not a software shop and should be writing as little code as possible.
Realistically Widget Masters could run these sites with a rather small staff unless they decided to do it all manually, in which case they'd probably need a lot larger staff.
The core business for Sprocket Masters isn't really tech stuff: it's making sprockets. For those kind of businesses it makes a lot of sense; the tech stuff is required, but only in the sane sense that a phone line or electricity is.
However, what I also see – and what I think the previous poster was talking about – are businesses where tech is at the core of the business, and there it often makes less sense, and instead of saving time it seems to cost time. There's a reason there are AWS experts: it's not trivial. "Real" servers also aren't trivial, but also not necessarily harder than cloud services.
"Tech" isn't a thing. If I ran a company that produced CAD software, I would work in "tech", but I would have no reason to believe that my competency in writing CAD software should translate to competency in maintaining web servers or network infrastructure.
You still have to do all that with cloud though - instead of firewalls and IP tables it’s VPCs, IAM, security groups, auto scaling groups, etc etc. The reason I think it’s still probably better for Sprocket Masters to go cloud is purely because those skills are easier to hire for.
Sounds like Sprocket Masters should really outsource their two sites to a an agency that specialises in maintaining such solutions for SMEs, then they wouldn't need to concern themselves with the nitty gritty of hosting/backups/security/updates etc…
> . In this case, I would definitely think Sprocket Masters should not attempt to manage their own hardware and should rely on a provider to handle scaling, security, uptime, compliance, and all the little details.
But Sprocket Masters still has to have an expensive Cloud Consultant on retainer simply to respond to emergencies.
If you're going to have someone on staff to deal with the cloud issues, you may as well rent a server instead.
When the web was starting, that was the hardest sell to companies. They don't want to worry about those technical staff they just want a website/ecommerce working and not putting too much resource on it. Then social media happens and those sites just became status symbols or just to retain the email address.
it's not all or nothing. There's plenty of cases where using AWS or similar makes sense, but using the cloud for absolutely everything has a bunch of costs, both visible and invisible. Nuance and taste are the hardest things to teach, and these are in short supply in many engineering orgs.
Because cloud is the new "No one gets fired for using IBM". If you are using dedicated servers somewhere, you cannot have the same reputation of say Using AWS for cloud. Everyone knows the AWSs, Google Cloud etc and no one gets fired for selecting/using them.
I personally have run Dedicated Servers for our business in the earlier days but as we expanded and scaled, it became a lot easier to go with the Cloud providers to provision various services quickly even though the costs went up. Not to mention it is a lot easier to tell a prospective customer that you use "cloud like AWS" than "Oh we rent these machines in a data center run by some company" (which can actually be better but customers mostly wont get that). Audit, Compliance and others.
> trivially solved with one or two dedicated servers...
For many even lot less than that. I run a small side project[1] that went viral a few times (30K views in 24 hours or so) and it is running on a single core CPU web server and a managed Postgres likewise on a single CPU core. It hasn't even been close to full utilization.
I feel like many people use the cloud "wrong". If you're just standing up VMs then yeah, it's going to be slower and more expensive than renting a physical server. If you're just going to setup VMs and pretend you're still on-prem you're better off not switching. But I've got projects setup on PaaS services that literally cost a few bucks a month because it's only charging me for actual use and not idle time. I've got some small customers (tens of thousands of users) who I've helped move into the cloud who see the same thing. They have SPA websites backed by lambda functions and on-demand databases. If their website isn't being hit, it's not costing them anything at all. The only lock-in is the boiler plate code around the lambda activation which could be switched fairly easily to target any Functions as a Service platform.
I'm curious to know what on-demand databases do you use with AWS Lambdas? Two options that I've evaluated are: Aurora Serverless v2, which isn't quite serverless in practice and DynamoDB. And the mental model for DynamoDB very different from that of traditional SQL databases.
I’m actually primarily building on Azure with Cosmos DB. The mental model is very different, but I think important if you want to build cheap cloud services. I think that’s the larger point. You have to think about doing things differently in the cloud otherwise you’re just deploying and managing VMs as if you were on-prem albeit with more scaling control. It feels like everyone who is complaining about how expensive cloud hosting is go into it thinking it’s just someone else hosting the VMs where as a VM is the option of last resort for me.
I am responsible for about 10-12 t3.medium-class servers (number includes redundant servers) and the services running on them. All of them are fairly overprovisioned for what they are, excepting that the monitoring system we use on them for some reason likes to consume about half-a-gig of RAM so I can't run on even smaller servers. I write my services in Go, so the CPU isn't sitting there spending 98% of its time chasing pointers and can use multiple CPUs as needed for its heavy-hitting tasks. It's a rough day for those servers when they pass 5% average CPU for the day.
Could I switch some of them to lambda functions? Or switch to ECS? Or switch to some other cloud service du jour? Maybe. But the amount of time I spent writing this comment is already about six month's worth of savings for such a switch. If it's any more difficult than "push button, receive 100% reliably-translated service", it's hard to justify.
Some of this is also because the cloud does provide some other services now that enable this sort of thing. I don't need to run a Kafka cluster for basic messaging, they all come with a message bus. I use that. I use the hosted DB options. I use S3 or equivalent, etc. I find what's left over is almost hardly worth the hassle of trying to jam myself into some other paradigm when I'm paying single-digit dollars a month to just run on an EC2 instance.
It is absolutely the case that not everyone or every project can do this. I'm not stuck to this as an end-goal. When it doesn't work I immediately take appropriate scaling action. I'm not suggesting that you go rearchitect anything based on this. I'm just saying, it's not an option to be despised. It has a lot of flexibility in it, and the billing is quite consistent (or, to put it another way, the fact that if I suddenly have 50x the traffic, my system starts choking and sputtering noticeably rather than simply charging me hundreds of dollars more is a feature to me rather than a bug), and you are generally not stretching yourself to contort into some paradigm that is convenient for some cloud service but may not be convenient for you.
> Even the mere suggestion of renting a dedicated server provokes scorn from devops teams.
Have you ever had to manage one of those environments?
The thing is, if you want to get some basic more-than-one-person scalability and proper devops then you have to overprovision by a significant factor (possibly voiding your savings).
You're inevitably going to end up with a bespoke solution, which means new joiners will have a harder time getting mastery of the system and significant people leaving the company will bring their intimate knowledge of your infrastructure with them. You're back to pets instead of cattles. Some servers are special, after a while automation means "a lot of glue shell scripts here and there" and an OS upgrade means either half infra is KO for a while or you don't do OS upgrades at all.
And in the fortunate case you need to scale up... You might find unpleasant surprises.
And don't ever get me started on the networking side. Unless you're renting your whole rack and placing your own networking hardware, you get what you get. Which could be very poor in either functionalities or performances... Assuming you're not doing anything fancy.
> The thing is, if you want to get some basic more-than-one-person scalability and proper devops then you have to overprovision by a significant factor
If you want 100.0000% uptime, sure. But you don't usually. The companies that want that kind of uptime normally has teams dedicated to it anyway.
And scaling works well on bare-metal too if you scale vertically - have you any idea the amount of power and throughput you can get from a single server?
It's concerning to keep hearing about "scaling" when the speaker means "horizontal scaling".
If you requirements are "scaling", then vertical scaling will take you far.
If your requirements are "horizontal scaling on demand", then, sure, cloud providers will help there. But, TBH, few places need that sort of scaling.
Just getting a highly available storage with any kind of performance requires you to overprovision by something like 12x (3 boxes with raid 1+0) which is frankly insane. And then you have to manage it and fix it when it inevitably breaks. The team who’s supposed to do that will be swamped by trying to keep the other 15 infrastructure services running and upgraded to a version which is only barely out of vendor support.
> Just getting a highly available storage with any kind of performance requires you to overprovision by something like 12x (3 boxes with raid 1+0) which is frankly insane.
I'm not saying 100% uptime on bare metal is cheap, I'm saying 100% uptime is frequently not needed.
Its big companies - their priorities are different. Saving a couple million dollars isn't worth the tradeoff of not being industry standrd (AWS, Google, MS). They hire tech consulting companies who sell their product, large deployments.
IME aiming for scalability is exceedingly wrong for most services/applications/whatever. And usually you pay so much overhead for the "scalable" solutions, that you then need to scale to make up for it.
Having talked to AWS evangelists, it seems that they truly believe it cuts costs. In their reality this is true, because an alternative with the same guarantees and risk costs more. The implicit disagreement is that you often don’t need all those guarantees.
> because an alternative with the same guarantees and risk costs more
I really doubt this. The one theme you see on almost every AWS proponent is some high amount of delusion about what guarantees AWS actually provides you.
Hmm. I guess there's guarantees that it won't happen, and guarantees that if it happens then it wasn't supposed to and can't be your fault, and the latter may still be pretty attractive to some decision-makers.
> if it happens then it wasn't supposed to and can't be your fault
Yeah, sure. Nobody gets fired for buying from IBM.
Well, if large companies had any competence in decision-making, they would be unbeatable and it would be hopeless to work on anything else at all. So, yeah, that's a public good.
Anybody with experience on the ops side of that is absolutely in favor of simple and easy to understand -- and that often gets you cheap as a side effect.
In my experience those devops people where hired and empowered by senior managers to make things expensive and complicate because the company is 'enterprise' and has to follow "industry best practices"
if you need durability in the cloud you just pick any object storage service from the 3 bigs, and a db with multiple deployment with automatic replication and managed failover.
getting the equivalent reliability with irons is a lot more expensive than renting "two dedicated servers" - now you might be fine with one server and a backup solution, and that's fair. but a sysad to create all that, even on a short contract for the initial setup and no maintenance, is going to go well beyond the cloud price difference, especially if there's a database in the mix and you care about that data.
I'm not saying there's no place for cloud, but that many workloads benefit from using dedicated hardware. It is often much simpler to deploy to a dedicated server rather than spending months rearchitecting your system (or even worse, cutting customer facing features!) to efficiently make use of many small cloud instances.
There are several reasons for that:
- lack of knowledge how to maintain own servers on premises
- MASSIVE PR by a handful of top tier cloud providers to instill the notion that cloud is the only solution, the best one and most advanced technologically and attractive silk set wise
- hockey stick growth expectations of (past days) startups from investors, forming the mindset that it must be met from day one in deployment
- “no one got fired for buying IBM” managers/tech leaders mentality, where IBM is replaced with “cloud”
- difficulty obtaining true costs information of cloud vs on premises deployment. For example - a team of ~16 people already pays off the costs of dedicated sysadmin to maintain on premises servers
- etc.
As a developer I appreciate the compartmentalization, being able to make truly isolated changes. This is something that's not trivial for lots of folks, me included. I guess if one has the expertise in house to manage a K8s cluster on a raw machine, that'd be an option but I, personally, am not gonna touch that with a ten foot pole. So yeah with a big and capable enough infrastructure team that complexity could be abstracted away but in reality I (where I've worked) haven't seen that yet.
Growth hides sins. I ran a large self-funded enterprise service at a loss for 4-5 years, which is possible if you are growing 30%.
Today, cloud is similar - the time to market is quicker as there are less moving parts. When the economy tanks and growth slows, the beancounters come in and do their thing.
the most funny thing is that cloud engineering teams have no problem of using EC2 hosts, but somehow don't want to rent dedicated servers/VPC from regular datacenter companies.
This only makes AWS richer at the expense of companies and cloud teams
> the most funny thing is that cloud engineering teams have no problem of using EC2 hosts, but somehow don't want to rent dedicated servers/VPC from regular datacenter companies.
It is trivial to provision and unprovision an EC2 instance automatically, within seconds if your deployment needs to scale up or scale down. That's what makes it fundamentally different from a bare metal server.
Now, I'm not denying that it might still be more cost effective when compared to AWS to provision a few more dedicated servers than you'll need, but when you have really unpredictable workloads it's not easy to keep up.
the whole concept of a need to spin up more VM instances to meet increased load is flawed and is driven by cloud vendors to make money.
if you are spinning up and shutting down VMs to meet demand curve - something is seriously wrong with your architecture.
Did it ever occur to you, how come stackoverflow uses ~8 dedicated servers to serve entire world and doesn't need to spin up and shutdown VMs to meet global customer demand?
--
When planning compute infrastructure, it is important to go back to basics and not fall for cloud vendor's propaganda
> serve entire world and doesn't need to spin up and shutdown VMs to meet global customer demand?
You said it yourself. Not all applications need to serve entire world, therefore demand will be lower when people go to sleep.
Even with global applications there are regulations that require you to host applications and data in specific regions. Imagine an application that is used by customers in Europe, Australia, and the US. They need to be served from regional data centres, and one cluster will be mostly sleeping when the other is running (because of timezones). With dedicated servers you would waste 60-70% of your resources, while using something like EC2/Fargate you can scale down to almost 0 when your region is sleeping.
I can use a 4$ VPS for my own personal cloud. I will never pay 45$ for that.
There's a whole band of people who have the technical chops to self-host, or host little instances for their family/friends/association/hiking club. This small margin where you're ok to spend a little extra because you want to make it proper, but you can't justify paying so much and spend time doing hard maintenance. A small VPS, with a shared Nextcloud or a small website, is all that's needed in many cases.
I’ve self hosted my own stuff for close to a decade now. Nobody has tried DDoSing my setup, because why would they? What benefit would they possibly get out of it? I would be pretty much the only person affected, and once they stop it wouldn’t take long to recover.
There is little to no incentive to DDoS a personal box, let alone by a “internet rando”.
The chance of meeting someone online that’s that immature and spiteful, and at the same time possesses enough knowledge to successfully execute a DDoS attack is infinitesimally small.
> enough knowledge to successfully execute a DDoS attack
You are drastically overestimating a teen's abilities.
Just pinging the IP over and over again isn't really going to do much. Maybe a DoS attack depending on what the target network has in terms of IPS, but even then it's more likely they'll infect their computers with viruses before they get the chance to actually attack you.
I've remember when I've played Rust, year or two ago on public server.
Some kid was mad, because thought that some one was cheating.
He managed to DOS that server.
And globally it doesn't sound hard: google -> ddos > low orbit ion canon(as one of the most famous) -> fire in the hole!
Especially if you are dumb enough to just run that tool as is, without any tries to hide your own personality.
On the contrary, you're vastly underestimating the availability of various "booting" and "IP stressing" services that sell a 30 minute 1Gbps+ DDoS attack to anyone for $5. Launching a DDoS attack is just as easy, if not easier than, signing up for Netflix. A simple search for "IP stresser" should yield dozens if not hundreds of results.
I've personally been on the receiving end of one of those for somehow pissing off a cheater in GTA 5. It definitely happens and it's not fun.
That’s interesting. Do use a dynamic IP at home in this case or static? If it’s dynamic, what does the update process look like?
Edit: It looks like this might be automatic. This is something interesting I should look into a bit. It’s probably just extra complexity for my little server, but I’ve got some uses in mind.
like dvdkon says, only the VPS has a static public address, and my homelab reaches out to keep the tunnel alive.
Tehcnically my homelab is also on a static public IP as well--this was more an exercise in "could I do this" than "actually necessary," but it's still cool as hell and I'm very happy.
About the only hangup was I had to configure Wireguard to keep the tunnel alive, otherwise sometimes the VPS would receive incoming traffic and if my lab hadn't reached out in a while (which, why would it?) the tunnel would be down, and the proxy connection would die. Thankfully that's built-in functionality.
No, unfortunately I haven’t built an RSS feed for my blog. I thought RSS was dead, but I’ve noticed a resurgence lately. My blog is a big collection of markdown files these days. I don’t even run the static site generator myself, just using whatever default Jekyll magic GitHub Pages does. Maybe this is something I should get to soon.
I found Atoms to be unbearably slow, even with Linux. Of course it’s enough for serving websites and whatnot, but it’s baffling how much power they use just… not performing.
You get a lot for the bucks, good luck finding a VPS with those spec for less. And the power cunsumtion is the DC problem - maybe they run on solar, wind, hydro...
> I can use a 4$ VPS for my own personal cloud. I will never pay 45$ for that.
Exactly. These sub-$10 VPS instances are great for small projects where you don't want to enter into long contracts or deal with managing your own servers.
If you're running an actual business where margins are razor-thin and you've got all the free time in the world to handle server issues if (when) they come up, those ~$50 dedicated servers could be interesting to explore.
But if you're running an actual business, even a $10,000/month AWS bill is cheaper than hiring another skilled developer to help manage your dedicated servers.
This is what's generally missed in discussions about cloud costs on places like HN: Yes, cloud is expensive, but hiring even a single additional sysadmin/developer to help you manage custom infrastructure is incredibly expensive and much less flexible. That's why spending a hypothetical $5000/month on a cloud hosted solution that could, in theory, be custom-built on a $50/month server with enough time investment can still be a great deal. Engineers are expensive and time is limited.
> But if you're running an actual business, even a $10,000/month AWS bill is cheaper than hiring another skilled developer to help manage your dedicated servers.
Uhhh, excuse me but how much are you paying this DevOps guy? This seems like a very American perspective, even valley area. In Europe, hiring a guy would be cheaper.
> Uhhh, excuse me but how much are you paying this DevOps guy? This seems like a very American perspective, even valley area. In Europe, hiring a guy would be cheaper.
AWS is very cost efficient for other services (S3,SES,SQS, etc) but virtual machines are not a good deal. You get less RAM & CPU, with the virtualization overhead, and pay a lot more money.
Especially for Postgres if you run some tests with pgbench you can really see the penalty you pay for virtualization.
Maybe the sysadmin skill of being able to build your own infrastructure is becoming a lost art, otherwise I can't explain why people are so in love with paying 5x for less performance.
Hetzner is cheap and reliable in Europe, if you're in North America take a look at OVH. Especially their cost-saving alternative called SoYouStart. You can get 4/8 4.5ghz, 64 RAM and an NVME drive for $65.
(I have no affiliation with OVH, I'm just a customer with almost 100 servers, and it's worked out great for me)
AWS’s value proposition is dead simple to understand if you’ve actually used it. You said it yourself. AWS gets you through the door with their managed services, meta components (like billing and IAM), and whatever else. Saying even in a tongue in cheek way that people are in love with paying more for less raw power isn’t giving people enough credit. I know I could get a better cost per hertz elsewhere, or whatever. That’s not the whole equation.
Yeah, raw compute is only one of many things I need to optimize for now. For many use cases compute is a solved problem. What I do think about is ease of backups, restores, ability for multi-region, scaling, deploys, then the many other services I don't need to build and maintain. If my problem was compute constrained then sure, back to metal. Or, if my business is so big I can handle the cost, yeah run my own DCs.
I'll also note that I'm old hehe, and one of my first jobs we had a decent sized data center on site. Dealing with SANs, tape drives (auto tape rotators at the time were garbage), servers, etc... was a huge PITA. Packing up tapes and shipping them to another office for location redundancy was always fun.
I understand what you're saying. It might come down to use-case.
The particular application I manage really suffers from low GHz and not having all data in memory. Ive run the benchmarks on EC2, certain reports that finish in ~5 seconds can take more than a minute on a comparable EC2 instance that costs about 10x as much. This application really needs the raw CPU. and yes we have a pretty large engineering team that has optimized all the queries, índices etc.
As far as replication, backups, etc. I set all that up, and honestly it wasn't a big deal. It's a couple short chapters in the Postgres book that explain it all very simply, how to configure, continuously (and automatically) test, etc.
I do agree that SANs are a nightmare. Thats why I ship all my WALs (PG backup files) to S3 (and eventually Glacier). That way I don't have to think about losing those files and it's dirt cheap.
I think there's a misconception that these kinds of configurations are too complicated for a single engineer to setup, with never ending maintenance required. In reality you can set it all up in less than a week and it only really needs maintenance when you want to upgrade Postgres (some settings may have changed). I'd estimate it takes about 5 hours per year of maintenance.
I'm not sure if cloud has a valid value-proposition. The more I explore and build the more irrelevant it seems for the average developer. Besides price and performance being obvious concerns, it's also a platform. Working with it fundamentally ties your business to a set of products. Historically, this hasn't worked well for Internet businesses. Plus, all the benefits of cloud can be mirrored by traditional servers.
Self-serve infrastructure appears likely to become increasingly viable as we continue improving last mile delivery and expand fiber access. Will cloud become self-cannibalizing? Definitely maybe.
That could have been true if the industry had not screwed up IPv6 and security so badly that it's actually rare for even good internet connections to expose their end users to full inbound internet traffic so it's actually harder to self host out of your basement today then it was 20 years ago because of the prevalence of ISP supplied hardware firewalls for todays consumer internet.
What cloud gets you is the ability to put your data/workload right at the core without having to make special deals with your local isp, and with a lot more resilience then you would likely afford unless your at least at the multiple 20 foot container full of servers scale of compute need.
Edit: If anyone is interested in self-hosting, it's stupid simple with cloudflared. I have a 2017 Google Pixelbook running Ubuntu on custom firmware that's serving a Flask-based website. It sits on my desk charging while connected to a guest wifi network. It receives a 100/100 Mobile PageSpeed score and takes 0.8 seconds to fully load.
From what I've been able to find, the kind of pricing OP is talking about for a dedicated server is only available in Europe and possibly even only through one provider (Hetzner). I looked around and could only find dedicated servers in Asia that were pretty much the same specs as what I'm getting for a similar price from DigitalOcean (for a Singapore VPS), except coming from shady looking companies with bad websites filled with flashing ads.
From DO I get all the benefits of a reliable company, scalability, automated backups etc etc. There's no way I'd change.
Hetzner cloud now has two US locations... Still no US dedicated servers though - those would kick real ass. Even if their current cloud offerings themselves are already ~30% of the price of the major cloud equivalents...
I was upset last week when I saw how much our managed Postgres service cost us at work. $800 for the month, it's storing around 32GB of data, and is allocated 4 CPU cores.
Like you, I also run my services from a rented physical server. I used to use Versaweb, but their machines are too old. I didn't previously like Hetzner because I'd heard bad things about them interfering with what you're running.
However, I moved to them in December when my Versaweb instance just died, probably SSD from old age. I'm now paying 50% of what I paid Versaweb, and I can run 6 such Postgres instances.
Then it makes one wonder whether it's worth paying $700 of $800 for a managed service with a fancy cloud UI, automatic upgrades and backups, etc.
For a 1 person show or small startup, I think not. Cheaper to use an available service and dump backups to S3 or something cheaper.
$800 for the month, it's storing around 32GB of data, and is allocated 4 CPU cores.
Company I used to work for happily paid company A four times what company B charged for the exact same service, just because company A was willing to send quarterly invoices in way that played nicely with our invoicing system. For companies, saving a few hundred bucks here and there often isn't worth the hassles of introducing any extra friction.
I pointed out a difference like that once to the CTO, who then proceeded to show me the financials for the service. We were making something like a hundred thousand dollars a month from it (i had no idea, seemed like we only had a few clients... but they paid A LOT). $400 wasn't worth spending time thinking about. Especially if it might cause downtime.
for a startup, it might actually make more sense. Do you want to pay an engineer to setup the backups and monthly update cycle? Setup the alert monitoring?
There is an implicit cost there. If its only one or two of those things, just take the managed services.
If you start to scale, get an administrator type of employee to save on this
Managed PostgreSQL seemed worthwhile for an early startup that couldn't afford to lose an hour of production data.
Otherwise, I'd have to hire/contract someone very experienced, or dedicate a solid month or more of my time (which was not available), just to be 100% sure we could always restore journaled PITR backups quickly.
I can save orders of magnitude on cloud costs other places, but credible managed PostgreSQL was a pretty easy call (even if the entry-level price tag was more than you'd expect).
> Managed PostgreSQL seemed worthwhile for an early startup that couldn't afford to lose an hour of production data.
An early startup that cannot afford to lose an hour of production data is probably too fragile to survive anyway.
It's an early startup - there's going to be larger interruptions than that to the service and any customers who flee after a one hour loss of production data just didn't value the product enough anyway.
Different startups have different needs, and sometimes you have to try something with demanding technical/process execution, to possibly win big at something not everyone could pull off successfully.
(In the specific startup I was thinking of, I already had some nice automated frequent DB-online dumps to S3 with retention enforced, but I didn't think that was good enough for this particular scenario. But not being sure we coudl recover with PITR/journaling would adding a new single point of failure gamble on the success of a business that otherwise might have a 9+ figure exit in a few/several years, just to save a few hundred.)
Also, I suppose that some of the early startups that have less demanding needs, but are cavalier about their obligations towards customers'/users' data, are still being negligent wrt minimum basic practices.
Maybe one intuitive way to appreciate: Imagine a biz news story on HN, on some startup operations dropping of the ball, with startup founders' names attached, and the story says "...and it turns out they didn't have good backups...". Then one of the cofounders, who's maybe not slept much as their company is crashing around them, responds "Customer data isn't that important in an early startup; if it were, we'd be too fragile" (typed before the cofounder could throw that person's laptop across the room to stop them typing). It wouldn't be a good look.
> Imagine a biz news story on HN, on some startup operations dropping of the ball, with startup founders' names attached, and the story says "...and it turns out they didn't have good backups...".
ITYM "...and it turns out they didn't have the last hour backed up..."
I can imagine everything in your scenario, even the unsnipped bits, and it all seems normal, unless you read "Our startup clients, who've been using us for a month, all left immediately when we lost the last hour of their data".
I really can't imagine that scenario.
Now, granted, there are some businesses where the benefit to using it is that there is not even an hour of lost data.
IOW, customers use it because it won't lose any data: online document collaboration[1], for example[2]. If you have a meltdown that loses an hour of the last inputted data, then sure, expect all affected current users to flee immediately.
[1] Although, personally, I'd mitigate the risk by duplicating the current document in localstorage while it is being edited.
[2] Maybe stock exchange also needs the system to keep the last hour of data? What else?
I’ve come to the same conclusion. Whenever I’ve looked at managed database pricing, I’ve always wanted to just do the management myself and just rent the underlying computation and storage.
I think even for larger teams it may make sense to manage databases yourself, assuming you have the competence to do it well. There are so many things that can go wrong with managed services and they don’t hide the underlying implementation the way that things like block storage or object storage do.
I would suspect it’s because of memory. I remember years ago my cheap 512m mem vps is easily bottlenecked by pg’s memory usage. CPU is idle when idled, memory eat by pg does not get released. Scaling memory is not cheap. Memory is the “scarce” for cloud hosting.
I went the opposite direction at Hetzner with the last round of price hikes. I now use multiple of the Hetzner Cloud instances for my personal projects, for 1/4 of the price (most of the time) or for more if I am messing with something in particular.
Peak performance is certainly worse - but I am not too bothered if something takes longer to run anyway. You are certainly correct on having as much automation in the provisioning of a server, something I did not do with a physical server.
I used to have a root server for my pet projects, but honestly, that doesn't make sense. I'm not running a high traffic, compute intense SaaS on my machines. It's just a static website and some projects. I'm down to monthly costs of 24€, which includes a storage box of 1 TB to store all my data.
Static website I like the combo of Git(Hub,Lab) Pages and Cloudflare fronting it for SSL/domain name. Nice and free, and if I want to move elsewhere it's also simple enough.
You must have great and ultrareliable service. My monthly cost is just over $8 and I have one 1TB storage and one 2TB storage besides three little machines.
I would actually say just invest in the hardware and count the asset depreciation on taxes. Further, “scaling” horizontally is rather easy if you properly separate functions into different servers. For example, a few really light machines running nginx (with fastcgi cache enabled, because yes) behind an haproxy machine, your PHP/Python/JS/Ruby machines behind your nginx machines, and your DB cluster with TiDB or something behind that. You’ve removed the overhead of the container systems and the overhead of the virtualization platform. You’re no longer sharing CPU time with anyone. You’re not experiencing as many context switches or interrupts. The cost is all upfront though. You will still pay for bandwidth and power, but over time your cost should be lower.
The main issue in any scenario involving real hardware is that you need staff who are competent in both hardware and Linux/UNIX systems. Many claim to be on their resumes and then cannot perform once on the job (in my experience anyway). In my opinion, one of the major reasons for the explosion of the cloud world was precisely the difficulty in building and the financial cost of building such teams. Additionally, there is a somewhat natural (and necessary) friction between application developers and systems folks. The systems folks should always pushing back and arguing for more security, more process, and fewer deployments. The dev team should always be arguing for more flexibility, more releases, and less process. Good management should then strike the middle path between the two. Unfortunately, incompetent managers have often just decided to get rid of systems people and move things into AWS land.
Finally, I would just note that cloud architecture is bad for the planet as it requires over-provisioning by cloud providers, and it requires more computer power overall due to the many layers of abstraction. While anyone project is responsible for little of this waste, the entire global cloud as an aggregate is very wasteful. This bothers me and obviously likely factors as an emotional bias in my views (so large amounts of salt for all of the above).
Generally agree but in the US at least from a financial and accounting standpoint you can actually do better than the favored op-ex of cloud services with a Section 179[0] lease[1]. Caveat here, of course, is that you have to have income.
The argument could be made you can develop a means to to rent physical servers pre-income, then, when it makes sense, you can either use standard depreciation -or- Section 179 on outright purchases and/or Section 179 leases.
As an example, you can deploy an incredibly capable group of let's say four absolutely ridiculous completely over-provisioned $100k physical 1U machines in different colo facilities for redundancy. There are all kinds of tricks here for load balancing and failover with XYZ cloud service, DNS, anycast, whatever you want. You can go with various colo facilities that operate datacenters around the world, ship the hardware from the vendor to them, then provision them with Ansible or whatever you're into without ever seeing the facility or touching hardware.
So now you have redundant physical hardware that will absolutely run circles around most cloud providers (especially for I/O), fixed costs like all you can eat bandwidth (that doesn't have the 800% markup of cloud services, etc) - no more waiting for the inevitable $50k cloud bill or trying to track down (in a panic) what caused you to exceed your configured cloud budget in a day instead of a month. Oh btw, you're not locking yourself into the goofy proprietary APIs to provision and even utilize services other than virtual machines offered by $BIGCLOUD.
If you're doing any ML you can train on your own hardware or (or the occasional cloud) and run inference 24/7 with things like the NVIDIA A10. Continuous cloud rental for GPU instances is unbelievably expensive and the ROI on purchasing the hardware is typically in the range of a few months (or way ahead almost immediately with Section 179). As an example, I recently did a benchmark with the Nvidia A10 for a model we're serving and it can do over 700 inference requests/s in FP32 with under 10ms latency. With a single A10 per chassis across four healthy instances that's 2800 req/s (and could probably be tuned further).
Then, if you get REALLY big, you can start getting cabinets and beyond. In terms of hardware failures as mentioned, all I can say is dual PS RAID-ed out, etc hardware is (in my experience) extremely reliable. Frankly having had multiple full cabinets of hardware in the past hardware failures were few and far between and hardware vendors will include incredibles SLAs for replacement. You notify them of the failure, they send a tech in < eight hours directly to the colo facility and replace the disk, PS, etc with the flashing light.
My experience is one (good) FTE resource can easily manage this up to multiple cabinet scale. To your point, the current issue is many of these people have been snatched up by the big cloud providers and replaced (in the market) with resources that can navigate the borderline ridiculousness that is using dozens (if not more) products/services from $BIGCLOUD.
I've also found this configuration is actually MUCH more reliable than most $BIGCLOUD. No more wondering what's going on with a $BIGCLOUD outage that they won't even acknowledge (and that you have absolutely no control over). Coming from a background in telecom and healthcare it's completely wild to me how uptime has actually gotten much worse with cloud providers. Usually you can just tell customers "oh the internet is having problems today" because they'll probably be seeing headlines about it but for many applications that's just totally unacceptable - and we should expect better.
I do exactly this, using Hetzner as well. I was managing some side projects and self-hosting and the bill just seemed to creep up because the VPS's we never power enough to host. I started feeling the need to add more VPS's and then I started shopping around. In the end I got a similar deal and specs. I can do anything I want with it now and even with quite a few self hosted services and projects I'm still running at only about 10-15% capacity.
If I want to spin up a new project or try out hosting something new it takes a couple minutes and I've got the scripts. Deployments are fast, maintenance is low, and I have far more for my money.
For anyone who's interested this is the rough cut of what I'm using:
* Ansible to manage everything
* A tiny bit of terraform for some DNS entries which I may replace one day
* restic for backups, again controlled by ansible
* tailscale for vpn (I have some pi's running at home, nothing major but tailscale makes it easy and secure)
* docker-compose for pretty much everything else
Your management tools are quite similar to what I use. Ansible, terraform for disaster recovery and development cloud systems, several approaches to backups (duplicity+gpg, rsync), ansible+docker for updating certs, VpnCloud for VPN, docker containers for various things.
Main app is Clojure, so I run a native JVM. Database is fully distributed, RethinkDB, now working on moving to FoundationDB.
The important thing is not to manage anything manually, e.g. treat physical servers just like any other cloud server. It shouldn't matter whether it's physical or virtualized.
In 2015 I worked in a project where really big servers (lots of RAM, fast SSDs) where needed for large database. The client had preferred AWS, but the monthly bill would have been something like 30K Euros. So, they went with Hetzner for a few hundred bucks a month ...
Don't discount your local colo, either. I pay $75/month for 2U, a gigabit Ethernet link to a router two hops from the metro SONET ring in Albany, NY, and 1 mbps 95th percentile bandwidth. I've got a router, a switch, and a 1U 32-core AMD Bulldozer box in there hosting VMs (it's past due for replacement but running fine).
Yes, you're supporting your own hardware at that point. No, it's not a huge headache.
And with that computing power it's easy to install qemu-kvm and virtualise your own servers which is more scalable (and easier to move when the hardware you're renting becomes redundant) than having one or two monolithic servers with every conceivable piece of software installed, conflicting dependencies, etc.
The biggest additional cost to this is renting more IPv4 addresses, which Hetzner charge handsomely for now that there are so few available.
Whatever you create, will start with 0 users, and an entire real machine is completely overkill for that 0 load you will get. You upgrade your VPS into a pair of real machines, then into a small rented cluster, and then into a datacenter (if somebody doesn't undercut that one). All of those have predictable bills and top performance for their price.
Modern server hardware can hit very low power states at idle just like modern desktops can. Most servers are also headless, so you’re not wasting power on a GPU. This means that you’re looking at a lower power bill if you’re not doing much. Likewise, you usually pay most for egress, and at low traffic that’s not much of an issue. Physical hardware can scale down exceedingly well. The main thing I would argue is that one own the hardware rather than rent.
It's hard to scale down the cost to the range of $4/month. I've seen offers for rented dedicated severs in that price range, and it's Core2 and similar.
Anything you own in a colo is going to be more per month too. When I had connections where I could pay for a static IP, that was usually $5/month.
I'm now renting a pretty low end server, but it's $30/month. Way more everything that I need, but it's nice. And they didn't drop support for my OS while increasing prices to improve support or something. (Although I did have some initially flakey hardware that needed to get swapped)
When colocating, contracts tend to pay for power at a fixed price based on provisioning (which has to be more than the max power that will be used). Power savings are generally irrelevant for the customer paying for colocation despite being a good thing for the data center.
I actually agree with you, it's just a little bit more expensive. An under-appreciated thing with dedicated servers is that they often come with very solid network bandwith, which really helps for use cases like streaming audio/video.
the cloud is the golden cage. companies, and people, got sold on comfort and ease of use whilst trapping themselves into vendor lock-in environment that is the california hotel. when they realize the problem, they are too deep in the tech and rewriting their codebase would be too complex or expensive so they bite the expense and keep on doing what they are doing. constantly increasing their dependency and costs and never be able to leave.
as you pointed out, bare metal is the way to go. is works the opposite of cloud - a bit more work at the beginning but a way lot less of expenses at the end.
In general I agree that physical servers are great, but I think it's important to note that for most people a $4/month VPS is more than enough. So actually 45€/month would be overkill in that case.
It can actually be an even better value if you are not based in Europe, because for certain countries they don't charge you VAT, so you effectively get everything ~20% cheaper.
1. Forces config to be reproducible, as VMs will go down.
2. You can get heavy discounts on AWS that reduce the pain.
3. The other stuff you have access to atop the VMs that's cheaper/faster once your stuff is already in the cloud
4. Easier to have a documented system config (e.g. AWS docs) than train people/document what special stuff you have in-house. Especially useful in hiring new folks.
5. You don't need space or redundant power/internet/etc on premesis. Just enough to let people run their laptops.
I've been on a physical server for years, but the problem is wear & tear and eventually they will shut down forever; unless you're willing to set up backups and a recovery plan for physical hardware failure, I'd stick with a VPS for now.
I used a VPS before that, but stopped and switched to a physical one because it was a better deal and we didn't run into CPU limit(ation)s.
Hmm. But every server goes down eventually. What's the difference whether it's a VPS or a physical one? I don't assume anything about my physical servers.
Ask in advance about who's responsible for hardware health monitoring, recommended tools for that, and how they handle hardware failures. Bonus - how they respond to such questions may separate the good providers of private rent-a-servers from the not-so-good ones.
Who faces the immediate consequences of failed hardware --- that's who needs to monitor it.
Disk monitoring isn't too hard though. For hard drives, run smartctl once an hour, alert when reallocated or pending sectors grows quickly or hits 100. For SSDs, cross your fingers; in my experience with a few thousand, they tend to work great until they disappear from the bus, never to be seen again. Have a data recovery plan that doesn't involve storage of the data onto the same model devices with very similar power on hours --- power on hour correlated firmware errors are real.
The problem with bare metal is quite sophisticated contingency plan for physical failure. With VMs when any one of them fails - you just re-run your Terraform/Ansible scipts, restore backup (if it was a stateful VM that failed) and voila, you are up and running again in minutes.
You have to provision a new server first, preferably the same or better configuration. And then restore all backups, because probably all your components didn't scale beyond one server yet.
No? Terraform can do all of that for me. I can order (and get it delivered), install, configure, and restore from backup with terraform in less than 2 minutes.
Hetzner has an API for ordering dedicated servers after all, and an API for installing an OS (or for rebooting to rescue and flashing whatever image you want)
For me I'm wondering about ISP overhead. When I rent a VPS I'm more confident in their uptime and that all the funky dns shit I'm less confident in will just work. I run a home server as a hobby and I had to do all sorts of weird negotiating with my isp to make sure I always have uptime. Then my shitty modem that the isp refuses to let me replace randomly resets my forwarded ports once every 6 months or so. Etc just weird shit like that.
I guess if I was investigating commercial options I'd have the "trunk" sorted at the office with a commercial isp solution, static IP, good IT hardware maybe, but from what I know at this exact moment if a client needed hosting I'd always go straight to renting a vps.
I'm not a devops guy but I had to manage our Ansible deployment at one of my first jobs and always despised it. Scripts that would work locally would often not work on the Ansible deployment, and it was hard to debug. The other engineer (don't think he had experience with it either prior to the job) also felt the same way.
I was more of a junior dev at the time so maybe I was an idiot, but I don't miss it at all. In theory I agree with what you're saying, but deploying a Dockerfile to something like Google Cloud Run is just a hell of a lot easier. Yea I'm paying more than what I would be managing my own VPS, but I think this is more than offset by the dev hours saved.
This absolutely works, but this comes at a later stage, perhaps after an MVP has picked up ground.
For a beginner, the cheapest ones get the work done.
I am sure that as cloud computing evolves, these offering become more common.
There is another aspect of cloud computing. The medium to large corporates, count cloud computing as single digit percentages on their cost calculations. This means that the decisions taken by managers and teams, often search for reliability and scalability (to be put on their presentations) rather than "is my setup costly or cheap".
Once you know you are going to use the machine for a while, buying two used server (one for backup) and co-locating them somewhere breaks even pretty quickly.
Usually the issue is that on-prem is seen as legacy and gets legacy budget and talent. Bigger companies are going to stick to a couple of big providers who don’t sell/rent iron.
My employer adopted cloud as a business/financial play, not a religious one. We often land new builds in the cloud and migrate to a data center if appropriate later.
The apps on-prem cost about 40% less. Apps that are more cost effective in cloud stay there.
I recall an HN user talking about their overly complicated cloud setup and … they found they could just do the job substantially faster on their local GPU.
That's a great option when you need servers in Europe. Hetzner offers cloud products only in its US datacenters, and as far as I know there are no dedicated server providers in the US with comparable pricing.
I think it's the case that AWS/GCP/Azure are not very cost-competitive offerings in Europe. What I'm not seeing is evidence of that for the US.
for the same spec, sure. I think virtuals make sense at both ends - either dynamic scalability for large N is important, or you only actually need a small fraction of a physical box. Paying 45/mo for something that runs find on 5/mo isn't sensible either, and gives you more flexibility for not ganging things together just to use your server.
How many nodes (droplets) do you spin up that you need Terraform? I do something similar but I use a single script to spin up the Digital Ocean side and then I complete the setup in Ansible (with an all-in-one master script, since the DO droplets are fetched with a handmade inventory plugin).
The whole VPS can go up in smoke fairly easily too, quite literally in some cases. There were a couple of small VPS providers hit buy the fire that took out one of OVH's data centres and either had no backups or had the backups on other machines in the same building. Heck, many cheap VPS providers don't have a reliable backup system at all, some are honest about it (and tell users to manage their own backups) and some are less so. Also remember that a small VPS provider will have low staff because the margins are low, so if there is any manual intervention needed to restore services when there is a hardware failure you might find spinning up a new VPS elsewhere, restoring your own backups¹, and switching over DNS, is faster than the hosting providers restore process. And their backups are often daily, with your own you may be able to efficiently manage much more frequent (hourly, or even perhaps near real-time if your apps are not write-intensive) snapshots. You aren't going to get a 1-hour max restore and 1-hour max data-loss guarantee for $4/month!
Keep backups in any case. Preferably on another provider or at least in a different physical location. And, of course, test them.
And if you are managing a good backup regime, and monitoring your data/app anyway, is monitoring drives a significant extra hardship?
--
[1] in fact if you automate the restore process to another location, which I do for a couple of my bits, then you can just hit that button and update DNS when complete, and maybe allocate a bit more RAM+cores (my test mirrors are smaller than the live VMs as they don't need to serve real use patterns).
Hijacking this—what are the main options here? I found pricing for Hetzner and OVH dedicated / bare metal instances easily enough, but I found it a little difficult to find information about other providers.
Not the parent commenter but I do basically the same as them. It really depends how much you're hosting and how much you want the latest updates. If I didn't want to do any updates to the selfhosted stuff I could probably spend 0 time a month. Most of the stuff I selfhost is only available over my VPN anyway so security isn't a huge concern on those.
Even if I did want to update, it's just a case of pulling the latest version into the docker-compose template and re-running the ansible playbook. Obviously if the upgrade requires more then so be it, but it's no different to any other setup work wise.
Probably the only thing I _need_ to do which I do manually is test my backups. But I have a script for each project which does it so I just SSH on, run the one-liner, check the result and it's done. I do that roughly once a month or so, but I also get emails if a backup fails.
So it can be no time at all. Usually it's probably 1-2 hours a month if I'm taking updates on a semi-regular basis. But that will scale with the more things you host and manage.
I don't see a difference between physical and VPS servers here. I manage everything using automated tools anyway. Why would this take longer for physical?
In other words, the only difference is where the ansible inventory file comes from. Either it's a static list of IPs, or it comes from terraform.
The person at the top of the thread claimed €45/month, but the configuration they're describing actually seems to be €37/month.
If you want ECC RAM, that appears to be €60/month, and it also steps up to a more powerful 8-core CPU.
Regardless, if we're talking about a "full production environment and a duplicate staging/standby environment" (to quote the person you replied to), then €60/month * (2 or 3) is still dirt cheap compared to any startup's AWS bill that I've seen.
Use cases vary, but I tend to agree that AWS/GCP/Azure is not the answer to every problem.
For someone who can fit their application onto a $4 VPS, that's obviously going to be cheaper than anything bare metal, but the cloud scales up very expensively in many cases. Bare metal isn't the answer to every problem either, but a lot of people in the industry don't seem to appreciate when it can be the right answer.
For 5 EUR / month you can also get a dedicated server (not a VPS) from OVH.
Sure it's only an ATOM N2800 with 4 GB of RAM / 1 TB SSD / 100 Mbit/s bandwith (which is definitely the bottleneck as I've got gigabit fiber to the home).
But it's 5 EUR / month for a dedicated server (and it's got free OVH DDoS protection too as they offer it on every single one of their servers).
I set up SSH login on these using FIDO/U2F security key only (no password, no software public/private keys: I only allow physical security key logins). I only allow SSH in from the CIDR blocks of the ISPs I know I'll only ever reasonably be login from and just DROP all other incoming traffic to the SSH port. This keeps the logs pristine.
Nice little pet these are.
I'm not recommending these 5 EUR / month servers for production systems but they're quite capable compared to their price.
I was going to recommend OVH too, they have such cheap offerings for VPS too (on the screen in the article, we see that their 4$ VPS has 500MB RAM (probably amazon lightsail), for that same price you get 2GB RAM on OVH VPS
I didn't see your 5€/month offer though
I'd think they are fit for production, a few services use them, like Lichess (can see their stack here https://lichess.org/costs )
Oh my bad: OVH is totally fit for production and they've got very good DDoS protection (which you can combine with CloudFlare and whatnots) but...
I just meant that I wouldn't recommend the 5 EUR / month dedicated servers for production: these do not have a big bandwidth and they don't have ECC RAM.
> just seems to null route YOUR ip if it receives more than a certain amount of traffic/second
This is not how it works. I recommend you go to the related webpages (just type "OVH antiddos" on Google), the anti-DDoS system is well documented nowadays.
If you _actually_ suffer from "null-routing"-like issues when the anti-DDoS triggers, you might want to get in touch with the support team to escalate the issue.
I have a feeling they may be very interested about this.
Seeing their single greatest cost line-item being "site moderation" (more than developer salary!) is such a stark reminder of where the real problems running an internet service are.
They're pretty much worthless. That atom processor hasn't even got support for AES-NI, meaning that all crypto must be done without hardware acceleration.
Basically all traffic (https? ssh? sftp? vpn?) is heavy duty for that procesor for the sole reason of existing.
I can literally see a cpu 100% busy because i'm downloading a file over sftp in another terminal.
Unless you're doing stuff in cleartext, which restricts the acceptable use cases by a lot.
Really, that kind of servers are really toys.
Also, in case of problems the datacenter people will just shut it off, replace it and re-provision it. I had the (single) disk fail on my kimsufi and the OVH people replaced it and rebooted my server to a blank state.
Ok fine, thank you and everything but where did my data go? Who's been handling my data on the PHYSICAL disk?
Had a similar experience with online.net's dedibox.
Was a customer for years, and one day they said my server had died and gave some excuse that there was no way to physically access the hard drive as it was in a rack of other servers or something along those lines.
So what happens to my data? It can't be recovered but when is it going to be securely destroyed?
I've got something called "Kimsufi 2G" which I've been paying for since 2013. It's only got 2GB of RAM and 500gb SSD, but it's been going strong since then. The same thing runs a small IRC and mumble server for my friend group. I use it primarily for wireguard and hosting random tiny projects.
Works really well, highly recommend it. I don't block traffic from anywhere since I travel a lot. It's interesting to open the nginx logs and see all the automated scans checking me out.
FWIW, if your Free Tier Oracle service seems to go "unused"--which isn't defined as far as I can tell, and the one I use as a DNS server was dinged for being "unused"--you run the risk of it being shut down and you have to restart it, unless you upgrade to a pay-as-you-go account.
This is a new thing as of last week, I think.
Also, Oracle Cloud's management interface is best described as "let's make this as complicated as AWS, but with more 'Enterprise-y' features, but somehow worse in every possible way."
That said, I can't fault Oracle for being Oracle. I knew what I was getting myself into. And their "Always Free" tier is still free. And it does work well enough for my purposes.
Idle Always Free compute instances may be reclaimed by Oracle. Oracle will deem virtual machine and bare metal compute instances as idle if, during a 7-day period, the following are true:
* CPU utilization for the 95th percentile is less than 10%
* Network utilization is less than 10%
* Memory utilization is less than 10% (applies to A1 shapes only)
Just run a `while :; do :; done` shell script under `nice` (to have lower priority than everything else) and then under `cpulimit` (to have an upper bound on CPU usage), or in a cgroup.
You're correct of course. My devils argument to that however is an increase from 0 to a natural number will always be a larger % increase than 4$ to 10$ etc.
The other argument would be paid for services tend to be setup with the expectation that the price will increase ( inflation for instance ). Where as an always free gives the expectation that it'll always be free and as such a user might specifically design their system to stay within that limit.
OVH "ECO Kimsufi" offering. Now... You'll need to "refresh" regularly the page for the 4.99 EUR one (I rounded @ 5 EUR but it's 4.99) for they're in demand and often sold out. Or you write a script that monitors the page to see when they're available again.
I had to wait a few days to fetch my last one but I got it. Always do : )
On OVH's website: OVH cloud / Bare metal & VPS / ECO Dedicated Servers.
P.S: back in the days the "Kimsufi" (french for "qui me suffit", literally "which is enough (for me)") used to be part of OVH, then OVH spun Kimsufi out of OVH and then now... Kimsufi are back into OVH (the older Kimsufi servers are still accessed using the old Kimsufi credentials but the newer ones are using the OVH credentials again).
Yes, I was able to snag one ($6.10) about an hour after I first checked, where it was originally disappearing after a split-second for me.
Just a small gotcha for anyone considering migrating off another platform: I only realized after purchase the 100Mbps advertised network bandwidth, versus a $5 Lightsail's advertised ~400-500 that I'm moving over from.
Another update for anyone seeing my parent post later on...
The OVH machine I ordered seems to be less smooth, and I'm simply running into issues. I am performing the same exact steps as I do on a 0.5 GB Lightsail instance, where it works just fine. My workloads just aren't working on OVH. I have run out of patience and am going to cancel and stay with Lightsail.
Yeah I know why you made the comment, my VPS burned. If you think other providers aren't as cheap as OVH you're probably wrong, and in any case, you should always have an other location redundancy if you're doing something critical.
I’ve recently started deploying on Cloudflare workers.
They’re cheap and “infinitely scalable.” I originally picked them for my CRUD API because I didn’t want to have to worry about scaling. I’ve built/managed an internal serverless platform at FAANG and, after seeing inside the sausage factory, I just wanted to focus on product this time around.
But I’ve noticed something interesting/awesome about my change in searches while working on product. I no longer search for things like “securely configuring ssh,” “setting up a bastion,” “securing a Postgres deployment,” or “2022 NGinx SSL configuration” - an entire class of sysadmin and security problems just go away when picking workers with D1. I sleep better knowing my security and operations footprint is reduced and straightforward to reason about. I can use all those extra cycles to focus on building.
I can’t see the ROI of managing a full Linux stack on an R620 plugged into a server rack vs. Workers when you factor in the cost of engineering time to maintain the former.
I do think this is a new world though. AWS doesn’t compare. I’d pick my R620s plugged into a server rack over giving AWS my credit card any day. AWS architectures are easy to bloat and get expensive fast - both in engineering cost and bills.
I'm scared to use Cloudflare products, because yes they are cheap and good but the company is burning money, not profitable and has large amount of debt. They wil have to raise those prices to not be cheap. Can you predict when and how much they will increase those prices?
If you depend on them for everything and then they decide to make a big price increase to become profitable. Will you be able to handle that price increase? You are pretty much stuck with paying the price.
Yeah other companies can increase their prices, but most of the time profitable companies in cloud infrastructure will only increase if their expenses increase and this is pretty predictable if you pay attention to costs. Like last year it was pretty easy to predict a price increase coming because of inflation and supply chain issues.
Imo, even if they tripled their pricing, they'd still be more cheap than any serverless product other cloud providers have to offer. Looking at their performance over the past 2 years, their losses are in no proportion to their revenue increase [0].
I'm nervous about them changing their pricing too, but just the fact that they're so much more transparent than AWS or GCE is a net plus for me, even with an increase in price.
It’s also worth noting the development patterns they force when building on Workers and Pages sends you down the path of a fairly portable architecture.
I can’t say anything I’m doing would be difficult to port to another provider on short notice.
I completely agree. Most of my personal projects are unlikely to ever go above 50 concurrent users, so I don't really benefit from the scaling part of cloud flare, but I recently switched to using cloud flare pages for all new personal projects and it's fantastic. The ease of use really makes my life all that much better.
Just buy a domain name and start deploying. Unlike other cloud providers (looking at you Azure/AWS) the time from push to deployment finished is under a minute. Azure could take 15-20 minutes and AWS still relied on zip file uploads for functions last I checked.
I recently was asked to port an app to cloudflare pages but found it can only basically handle static rendered content or server side rendered content if the toolset is compatible with their workers thing. Is that the case for you or do I have more to learn about cloudflare? Like I can't just drop Django onto it I assume?
cf workers look so promising, but their pricing makes websocket / persistent connections untenable. I know they are possible with durable objects, but wish they would have a full product story around actually building apps with live requirements with pricing that makes sense.
How's that 100MB limit on D1 going though? I realise support for 'larger' databases is coming, but it gives me the impression they don't intend it ever to be a main application database, for anything that's not small and with a fairly constant data requirement (not scaling with users adding content, say).
Pretty fantastic (not an employee of cloud flare or anything, just a happy customer). They have this concept of mini flare that you can host a tiny cloud flare on your dev box/CI pipeline so it makes it easy to run unit tests and the like.
I don’t have the hardware to self host it. The value of this is that it’s an operating system for planet scale computers. It deploys your process across a global super computer with 100+ data centers.
Most code I’ve rolled on Workers is simple because it’s just business logic (the OS takes care most of the heavy lifting that adds bloat to other code bases). Migrating a few 1000 lines of JS isn’t a big deal. I just don’t have very many places I could move it to.
Lambda is region bound. I could do lambda@edge which is closer. But self hosting it on an R620? I could probably roll an API compatible wrapper that loads my worker into a node process on a standard server and plug it into a colo rack, would take me a few hours, but that’s not comparable.
This idea of self hosting and building portable abstractions I feel is jumping the gun. We are just starting to figure out how to build operating systems for datacenter scale computers, but standardization is still a ways out there. Planet scale is a whole ‘nother level, and we’ve got a long ways to go to figure out what the right abstractions are for computers of this scale.
I have worked with several small clients to migrate away from AWS/Azure instances onto dedicated hardware from Hetzner or IBM "Bare Metal" hardware.
The question I ask first is: as a company, what is an acceptable downtime per year?
I give some napkin calculated figures for 95%, 99%, 99.9% and 99.99% to show how both cost and complexity can skyrocket when chasing 9s.
They soon realise that a pair of live/standby servers might be more than suitable for their business needs at that particular time (and for the foreseeable future).
There is an untapped market of clients moving _away_ from the cloud.
SLA is overrated. SLA mostly relates to "unplanned downtime" so if you need to often fix things, just schedule downtime, mess around with it and bring it back up.
Also, we have seen both cloud and non-cloud hosts having significant downtime more than their SLA but just put it down to a "small subset of our customers" so they don't have to do anything.
It's a bit like my Student Loan guarantee, "Do the paperwork and we guarantee you will have the loan on time". The loan was not paid, "I thought you guaranteed it?" "We do but we made a mistake" "So what do I get because of the guarantee?" "Nothing". Cheers!
I have never seen a publicly-advertised SLA practically worth anything, by my reckoning—whether offered to all customers or an extra that you’d pay for. (Privately-arranged SLAs I can’t comment on. They could potentially have actually meaningful penalties.)
Vultr’s, as an example I’m familiar with, being a customer, but which I believe is pretty typical:
• 100% uptime, except for up to ten minutes’ downtime (per event) with 24 hours’ notice or if they decide there was a time-critical patch or update. (I have one VPS with Vultr, and got notice of possible outages—identified purely by searching “vultr service alert” in my email—8× in 2022, 3× in 2021, 14× in 2020, 9× in 2019. No idea how many of them led to actual outage.)
• They’ll give you credits according to a particular schedule, 24–144× as much as the outage time (capped at a month’s worth after a 7h outage, which is actually considerably better than most SLAs I’ve ever read). Never mind the fact that if you’re running business on this and actually depending on the SLA, you’re probably losing a lot more than what you’re going to get credited for.
• Onus of reporting outages and requesting credits is on you, by submitting a support ticket manually and explicitly requesting credit. So the vast majority of SLA breaches (>99.9%, I expect; I don’t care to speculate how many more nines could be added) will never actually be compensated. And determination of whether an eligible outage occurred is at their sole discretion, so that they could frankly get away with denying everything all the time if they wanted to.
Such SLAs basically just completely lack fangs. I suppose you’d want something along the lines of insurance instead of an SLA, if it all mattered to you.
> They soon realise that a pair of live/standby servers might be more than suitable for their business needs at that particular time (and for the foreseeable future).
I've worked at one of those companies that have the live/standby model in place.
The problem is, how to switch load from live to stand-by in case of problem often requires manual intervention and a procedure.
The procedure must be tested from time to time, and adjusted according to changes.
Oh and the live and standby environments must be kept in sync...
My go to setup if I need more uptime that a single server running in google cloud with live migration grants, is a three node galera cluster, with an A-record pointing to each node, which also runs the application in addition to the database. You can do rolling updates without any downtime, and I've even had setups like this go years without downtime. It isn't perfect but it works very well and obviates having to worry about things like stand-by switchover.
IME many companies claim 99.99+ uptime but then the penalties are trivial. If a 99.99 SLA is busted with an hour of downtime in a month but the penalty is 5% bill credit, the company just lost $500 on $10k revenue, assuming that:
A) Customers actually chase the credit, which (again IME) many companies make very difficult
B) The downtime is very clearly complete downtime. I've seen instances where a mobile app is completely down (but the web product works) or a key API is down (but the core product works) or there are delays in processing data (but eventually things are coming through). All of these can cause downstream downtime to customers but may not be covered by a "downtime" SLA.
Once a company claimed nine 9s (99.9999999%, 0.03 seconds down per year) uptime on their new cloud service to me. When pressed how they came up with the number their measurement they said they were measuring the percentage of time the login webpage loaded (not that you could log in or things worked inside the page and app) and the https://uptime.is/ tool only went up to nine 9's.
I've been running my company website for years on $5 Linode. I used to host everything on there (downloads, update checking, crash reporting, licensing, a Postgres database for everything).
I've never had any performance issues. A $5 VPS is plenty for Apache, PHP, PostgreSQL, for a few thousand users a day.
I've started using multiple VPS, one for each service. Not for performance reasons, but for two things:
- isolation: if there's a problem with one service (eg. logs used up all disk space) it doesn't bring everything down at once
- maintainability: it's easier to upgrade services one by one than all at once
Does anyone here remember developing applications on machines with 25MHz of CPU and 8MB of memory? That VPC has probably 1GHz CPU and 1GB of memory.
How you develop an application depends completely on what you have available to you and what its use case is. If you don't have money, design it to be resource-efficient. If you do have money, design it to be a resource pig. If it needs to be high performance, design it to be very efficient. If it doesn't need to be high performance, just slap something together.
As a developer, you should know how to design highly efficient apps, and highly performant apps, and how to develop quick and dirty, and how to design for scalability, depending on the situation. It's like being a construction worker: you're going to work on very different kinds of buildings in your career, so learn different techniques when you can.
I highly recommend, for fun, trying to develop some apps inside a VM with very limited resources. It's pretty neat to discover what the bottlenecks are and how to get around them. You may even learn more about networking, file i/o, virtual memory allocation, CoW, threading, etc. (I wouldn't use a container to start, as there's hidden performance issues that may be distraction)
For a few years I did run my mail/web/... servers on a light virtualization host that billed by actual memory, disk and CPU use by minute. It's amazing what optimizations one finds to lower the resource consumption when it has direct effect on the price. At times I was running for $0.5/month :D
The article does not really answer the question in any meaningful way, just tests a CRUD blogging server written in go, using a mongodb database (both dockerized…)
If you expect any comprehensive benchmarks or testing, save the time.
Although a major point with most cheap providers is what you don't get: consistency in performance and reliability. (Although $4 is not the deepest bargain barrel yet, so not necessarily that bad)
I think the biggest thing that snipes a lot of technology teams is some notion that production can never ever go down no matter what. Every byte must be synchronously replicated to 2+ cross-cloud regions, etc. Not a single customer can ever become impacted by a hacker, DDOS, or other attack.
Anyone in this industry is prone to these absolutist ideologies. I wasted a half-decade chasing perfection myself. In reality, there are very few real world systems that cannot go down. One example of a "cannot fail" I'd provide is debit & credit processing networks. The DoD operates most of the other examples.
The most skilled developer will look at a 100% uptime guarantee, laugh for a few moments, and then spin up an email to the customer in hopes of better understanding the nature of their business. We've been able to negotiate a substantially smaller operational footprint with all of our customers by being realistic with the nature and impact of failure.
If you can negotiate to operate your product on a single VM (ideally with the database being hosted on the same box), then you should absolutely do this and take the win. Even if you think you'll have to rewrite due to scale in the future, this will get you to the future.
Periodic, crash-consistent snapshots of block storage devices is a completely valid backup option. Many times it is perfectly OK to lose data. In most cases, you will need to reach a small compromise with the business owner where you develop an actual product feature to compensate for failure modes. An example of this for us would be emailing of important items to a special mailbox for recovery from a back-office perspective. The amount of time it took to develop this small product feature is not even .01% of the amount of time it would have taken to develop a multi-cloud, explosion-proof product.
Putting my recommendation in for vultr - have used them for many years and have had very good results off of a cheap vps. Also trivial to migrate and upgrade hosts on the fly.
Someone had a site set up to measure VPS providers by running a suite of tests every hour and collecting the results by hosting provider. Was surprising to see transient performance degradations, downtimes and stark differences in performance for "2 vcpu 1gb ram" depending on the hardware underneath and level of overprovisioning.
I used Johnscompanies, Linode, DigitalOcean, then Vultr. Vultr shocked me by how poor their customer service was, after 3 days of downtime, multiple claims of fixing the issue soon, and not bothering to notify me when it finally was fixed. I didn't experience that at any of my previous hosts.
Yeah the CS isn't excellent but it is mostly for self-supported workloads.
Like OVH - if you need support for anything beyond provisioning/troubleshooting things outside of the VM, it's not the best choice.
If you compare it with ec2 support costs + vm costs... it's difficult to have it all.
Digital Ocean does a good job of support too, but I'd rather not need support (with most tooling self-serve) than have support but have issues. I've had VMs at vultr running for 3+ years with very few issues (one host migration which they did "live" for me and notified me a few days in advance). I've had more issues with degraded instances in ec2 that require a ticket sent to ec2 support and 3-days wait for them to assign it to a new host.
> Vultr shocked me by how poor their customer service was
I'll counter that. I found that their customer service was acceptable as far as I could tell. I ran an OpenBSD bare metal server on them for quite a while.
Were they great? No. But I have also found that the big guys aren't that great either. Sure, the big buys hit a lot more problems so it's likely your issue is resolved because somebody big paying lots of money also just had that problem.
However, if your problem is semi-unique and some large customer isn't also having it, you are completely SOL with the big providers. They will never fix your issue.
I dislike Vultr based on their deceptive marketing around the very cheap 2.5 and 3.5$ instances they (used to?) list on their website. Usually those are only available in one or two sites, with no way of checking before creating an account and loading up the minimum amount (10$ when I tried).
You can upload a custom ISO and run it - as long as your OS supports virtio and the defacto virtual newtork cards it should be fine. I recall running a windows vm from an iso that was uploaded.
They changed the pricing out under me and make it difficult to migrate out. At the time there was a very restrictive upload bandwidth so it would have taken weeks to upload my database backup files to the new hetzner servers. We ended up putting effort into finding the core data which can't be lost and only uploading those individual tables/row filters.
IDK how they are now but for sure go check upload limits.
Does anyone have tips for managing/monitoring a few cheap VPS? I have one that I pay $4 a year for and only use it as a Syncthing middle between my laptop and phone. I also have a few other small ones that I use for single purposes. However, I don't have a good way to see how much storage is on each VPS and the CPU utilization without sshing into them to check.
I would use telegraf (https://github.com/influxdata/telegraf) to gather the metrics you want from your servers. It has built-in functions to get metrics like disk usage, cpu, etc...
From there I would export those metrics to a grafana+influxdb setup. But honestly this is because that's what I'm used to professionally. There might be simpler solutions around.
If you're happy not having a home-grown open source solution, New Relic is essentially free if you don't have many servers and turn off extended metrics. If you start adding in more integrations, it's gonna cost you, but for basic monitoring and nice graphs hosted externally from your systems itself, it works nicely.
https://opsverse.io/observenow-observability/ ...As close to free as possible since the cost is primarily driven by amount of ingestion. Works great for small setups with scope to grow over time!
I use cockpit widely as well. I too was initially concerned that it may be an overkill as well, but it solves so many more administrative problems than just metrics, that I’ve found it’s worth the few extra resources used.
I bought it from VirMach on Cyber Monday back in 2017. It was a pretty good deal and they've stuck to it. I've barely used the box for anything over the years but it's nice to have.
I think you'll still find deals like this on lowendbox occasionally.
As I said above I had a bad customer service experience with them. I've used a lot of hosting providers and Vultr was the most ghetto-feeling by far. Back to Digital Ocean for me, or if they stop hosting custom images, I'll try and find another
This is the parent company of BuyVM. They have a very good reputation, but their stock goes up and down throughout the month. If you want a specific data-center location, wait until the first of the month when stock replenishes.
Not sure about $3.5/year, but Hosteon has servers at $16/yr (openvz) and $21/yr. Small companies on LEB have yearly prices occasionally, and frequently they never disable the sign up page for them, for example:
The part I hate most is the security aspects. Keeping things up to date, port blocking, iptables, firewalls, etc. Anyone know if there’s a SaaS that just ssh’s in and does that stuff? I use serverpilot.io but it’s aimed specifically at DO + PHP, and would like more flexibility on which core services could be installed.
With respect to port blocking / iptables / firewalls, what do you need to do other than shut off all ports other than the one(s) you're serving on? And for updates, I don't know that any other provider does this any differently. You'll have to do some work, but that's what I'd prefer anyway; the last thing I'd want is AWS automatically upgrading the OS of live production systems without me testing it first.
It's a good question and the answer is I don't know what I don't know when it comes to this stuff. Perhaps I've been overthinking it, but I feel like there's some gapping hole I'm leaving exposed. If that's all there is to it then I feel better already about a DIY approach. But for instance, SSH port has to remain open just so I can get in. I read occasionally about OpenSSH, or some foundational level service, being exploited. Is it common to just have to follow the security issues of every service and rush to patch accordingly, or is there something that helps automate this part?
I do agree that there are some core services that I don't want changing out from under me without my notice/prior testing. But then there's also a lot of stuff installed that I don't use directly (eg OpenSSH) in my application and I'm not sure if those are attack vectors.
The gist is, yes, that really is all there is to it.
Setup unattended upgrades for your distro of choice, setup fail2ban, only make internet accessible the ports you need, upgrade out of date software (i.e., don't fall behind LTS). Make sure your software behaves with good security practices (don't trust user input, etc). Any modern guide these days should just about cover it.
For more complex deployments you'll enter the world of reverse proxies, custom VLANs, automation abstraction, intrusion detection systems (i.e., applications that proactively monitor access logs for suspicious activity), logging systems, alerting systems...
But for simple app deployments, getting a reasonably secure system setup is actually not that hard. Maintaining it and keeping it secure is another matter (keep private keys secret, don't use simple passwords for SSH, etc), dealing with large upgrades, don't deploy debug to prod...
Do the initial setup with Ansible. It should be static unless your application changes. Also it's hard to do it as a service because it really depends on your applications.
Keep the boxes up-to-date with "unattended-upgrades" or similar.
If you're talking host firewall, I would focus more on making sure only the necessary services are installed and configured for startup - meaning only authorized apps are listening inbound. For outbound, I don't have an answer, though I suspect there is one.
For network, again, your required services should be somewhat easily definable for inbound unless you're hosting multimedia/UDP/P2P services. This is the basics... for enterprise level stuff you get into application-aware firewalls, IPS, and WAF.
You don't need any firewall. All you need is to check `ss -ltunpr` and disable all services that are not listening on localhost, which is not usually many services on minimalistic OS installation. And/or make sure [your own] internal services listen only on localhost addresses.
So that just leaves keeping things uptodate, which is easy by subscribing to your distro's security mailing list, and updating when something relevant comes up. Which is rarely on a simple webhost VM.
Hosting stuff on small machines was why I came up with https://github.com/piku, and I still use it for those - I spent a long time trying to cram LXC, Docker and the like into single-core machines, and wanted a way to make it as painless as possible.
These days I’m running my static site builder, a few scrapers/RSS converters and a number of Mastodon-related services on it, on various kinds of cloud and physical hardware…
Vertical scaling is seriously underrated nowadays. Also everyone chases those 99.99999 availability, but very few actually need it, so scaling vertically is not a problem for 99.9% startups.
These test results are surprising. In my experience, when the server cpu is pegged, it causes latency to shoot through the roof unless the number of parallel requests is finely tuned.
In this case, there are max 50 workers hitting the server, so you’d expect 50 parallel requests to be outstanding at once. 1300 req/sec with 50 workers, would be 26 msec/req, which matched the results.
So I wonder why the server being pegged didn’t affect things more? Super curious what the server side metrics were during the test.
I guess one explanation is that given the load test isn’t sending constant traffic but each virtual user instead waits for each request before sending the next one, it naturally starts throttling.
Constant Load, which k6 supports, can help pinpoint the server’s breaking point.
Hetzner Cloud allocates you 20TB per VPS (yes, even the cheap ones) and lets you use that however you see fit. There have been about 2 known instances of Hetzner kicking off dedicated (not VPS) customers for traffic abuse, and those customers were saturating the link 24/7 and were offered dedicated lines ahead of time. (their actual pain limit seems to be averaging over 750Mbit/s for 2-3 months). Their network team gets very upset if you scan from the instances, but not usually to keep a single limited interface from being saturated.
Netcup will throttle you 100 Mbit if you exceed 80 TB a month. Even on their 3,25 EUR VPS product.
And you can do a LOT using such VMs, now that most are hosted on SSDs instead of spinning disks.
My take-away points are the following:
1) Beware of cheap OpenVZ offers (e.g. on LEB or WHT), performance is usually worse than offers with proper virtualization like KVM, and the need to patch OpenVZ into the kernel causes most offerings to use a more or less outdated Linux Kernel leading to a very questionable level of security.
2) If your VM hosts "serious" data, you should better make sure to do your research and use a reputable hosting provider. This may potentially cost a bit more but will save you a lot of headache in the future.
3) Unless it's just a toy project, you should look into enabling replication of your data across two or three different VPS providers. While this at most triples your performance, the reliability will increase at least tenfold.
Some companies are still offering OpenVZ because it allows to heavily oversell RAM, CPU and storage bandwidth with somewhat graceful degradation of guest performance.
I think OpenVZ has kernel patches for RHEL7's 3.10.x kernel, which is supported by Red Hat till 2024. So in theory it's possible to have a secure OpenVZ VM but in reality bad practices (like heavy overselling the hardware) flock together.
Personally for me the $5 ones no longer work. Nightly "dnf update" gobbles up >1GB of memory for God knows why and kills off httpd or application server randomly.
But a ~$10 virtual box with 2GB of RAM works fine. Nothing to complain. I get 2TB transfer and 50 GB space.
Same. I even have some scripts in the past that would use more memory for some operations that would first add extra swapfile, do stuff, then remove it after.
Thank you for this. I have been having some issues recently with one of my servers and my solution was to increase the size of the tmp mount but that's basically a Russian roulette.
Enabling swap during the update sounds like an elegant solution.
I was running one of my products on 7 5$ instances from DigitalOcean. Which includes load balancer (Apache), database with replication, static site hosting, web app and 2 backends. It was happily serving hundreds of concurrent users with quite a lot of space to still grow. With their s3 clone and few volumes we rarely paid more than 45$ per month. You really can get far with cheap cloud machines.
Does anyone know of the equivalent of Terraform for on-prem hardware? I explicitly do not want an automated agent that applies things or anything like that.
I want to do this:
- image some hardware with Ubuntu
- set up SSH
- write a definition file, HCL is fine
- run a program that uses the definition and the IP address of the machine that applies the definition installing files, programs, whatever or removing them
It would be cool if:
1. There were a terraform provider for this
2. I can specify which IP address the hardware is at
3. `terraform apply` and be done with it
The cloud is absolutely fantastic for lots of things, and we have a mix of cloud infra and on-prem hardware. Ideally, I'm looking for something a 4-person team can manage with some wiggle room for failure. If we hit 99.9 we're fine, maybe even get by with 99.
After all, the alternative is that I reimage one of the servers on the few racks we have and it takes precious time but it's not really a problem.
I'm a heavy terraform user and I want something like this too. HCL and the surrounding tooling is just so nice.
I mainly use puppet to manage my hobby machines & VMs, and puppet does violate the agentless bit you mentioned. What I like about it (over something like Ansible) is that it understands the resource dependency tree like Terraform does. Furthermore, I've set up my implementation so that it restores backups after installing services. So, for me, rebuilding a server is simply running a backup (optional) and then wiping the box.
I saw a libvirt provider for terraform recently that can SSH to a host and then operate the libvirt API on it. That seems like a good starting point for something like this; take the SSH parts and use it to manage resources like files on the remote host.
I've written a few simple terraform providers, it's not that hard to do. This sounds like a fun project and I'm pretty tempted to do this, actually.
Also make sure you know how the pricing works. There's a specific configuration that enables 4 ARM CPUs, 24GB RAM, and 200GB disk space on the free tier.
Signed up with a region, always out of any free availabilities, locked out with no way to change regions, unless if I sign up with a different email address.
I've used everything from expensive dedicated servers, cheap dedicated servers (Atom, Pentium 4), to all levels of VPS, cloud VPS, and now I finally settle on hosting everything in my parent's home.
With gigabit symmetric fiber connection (that I paid for) I don't see why I need to host stuff on other people's infrastructure. I can control backup in person.
I don't need to worry about the hoster upgrade a SAS controller and boink the RAID-ed hard drive, or complaints about copyright materials etc, or the hoster snooping on the servers for sensitive data, or that the hoster suddenly go out of business and take all my data with it, or that I reach the monthly 1000TB limit.
My parents even get to use gigabit connection for free so it's a win-win.
> I used K6 to perform a load test. K6 is a software that will generate “virtual users” who continuously run test scenarios defined using javascript.
K6s is a pretty good load testing tool, however my problem with it is that it doesn't simulate everything a browser does: fetching all of the image files, fonts, as well as anything that might get downloaded and executed after upgrading the version of your application with some new functionality, but forgetting about adding new API routes etc. to the tests (e.g. if a new panel in the app gets loaded even without explicit user input, say, a new UI improvement with some useful data). You might need to do updates to your test code with each next app version for this, a relatively high maintenance approach.
The way I've worked around this previously was setting up Selenium + Python inside of containers that were assigned system users through a centralized service I wrote for that and then used the site in question like a real user would. It was pretty close to the real world, though sadly didn't scale too well - because with each automated browser instance needing ~512 MB of RAM, only small amounts of users could be viably tested.
Either way, small VPSes are still a great option in my eyes! Here's a few providers that I've personally found viable:
- Hetzner: https://www.hetzner.com/cloud (time based billing, good selection of services, also allows easily attaching more storage etc.)
- Contabo: https://contabo.com/en (pretty good option, the UI used to be a bit antiquated, there are setup fees, apparently a bit overprovisioned)
- Time4VPS: https://www.time4vps.com/?affid=5294 (I use them for my sites, affordable and stable, though not as modern as Hetzner; affiliate link, remove affid otherwise)
- Scaleway: https://www.scaleway.com/en/stardust-instances/ (overall expensive, but their Stardust offering is pretty good, when available, which isn't that often)
Apart from that, it can also be quite useful to take some old hardware and turn it into your own homelab - I'm currently doing that for my NAS, backup nodes and CI nodes, just a few AMD 200 GEs with 35 W TDP that are way cheaper than anything that actually needs good uptime. For example, buying a 1 or 2 TB HDD for storing data is cheaper than most cloud options, even when you include additional expenses for backups. As for compute, it varies - if you have workloads that need to infrequently do lots of number crunching, the cloud can be cheaper, actually.
The smallest VPS are also the most unreliable in my experience. If that's a requirement of your low compute project, it may make sense to massively over provision with either a more expensive VPS or dedicated server. I'm not sure why but I suspect it's some combination of older server hardware being relegated to host lots of tiny VPS (which tend to host less uptime-critical things). Sharing the hardware between more VPS giving rise to more problems, e.g abuse, or over loading since they will be on average under-provisioned.
This is of course completely anecdotal, historical and speculation, some providers offerings may be just as stable at the bottom end. But it's certainly more likely at the bottom end.
If you put several of these ultra cheap VPS behind something like Cloudflare, doesn't that mostly solve the problem with them being down every now and then?
Sure, if it's simple to horizontally scale your service.
But unless it's a simple static site it's usually not, and it's usually a source of a lot of complexity and pain. Which unless you really are doing something twitter scale, is not worth it.
By the time you've bought a handful of tiny VPSs and put in the work to horizontally scale your service, you could have put the same money with zero effort into a very reliable dedicated server. Spend the effort elsewhere and save your sanity (and probably improve your reliability).
Cloudflare isn't going to do load balancing for free, neither do most VPS providers (if at all), and you're likely making some network admin angry trying to run something like keepalived, but it sure is true that building your systems to be fault tolerant comes with the option of using cheaper "base resources".
I've had a $20 a month Linode VPS for over ten years. I have a $13 a month Ramnode VPS as secondary or backup for a lot of things, like DNS.
At one point I was pretty steadily making $2000 a month revenue on my side business, sometimes peaking to $3000. Mostly serving up JSON (or XML at one point) as well as media like PNGs or epub's or the like.
The Linode has 4 gigs RAM, 2 CPU cores, 80 gigs storage, runs Debian. I'm given 4 TB of net traffic a month, but I never even got to 1 TB a month.
I did look at VPS's which were even cheaper at the time - less than $10 a month, but I passed on them, $400 a year for VPSs was within my allocated budget, especially since revenue was over $20,000 a year.
I've always been pretty cheap with my spendings on VPS. So, when building my web applications, even if the traffic is building up, I opted into optimizing before upgrading hardware.
I've been doing this for more than 10 years and I've been making incremental (sometimes really small) improvements to the way my web apps work so that I rarely need to go down to AWS, k8s, load balancer etc etc way.
Sure, these are personal projects and of course there is a diminishing return on optimizing (so I do upgrade hardware when I need to), but I always found it a rewarding challenge to first look at understanding the inherent issue, rather than just throwing money at it (at my work, it's completely opposite - see an issue? throw money and upgrade hardware ASAP and move on).
Some things I've done for optimizing are...
- Simple upgrading of software - going to latest postgres, upgrading PHP
- Identifying data that are not frequently updated and then caching them
- I've identified some bot traffics coming from China, so for one of my projects, I just blocked it completely (yeah, drastic I know, but not worth my $2!!)
There are also many many services out there that provide free tiers that you can utilize. So as a solo, indie dev, there are many ways to leverage to stay on a cheap $5 linode box as long as you need (I saw recently a box for $2.50 - tempting...)
Not sure about $4 but for $40 I get a dedicated box with Intel i7-8700, 128GB RAM, 1TB of NVME storage and 1Gbe of bandwidth at Hetzner. That is a lot of machine for the money.
I pay for a VM that is not hosted on the major cloud platforms, it comes with 6 cores, 16GiB RAM, 100GiB NVMe, a public IPv4 address, and 32TiB of bandwidth (supposedly I've never even used 1% of that) for 15 euro a month. It can handle anything I could throw at it. I currently use it to test kubernetes deployments with helm and k3s.
You cannot get anything anywhere close to that in Azure, GCP, AWS, etc. for that price.
I rented my first VPS 15 years ago and it was cheap. IIRC the VPS software was called Virtuozzo. Since I was using Java at work, it seemed a good idea to install a Java CMS:
But it was not so easy. Java refused to start with an out-of-memory error. It took me many hours to find out that the VPS had assigned very little memory at start. It was possible for the JVM to expand once running, but the initial request had to be small enough to avoid the error and not so small as to prevent Pebble from running.
Once this problem was fixed and iptables set, everything was fine. I even setup postmail. But the experience taught me that a VPS has different rules. I wouldn't trust the measurements in the article. They could depend on the load that other VPS in the same machine are supporting at the same time.
At current interest rates they wouldn't if they had to take out a loan for the house. That's my point. It's not profitable even on a 5 year return window.
These tests are basically useless as you never know how much CPU to VCPU oversubscription the provider actually runs at the moment. Problem is, that none of these providers guarantee you anything - if new hardware is hard to procure at the moment they will just increase general oversubscription. Even with a high oversubscription ratio you might be lucky finding yourself on a server where all machines are basically idle all the time and all the power belongs to you.
I remember some CPU-overloading loads categorized as "mining" in various cloud providers and shut down. I wonder if ML training will cause the same false-positives. (Or "true positive" in the case of "excessive load not allowed" providers)
This concept was more for inference on-demand vs training a model. For example, if there was an API call that had a model call as part of it's workflow. Training even a small model still requires serious compute power.
Except the $4 vps generally have fair use clauses. So you can’t actually sustain what the load test shows. 20% of it is common as reference point for sustained use though often judgemental
It used to be that growth rate and market capture was the most important metrics. The value of a marginal feature was far in excess of anything that would save money on infra, or that might delay engineers from deploying the next feature.
With the fed increasing rates, engineer salaries falling, and the market now valuing profit over sales, this is no longer true.
The companies that do not adapt to this reality will have subpar results.
The problem is that not all $4 VPS offer the same baseline perf. Unless you have the time/money to go sign up/provision/load test from a set of providers, it's definitely hit or miss.
That said, you shouldn't dismiss cheap hosting, I use a $4.5 VPS to constantly encode h.265 and it's been a great value.
I recently migrated a client's app to a $10 VPS. Before that, the app was running on AWS with a couple EC2 instances, RDS, and lambda costing about $300/month.
The client was skeptical and asked about whether it's gonna be stable and scalable.
3 months later, the app is running buttery smooth.
I'm a devops engineer and I would prefer not have to worry about scaling or unexpected costs from the provider.
My dream SAAS or cloud company is one that does payments and revenue to resource scaling. They integrate your payments solution of customers to scalability of your infrastructure.
In other words, the more active customers you have the more capacity you have. They would handle all the payments collection and take a cut of your revenue.
The guarantee is that you can handle any number of customers based on the number of paying customers.
But then it's static while transactions aren't occurring. This only makes sense to me in a system in which the load IS a transaction like a payment gateway, or a strict single tenant architecture.
You're not gonna scale when a customer bursts because they didn't know enough in advance to pay you before?
I assumed that the provider of said service would have profoundly scalable systems that can absorb load fast, similar to AWS Lambda and Firecracker VMs.
"A virtual private server (VPS) is a machine that hosts all the software and data required to run an application or website. It is called virtual because it only consumes a portion of the server's underlying physical resources which are managed by a third-party provider. However, you get access to your dedicated resources on that hardware."
Pretty typical BS article. Profile a pointless small app (written in Go, fast but used by very few people) and then caveat that your mileage may vary.
It sure does. Having to size for peaks and troughs, for when the updates are running, for when you get a spike in traffic, for when you need to use a slightly under-performing DB library or some connections to cache.
The only thing this small server would be any good for would be a static web site, pretending that any web app would work on a tiny vps is just not true.
Virtualized offerings perform significantly worse (see my 2019 experiments: https://jan.rychter.com/enblog/cloud-server-cpu-performance-...) and cost more. The difference is that you can "scale on demand", which I found not to be necessary, at least in my case. And if I do need to scale, I can still do that, it's just that getting new servers takes hours instead of seconds. Well, I don't need to scale in seconds.
In my case, my entire monthly bill for the full production environment and a duplicate staging/standby environment is constant, simple, predictable, very low compared to what I'd need to pay AWS, and I still have a lot of performance headroom to grow.
One thing worth noting is that I treat physical servers just like virtual ones: everything is managed through ansible and I can recreate everything from scratch. In fact, I do use another "devcloud" environment at Digital Ocean, and that one is spun up using terraform, before being passed on to ansible that does the rest of the setup.