more developers need to hear this

Sven Slootweg

@ryantownsend I think their answer to "how did we get here" is missing a crucial bit of nuance: the influence of tech company blogs.

I've noticed a pretty clear pattern over the years where some tech company has to solve a problem at scale, blogs about how they've done it, and then there's a horde of developers who excitedly reads that blogpost and declares it the new best practice, elevating it to the level of "you are not a serious developer if you don't do this", often egged on by the tech company in question.

When prodded as to why, given that they are not a big tech company themselves, the answer has always been the same: a *belief*, not merely a hope, that they will be soon. Many of them outright reasoning along the lines of "if I do the same thing as this big tech company, I *will* grow as big as them and get rich, because clearly it worked for them".

This is, IMO, a much stronger effect than that article implies; this kind of technical writing actually drives entire hype cycles and steers entire developer communities in specific directions (as opposed to individual developers just being a bit optimistic), and I've seen it happen first-hand many times.

pancake :butterfly_::neofox_lesbian:

@[email protected] @[email protected] Ignoring the obvious cases of overengineering for the sake of quick monetary gain, I feel like sometimes we just wanna build stuff in a way akin to making a small shed, and deriving enjoyment out of committing to build it in a way where it lasts and maintaining it is enjoyable. We could both make it out of used wooden pallets and have a quick solution, or we could build it from bricks and be satisfied with it standing for a long time.

There's this sort of DIY (repair-ish) culture where people would rather build something solid themselves and enjoy the process, and there are people who don't wanna invest the time into it and I think it's valid when devs have a preference in how they deploy even if it isn't the optimal one.

We absolutely despise shell scripts and writing systemd services, but still enjoy running stuff. I feel we're justified in choosing our deployment pathway purely based on vibes if it brings us satisfaction in seeing it work, sort of [autistic] joy.

We like working on a website but the thought of having a deployment path that isn't fun is more detracting than the desire to write some article or blog for it

So I believe even spending 5 hours to automate a 2 minute task is a valid form of entertainment and learning new skills

Ryan Townsend

@natty you're absolutely right – to be clear, my viewpoint is:

1. DIY on personal projects to your heart's content – use FTP, K8s, bare metal, IaaS, PaaS (e.g. Heroku, Render, Vercel, Netlify), or whatever else makes you happy.

2. If you're on a commercial project: use a PaaS unless a) you can _afford_ and _justify_ hiring >=2 full-time DevOps people or b) you have some specific infra needs PaaS cannot cater to... if either of these are true, then _consider_ K8s

always tired

@ryantownsend Even with a simple fork exec based CGI 1/s was easy. 25 years ago. True. php stuff got a bit sluggish. But the C replacement I wrote? We didn't even need to do fastcgi. And it could process HTML templates.

always tired

@ryantownsend (Tbf, with a custom precompiler, so the actual CGI would only mmap one file)

Ryan Townsend

@project1enigma my suggestion here isn't to get more low-level, people should just default to outsourcing to PaaS (Heroku, Render, Vercel, Netlify, et al).

For 99% of commercial projects:

* K8s is over-engineering
* Bare metal / SFTP is under-engineering

Time/budget is generally better on product development than maintaining infrastructure.

The exceptions are:

* Massive scale (> mid 5-figure spend per month, where hiring DevOps would save BIG)
* Niche infra needs that PaaS doesn't cater to

always tired

@ryantownsend I'm too old to know what "PaaS" is. And yes it was a specific need anyway and I guess your "PaaS" didn't even exist back then?

Ryan Townsend

@project1enigma possibly not: Heroku launched in 2007, they were one of the first.

PaaS is basically somewhere you can push your code (can literally be a `git push`) and they manage things like configuring necessary OS dependencies, OS patching, rolling restarts, auto-scaling etc for you – no DevOps engineers needed.

Examples: Heroku, Render, Vercel, Netlify, AWS Amplify.

always tired

@ryantownsend Code as in, within some certain framework?

Ryan Townsend

@project1enigma it depends on the platform...

Heroku, for example, natively supports: Node.js, Ruby, Java, PHP, Python, Go, Scala, Closure.

With open-source buildpacks for frameworks within each language (e.g. Express.js, Ruby on Rails, Laravel)

Worth watching the 60 second video demonstration here to give you an idea of how simple it can be: https://www.heroku.com/php

Ryan Townsend

@project1enigma literally 60 seconds to deploy something and get a full CI/CD pipeline with staging environments, promotion to production, instant rollbacks (all via a button), monitoring, log streaming, managed databases/SSL, auto-scaling.

No need to configure web servers, load balancing, OS security, containerisation.

It's more costly than something like EC2 when looking at purely infra, but when you factor in salaries, wasted time, risk, it's far cheaper (except at huge scale).

Mia ‘Meetings? I Abstain’ Luna Tearmoon

@ryantownsend

I have bad news: if you remember doing LANs back in the 1990s, you are probably old.

this made me feel my bones creak (DR-DOS 6, assembler inlining in Ada and Pascal to interact with the Novell NetWare driver through INT 21h)

Ryan Townsend

@mia I don’t understand what this has to do with my Mastodon post?

My suggestion is just for commercial projects to avoid K8s (given they’d need staff to manage it) and use PaaS, unless there’s a very good reason not to (e.g. massive scale or niche infrastructure requirements).