The cloud has made people forget how far you can get with a single machine.
Hosting staging envs in pricey cloud envs seems crazy to me but I understand why you would want to because modern clouds can have a lot of moving parts.
replies(11):
Hosting staging envs in pricey cloud envs seems crazy to me but I understand why you would want to because modern clouds can have a lot of moving parts.
I'd still like a staging + prod, but keeping the dev environments on a separate beefy server seems smart.
You get X resources in the cloud and know that a certain request/load profile will run against it. You have to configure things to handle that load, and are scored against other people.
* The big caveat: If you don't incur the exact same devops costs that would have happened with a linux instance.
Many tools (containers in particular) have cropped up that have made things like quick, redundant deployment pretty straightforward and cheap.
Cloud isn't worth it until suddenly it is because you can't deploy your own servers fast enough, and then it's worth it until it exceeds the price of a solid infrastructure team and hardware. There's a curve to how much you're saving by throwing everything in the cloud.
It offloads things like - Power Usage - Colo Costs - Networking (a big one) - Storage (SSD wear / HDD pools) - etc
It is a long list but what doesnt allow you do it make trade offs like spending way less but accept downtime if your switch dies etc etc.
For a staging env these are things you might want to do.
It's fun the first time, but becomes an annoying faff when it has to be repeated constantly.
In Heroku, Vercel and similar you git push and you're running. On a linux server you set up the OS, the server authentication, the application itself, the systemctl jobs, the reverse proxy, the code deployment, the ssl key management, the monitoring etc etc.
I still do prefer a linux server due to the flexibility, but the UX could be a lot better.
Things like Lambda do fit in this model, but they are too inefficient to model every workload.
Amazon lacks vision.
Today the smallest, and even large, aws machines are a joke, comparable to a mobile phone from 15 years ago to a terrible laptop today, and take about three to six months to in rent as buying the hardware outright.
If you're on the cloud without getting 75% discount you will save money and headcount by doing everything on prem.
It’s a lot cheaper than me learning to bake as well as he does—not to mention dedicating the time every day to get my daily bread—and I’ll never need bread on the kind of scale that would make it worth my time to do so.
This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
But the cloud is different. None of the financial scale benefits are passed on to you. You save serious money running it in-house. The arguments around scale have no validity for the vast, vast majority of use cases.
Vercel isn't selling bread: they're selling a fancy steak dinner, and yes, you can make steak at home for much less, and if you eat fancy steak dinners at fancy restaurants every night you're going to go broke.
So the key is to understand whether your vendors are selling you bread, or a fancy steak dinner, and to not make the mistake of getting the two confused.
I think this is partly responsible for the increased popularity of sqlite as a backend. It's super simple and lightstream for recovery isn't that complicated.
Most apps don't need 5 9s, but they do care about losing data. Eliminate the possibility of losing data, without paying tons of $ to also eliminate potential outages, and you'll get a lot of customers.
Water is cheap, yes. Salt isn't all that cheap, but you only need a little bit.
> [...] and I’ll never need bread on the kind of scale that would make it worth my time to do so.
If you need bread by hand, it's a very small scale affair. Your physique and time couldn't afford you large scale bread making. You'd a big special mixer and a big special oven etc for that. And you'd probably want a temperature and moisture controlled room just for letting your dough rise.
Certainly true, but there are a whole lot of tools to automate those operations so that you aren't doing them constantly.
https://postmates.com/store/restaurant-depot-4538-s-sheridan...
I blush to admit that I do from time to time pay $21 for a single sourdough loaf. It’s exquisite, it’s vastly superior to anything I could make myself (or anything I’ve found others doing). So I’m happy to pay the extreme premium to keep the guy in business and maintain my reliable access to it.
It weighs a couple of pounds, though I’m not clear how the water weight factors in to the final weight of a loaf. And I’m sure that flour is fancier than this one. I take your point—I don’t belong in the bread industry :)
I wonder, though—at the risk of overextending the metaphor—what if I don’t have a kitchen, but I need the lunch meeting to be fed? Wouldn’t (relatively expensive) catering routinely make sense? And isn’t the difference between having steak catered and having sandwiches catered relatively small compared to the alternative of building out a kitchen?
What if my business is not meaningfully technical: I’ll set up applications to support our primary function, and they might even be essential to the meat of our work. But essential in the same way water and power are: we only notice it when it’s screwed up. Day-to-day, our operational competency is in dispatching vehicles or making sandwiches or something. If we hired somebody with the expertise to maintain things, they’d sit idle—or need a retainer commensurate with what the Vercels and Herokus of the world are charging. We only need to think about the IT stuff when it breaks—and maybe to the extent that, when we expect a spike, we can click one button to have twice as much “application.”
In that case, isn’t it conceivable that it could be worth the premium to buy our way out of managing some portion of the lower levels of the stack?
Configuring a web server is a low-difficulty task that should be available for any good software developer with 3 days to study for it. It's absurd for a developer to need to configure a web server, but insist on paying a large rent and cede control to some 3rd party instead of just doing it.
(Similarly to how you pay Amazon or Google etc not just for the raw cloud resources, but for the system they provide.)
I grew up in Germany, but now live in Singapore. What's sold as 'good' sourdough bread here would make you fail your baker's training in Germany: huge holes in the dough and other defects. How am I supposed to spread butter over this? And Mischbrot, a mixture of rye and wheat, is almost impossible to find.
So we make our own. The goal is mostly to replicate the everyday bread you can buy in Germany for cheap, not to hit any artisanal highs. (Though they are massively better IMHO than anything sold as artisanal here.)
Interestingly, the German breads we are talking about are mostly factory made. Factory bread can be good, if that's what customers demand.
See https://en.wikipedia.org/wiki/Mischbrot
Going on a slight tangent: with tropical heat and humidity, non-sourdough bread goes stale and moldy almost immediately. Sourdough bread can last for several days or even a week without going moldy in a paper bag on the kitchen counter outside the fridge, depending on how sour you go. If you are willing to toast your bread, going stale during that time isn't much of an issue either.
(Going dry is not much of an issue with any bread here--- sourdough or not, because it's so humid.)
Wait, what? Salt is literally one of the cheapest of all materials per kilogram that exists in all contexts, including non-food contexts. The cost is almost purely transportation from the point of production. High quality salt is well under a dollar a pound. I am currently using salt that I bought 500g for 0.29 euro. You can get similar in the US (slightly more expensive).
This was a meme among chemical engineers. Some people complain in reviews on Amazon that the salt they buy is cut with other chemicals that make it less salty. The reality is that there is literally nothing you could cut it with that is cheaper than salt.
Oh, and the new machine has unified RAM. The old machine had a bit of extra RAM in the GPU that I'm not counting here.
As far as I can tell, the new RAM is a lot faster. That counts for something. And presumably also uses less power.
Ansible basically automates the workflow of: log in to X, do step X (if Y is not present). It has broad support for distros and OSes. It's mostly imperative and can be used like a glorified task runner.
Salt let's you mostly declaratively describe the state of a system. It comes with a agent/central host system for distributing this configuration from the central host to the minions (push).
Puppet is also declarative and also comes with an agent/central host system but uses a pull based approach.
Specialized/ exotic options are also available, like mgmt or NixOS.
But sure, it's cheap otherwise. Point granted.
One way or another, salt is not a major driver of cost in bread, because there's relatively little salt in bread. (If there's 1kg of flour, you might have 20g of salt.)
It's actually not too bad, if look at the capital cost of a bread factory amortised over each loaf of bread.
The equipment is comparatively more expensive for a home baker who only bakes perhaps two loafs a week.
Actually I am looking for tools to automate DevOps and security for self-hosting
In practice, there are two situations where cloud makes sense:
1. You infrequently need to handle traffic that unpredictably bursts to a large multiple of your baseline. (Consider: you can over provision your baseline infrastructure by an order of magnitude before you reach cloud costs) 2. Your organization is dysfunctional in a way that makes provisioning resources extremely difficult but cloud can provide an end run around that dysfunction.
Note that both situations are quite rare. most industries that handle that sort of large burst are very predictable: event management know when a client will be large and provision ticket sales infra accordingly, e-commerce knows when the big sale days will be, and so on. In the second case, whatever organizational dysfunction caused the cloud to be appealing will likely wrap itself around the cloud initiative as well.
Ansible can also do that, on top of literally anything else you could want - network configuration, infrastructure automation, deployment pipelines, migrations, anything. As always, that flexibility can be a blessing or a curse, but I think Ansible manages it well because it's so KISS.
RedHat's commercial Ansible Automation Platform gives you more power for when you need it, but you don't need it starting out.
Ansible-Lockdown is another excellent example of how Ansible can be used to harden servers via automation.
I have to ask - do scripts not work for you?
When I had to do this back in 2005 it was automated with 3 main steps:
1. A preseed (IIRC) debian installation disc (all the packages I needed where installed at install time), and
2. Which included a first-boot bash script that retrieved pre-compiled binaries from our internal ftp site, and
3. A final script that applied changes to the default config files and ran a small test to ensure everything started.
Zero human interaction after powering a machine on with the disc in the drive.
These days I would do it even better (system-d configs, Nix perhaps, text files (such as systemd units) can be retrieved automagically after boot, etc).
It is in general the simplest of these systems to get started with and you should be able to incrementally adopt it. There is also a plethora of free online resources available for it.
Of course, the difference between sourdough and anything else is astonishing, I just can't comprehend someone charging $21 for it!
Breaking into a home is relatively easy.
And unless you live in the US and is willing to actually shot someone (with all the paperwork that entails, as well as physical and legal risks), the fact is that you can't actually stop a burglary.
Simplicity is uncomfortable to a lot of people when they're used to doing things the hard way.
I bet you could figure out `apt install nginx` and a basic config pretty quickly, definitely faster than a web dev could learn game programming. “What do you mean, I have to finish each loop in 16 msec?”
The default thought to use the cloud because it's more performant though for even the most basic to intermediate loads instead of the hardware directly is what I'm referring to and what the article is referring to.
It's very easy to pay for cloud services per transaction at greatly inflated prices than what it actually costs, and how many cpu cores it actually uses at any given time.
The person you're replying to mentioned a self-hosting use case, so this probably isn't relevant for that, but Ansible can also be configured for a pull approach, which is useful for scaling.
Some skills are required, but it's really not that hard once you learn the technique and have done it a few times.
Edit: I feel like I should give you a more fulsome response, so here goes:
I understand the frustration. I feel it too, even apart from HN making me feel it as part of my job. But I've had to learn some lessons about this, such as:
1. It doesn't help to assume the position of the-one-who-is-not-stupid. Doing that is supercilious and just means you'll contribute to making things worse.
2. Far better is to accept that, as one is human, one shares in all the qualities of being human, including a full complement of stupidity.
3. I forget the third lesson!
No. It covered setting up all the applications needed as well (nginx, monitoring agent, etc), installing keys/credentials.
What did parent mention that can't be covered by the approach I used?
Sure you can script all the things into 3 steps, just like you can draw an owl with a couple circles.
Stupid people ruin everything.
Maintain, maybe. The setup for everything extra can scripted, and include a few packages I had to build from source myself because there was no binary download.
I'm not a PaaS user, and I encourage people to avoid vendor lock-in and be in control of their own destiny. It takes work though, and you need to sweat the details if you care about reliability and security, which continue to be problem areas for more DIY solutions.
If people aren't willing to put in the work, I'd rather they stick to the managed services so they don't contribute to eroding the already abysmal trust of the industry at large.