jiaosdjf
2 hours ago
The cloud space is absurd, we've sat by for 2 decades while the likes of AWS define every aspect of deployment, auth, even containerisation.
Containerisation was supposed to mean host anywhere, literally redeploy a complex set of services and their connections on any cloud provider at the drop of a hat. That is what a f**ing shipping container is, you rock up to any port in the world and the same container is lifted by any crane onto any ship or truck.
Amazon, Google, Microsoft - these people have sold vendor lock-in to the very segment of tech society that should have been fighting it tooth and nail. 20 years ago you ftp'd some PHP files and it just worked, now you have to figure out 20 IAM profiles and shit your files across buckets because everything must be 1000000x scalable out of the box.
No joke I was building a static firebase site the other day and just wanted a simple way to password protect it (like http auth) for staging so my client could see it - of all the useless shit firebase tries to lock you into they can't even do something as simple as basic http auth without a shit show and spinning up a cloud run instance or something to check a static password.
Yes we 100% need fix hosting, everything should be portable, simple, generic.
figassis
16 minutes ago
I think vendors will do what vendors will do, and you can choose to buy into that or not. Containers fullfilled their promise. You can today host anything yourself easily, with a single command.
The problem comes when developers start building things without this in mind. I see simple site analytics apps in github, where the docker compose file is a web os services and the repo itself is full of init scripts and the sort. You have redis, mongo, an RDBMS container, an analytics db, kafka, all the kafka tooling like bookkeeper, then you have outsourced auth liek clerk or supabase (when the whole thing is not just some supabase chimera with edge functions and whatever else supabase is supposed to run outside your infra).
And the repo description is: simple, anonymous wesbite analytics. The entire thing is more complex than the thin you want to do analytics for. So you bring that into a cloud, and instead of a container, you are now advised, but both AWS and your HN peers that you need to replace each component with it's cloud version, such as elasticache, AKS, cognito, firebase, whatever.
All of these services as you set up, trap you into overprovisioning. Your DB needs to have 3 replicas or you have no guarantees, your auth needs an entire instance of something running somewhere or unicorns start dying.
By the time you come out for sunlight your bill could pay your rent. So you don't self host, you signup for google analytics.
Everytime I find a project on GitHub, the first thing that makes me close it immediately is whether it has a docker-compose.yaml and if it's a single, sane/dumb, low footprint deployment or a chimera.
So self hosting is alive and well, whether your app is easy to self host, and whether you know how to use just what you need from cloud vendors are different questions.
ezst
21 minutes ago
That's why, every time a discussion comes up about decoupling from the US tech and cloud offering, and how supposedly the whole world is captive and incapable without it, I'm like "well, certainly we should give it a serious try, because we might love a bit too much what we encounter down the road in terms of complexity and costs savings."
walrus01
2 hours ago
If you don't mind me asking a question to better understand your perspective: Are you old enough to have personally experienced and built self-hosted things before the advent of AWS, cloud hosted stuff, or is your text above (which I do not disagree with in any way) the point of view of a person who began working on this stuff in the "cloud-native" era, post-2012 or around then?
I'm thinking from the "20 years ago" it is the first one, so your experience is even more valuable for those younger persons reading it because you've seen how things were before the vendor-lock-in era began.
I ask because I've been seeing an increasing trend of people who've self-taught themselves Linux/BSD things, grew up in the cloud-native era, and have now become increasing dissatisfied with the "Do everything in one vendor cloud" operations model that they initially learned. Many are now going the opposite direction and deciding to self host their own projects at much lower cost and much less vendor lock-in.
jiaosdjf
an hour ago
I'm in my 40s, full disclosure I've never worked in devops 'officially' but have hosted many personal and commercial projects, worked as a developer and later product manager. I have run my own small businesses as well as working for various corps.
In defence of cloud I will say that back in mid 2000s I did have to buy and rack my own servers, this was a pain in the ass and I don't want to ever see and especially hear the inside of a datacenter again. I'll also say that a lot of things are much easier and safer today, the industry has developed a lot of process and tooling.
So the issue isn't necessarily "cloud" but how large cloud vendors have strategised in their own best interests to do vendor lock-in, especially on the lower end of startups that are obviously open to shipping now and paying later, and how we have all lapped that up because they do give generous free-tiers and they do solve some real problems.
dgellow
an hour ago
Yeah, self-hosting is definitely having a come back. Lots of content creators who would have been evangelizing cloud solutions in the past have been instead going into the various self hosting rabbit holes. There is a bit of a pendulum swing. You now have access to so much information and tooling to host your own things, it’s pretty awesome compared to what we had before 2010.
Not sure how much impact that will have for companies, that will likely stay more niche. Companies will still want to delegate much of the effort to a cloud provider, but with pressure to have less lock-in
jiaosdjf
22 minutes ago
I've worked for a corp that spent good money to mirror their entire Salesforce setup internally on the basis that Salesforce was expensive, slow, and had all their customer data and could bring the entire business to its knees.
I've worked for another corp that spent insane amounts for a CMS that nobody understood and required a full time engineer on duty to "unlock" files for the content team - this company later built a simple CMS that just stored a title, body and image in a database because I shit you not: thats 90% of what they needed from a CMS and to do quick announcements/news in a mobile app would have taken weeks longer to develop if they had to integrate with the real CMS.
This was a few years ago before LLMs btw, so I can only imagine how crazy it is today
mitchitized
an hour ago
I remember driving to the datacenter to setup my own servers. I had a fractional T1 to my desk, it provided a blazing 640k (sometimes all the way up to an unfathomable 1MB!!1!) of bandwidth and only cost around $1,300 a month. Good times.
That gave way to hosting providers, like ServerBeach and Rackspace, where you paid them to setup the server hardware for you, saving the drive. You still had to deal with bandwidth, backup, redundancy, etc. Much easier than before but still a pretty big hassle.
Then the cloud happened. "Come to the cloud, where everything just magically happens for you," the salesperson said. So I went. And discovered that none of my scripts, tools or knowledge worked there, and had to completely start over from scratch. FOR EACH VENDOR. Gah.
The ONE thing I will grant cloud providers is that I can usually automate my way around their enshittification. They over-complicate things to an extreme where I do wonder if there is an actual savings or not, just based on the headaches their setups can consistently produce.
My take is that your needs pretty much determine which route is more/less painful. Sometimes you DO need the redundancy and uptime enough to tolerate the shenanigans of the vendor, and other times you just need your own machine to quietly get things done (without worrying about SLAs or client expectations).
The ultimate question you should be asking, and there is no right/wrong answer: For this particular effort, is it more valuable to you to learn how to do these things by hand, or is the infrastructure just a means to an end so you can do something specific?
jiaosdjf
31 minutes ago
Yeah agreed, there are pros and cons but ultimately we are exchanging control for convenience.
The idea of a hosting provider that manages all the boilerplate, security updates etc is not a bad thing. The idea of being able to spin up another node, have load balancing etc just work and you didn't even have to get out of bed - is also not a bad thing.
Where it becomes suspicious is when Amazon and Google both have their 'own' databases, which are just different enough to make it a pain. And yes I know I can spin up e.g. a Postgres instance on Google or AWS for not much money, but now I have a vendor-specific provisioning script. "Just use Terraform or Pulumi" - even when an LLM manages this web of corporate enterprise nonsense it's still unmanageable and everyone just ends up with a run book of prayers.