Hacker News new | ask | show | jobs
by bomdo 2200 days ago
Not nitpicky at all - this is an important distinction to highlight for pointy-haired decision makers.

This product is undoubtedly the P in PaaS, but there is no service behind it. If your company uses this as an alternative to a real Heroku/AWS/xyz PaaS, you must have engineers at hand for 24/7 ops, scaling servers and fixing bugs. In my opinion, this is quite risky for anything running in production and should not survive a cost-benefit analysis.

1 comments

> should not survive a cost-benefit analysis

I completely disagree, the difference of price between dedicated servers and even EC2 instances is completely amazing.

This is what you get for less than $200/month with a dedicated server:

1× AMD EPYC 7281 CPU - 16C/32T - 2.1 GHz, 2 × 1 To NVMe, 96 Go DDR4 ECC, unmetered 750 Mbps

In one of my companies the AWS bill is just completely insane, we have like half that hardware, with a really small bandwidth, which is metered, for more than $800/month, which is fine while we're on free credits.

I love working for cloud companies, it's a lot of fun, but when it comes to my money then I never go for anything but a dedicated server.

All these things are relative.

When you got applications that don't require high availability while needing a very low cost per CPU, dedicated servers just make sense. We are running a cluster of a few high-CPU dedicated servers for our data-science team, and it just makes sense: we don't need 99.99%+ availability, and the servers we rent are cheaper than the equivalent AWS storage cost alone ... The op cost of managing these is exactly the same as managing equivalent EC2 instances. We don't need backups either.

On the other side, we got some low-CPU web services that require high availability, redundancy and reliable backups. For these I just use Heroku. It's extremely reliable and easy to operate, while only costing about $100/month (a few hobby dynos + a fully managed PgSQL DB). Sure it's probably 5x more expensive than a dedicated server with 10x the performance, but I don't have to worry about backups, availability and scalability. And these apps just don't need this 10x faster CPUs anyway.

>web services that require high availability, redundancy and reliable backups. For these I just use Heroku.

How do you handle Heroku outages then?

Heroku outrage free was 99.9999%+ over the past 60 days[1], I'd have a hard time achieving this with a single dedicated server.

[1] https://status.heroku.com/

Do you really mean that you never had a server with 60 days uptime ? This is really insignificant to achieve, even a reboot per month is nothing, 99.9% of uptime is enough for 99.9% of projects, and a monthly reboot does not even get you close to that service level.

I am not affiliated nor haven't tried CapRover (for special reason of: coding my own for my tastytastes), but I would bet any standard system administrator could get a 99.9% uptime after the second month of production without particular effort (unless they don't know underlying technologies ie. "what a container" "what http" "what is namespace" "what iptables" ...)

I have a raspberry pi running on my desk that has been running for 60 days sitting on my desk with no outages. I don't even have a battery backup!
Maybe I am just an exception but I have 100% availability on one dedicated server for the last 2 years.
Yes, hardware as a service will always be much more expensive than hardware you own. But it may be less expensive than the team you will require to run that hardware at an acceptable service level. It very likely will be less expensive than the opportunity cost of running your own hardware.

As an example of the latter bit, if you are running your own hardware and need to add another host and you do not have a spare lying around, then you need to order one. It has to be shipped. Someone has to unpack it. Someone has to make sure that the data centre has sufficient power. Someone has to install it, its power and its network cables. Each of these steps takes time, but also each step is an opportunity for friction.

By contrast, with a service, you would just add a new host. Five minutes later you are up and running. That gives you an operational nimbleness that you wouldn't otherwise have had.

I love how there's this myth that servers and services just blow up every 10 minutes 24/7 and unless you have a legion of ops personnel you're going to get hours of downtime each year.

Servers, for the most part, just work. In DC climate-controlled environments, hardware failures is exceedingly rare. Apart from harddrives, most hardware will happily tick along for a decade, if not longer.

Sane production-grade OSes (read: not Ubuntu) will also happily run for literal years with zero human intervention. For obvious reasons, it's a bad idea to not patch your systems, but things will continue to "just work" pretty much forever unless you're running really shitty code.

For renting vs buying servers, there's upsides and downsides. Buying gear is far far cheaper if you plan to be around for more than a year, but renting dedicated servers gives you a lot more flexibility -- to provision a new server, you hit a button in their online panel, wait 15 minutes, then let your deployment strategy take care of the rest.

I find it almost mind-boggling that AWS and friends have convinced people that it's normal to spend ridiculous amounts of money for fairly "meh" service specs in what's essentially VMs.

The points you make are fine but I think the experience becomes more painful linearly with the number of servers you manage, since you're N times more likely to see something happen that takes down a server. It just happens more frequently. At some point that becomes often enough that you don't want to deal with it anymore.
I don't think you understand the sheer scale you need to be experiencing a failure more often than once a month. By my anecdotal experience you'd need at least 1k servers for that to happen... and if your company is big enough for $2MM capex for servers alone you can handle $100 remote hands and 30 minutes of engineer time.

Not to mention that at that scale you have plenty of redundancy and, if your ops team knows what they're doing, automagic failover / HA. Anything that happens can easily "wait till Monday", no need for 24/7 anything.

If it's often enough to be noticeable, your scale is large enough to pay someone to be ops full time.
That example is not realistic. You rent dedicated servers from a provider that will always have extra hardware at hand, and handle all of those steps; you don't rent hardware yourself and run it in your basement :)
What you just described is a kind of hardware service!
Or you rent managed servers or colo space from one of the many hosting providers that also offers cloud services, and pick and choose. That lets you migrate your base load to colo or managed servers over time, while you still have the nimbleness of being able to scale up and down dynamically if you want or need to.

And my experience from providing devops services to clients on a contract basis is that the clients who use cloud services tends to need more, not less, devops assistance.

Certainly hardly anyone should be physically managing their servers. The relevant comparison is between getting 1GB RAM in the form of a $50/month Heroku dyno and getting it with a $2/month VPS (actually with Hetzner that will get you 2GB, they don't go below 1GB).