[sufehmi]

Clearly the author still hasn't learned his lesson: his "no more vendor lock" solution is another vendor(s) - which is always able to vendor-lock him, again.

It is truly mind blowing on how many people keep falling for one of the oldest trick in IT : vendor lock-in.

===

No more vendor lock In 2018 Heroku was pretty much the only option for a newbie like me to get started with web-development. The landscape is very different now with providers like Render, Railway, and more

[Dylan16807]

"always able to vendor-lock him" how?

Moving to another vendor while making it easy to move between vendors doesn't get you locked in.

[Gordonjcp]

> Heroku was pretty much the only option for a newbie like me to get started with web-development

How, exactly? What happened in 2018 that somehow made it impossible to just host a website?

[remram]

Plenty of VPS options, with free tiers, in 2018.

[govolckurself]

When all you have is a Heroku, everything starts to look like a nail.

[emodendroket]

So what should he be doing, building his own data center?

[jakear]

Building your own data center isn't enough, land ownership is a myth as you'll still be locked in to your government via property taxes.

The real self-hosted solution is running your server off a solar powered yacht in international waters while transmitting and receiving all data via worldwide shortwave radio. Fire any customers not willing to invest in a SW-Ethernet adapter.

[cozzyd]

Shortwave radio depends on ionospheric conditions, which can be manipulated via nuclear blasts, ionospheric heating facilities, solar activity, and volcanos. Instead you must modulate a neutrino beam from international waters using a nuclear submarine for power. Fire any customers not willing to invest in kiloton-scale neutrino detectors.

[hot_gril]

Or just use the regular Internet but conquer the entire world first to make sure nobody can tell you what to do with it.

[TylerE]

Rent a $5/month VPS, install a few packages? Or just run a linux vm locally.

[emodendroket]

So, rely on yet another vendor, or do as I suggested except without any semblance of reliabiliy.

[TylerE]

Some one just starting out is not Google. They do not have Google's problems. They do not need Google's complexity, or a dozen layers of docker/terraform/k8s bullshit.

[qeternity]

I really don’t understand this. Docker is not difficult to learn. K8s marginally more so.

Even if you don’t need HA it’s still worth it for a small team for ease of deploy.

[govolckurself]

Docker is difficult to understand in-depth, and, at least in my career, I haven't met too many people who do more than just skim a blog post and then think they know everything about Docker. This is how you get Docker punching holes in your firewall[1] and everyone acting surprised, because they a) didn't read the docs and b) have no idea how firewalls work.

Docker's interface might seem simple, but it adds an entirely new layer of complexity, with semantics only superficially understood by the vast majority of its users, and nobody ever seems to talk about Docker's negatives. A good rule of thumb might be: if you can't accurately explain how Docker works under the hood, or if you don't understand the OS components Docker itself uses, you shouldn't use it.

[1] https://news.ycombinator.com/item?id=29576522

[akie]

Dockerizing (what the author said he would do) is almost always worth it though.

[slyall]

Agreed, instead of "a dozen layers of docker/terraform/k8s bullshit" they just need they application code and some config that will take them an hour to setup once.

[progval]

But there is no vendor lock-in here, VPS providers are interchangeable.

[bastawhiz]

Sure, and the vendors the author mentions are interchangeable, too. Just at a different layer of the stack.

[jostiniane]

you clearly have no idea how things work outside of hobby projects, what about reliability? scalability, guaranteed uptime, resolving incidences,... You can account for all for that for yourself by creating a mini cloud provider.. good luck with that

[Toutouxc]

Easy with the big words. All of that really depends on whether you're B2C or B2B, what kind of app it is and what kind of client. There's a company that has my code (Rails apps) running on Ubuntu Server VPSes with one guy who picks up the phone and restarts the server if something goes wrong (i.e. once a year). And the clients are multi-million businesses.

[jostiniane]

Yeah, common primitive sense is "big words". You understand that competitiveness and cloud certificatios based on some sort of a measurements of those "big words". I wonder how B2B or B2C is a decisive choice.

[CogitoCogito]

Half of the "robust" and highly complex solutions I see employing modern practices go down way more often than the simple version that the GP described.

[jostiniane]

Probably I don't know enough to argue, but those are the repeated arguments and which I agree with. In my current place, I know we can reduce the infra bill significantly if we move to renting physical servers or VPSs, but nobody would like to gamble on the "big words" (availability,..). We already have a system to deal with downtime in one region but it will take much more efforts that would lead to a minicloud if we want to go with the dedicated hosting.

[govolckurself]

What about those things? They're just glittering generalities, and an appeal to them is frequently used to justify adding ever more complexity to software.

The vast majority of startup web apps don't need anything more than a decent MVC framework (seriously, just use the web as designed) and a fast database. Keep a warm spare of your application running if a box goes down and you need to cut over or something. No, it's not sexy. No, they probably won't invite you to speak at Re:Invent. But your shit will work and it'll be cheap and FAST.

I've seen way too many basic CRUD apps, written by developers who mean well, needlessly overcomplicated in the name of things like "scalability" and "reliability". And guess what? They were some of the least scalable, least reliable applications. I'm talking applications where low double-digit requests per second for basic web pages caused the entire thing to shit itself.

So no, you don't actually need your own mini cloud provider to run a solid service. You just need to know what the hell you're doing.

[Hamuko]

I don't really see avoiding vendor lock as the most important part of creating systems. It's definitely nice to have and all things being equal, I'll take a solution that avoids vendor lock over a solution that doesn't. But I'm still going to keep using AWS Lambda for example, since I can get pretty good value out of it despite it being not a portable solution.