Hacker News new | past | comments | ask | show | jobs | submit login

I've spent a lot of time over the years trying to think up the perfect analogy for software development and I've never quite found one.

It seems like they all tend to break down but cooking is ok for some parts.

To that end I see these conversations as

"never use stainless steel to cook a hamburger"

"never use cast iron on a food truck"

"Always use an crock pot for soup"

Especially for startups it just doesn't matter that much. Use whatever you know how to cook with. If your DevOps guy can deploy kubernetes into AWS managed with GitOps designed by GitHub copilot and ChatGPT in terraform in 40 minutes and manage without waking up in the middle of the night...that's fine.

Or if you have a die hard linux admin who wants to buy servers on eBay and host them in the basement and do hardware updates at 2am...that's also really fine.

Stackoverflow literally uses windows servers.

These are all just different methods of cooking. Sure we each kind of prefer our way and insist it makes the food come out best, and sure there is truth to that at a point - infra does eventually wind up mattering.

But mostly we're just nerds arguing about what brand of chef's knife we use and that sort of thing.




> If your DevOps guy can deploy kubernetes into AWS managed with GitOps designed by GitHub copilot and ChatGPT in terraform in 40 minutes and manage without waking up in the middle of the night...that's fine.

So your bus factor is one ?

I think it's good to have articles like these. I see overzealous intelligent people over engineering things so often.

Just recently I saw a project where silly overgeneralization made development and testing way harder than it needed to be for MVP, it stretched development by a few months, by the time they launched they missed the investment window (last year with market contracting). If they launched garbage code that worked for MVP they would have had enough users and caught the next investment round to fund whatever refactoring they needed.


Bus factor doesn't really matter for a startup. Because literally everything early on is a bus of one, maybe two. Scaling is a good problem to have later on.

To your deeper point being that if you work at a startup to make your own life easier and those who eventually will work with you; write down what you're doing and get good at teaching/explaining process to people.


Fwiw, bus factor seems like an extremely good reason to use Kubernetes.

One can absolutely invite in a lot of complexity, but if you take a reasonably well integrated starting point/KISS (and you absolutely can with Kube), there shouldnt be a ton of additional complexity.

And given how self-describing via manifests-for-everything kubernetes is, someone spinning up who already is sort of familiar with Kubernetes ought be able to get a good picture of what pieces are in play & the shape of how things are setup extremely quickly. Unlike choice-making in most devops, there's still huge commonalities & massive shared base. If you & another startup make totally different choices about how you will Kube, the superstructure will still be the same. Porting people in is way easier.


You always start with 1 in startup


If that 1 is DevOps/employee you are doing things wrong.


Caveat to that, IMO, your DevOps guy needs to make it so it can easily be understood and run by other people in case they get hit by a bus.

The last thing you need is for the new guy to come in and rewrite everything because it only really worked for the previous guy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: