4 ms·

There may be a rare exception here or there where network effects or some other unique market need require a startup to treat their infrastructure as cattle, bu

There may be a rare exception here or there where network effects or some other unique market need require a startup to treat their infrastructure as cattle, but otherwise it's absolutely true. Running `git init --bare` on a server, setting up some remote origins, slapping some bash scripts into the git hooks folder, some .service files for systemd, and then running `git push origin dbhost && git push origin apihost && git push origin ...` is a hell of a lot simpler than even getting a toy version of kubernetes up and running. For the developer with average linux skills, it's probably even easier than figuring out which cloud orchestration monstrosity to choose. Throw in Github actions and baby, you've got a stew going! Maybe I'm misunderstanding the whole "pets vs cattle" thing but you don't need to lose repeatability or give on process altogether; it's a false dichotomy. Just don't dive headfirst into the massive complexity that is "scalable" devops - you can still use terraform or docker compose or whatever to deploy your application and provide repeatable development/staging/test infrastructure.

throwaway894345 6y ago
> is a hell of a lot simpler than even getting a toy version of kubernetes up and running. Getting it off the ground is one thing, keeping things reproducible so you can stand it back up reliably if the instance goes down is another thing. You need to know what are the relevant changes that people have made to the instance over its lifetime in order to reproduce them on the new machine. Maybe this is not what people mean by "pets vs cattle", but they seem pretty closely related if nothing else. I guess the thing I care about is "reproducibility" and for all of its complexity, Kubernetes makes the happy path pretty clear in this regard whereas with EC2 you need Ansible and a whole bunch of playbooks to reproduce things like SSH, logging, monitoring, process management, etc that Kubernetes or ECS or whatever give you out of the box. And if you find that you need to scale beyond one or two instances (not everything is a CRUD webapp, after all) especially autoscaling, then it seems like the EC2 story becomes even more complicated (you now need something to automatically invoke Ansible with the right playbooks for each node). I'm probably biased by my experience (aren't we all?) but it seems like Kubernetes or ECS/Fargate are simpler in these regards.
- AlchemistCamp 6y ago
  > And if you find that you need to scale beyond one or two instances (not everything is a CRUD webapp, after all) especially autoscaling, then... Have you ever been working a solo project that needed autoscaling? If so what was it doing that was so resource intensive per $ earned that it was still a solo project?
  - throwaway894345 6y ago
    Picture an analytics application--something that has to crunch a bunch of data per request, and your users are mostly visiting from 9-5. Depending on the size of the user's data source, they could easily use a whole CPU and a lot of memory for each request and requests can take up to 60s or maybe even multiple minutes. You need to run more than a handful of machines, so you can either overprovision or autoscale, but in either case you need some amount of reproducibility to wrangle all of those machines and you'll probably want to plan for them to come and go because you probably don't want to pay for a bunch of high-end machines sitting idle every night. Optimization is nontrivial so you'll get around to it eventually and maybe even hire, but hiring your first employee is a lot harder than hiring your 101st employee, so you're not going to do it right now but you still need a solution to your problem...
    - AlchemistCamp 6y ago
      Did you run an app like this? If so, which one? I very nearly launched an event analytics app at the beginning of this year but ended up just rolling one for my own internal use.
      - throwaway894345 6y ago
        I did in a past life. I'd prefer not to say which one because this is an anonymous account and I don't want to make it too easy to associate to my real world identity.
        6y ago

throwaway894345 6y ago

> is a hell of a lot simpler than even getting a toy version of kubernetes up and running. Getting it off the ground is one thing, keeping things reproducible so you can stand it back up reliably if the instance goes down is another thing. You need to know what are the relevant changes that people have made to the instance over its lifetime in order to reproduce them on the new machine. Maybe this is not what people mean by "pets vs cattle", but they seem pretty closely related if nothing else. I guess the thing I care about is "reproducibility" and for all of its complexity, Kubernetes makes the happy path pretty clear in this regard whereas with EC2 you need Ansible and a whole bunch of playbooks to reproduce things like SSH, logging, monitoring, process management, etc that Kubernetes or ECS or whatever give you out of the box. And if you find that you need to scale beyond one or two instances (not everything is a CRUD webapp, after all) especially autoscaling, then it seems like the EC2 story becomes even more complicated (you now need something to automatically invoke Ansible with the right playbooks for each node). I'm probably biased by my experience (aren't we all?) but it seems like Kubernetes or ECS/Fargate are simpler in these regards.

AlchemistCamp 6y ago
> And if you find that you need to scale beyond one or two instances (not everything is a CRUD webapp, after all) especially autoscaling, then... Have you ever been working a solo project that needed autoscaling? If so what was it doing that was so resource intensive per $ earned that it was still a solo project?
- throwaway894345 6y ago
  Picture an analytics application--something that has to crunch a bunch of data per request, and your users are mostly visiting from 9-5. Depending on the size of the user's data source, they could easily use a whole CPU and a lot of memory for each request and requests can take up to 60s or maybe even multiple minutes. You need to run more than a handful of machines, so you can either overprovision or autoscale, but in either case you need some amount of reproducibility to wrangle all of those machines and you'll probably want to plan for them to come and go because you probably don't want to pay for a bunch of high-end machines sitting idle every night. Optimization is nontrivial so you'll get around to it eventually and maybe even hire, but hiring your first employee is a lot harder than hiring your 101st employee, so you're not going to do it right now but you still need a solution to your problem...
  - AlchemistCamp 6y ago
    Did you run an app like this? If so, which one? I very nearly launched an event analytics app at the beginning of this year but ended up just rolling one for my own internal use.
    - throwaway894345 6y ago
      I did in a past life. I'd prefer not to say which one because this is an anonymous account and I don't want to make it too easy to associate to my real world identity.
      - 6y ago