I think a lot of programmers in the industry just follow trends, they don't really understand the benefits and drawbacks of the technology they are using.

I have coworkers who host personal projects for their own use and put them in docker, set up CI pipelines, host them on a cloud service, use an enterprise level database on the backend. One of my coworkers made a completely static portfolio website with a single page and used react.

I don't mean this in a judgemental way, people are free to use whatever they like. But it does sadden me that instead of seeing tools and processes as having certain benefits and certain overheads it's now just "this is the tool we use for everything", and therefore "everything now has this overhead". Where the overhead is performance, time, complexity.

I understand your viewpoint because but also have you considered that your approach adds nothing to the builder?

I don't mean this in a judgemental way. In your scenario, I spend learning 50 different technologies that I will never use because they are not hired for. Whereas the colleague makes 50 different projects, gets comfortable with the technology and maybe hits an interesting edge case or two to talk about at their next interview, if they are lucky.

I am saying this as someone, who has tried to think about complexity and what not in my projects. But it turns out that I get a lot more mileage from practicing deployment with k3s than know what Dokku and Kamal do and how to deploy the app directly as a process.

> In your scenario, I spend learning 50 different technologies that I will never use because they are not hired for

I'm actually saying the opposite of this. To learn react you also need to know html, css and javascript, so I am saying if you need to make a static website that is just a single page you may as well just write it in HTML. I am saying you should use less technology.

Similarly to learn Docker you need to know bash so you already have the skills to just skip over docker and deploy your app directly by running bash commands on a linux server.

The "50 different technologies" is how I see the flavour-of-the-month cloud platforms that take something that's relatively simple (copying code to a server and running a command to start it) and turning it into a proprietary cloud platform you now have to learn. Whereas you could have just learnt how to deploy software to a linux server instead and have a skill that was valuable 20 years ago, is still valuable, and will still be the way software is fundamentally run in 20 years time as well I am sure. Meanwhile I have no idea what Dokku and Kamal even are - I'm sure they won't last as long as linux and bash have.

Dokku maintainer here.

I'm sure bash will outlast me. I do hope to work on Dokku for another 10/20/40 years, but if there's a better project out there, I'd be happy to help users migrate and bow out of the deployment space.

I maintain Dokku for the folks that don't want to build and maintain a bespoke deployment process around docker, and the k3s implementation uses helm at its core, so users can eject when Dokku has run its course. I think there is value in that - maybe not for everyone, but at least for folks busy with building product on a budget.

That said, I'm happy to see folks continue to build new tools and iterate on ideas in this space. Definitely cool to see how everyone improves on stuff I - and others - been working on for the last two decades.

I think the gp is saying the exact opposite of what you gave an example for, and in line with what you are saying i.e. less technology.

one more thing is you tried both kamal and dokku, and then made a deliberate choice of sticking to k3s because suits you the best rather than making a mindless descision about using k3s, which most people do!

> One of my coworkers made a completely static portfolio website with a single page and used react.

People love hating on react, but I mean this is pretty common. Raw is fine, but even in a "static" thing, you'll eventually go "ok now I want to reuse some text here.." Or have some common elements with x things shared. So I'm gonna have to write some hacky imperative JS? Or messy CSS? And what starts as static very easily becomes slightly dynamic. I hate overengineering, so if React were hard to setup or deploy I'd agree (eg Kube), but the cost-benefit of React makes it worth it in most cases for me

Yeah pretty much this. I tend to use Astro but I think your point still stands.

I wanted to make a basic online agenda in a few different formats for a Toastmasters club and though I could have used raw html and css to build it, but each agenda had slightly different layout that would have been a lot of copy pasting in html and lots of room for error.

With astro and react islands it was fairly simple to implement.

I had a similar problem and used 11ty to build static html from templates and markdown files. Works great and keeps you close to the metal

That sounds nifty, I'll check it out!

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.

sorry for the typos, I didn't actually come back to grammar check and I'm cringing now

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.

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.

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

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

Unfortunately it getting more expensive, as hosting companies started to rise prices because of memory costing more

Kind of unavoidable now for hosting companies purchasing new hardware, much as diesel costs are affecting trucking companies.

Let's say theoretically that a company decides to buy raw rack space+power colo and DIY your own router setup, upstream IP transit connections and buy their own server hardware... You're suffering equally from the increase in RAM costs buying your server hardware much the same as if you go with a dedicated bare metal hardware hosting company.

Every project I've ever worked on - sans two at IBM post Red Hat acquisition - had legacy style Javaboxes at the customer's DC or was still rocking mainframe DB2 stuff. I'm seeing bare-metal Kubernetes / OpenShift gaining a stronger foothold though. Rarely, some specific workloads did run on Azure - never anything critical though.

For context, I do mainly development work for EU enterprises and the public sector.

I've been doing this pre-2012.

There's always been vendor lock-in. Someone has to implement technologies to the standards, those are most of the time commercial interests.

Apache vs nginx, rhel vs debian, spring vs j2ee, etc. etc.

I think it's good for the young crowd to get into self-hosting. You learn more fundamentals that way, for sure. But I'm not looking to move stuff into self-hosted.

I get unlimited scalability in AWS. I can standup and run an app for $0-$5/month depending on how I want to build it. That app will have unlimited scalability, redundancy, automated backups, etc. It's not worth dealing with the headaches of managing things myself.

Most everything is the way it is today for good reason, it's just that the youngsters haven't had to learn those reasons themselves.

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?

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.

There’s a big gap between hobby self-hosting and enterprise.

Clouds are appealing (note, not technically better but more appealing) in the enterprise for numerous reasons. We already have a contract, I don’t have to spend a month with procurement. Their support is “respected” so “I asked AWS and they told me to pound sand” is an acceptable response to a lot of requests. No one ever got fired for picking AWS. The list goes on.

None of those friction points apply to hobby hosting, really. IAM is annoying because the alternative isn’t “fill out 7 forms and host 12 meetings to get a new vendor in”.

You also get less of the benefits. Low volume SQS can be trivially replaced, but if you use enough that you’re debating making a whole team to manage Kafka then paying the cloud tax can look appealing because of the predictability (your Kafka team might fail, SQS probably handles larger workloads currently).

At some scale, not having to wait 12 months for the message queuing team to support TLS for some regulation becomes worth a cloud tax.

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."

yea i also think it's weird that people who aren't doing work for organizations champion using aws/gcp/azure. we've all been around computers for a hot minute, we've seen stuff that is exciting and fun and easy to use, and stuff that is not.

i occasionally do a bit of aws and azure deployments for work, everything is reduced to yaml hell, i think its the most over convoluted experience ever to do anything and opaque billing strategies, abstractions, it's just gross. its hard to be passionate about that stuff.

i kind of laugh when people at my org talk about colocation and elastic strategies for some podunk reporting app, like the bare minimum sla 99.9999999% uptime and runs in regions close to the data and weeks of planning to have like a stupid crud app that maybe five people. use. everything has to neatly fit into this one size fits all cloud strategy the infra/devops team came up with and they could've just run multiple apps off a server rack in the office it's literally an internal tool. or hell they could've just came up with a desktop app deployment strategy to company devices and not used any cloud services. feels so boring

feel like the field of "devops" just kinda threw their hands up got really weird this past decade, and like you said just kinda bought into the deployment strats aws/gcp/azure pulled out of their ass.

I agree with part of your complaint, and many cloud services are deliberate vendor lock in (e.g. “serverless”).

But all the cloud vendors offer containers as a service, where you build your image locally and run it in a region. Naturally there will be setup to access networking, IO, gpus etc.

so i think you have some fair claims but you’re not making the best case here.

Containers as a service are ludicrously expensive as a way to buy compute though. It’s just amazing how much a poxy 1cpu 1gb instance is on azure.

Indeed. Convenience has a price. It’s the DoorDash of vcpu

We don't need to fix hosting. There's no such thing as "portable" or "generic" and there never will be. At a certain point you have to use an implementation of <thing> and that's going to lock you in.

I mean, containers are working fine like that. Choose any hoster you want, either specifically supporting docker deployment or bare metal and host your containers. It's just that many tools come with bad images or bad documentation on how to configure things for your domains and needs. That's usually where it breaks down. Not the container tech in itself. That one's working fine mostly.

This is just an incoherent bluster. Calm down.

You can still ftp some PHP files and it will just work - there are plenty of services that offer that.

You don't need to shit your files across buckets and provision 20 IAM profiles - noone's forcing you to do that and that is not how you host a web app.

If you're fond of the ftp-based hosting days, those services are available and they will happily take your money.

It's not that it has disappeared it's that vendor-specific cloud has become too normal.

And for the record obviously I'm not advocating for going back to the dark ages, ftp / php / shared hosting also had massive issues, my point was that things were _designed_ to be simple and the model in your head was simple and close to the metal.

If you're joining an existing project today, or like OP's problem/solution you just want to self-host something, maybe even just to evaluate it, it has become a headache.

I've never actually seen a "real" containerised app, one that was 100% agnostic and simple to deploy without multiple exceptions for 3rd party services and so on.

Yep, shared hosting might go away one day (altho I doubt it), but it's not going to be anytime soon