There are still reasons to have a VPS. However nearly all of them are driven by one factor for me:
American ISPs suck; cash from the wallets and otherwise.
For one thing, they often make it against the ToS to host 'a server' (generally).
ISPs with even remotely decent uploads, EVEN for their business offerings, in the metro area around Seattle (still crazy rent, can't even afford to try buying a house) are like CableCo for 1000mbit down 35mbit up for too much a month or DSL for (I am not joking) 7mbit down (if your connection is GOOD) and (LESS THAN) 1mbit up.
At least for CableCo they also have far too many outages for long periods. I strongly suspect 50%+ of what I pay goes to someone's profit instead of even a tiny bit of (maybe not 100% speed) redundancy and ways of performing maintenance that aren't several hours overnight.
>For one thing, they often make it against the ToS to host 'a server' (generally).
Beyond this, it can also be impossible due to lack of a static IP or control over the router (5G internet service with CGNAT). A VPS with WireGuard and remote port forwarding allows access for things like SSH.
Many DNS providers allow you to curl a particular URL to set the IP address for your domain. Set your server to curl it periodically, and it solves the lack of a static IP.
"It's 2022, and I'm here to tell you, that deploying stuff online purely using SaaS / IaaS offerings is an option, and it's often the quickest, the cheapest, and the best-quality option (although can't you only ever pick two of those? hahaha), and it quite possibly should be your go-to option."
For me, the solution is Cloudflare + (pick 2) random cloud providers + a sanity check for failover or bypass of Cloudflare if something really messes up.
I run a custom stack on 90% of my sites, so it isn't feasible to use SaaS / IaaS.
I'm in the metro area around Seattle (across the sound), and my CenturyLink bonded pair syncs at 92M/15M (it was 87M/11M but it mysteriously changed last November; pricing tier is 80M/unspecified). Although there are a lot of places where the speeds are what you quoted, if they'll install for you at all. It always shocks people when I quote my speeds though... but Comcast won't service my property even though they service my neighbors and are on the poll. My county's PUD has a reasonable fiber program, but the install costs are too high / too much hassle because I'd need to trench down a long driveway to the street.
Anyway, the speeds are OK, but PPPoE is terrible (and I hear they run PPPoE over fiber around here too), and at least my Remote Terminal has no battery, only utility power and utility power on this side of the sound doesn't have a lot of nines. I've got a LTE hotspot to failover to, but the cell towers get iffy when the utility power goes out too.
Anyway, I feel your pain. I run servers in my house, but I have to run a VPS for my 'important' stuff.
> I hear they run PPPoE over fiber around here too
Yeah, the old CenturyLink fiber installs have PPPoE. New installs under the Quantum brand are plain DHCP, but still on VLAN 201. (Perhaps to discourage people from accidentally plugging in their router wrong? Not sure.)
> ISPs with even remotely decent uploads, EVEN for their business offerings, in the metro area around Seattle (still crazy rent, can't even afford to try buying a house) are like CableCo for 1000mbit down 35mbit up for too much a month or DSL for (I am not joking) 7mbit down (if your connection is GOOD) and (LESS THAN) 1mbit up.
There are residential ISPs offering symmetrical gigabit fiber in a pretty good chunk of metro Seattle. I lived in an apartment tower so had access to Wave-G (previously CondoNet)'s insanely good gigabit offering, but friends who rented houses in the suburbs also had residential fiber.
Have these anti-server ToS clauses ever been enforced?
To me it seems like a “cover your ass” clause they put in there to be able to disconnect people who put undue stress on a shitty oversubscribed asymmetric network by hosting a very popular and heavy website, or if they notice a large business website being hosted and need an excuse to force the company to upgrade to a business-grade plan. It does not necessarily mean they’ll enforce it religiously without a good technical & financial justification.
As long as your overall usage remains within the bounds of a typical home user, you’ll be fine. Keep in mind that nowadays home users use a ton of upload bandwidth for things like cloud storage/backups and don’t get cut off even if they saturate the pipe for hours, so you have a pretty wide margin to play with. Torrenting and P2P also use upload heavily and have been around for decades without many horror stories that I know of (the main problem with torrents is copyright infringement and not bandwidth usage).
A self-hosted personal website or some apps (Nextcloud, etc) for personal usage will be a drop in the bucket compared to the above.
Well, there is Cloudflare Tunnel if you need to expose something (ssh, database, http services, etc) to the internet without maintaining a vps to act as a tunnel/reverse proxy yourself.
It sounds like you never really needed a VPS, that you could have just paid some shared hosting provider $10 a year to host your site and been fine, but instead you chose to do so and now somehow came to the realization that you never needed to do so. Cool story, but then you throw in a bunch of stuff like about how SaaS is hard to compete against but simply because you never had a reason for a VPS in the first place.
Once you calculate things like bandwidth, then SaaS is not hard to compete against... so if you need to upload 20TB+ a month with a 10GB uplink, then certain VPS providers make perfect sense cause you'd end up paying 1000+k dollars per month to do the same through some cloud SaaS solution.
The things he has moved to SaaS sounds like it's, simple, public low volume stuff. My only concern is what happens if the free provider just disappears, but reading between the lines it sounds he's got that covered. His web site is in git, he has a local copy of his git repositories and he backs it up to S3. Personally I've always used SaaS for stuff like that.
Much harder is personal private stuff like email / contacts / calendar / photos. Stuff you want kept private, you don't want to loose ever and must be online 24/7. In utopia the back end would be redundant store with copies stored at multiple vendors, so you don't care if one dies. And the front end is yet another SaaS provider that uses the back ends. If they disappear you just move to another one, pointing them to your back ends.
In the real world you use Google or a competitor to do all jobs, they make it hard to export / import your data to other providers, they mine your data, they will make it available to governments and law enforcement agencies and possibly lawyers on request without telling you, and if they get the shits with you it disappears and you loose everything.
In todays world that what SaaS delivers to most people, and it's reads like a deal with the devil.
Author here. That's right, I'd like to think I do have it pretty well covered, if the free provider just disappears. They're static sites, they can be hosted anywhere. I have almost no lock-in (except for a few config files, and function hooks, that could be ported fairly easily). If one provider pulls the rug out from under me, I can move to another one. In the worst case scenario, if all the providers stop offering free static hosting, I could just move all my www hosting back to a VPS (although I'd probably move it to S3 + CloudFront + Lambda, which isn't free, but is so cheap for low-volume that it might as well be free).
Yes, I agree, personal private stuff is harder. Before embarking on this static-site endeavour, I migrated my photos from Flickr to S3 / CloudFront, and that was a big project in itself (and Flickr is one of the nicer SaaS'es, that lets you export your data quite easily). For email / contacts / calendar, I'm pretty locked in (with one of the big providers), I wouldn't mind moving to a better setup where I own and I control the data, but honestly, it's in my too hard basket.
Author here. I never needed a VPS for the bandwidth. But I did need it for dynamic www hosting (mainly powered by Gunicorn + PostgreSQL). SaaS / PaaS alternatives (e.g. Heroku - which I've used occasionally), or IaaS alternatives (e.g. in Amazon land, RDS / ECS / S3), in that space, are generally more expensive.
Now that my sites are "static" (the inverted commas are because there's still actually dynamic functionality, powered by serverless functions), I can host them on a number of different SaaS / PaaS providers, that have fairly generous free plans.
And that is understandable. I have my site hosted on GitLab Pages for free and love that it is fast and feels dynamic even though it is static. However, I also have some other stuff that takes up quite a bit of storage that would only work on a VPS or dedicated server, but in pricing it out with cloud providers it was like 100x the cost.
I would argue that production servers should be immutable appliances. They should not have mutable root file-systems, they should not have package managers, they should not have ssh or require direct modification. Those are security accidents waiting to happen. I do not babysit my servers in my home rack. I have a company to run and better things to do just like the author, but that is no reason to give up freedom, privacy, and security. I like my servers to be as reliable and low maintenance as a refrigerator. They are not pets or a garden.
Try container optimized appliance operating systems like Talos OS or application specific firmware-like images like Homeassistant provides and you can generally set up services with automatic updates and forget about them for extended periods of time, knowing they will auto-rollback and notify you if manual intervention is ever required. If they fully fail you can just restore a new stack in minutes from a git commit and your last backup.
My Nix machine is stateless apart from a few directories such as home that I want to remain across reboots. When I shutdown/restart the server anything not in a mount I’ve explicitly configured to be persisted, gets erased.
The initial setup was a bit of work but the end result works flawlessly.
There are several options, one of the most popular Linux options right now is Fedora Silverblue[0]
"The toolbox is using container technology to bring back your familiar tools and development environment on top of the immutable Silverblue base, for the best of both worlds."
There is Flatcar Linux which is literally based on ChromeOS for standalone systems. For high availability Talos Linux is the way to go with their k8s-appliance-os approach, IMO.
There is still some work there for the use cases he's mentioned (git hosts, backups, web servers). Rotating https certs, adding mutable volumes for backups, ssh (you say you don't need it, but it's pretty useful if you're running a git server), and so on. So, yes, they can do much of what you're describing, but it doesn't always work out of the box...there's work involved.
I run ssh for git inside a "from scratch" container with the git binary running unprivileged as an application. There is no need to interact with the host operating system.
Backups can be handled by a backup container. If the host OS is stateless, there is nothing to backup. All you care about are data volumes, which you can then use any automated container daemon backup solution for. A very well solved problem.
For rotating https certs, there are endless letsencrypt containers that automate that for you too.
The point is you do the work for what you need up front, once, and then you don't need much work to keep it maintained.
I think the point there is that all of what you've mentioned are one-time "costs". You set them up in the beginning (and presumably the parent is managing this stuff in Ansible or Chef or whatever, so if the box irreparably dies, it's not hard to provision a new one) and then you don't need to worry about them.
(The one recurring thing is TLS cert rotation, but for a home/personal server I'd presume most people would just use Let's Encrypt via certbot, which will auto-renew via cron.)
Most of my services are at home in a dedicated lan but I still have one vps server that is used as a reverse proxy and which forward everything via a tunnel.
The OS itself doesn't need much maintenance. I have set up auto updates and auto reboot on a regular basis. And you know what? Distros do their job very well and it just works. We are talking home service, I can deal with (less than) 5 minutes of downtime once in a week. I use rhel derivated distro which means major disruptive upgrade are only dealt with once every n years. I may choose an immutable distro in the future when support ends though.
Rotating https certs? Certbot makes automatic rotation easy.
ssh? What is the deal? You set it up basically once. Add a bit of port knocking if you want more silent logs.
To add a bit of security, set up crowdsec, fail2ban. Again, these tools do not require a lot of maintenance.
Most of the burden of maintenance comes from the management of the apps/services you want to have live. PaaS won't really help you much with that. SaaS tend to be expensive or lock you, they help if the service you want to maintain is complex. I don't think that is the case for the services described in the OP: static websites, git and backups.
There are traps though. For example should you run containers to easily maintain certain services or use the distro packages? You can argue that containers whom upstream project provide image for allows you to easily upgrade any service. I can switch from any postgresql version in a snap for instance. However while it is easy to track and set up auto update a major version using a tag, you might want to be more cautious with major versions bumps. And this keeping informed with the various upstream project, know when and why to do major upgrade, what are the impact and potentially maintenance task of any major release upgrade. This is the hardest part. Sometimes it might be best forgetting about using upstream container for some services and sticking to the version supported by your long term maintenance distro that does the job of backporting any security patch to have that peace of mind. You can still run it as a container, but using the distro packages. That is what I do for databases for example.
Cloud is all about buying resources(IaaS) and functions(SaaS) of your choice. That means, one can purchase storage and traffic like the case here, or CPU time and memory for data processing. One specific scenario can work for someone, but that doesn't define what cloud is or should be, because it's all about choice.
Fine if you can make do with static sites but that's hardly a common use case. Most of us who use a VPS are hosting Nginx with a reverse proxy to Rails, Django, Express or Laravel + PostgreSQL or MySQL where the memory costs are a fraction of the equivalent cloud offering. I tried Github pages once, rather than Netlify, and pulled my hair out trying to get HTTPS working with a personal domain. Last I checked it's still not possible.
Author here. A big part of why I'm saying "I don't need a VPS anymore", is because I'm also saying "I don't need dynamic sites anymore". I've been building dynamic sites for two decades (once upon a time "original LAMP stack" PHP + MySQL, more recently Python + PostgreSQL). I honestly never imagined that static sites could one day compete with that. But times have changed, and the JAMstack of 2022 has all the functionality you need. I've managed to convert all my old dynamic sites to be statically generated, without really compromising on bells and whistles. And the SaaS I'm now using is (almost) all free. As far as I'm concerned, I'm having my cake and eating it too.
I think you're overplaying the "static" card. If you're using the JAMstack the static bit is only half of the equation. Need a contact form? Now you need a form-processing service and it's no longer static. If you're replacing old PHP + MySQL sites you'll need a lot more than a static site generator. "Mostly static" might be more accurate but then how long does that last? Clients typically want WordPress plus a ton of plugins. I don't see how JAMstack addresses that need. You say it's nearly 100% free but I just looked at Netlify's free tier and you're only allowed 100 form submissions per month after which they're $19 each. I don't think I would get a night's sleep with that hanging over my head.
It's up to you when you think a traditional server back-end is still warranted, there are certainly still cases where it makes sense. But if all you need is a contact form, then I'd argue that it doesn't make sense! Yes, I agree, Netlify Forms is a rip-off, if you need more than the free limit of 100 submissions per month (which personally I don't, but of course many people do). But there are many other options for simple form handling, I'd recommend looking into them. And the JAMstack can compete quite well with WordPress and co these days, check out https://myclientwants.com/
The thing is I only picked on forms off the top of my head. There's a ton of functionality in your average client site which I can't imagine JAMstack catering for without it costing a lot more than hosting it on a VPS. JAMstack seems to cater for the painting by numbers model of web development but that's only a small fraction of what clients need. The JAMstack equivalent of a typical WordPress site, I imagine, would have to pull-in a dozen external services costing a lot more than the VPS alternative. Netlify make a big deal about the low-cost scalability of the CDN factor in JAMstack but it's only low-cost when you don't use external services. It's quite the opposite, I've heard, once you've outgrown static and need a third party service for every new feature.
That’s right. Plus you miss out on control, functionality, optimization, flexibility on the dev side and predictability and simplicity on the business side. It turns things upside down and for the type of work we do these are exactly the wrong tradeoffs.
Agreed. I used to be on the JAMstack train, but when your dynamic needs grows, you site has more and more dependencies and some are vendor specific such as Netlify. Now I have simplified all to use just one web stack for simple static site, to crud site to rest api backend, running from container. Minimise vendor dependency so I can easily move around be it self hosted at home, vps, AWS, Cloud Run or whatever. Rather than creating more Netlify clone, I hope HN crowd can create Cloud Run clones that let you easily host a container, not just static pages.
> It's up to you when you think a traditional server back-end is still warranted
All the cases outside of "oh, I dump my thoughts on the page once a year".
Even for a blog in the modern world I would like:
- automatic crossposting to Twitter and Facebook
- automatic retrieval and reformatting of external content (because, for example, twitter embeds are very cumbersome, heavy and slow)
- automatic retrieval of video and images from external sites (youtube, instagram, twitter etc.) because of link rot
- delayed publishing
- search
- and a plethora of other things
Yes, you can stitch togethe a bunch of "serverless" stuff for this, but you've just "replaced" the "traditional server backend" with a bunch of traditional server backends.
> A big part of why I'm saying "I don't need a VPS anymore", is because I'm also saying "I don't need dynamic sites anymore". I've been building dynamic sites for two decades (once upon a time "original LAMP stack" PHP + MySQL, more recently Python + PostgreSQL). I honestly never imagined that static sites could one day compete with that. But times have changed, and the JAMstack of 2022 has all the functionality you need.
This IMO should have been the main point of the article, not VPSes. No one can argue that a maintaining a live website is better if a few HTML pages will do.
> "I've managed to convert all my old dynamic sites to be statically generated, without really compromising on bells and whistles."
In your linked article you say:
"Anyway, site search is only a nice-to-have...and folks can just use Google with the site: operator instead"
To me that sounds like a compromise.
I'm out of my depth talking about SSG-powered sites because I've never developed them. My area is frontend design-dev, without the engineering stripes or desire for overly complicated builds. That's why PHP and the traditional dynamic sites work for me.
PHP, javascript, templates and a good reliable CMS allows me - the non-engineer, to do really interesting things such as site search with lots of added unique tricks to make users happy when they search for things.
Beyond my needs, the non-technical people I build sites for need to manage the content easily. That's where I scratch my head with the SSG offerings in that regard. Where the CMS is often the lowest priority, with bizarre suggestions and workarounds to fill the CMS void. For complex content-heavy sites with lots of products, forms, landing pages and categories, a good CMS is really important... and a general architecture that isn't scattered around big tech services IMHO.
Re: search. It's not that site search is impossible, or even particularly hard, with a JAMstack site. It's just that I didn't consider it MVP for my personal site. I know how it can be done, and I'll implement it when I have time.
Re: CMS. I know where you're coming from, I spent a good decade or so specialising in traditional CMSes / frameworks myself, mainly Drupal and Django. There are various answers to the CMS question for static sites - the ones that I'm most familiar with are https://forestry.io/ and https://tina.io/ (and I've heard no end of buzz about <https://www.sanity.io/>). Those solutions are solid, I wouldn't call them "bizarre suggestions and workarounds". And they're good enough for most needs, IMHO. But I haven't tried pitching them to clients yet.
> I tried Github pages once…and pulled my hair out trying to get HTTPS working with a personal domain.
Last I checked HTTPs was available by default even on custom domains. I did have to remove and re-add my custom domain on a Github pages site that was created before this was the case. But after doing that, it was 0-config.
>Fine if you can make do with static sites but that's hardly a common use case.
This feels odd to me. Unless you are building a web site that is a product, why do you need anything besides a static site? I am going to go as far as to claim that: most websites should be static sites.
>I tried Github pages once, rather than Netlify, and pulled my hair out trying to get HTTPS working with a personal domain. Last I checked it's still not possible.
Don't know when you checked last, but this is false and has been for years. My personal page/blog/demo has been running in Github pages for past 5 years and I've had custom domain the whole time. I can't remember if HTTPS was from the beginning, but it sure is there now.
If memory serves me correctly all you need to do is to point your domain to githubs name server and add a file called `CNAME` with your custom domain to your repo to get it working.
> Nginx with a reverse proxy to Rails, Django, Express or Laravel
/me over here reverse proxying to Hunchentoot with CL framework of the week. Have yet to see a serverless setup that even has any idea what CL is . . .
Once there were a lot of free tera byte image hosting services. And then after some market ups and downs, most of them either closed down, asked for subscription fee or hugely restricted what can be done.
Free static hosting services might not remain such for long. At the very least, they might introduce terms or condition you might not like. Then it will be harder for you to shift to another service, compared to switching your VPS server.
Also I count my time spent on managing the servers as free. For me it's experimenting what else can be done, gaining experience and overall enjoyable time spent.
If your VPS was build by hand over a long period of time, sure it's hard to switch to another service. If your VPS setup is automated by Ansible or NixOS or something, it ceases to be hard.
Sites hosted on Netlify literally just depend on a github repo with a TOML configuration file at the root.
For basic static sites, which I imagine fit the needs of the majority of personal hosting, it's incredibly trivial to point the same repo at a different static hosting platform.
A long hold out! Works for most use cases. If you are doing any big data processing that doesn't neatly fit in a predefined resource plan then you are still doing all the SSHing etc. You might even be buying your own physical beefy computer to throw in the closet and SSH into from elsewhere.
I wonder how long the likes of Netlify and Vercel will last though, before they too introduce onerous conditions.
Author here. Yes, I'm singing Netlify's praises, but there are plenty of alternatives - GitHub Pages, Vercel, Cloudflare Pages, to name a few - that are just as good. And it's a funny kind of "ad", when you consider that I'm paying $0 for my Netlify account, and I'm making it pretty clear that most other people should be able to use it for free too.
Edit: Sourcehut pages is the most direct parallel to Github pages but there's a bunch more options for free hosting listed on gemini://geminiquickst.art/ And that's not even mentioning the number of Tilde's that are configured to let you host Gemini content.
I think people forget that unavailability can be caused by non-technical things like changing terms of service.
It's easy to recognize that you shouldn't run something critical on a piece of software considered "beta", but too many people happily seek the loss-leading free tier of cloud providers.
If your service is essentially losing money for the company hosting it, that's not a good place to be. Still trying to convince my company to stop using the Dockerhub free tier after they pulled the rug out once already...
“If you wish to make an apple pie from scratch, you must first invent the universe” - Carl Sagan
The same can be said for self-hosting. Everyone trusts some other person or company at some level in the stack. It's all about balancing the tradeoffs and finding a sweet spot that works for you. Too many people miss the forest for the trees – the important thing is to create and get your work out there, not endlessly argue about what sized hammer to use.
No one never needs to trust copper wires or single transistors. One could, in theory, build an entire computer from discrete components and never have to trust external hardware or software. Of course, it wouldn't be very practically useful and would be a monumental amount of effort.
But hey, it's a cozy thought for those chasing the trust dragon.
I think in this context building a computer from individual transistors and copper wire is the same as “invent the universe” for the purposes of the expression.
Or baking an apple pie, to feed your electronics engineer? If you're going to carry it to its logical conclusion, "invent the universe" works in any context.
AFAIK, we don't currently have the ability to compile any of our software from scratch. Every compilation utilizes digital artifacts that were created externally. To operate a "no trust computer", not only would you have to build the hardware for scratch, but you would also have to recreate more than a half century of collaborative advancements in computer science. This isn't a cozy thought for those "chasing the trust dragon" since it means that a true "no trust computer" is impossible to create for any single individual and even practically impossible for any group operating on a timescale of less than decades.
You'd have to make an assembler then a compiler by hand to bootstrap. It's a monumental task, but reasonable to do. The blueprints are all there. Re-implementing modern operating systems and complex languages and the tools that run on them? That's wholly impossible for one human lifetime.
This is one of my favorite youtube videos in the past year.
You have to do that and much more. A "self-hosting" basic OS is a great achievement that I am not trying to downplay. However there really aren't any examples that I am aware of where that was achieved without relying on artifacts somewhere up the chain that come from an external source. I would say that achieving any self-hosting OS without relying on external artifacts is well outside one human lifetime. Edit: You have to completely manually bootstrap your hardware design and manufacturing simultaneously with your software.
Heh, check out the precursor. No blobs, serious concern over even simple chips like display controllers and keyboards. They implemented the risc-v CPU in an FPGA with opensource files, etc.
Definitely the most trustworthy computer I've seen.
Over the pandemic, as an ideological mission against surveillance capitalism, I went about as far as my technical skills could take me: self-hosting open source everything on a VPS, eliminating all FAANG software, Linux desktop, custom ROM on my Android. At the beginning, the amount of control I had over my data and my software was exhilarating. I learned a lot, and some of the changes will become permanent. But after about six months, I didn't have the free time any more to maintain all of that. I decided to switch to Apple's ecosystem and trust them to handle things for me. Yeah, I'm ideologically against some of their recent privacy and security moves. But at least they're not wholesale selling my data and attention to advertisers. I never did manage to find a suitable replacement for Google Maps, though I gave Organic Maps and OSMand a fair try. I tried ProtonMail and eventually switched to Fastmail. Still using Nextcloud for files, calendar and photos, but I'll probably switch to iCloud and/or Fastmail's options for those.
If you're interested, Here (the PaaS for automative industry in-dash nav), has a website based maps: https://wego.here.com. They also have a phone app. I only found this out because I was looking into where my vehicle pulled it's in-dash nav maps from.
When reading posts like this I often think, why do so many people not use Ansible (or an equivalent) for running these updates?
It's really easy to get a simple start. You can do one thing at a time. For a while I had only an inventory file and a small play that ran updates. With a single command I can make sure updates are installed on all the machines.
I might need some perspective. Every time I read one of these I'm just shaking my head, and yes the arguments are Less Power, Less Control, but also SysAdmin is me. That is my identity, and the part of the job that I like the most. I solve problems with configuration before code. So I hate to think that I'm becoming obsolete, of course. I also don't think that I am, because I do think that my way has some clear and definite advantages over eg. Netlify. I also think that "my site is free as in beer and also lightning fast" generally transposes to "my site doesn't have any traffic". Am I deluded? I recognize that I have a clear bias, but even stepping back, I do think that even if some don't need a VPS (or server) anymore, that there is still room for my ilk in the tech world.
I was a junior system administrator... And became an early cloud adopter...
I think your viewing is valid, but yes, biased by your knowledge.
Since you already know system administration, it's not hard for you to manage another system... That's your day job, what's a personal one?
But for people who prefer code, handing that off is a blessing.
I runs small light sail vps.. it took me only a few hours to write up scripts to manage containers.. and a few more hours to automate backups to a secure location in another AWS account... But for today years, what I just described is impossible, or a 1-2 week task.. not an afternoon...
And this is our bias... For us, it's easier than learning lambda, or api gateway... But for them, those are easier than learning system administration.
I also disagree with the idea we are becoming obsolete... I work in a serverless DevOps environment for 4+ years and still explain basic networking concepts regularly... Stuff that don't teach much of in computer science... Like failover DNS ... While managing DNS was moved to the cloud, many still don't understand the technical reasonings of things.
> I also think that "my site is free as in beer and also lightning fast" generally transposes to "my site doesn't have any traffic"
its more about being able to handle spurts of traffic and sustained traffic. these services are good enough to power whole communities and mobile apps. and that means it covers most use cases, as well as the placeholder websites that may launch a product once.
and by most use cases, we're talking about just the 99th percentile of high load intertwined ratsnest products not being able to handle it, but even then that's only because of an insanely high traffic load that is loading unique queries that are impossible to cache and this breaks view rendering - aka the bottleneck is still elsewhere.
with things that render quickly and have that view cached on the nearest CDNs, and that have giant memcaches of the queries that will be used, you really aren't needed!
fortunately there are many web services that are not designed that way, cannot be designed that way, but more so can't/won't be redesigned that way.
You're not wrong, and I think the right way to think about it is in the context of a company that wants to go "multicloud" -- suddenly they need to abstract a suite of infra-as-code configuration components up out the individual services and APIs offered by various cloud/VPS providers and the reductio ad absurdum of this process is systems administration.
Essentially, a system that requires administration is the opposite (on the far end of spectrum) of vendor lock-in (whether that's AWS, or technologies like k8s, et cetera). Make of that what you will, in terms of the need for your ilk (and mine) in the tech world.
There will always be sysadmins in the same way there will always be Fortran programmers. There are benefits to the old way of doing things, but those benefits are of shrinking relevance.
Don't you mean Cobol? Atleast here in Aus it was cobol on mainframes... My understanding of Fortran was that it found its niche in high performance scientific computing.
Sure, COBOL works for this example too. I was originally going to be a little spicy and use C++, which was once also the "everything" language but now exists only in a few (shrinking) areas.
You're not obsolete. It's just that some people just want to drive their car and get it serviced somewhere every once in a while rather than doing it themselves. Same for servers.
I would note that every single company I've had in the last 8 years has essentially been replacing sysadmins with infra-knowledgable programmers working with AWS services (who might have been sysadmins in a past life). No one in the engineering org was hired who couldn't program. IT's "System Engineers" were aimed towards "you need to write code to do your job with LDAP/AD/Okta/etc". If someone identifies as a sysadmin and can't write Python/Perl/Go/Ruby, I would... strongly suggest changing that, because I think _that_ has become mandatory for forward looking shops, if not normal shops.
Also. With respect to cost.
AWS costs me something under $1/mo to host my static page on S3 and have my domain point to it. I don't have much traffic. If I did, I could sort that out with relevant tooling; it's still wildly cheap vs compute. The FaaS model (although I personally loathe it) is also reported to be very cost-effective for certain classes of problems.
> [..] If someone identifies as a sysadmin and can't write Python/Perl/Go/Ruby [..]
this is the difference between a systems admin and a systems engineer. some folk can't make the jump from sysadmin, despite best intentions and training.
It is a common (new) myth that sysadmins didn’t code.
There were some IT technicians who couldn’t code and some operations staff who couldn’t code (and would proudly claim this, for some reason). But tools like ansible, salt, chef and terraform were written by sysadmins.
In fact a lot of non-feature code in my companies such as database fencing programs and automated blue/green rollouts has been written by sysadmins.
We’ve just been starting to call them something else since 2013 now.
Sysadmin long enough and you'll find yourself inadvertently scripting in Bash. A few languages and API later and you'll realize that you may be coding. That is how it went for me...
I cut my teeth on ancient VAX, AS/400, Solaris, HP-UX and Irix connected via NFS and Fibre SANs. Runbooks became shell scripts, then a DB backend, etc. Chef/Ansible/Puppet/et al all evolved from this practice.
At the time I moved on to greener pastures, I left behind a global Enterprise Storage environment that was semi-automated by workflow. Directly descended from ksh/bash and then moved to REST once that started to be available. Vendor tooling cost $ and sucked.
"Oh, you need to report on all your disparate proprietary backup environments, success/failure, generate reports and ServiceNow incidents? Cool, we'll just bang that out in python and store in Mongo."
Today, that would be a startup SaaS play (adjusted for technology of course).
It is amazing the stuff you learn and create to prevent burnout/churn while maintaining critical infrastructure as a cost-center org.
This might be pedantic, but DevOps originated in the idea that ops and devs needed to work very closely together to deliver capabilities. It _then_ turned into a role "cloud sysadmin" and then lately seems to be "build engineer".
Somewhere along the switch from "System Programmer" to "Sysadmin", probably around turn of the century Windows Server timeline, "sysadmin" somehow started to imply there's no programming.
Despite ridiculous amounts of Perl written by system admins, among other things.
What's really interesting is that I've run into a lot of sysadmins who can't/don't code; its a continual surprise to me. Writing Perl to manage a system was just part of the deal back when (dating myself now. :) ).
I think that given people don’t believe now that sysadmins used to write a fair chunk of code; what has happened is people hiring “sysadmins” these days don’t make coding a part of the job.
Thus, sysadmins today are doing what helpdesk and system operators used to do 15 years ago. Which means it is now true that sysadmins don’t code, due to a weirdly shifted perception over time and that perception becoming self-fulfilling.
This is something that annoys me. I’m most comfortable identifying as a sysadmin for a few reasons. I spend a lot of my time on problems that don’t make sense to automate. I spend my time at the code level building automation tooling instead of creating or debugging application code. Historically I have often spent my time with developers guiding them on how what they’re doing fits into a broader ecosystem, teaching them something both critical and esoteric about the application so that they can do their job better, and often guiding them on specs.
It’s not everyone’s experience, but my experience has been that a lot of developers who don’t have a sysadmin background aren’t as skilled at those things. The business analysis, cost control, or the application meets infrastructure parts. Case in point, one of my best friends and frequent professional collaborators is a pure-programming guy who works in AWS. He knows everything there is to know about provisioning the most common AWS resources via CloudFormation and Terraform, but I have never seen him demonstrate a realistic understanding of costs or _why_ certain resources are used in lieu of others, or a strong aptitude in optimizing for specific workloads and business cases. If he hits on an area that is “traditionally” sysadmin work, it’s deer in the headlights.
> there is still room for my ilk in the tech world.
Yes, there is. AWS/GCP/Azure are incredibly complex beasts, and people who know how to properly set them up (anything from proper user management and rights to correct ingress points and resource allocation) are as rare as 100-carat diamonds. It's a different kind of SysAdmin job, but it is that.
Don't believe people who are saying "you can just hire junior admins or infra-knowledgable programmers" are talking out of their asses (or until a kubernetes cluster upgrade or a lapsed IAM role brings the company down for 24 hours).
I sometimes write code, I sometimes configure things, I sometimes write code to write configuration, sometimes I rearchitect the damn thing. I do whatever it takes to reach the business goal.
If all you know is how to configure something, it's like only having a hammer in your toolbox
If all you know is how to code something, it's like only having a hammer in your toolbox
If all you know is how to run a network, it's like only having a hammer in your toolbox
Not many companies want someone that will move from network problems to code problems to configuration problems to physical problems to supplier problems to security problems over the course of an afternoon, but if you do get a job like that it's nice and varied.
Well I appreciate the feedback, but I didn't mean that I only configure. But over a decade in the business, mostly as a dev first (an infra-knowledgeable dev seems to be the term being bandied about here), I discovered that infra is my first love. So I don't wish to outsource it.
When the winds of change blow, some people build walls and some people build windmills.
You strike me as the type of person who wants to think about themselves as building windmills, but your resistance to embracing technology is building walls.
You’re being a Luddite, afraid of the textile mill because of the time you spent learning to weave. That’s not a good thing for someone who likes technology to do.
Go and learn go, and become an SRE.
That’s all the awesome parts of sysadmin, but modern, automated and without the massive downsides.
There are two or three scare-mongering arguments in the article that I cannot believe to be true. The rest might be valid but throwing-in these makes the whole post less valuable:
- traffic might take your site down: it's never going to happen, although I understand why one would hope so
- SSH attacks: change your default port
- shellshock: you use or used CGI scripts in the last decade?
Author here. Sure, maybe successful attacks in those categories are unlikely. But my main point was, so long as I maintain my own VPS, they're still possible, and I'm responsible for defending my box against them. Whereas in SaaS land, I don't even know what physical / virtual boxes the provider has, nor do I care, because I'm not responsible for their security nor for anything else regarding them.
If you have run VPSes for some time, how come you have not learnt and taken some steps to make it less prone to attacks? That's the part I don't find credible enough, or can't share the rationale to include it in this post.
Author here. Like I said in the article, "... I've picked up more than a thing or two when it comes to Linux sysadmin". I did harden my VPS here and there, over the years. And there never was a successful attack on my VPS - not that I'm aware of, at least.
But that doesn't change the fact that I simply don't want to manage a VPS anymore. Like I also said: "However, I've learnt what I have, out of necessity, and purely as a means to an end. I'm a dev, and what I actually enjoy doing, and what I try to spend most of my time doing, is dev work. Hosting everything in SaaS land, rather than on a VPS, lets me focus on just that."
I think you are misinterpreting the joke... it isn't pejorative against or parodying religion, it is making fun of tech companies handling security by just confessing security sins and then thinking that is enough.
There was a hype on serverless, so a lot of people here on HN is a bit allergic on them and tell ‘an EC2 instance is all you need’. And it’s not wrong — I’ve seen seriously over-engineered serverless systems with so much AWS-specific code. But a few years passed now a lot more services now provide (almost) lockin-free APIs that are pretty useful for simple.
IMO blindly recommending ‘just self host’, a sentiment that I see a lot in HN isn’t a good answer.
Blindly, nothing is a good answer; you need to weigh your needs. But so most people blindly grab aws; unlike yourself, I find HN actually almost The AWS & K8s Promotion Team. People swear by this stuff here, even if you don’t need it, at all. They forget that not all startups have million$/year to throw away on devops to handle the bizarre complexity of those solutions while they also just really do not need them (now and, statistically, as they will likely fail, ever). It all always reads like resume driven development; I understand it; good people you hire want to do stuff that furthers their career. But it makes it blind in almost all cases I read here (which are tiny companies with no traffic at all, ramping up to be the size of TikTok overnight).
But I digress.
Ec2 is incredibly expensive (outside the free tier that is) compared to many other vps options.
And as for serverless; last month a startup without funding was making a scraper and used aws lambda because it was easy. With their js code it took me 1 day to save them 1/1000th of their cost by using a vps; on ec2 that would’ve been a 1/10th save (outside the free tier which would not work; not enough power). This saving allows them to hire an extra dev for free to work on, you know, extra bottom line features to actually create a business.
For a $10m-for-a-PoC seed invested startup, this is all the usual blah blah about ‘but it saves time on management’ (it doesn’t in this case or many others I have seen in the wild), but if you don’t have prior VC relations on speed dial, you might be funding it all yourself (for now) and cloud stuff is just shovelling money into a pit if you don’t need the upsides at this moment.
I find the argument that you shouldn’t be using serverless because you don’t have money to throw on devops a bit… strange? Isn’t the big reason on using serverless to avoid spending money and time to managing your own server?
And IMO the lambdas-are-cheap argument is more like that lambdas are expensive, but they multiply to your scale, so it’s super-cheap in small startups. I view lambdas as a starting point for PoCs — they eventually have to move to VPCs, but lambdas are free if it gets no traffic.
And that’s why I’ve mentioned lockin-free APIs: lambdas are terrible if you can’t migrate away from it. But if you can without much effort, it provides pretty good value.
Your Ubuntu VPS is free, open, loosely configured, and vulnerable.
Your Netlify account is closed, tightly configured with specific focus on one problem, and secured with timely patches and a monitored network.
What product is free, open, tightly configured, and secured with updates and a default iptables that isn’t just -P INPUT ACCEPT?
Perhaps someone awesome is providing docker images that have the latest and greatest in single-problem-focused software, with a built in firewall, and a security team? That’s the kind of thing I’d be into helping out, in my spare time.
As a js/node guy I would pay money for a opensource "managed" base os image with only 22,80,443 open with app armor/selinux configured and user accounts with plug and play containers for select from (nginx,haproxy,varnish,node,redis,postgres,couchdb)
196 comments
[ 2.8 ms ] story [ 274 ms ] threadAmerican ISPs suck; cash from the wallets and otherwise.
For one thing, they often make it against the ToS to host 'a server' (generally).
ISPs with even remotely decent uploads, EVEN for their business offerings, in the metro area around Seattle (still crazy rent, can't even afford to try buying a house) are like CableCo for 1000mbit down 35mbit up for too much a month or DSL for (I am not joking) 7mbit down (if your connection is GOOD) and (LESS THAN) 1mbit up.
At least for CableCo they also have far too many outages for long periods. I strongly suspect 50%+ of what I pay goes to someone's profit instead of even a tiny bit of (maybe not 100% speed) redundancy and ways of performing maintenance that aren't several hours overnight.
Beyond this, it can also be impossible due to lack of a static IP or control over the router (5G internet service with CGNAT). A VPS with WireGuard and remote port forwarding allows access for things like SSH.
"It's 2022, and I'm here to tell you, that deploying stuff online purely using SaaS / IaaS offerings is an option, and it's often the quickest, the cheapest, and the best-quality option (although can't you only ever pick two of those? hahaha), and it quite possibly should be your go-to option."
I run a custom stack on 90% of my sites, so it isn't feasible to use SaaS / IaaS.
My homelab has never been happier!
Anyway, the speeds are OK, but PPPoE is terrible (and I hear they run PPPoE over fiber around here too), and at least my Remote Terminal has no battery, only utility power and utility power on this side of the sound doesn't have a lot of nines. I've got a LTE hotspot to failover to, but the cell towers get iffy when the utility power goes out too.
Anyway, I feel your pain. I run servers in my house, but I have to run a VPS for my 'important' stuff.
Yeah, the old CenturyLink fiber installs have PPPoE. New installs under the Quantum brand are plain DHCP, but still on VLAN 201. (Perhaps to discourage people from accidentally plugging in their router wrong? Not sure.)
There are residential ISPs offering symmetrical gigabit fiber in a pretty good chunk of metro Seattle. I lived in an apartment tower so had access to Wave-G (previously CondoNet)'s insanely good gigabit offering, but friends who rented houses in the suburbs also had residential fiber.
To me it seems like a “cover your ass” clause they put in there to be able to disconnect people who put undue stress on a shitty oversubscribed asymmetric network by hosting a very popular and heavy website, or if they notice a large business website being hosted and need an excuse to force the company to upgrade to a business-grade plan. It does not necessarily mean they’ll enforce it religiously without a good technical & financial justification.
As long as your overall usage remains within the bounds of a typical home user, you’ll be fine. Keep in mind that nowadays home users use a ton of upload bandwidth for things like cloud storage/backups and don’t get cut off even if they saturate the pipe for hours, so you have a pretty wide margin to play with. Torrenting and P2P also use upload heavily and have been around for decades without many horror stories that I know of (the main problem with torrents is copyright infringement and not bandwidth usage).
A self-hosted personal website or some apps (Nextcloud, etc) for personal usage will be a drop in the bucket compared to the above.
AFAIK some ISPs block common ports (eg. 80/443). That sounds like "enforced" to me.
Edit: The author wrote “SaaS / IaaS” in the final paragraph.
The author duly notes that a VPS does not belong to you in ways similar to those SaaS offering don't, so why bother.
If all you used a VPS for was hosting public static web pages, then there's indeed little point to run a VPS by hand.
Once you calculate things like bandwidth, then SaaS is not hard to compete against... so if you need to upload 20TB+ a month with a 10GB uplink, then certain VPS providers make perfect sense cause you'd end up paying 1000+k dollars per month to do the same through some cloud SaaS solution.
The things he has moved to SaaS sounds like it's, simple, public low volume stuff. My only concern is what happens if the free provider just disappears, but reading between the lines it sounds he's got that covered. His web site is in git, he has a local copy of his git repositories and he backs it up to S3. Personally I've always used SaaS for stuff like that.
Much harder is personal private stuff like email / contacts / calendar / photos. Stuff you want kept private, you don't want to loose ever and must be online 24/7. In utopia the back end would be redundant store with copies stored at multiple vendors, so you don't care if one dies. And the front end is yet another SaaS provider that uses the back ends. If they disappear you just move to another one, pointing them to your back ends.
In the real world you use Google or a competitor to do all jobs, they make it hard to export / import your data to other providers, they mine your data, they will make it available to governments and law enforcement agencies and possibly lawyers on request without telling you, and if they get the shits with you it disappears and you loose everything.
In todays world that what SaaS delivers to most people, and it's reads like a deal with the devil.
Yes, I agree, personal private stuff is harder. Before embarking on this static-site endeavour, I migrated my photos from Flickr to S3 / CloudFront, and that was a big project in itself (and Flickr is one of the nicer SaaS'es, that lets you export your data quite easily). For email / contacts / calendar, I'm pretty locked in (with one of the big providers), I wouldn't mind moving to a better setup where I own and I control the data, but honestly, it's in my too hard basket.
Now that my sites are "static" (the inverted commas are because there's still actually dynamic functionality, powered by serverless functions), I can host them on a number of different SaaS / PaaS providers, that have fairly generous free plans.
I would argue that production servers should be immutable appliances. They should not have mutable root file-systems, they should not have package managers, they should not have ssh or require direct modification. Those are security accidents waiting to happen. I do not babysit my servers in my home rack. I have a company to run and better things to do just like the author, but that is no reason to give up freedom, privacy, and security. I like my servers to be as reliable and low maintenance as a refrigerator. They are not pets or a garden.
Try container optimized appliance operating systems like Talos OS or application specific firmware-like images like Homeassistant provides and you can generally set up services with automatic updates and forget about them for extended periods of time, knowing they will auto-rollback and notify you if manual intervention is ever required. If they fully fail you can just restore a new stack in minutes from a git commit and your last backup.
https://docs.freebsd.org/en/articles/nanobsd/
My Nix machine is stateless apart from a few directories such as home that I want to remain across reboots. When I shutdown/restart the server anything not in a mount I’ve explicitly configured to be persisted, gets erased.
The initial setup was a bit of work but the end result works flawlessly.
https://cloud.google.com/container-optimized-os/
"The toolbox is using container technology to bring back your familiar tools and development environment on top of the immutable Silverblue base, for the best of both worlds."
[0] https://silverblue.fedoraproject.org/
Backups can be handled by a backup container. If the host OS is stateless, there is nothing to backup. All you care about are data volumes, which you can then use any automated container daemon backup solution for. A very well solved problem.
For rotating https certs, there are endless letsencrypt containers that automate that for you too.
The point is you do the work for what you need up front, once, and then you don't need much work to keep it maintained.
(The one recurring thing is TLS cert rotation, but for a home/personal server I'd presume most people would just use Let's Encrypt via certbot, which will auto-renew via cron.)
The OS itself doesn't need much maintenance. I have set up auto updates and auto reboot on a regular basis. And you know what? Distros do their job very well and it just works. We are talking home service, I can deal with (less than) 5 minutes of downtime once in a week. I use rhel derivated distro which means major disruptive upgrade are only dealt with once every n years. I may choose an immutable distro in the future when support ends though.
Rotating https certs? Certbot makes automatic rotation easy.
ssh? What is the deal? You set it up basically once. Add a bit of port knocking if you want more silent logs.
To add a bit of security, set up crowdsec, fail2ban. Again, these tools do not require a lot of maintenance.
Most of the burden of maintenance comes from the management of the apps/services you want to have live. PaaS won't really help you much with that. SaaS tend to be expensive or lock you, they help if the service you want to maintain is complex. I don't think that is the case for the services described in the OP: static websites, git and backups.
There are traps though. For example should you run containers to easily maintain certain services or use the distro packages? You can argue that containers whom upstream project provide image for allows you to easily upgrade any service. I can switch from any postgresql version in a snap for instance. However while it is easy to track and set up auto update a major version using a tag, you might want to be more cautious with major versions bumps. And this keeping informed with the various upstream project, know when and why to do major upgrade, what are the impact and potentially maintenance task of any major release upgrade. This is the hardest part. Sometimes it might be best forgetting about using upstream container for some services and sticking to the version supported by your long term maintenance distro that does the job of backporting any security patch to have that peace of mind. You can still run it as a container, but using the distro packages. That is what I do for databases for example.
But I don't use IRC anymore really :(
Cloud is all about buying resources(IaaS) and functions(SaaS) of your choice. That means, one can purchase storage and traffic like the case here, or CPU time and memory for data processing. One specific scenario can work for someone, but that doesn't define what cloud is or should be, because it's all about choice.
All the cases outside of "oh, I dump my thoughts on the page once a year".
Even for a blog in the modern world I would like:
- automatic crossposting to Twitter and Facebook
- automatic retrieval and reformatting of external content (because, for example, twitter embeds are very cumbersome, heavy and slow)
- automatic retrieval of video and images from external sites (youtube, instagram, twitter etc.) because of link rot
- delayed publishing
- search
- and a plethora of other things
Yes, you can stitch togethe a bunch of "serverless" stuff for this, but you've just "replaced" the "traditional server backend" with a bunch of traditional server backends.
This IMO should have been the main point of the article, not VPSes. No one can argue that a maintaining a live website is better if a few HTML pages will do.
In your linked article you say:
"Anyway, site search is only a nice-to-have...and folks can just use Google with the site: operator instead"
To me that sounds like a compromise.
I'm out of my depth talking about SSG-powered sites because I've never developed them. My area is frontend design-dev, without the engineering stripes or desire for overly complicated builds. That's why PHP and the traditional dynamic sites work for me.
PHP, javascript, templates and a good reliable CMS allows me - the non-engineer, to do really interesting things such as site search with lots of added unique tricks to make users happy when they search for things.
Beyond my needs, the non-technical people I build sites for need to manage the content easily. That's where I scratch my head with the SSG offerings in that regard. Where the CMS is often the lowest priority, with bizarre suggestions and workarounds to fill the CMS void. For complex content-heavy sites with lots of products, forms, landing pages and categories, a good CMS is really important... and a general architecture that isn't scattered around big tech services IMHO.
Re: search. It's not that site search is impossible, or even particularly hard, with a JAMstack site. It's just that I didn't consider it MVP for my personal site. I know how it can be done, and I'll implement it when I have time.
Re: CMS. I know where you're coming from, I spent a good decade or so specialising in traditional CMSes / frameworks myself, mainly Drupal and Django. There are various answers to the CMS question for static sites - the ones that I'm most familiar with are https://forestry.io/ and https://tina.io/ (and I've heard no end of buzz about <https://www.sanity.io/>). Those solutions are solid, I wouldn't call them "bizarre suggestions and workarounds". And they're good enough for most needs, IMHO. But I haven't tried pitching them to clients yet.
Last I checked HTTPs was available by default even on custom domains. I did have to remove and re-add my custom domain on a Github pages site that was created before this was the case. But after doing that, it was 0-config.
This feels odd to me. Unless you are building a web site that is a product, why do you need anything besides a static site? I am going to go as far as to claim that: most websites should be static sites.
>I tried Github pages once, rather than Netlify, and pulled my hair out trying to get HTTPS working with a personal domain. Last I checked it's still not possible.
Don't know when you checked last, but this is false and has been for years. My personal page/blog/demo has been running in Github pages for past 5 years and I've had custom domain the whole time. I can't remember if HTTPS was from the beginning, but it sure is there now.
If memory serves me correctly all you need to do is to point your domain to githubs name server and add a file called `CNAME` with your custom domain to your repo to get it working.
/me over here reverse proxying to Hunchentoot with CL framework of the week. Have yet to see a serverless setup that even has any idea what CL is . . .
I'm not. Not sure where you got that idea.
Once there were a lot of free tera byte image hosting services. And then after some market ups and downs, most of them either closed down, asked for subscription fee or hugely restricted what can be done.
Free static hosting services might not remain such for long. At the very least, they might introduce terms or condition you might not like. Then it will be harder for you to shift to another service, compared to switching your VPS server.
Also I count my time spent on managing the servers as free. For me it's experimenting what else can be done, gaining experience and overall enjoyable time spent.
That might not be true for everyone.
No way. I can move a folder of files to anywhere quite confidently. Even a VPS.
But I have no idea what I would do if I needed to move my VPS. I’d probably have to start over from scratch.
For basic static sites, which I imagine fit the needs of the majority of personal hosting, it's incredibly trivial to point the same repo at a different static hosting platform.
well, and: Netlify plus what that brings in.
I wonder how long the likes of Netlify and Vercel will last though, before they too introduce onerous conditions.
Edit: Sourcehut pages is the most direct parallel to Github pages but there's a bunch more options for free hosting listed on gemini://geminiquickst.art/ And that's not even mentioning the number of Tilde's that are configured to let you host Gemini content.
It's easy to recognize that you shouldn't run something critical on a piece of software considered "beta", but too many people happily seek the loss-leading free tier of cloud providers.
If your service is essentially losing money for the company hosting it, that's not a good place to be. Still trying to convince my company to stop using the Dockerhub free tier after they pulled the rug out once already...
The same can be said for self-hosting. Everyone trusts some other person or company at some level in the stack. It's all about balancing the tradeoffs and finding a sweet spot that works for you. Too many people miss the forest for the trees – the important thing is to create and get your work out there, not endlessly argue about what sized hammer to use.
But hey, it's a cozy thought for those chasing the trust dragon.
This is one of my favorite youtube videos in the past year.
https://youtu.be/SJ7lOus1FzQ
Definitely the most trustworthy computer I've seen.
It's really easy to get a simple start. You can do one thing at a time. For a while I had only an inventory file and a small play that ran updates. With a single command I can make sure updates are installed on all the machines.
I think your viewing is valid, but yes, biased by your knowledge.
Since you already know system administration, it's not hard for you to manage another system... That's your day job, what's a personal one?
But for people who prefer code, handing that off is a blessing.
I runs small light sail vps.. it took me only a few hours to write up scripts to manage containers.. and a few more hours to automate backups to a secure location in another AWS account... But for today years, what I just described is impossible, or a 1-2 week task.. not an afternoon...
And this is our bias... For us, it's easier than learning lambda, or api gateway... But for them, those are easier than learning system administration.
I also disagree with the idea we are becoming obsolete... I work in a serverless DevOps environment for 4+ years and still explain basic networking concepts regularly... Stuff that don't teach much of in computer science... Like failover DNS ... While managing DNS was moved to the cloud, many still don't understand the technical reasonings of things.
its more about being able to handle spurts of traffic and sustained traffic. these services are good enough to power whole communities and mobile apps. and that means it covers most use cases, as well as the placeholder websites that may launch a product once.
and by most use cases, we're talking about just the 99th percentile of high load intertwined ratsnest products not being able to handle it, but even then that's only because of an insanely high traffic load that is loading unique queries that are impossible to cache and this breaks view rendering - aka the bottleneck is still elsewhere.
with things that render quickly and have that view cached on the nearest CDNs, and that have giant memcaches of the queries that will be used, you really aren't needed!
fortunately there are many web services that are not designed that way, cannot be designed that way, but more so can't/won't be redesigned that way.
Essentially, a system that requires administration is the opposite (on the far end of spectrum) of vendor lock-in (whether that's AWS, or technologies like k8s, et cetera). Make of that what you will, in terms of the need for your ilk (and mine) in the tech world.
Those sysadmins are by and large someone else's problem now :-p
Also. With respect to cost.
AWS costs me something under $1/mo to host my static page on S3 and have my domain point to it. I don't have much traffic. If I did, I could sort that out with relevant tooling; it's still wildly cheap vs compute. The FaaS model (although I personally loathe it) is also reported to be very cost-effective for certain classes of problems.
this is the difference between a systems admin and a systems engineer. some folk can't make the jump from sysadmin, despite best intentions and training.
There were some IT technicians who couldn’t code and some operations staff who couldn’t code (and would proudly claim this, for some reason). But tools like ansible, salt, chef and terraform were written by sysadmins.
In fact a lot of non-feature code in my companies such as database fencing programs and automated blue/green rollouts has been written by sysadmins.
We’ve just been starting to call them something else since 2013 now.
I cut my teeth on ancient VAX, AS/400, Solaris, HP-UX and Irix connected via NFS and Fibre SANs. Runbooks became shell scripts, then a DB backend, etc. Chef/Ansible/Puppet/et al all evolved from this practice.
At the time I moved on to greener pastures, I left behind a global Enterprise Storage environment that was semi-automated by workflow. Directly descended from ksh/bash and then moved to REST once that started to be available. Vendor tooling cost $ and sucked.
"Oh, you need to report on all your disparate proprietary backup environments, success/failure, generate reports and ServiceNow incidents? Cool, we'll just bang that out in python and store in Mongo."
Today, that would be a startup SaaS play (adjusted for technology of course).
It is amazing the stuff you learn and create to prevent burnout/churn while maintaining critical infrastructure as a cost-center org.
Language shifts, man. Weird stuff.
Despite ridiculous amounts of Perl written by system admins, among other things.
Thus, sysadmins today are doing what helpdesk and system operators used to do 15 years ago. Which means it is now true that sysadmins don’t code, due to a weirdly shifted perception over time and that perception becoming self-fulfilling.
It’s not everyone’s experience, but my experience has been that a lot of developers who don’t have a sysadmin background aren’t as skilled at those things. The business analysis, cost control, or the application meets infrastructure parts. Case in point, one of my best friends and frequent professional collaborators is a pure-programming guy who works in AWS. He knows everything there is to know about provisioning the most common AWS resources via CloudFormation and Terraform, but I have never seen him demonstrate a realistic understanding of costs or _why_ certain resources are used in lieu of others, or a strong aptitude in optimizing for specific workloads and business cases. If he hits on an area that is “traditionally” sysadmin work, it’s deer in the headlights.
Yes, there is. AWS/GCP/Azure are incredibly complex beasts, and people who know how to properly set them up (anything from proper user management and rights to correct ingress points and resource allocation) are as rare as 100-carat diamonds. It's a different kind of SysAdmin job, but it is that.
Don't believe people who are saying "you can just hire junior admins or infra-knowledgable programmers" are talking out of their asses (or until a kubernetes cluster upgrade or a lapsed IAM role brings the company down for 24 hours).
I sometimes write code, I sometimes configure things, I sometimes write code to write configuration, sometimes I rearchitect the damn thing. I do whatever it takes to reach the business goal.
If all you know is how to configure something, it's like only having a hammer in your toolbox
If all you know is how to code something, it's like only having a hammer in your toolbox
If all you know is how to run a network, it's like only having a hammer in your toolbox
Not many companies want someone that will move from network problems to code problems to configuration problems to physical problems to supplier problems to security problems over the course of an afternoon, but if you do get a job like that it's nice and varied.
You strike me as the type of person who wants to think about themselves as building windmills, but your resistance to embracing technology is building walls.
You’re being a Luddite, afraid of the textile mill because of the time you spent learning to weave. That’s not a good thing for someone who likes technology to do.
Go and learn go, and become an SRE.
That’s all the awesome parts of sysadmin, but modern, automated and without the massive downsides.
There is. I'm trying to hire more of it as we speak.
- traffic might take your site down: it's never going to happen, although I understand why one would hope so
- SSH attacks: change your default port
- shellshock: you use or used CGI scripts in the last decade?
But that doesn't change the fact that I simply don't want to manage a VPS anymore. Like I also said: "However, I've learnt what I have, out of necessity, and purely as a means to an end. I'm a dev, and what I actually enjoy doing, and what I try to spend most of my time doing, is dev work. Hosting everything in SaaS land, rather than on a VPS, lets me focus on just that."
I also have a lot of projects which live in a GitHub repository but are then deployed by GitHub Actions to Cloud Run or Vercel.
IMO blindly recommending ‘just self host’, a sentiment that I see a lot in HN isn’t a good answer.
But I digress.
Ec2 is incredibly expensive (outside the free tier that is) compared to many other vps options.
And as for serverless; last month a startup without funding was making a scraper and used aws lambda because it was easy. With their js code it took me 1 day to save them 1/1000th of their cost by using a vps; on ec2 that would’ve been a 1/10th save (outside the free tier which would not work; not enough power). This saving allows them to hire an extra dev for free to work on, you know, extra bottom line features to actually create a business.
For a $10m-for-a-PoC seed invested startup, this is all the usual blah blah about ‘but it saves time on management’ (it doesn’t in this case or many others I have seen in the wild), but if you don’t have prior VC relations on speed dial, you might be funding it all yourself (for now) and cloud stuff is just shovelling money into a pit if you don’t need the upsides at this moment.
And IMO the lambdas-are-cheap argument is more like that lambdas are expensive, but they multiply to your scale, so it’s super-cheap in small startups. I view lambdas as a starting point for PoCs — they eventually have to move to VPCs, but lambdas are free if it gets no traffic.
And that’s why I’ve mentioned lockin-free APIs: lambdas are terrible if you can’t migrate away from it. But if you can without much effort, it provides pretty good value.
Your Netlify account is closed, tightly configured with specific focus on one problem, and secured with timely patches and a monitored network.
What product is free, open, tightly configured, and secured with updates and a default iptables that isn’t just -P INPUT ACCEPT?
Perhaps someone awesome is providing docker images that have the latest and greatest in single-problem-focused software, with a built in firewall, and a security team? That’s the kind of thing I’d be into helping out, in my spare time.