more developers need to hear this

Ryan Townsend

I can count on one hand the number of my clients over the past couple of years who haven't either over-architected for scale or were unnecessarily concerned about it (prior to coming to me for strategic advice, of course ).

You don't need to understand Distributional Little's Law to figure this out, it's obvious with primary school level math.

(screenshot excerpt from https://tailscale.com/blog/new-internet)

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.

Allan Chow

@ryantownsend a lot of engineers suffer from focusing on executing a solution, rather than solving a problem. With that said, going to click the link and read!

Allan Chow

@ryantownsend mm. I do agree with where they're getting at and it will be really cool to see if they unlock startups to self host again. The great MailChimp server migration story being something similar.

I don't think that's the cause for the insane complexity of "just launch a service" comes from though.

Ryan Townsend

@grumpasaurus fwiw, I see Kubernetes as basically self-hosting, yes it might be atop IaaS but your own team is responsible for uptime, security patching etc.

Most businesses should be outsourcing to a PaaS like Heroku, Render etc.

For 99%+ of use-cases, until your bill hits six figures monthly, it just doesn't make sense to hire DevOps/Infra people.

Allan Chow

@ryantownsend I think it just depends on your situation, use cases, and constraints that a vendor may have on your needs. Of course the most paramount situation being the type of people you have on hand and the budget you have to hire what function you're lacking.

Ryan Townsend

@grumpasaurus absolutely, context is always important, hence my use of "most businesses" and "99%+"

Ultimately: most applications just aren't special. Many are barely more than simple CRUD.

It's not uncommon that the people on hand are the problem... they are the ones driving the infrastructure complexity in order to keep their jobs and pad their CVs. It can mean swapping them out for more productive people who focus on shipping.

Allan Chow

@ryantownsend I'd like to think that people aren't necessarily being malicious to keep their jobs, but moreso maybe a bit too immature in understanding the complexity of taking on a new-to-them solution, especially when they haven't had the past experience of operating a similar process.

"Let's adopt this CI/CD pipeline so that my job in troubleshooting it is secure" - said no one

Ryan Townsend

@grumpasaurus not directly, but a DevOps team isn’t going to advocate moving away from Kubernetes/IaaS/bare metal and just using Heroku or Render.

React has seen enormous, continuous adoption despite very apparently flaws because “that’s where the employment/money is” (I’ve researched this before for my conference talks, it was the #1 voted answer on Reddit for why people use it)

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)