3 ms·

I remain unconvinced that most companies actually need systems 'at scale'. Just get a big relational database and know what parts of your workflow have concurre

I remain unconvinced that most companies actually need systems 'at scale'. Just get a big relational database and know what parts of your workflow have concurrency issues. If you ever actually approach BIGCORP_NAME scale, you'll have more than enough money at that point to rebuild it into something else.

BobbyTables2 2y ago
I’ve always felt the same. Though “scale” seems to mean 10 concurrent users supported by a Kubernetes cluster of 50 systems in order to host a simple web application…
sailingparrot 2y ago
DevOps has never been about scaling. It’s about shipping faster. How do we design systems and processes that allow us to go from idead to production very fast. Everyone needs that.
- latchkey 2y ago
  > DevOps has never been about scaling. How do you support tens of thousands of GPUs in a cluster?
  - sailingparrot 2y ago
    However you want. I’m not saying no one need scale, I’m just saying that’s not what the DevOps movement is about. Just like agile also won’t help you managing your cluster.
  - dijksterhuis 2y ago
    Why do you need thousands of GPUs in a cluster?
    - latchkey 2y ago
      Previously, I ran 150k gpus for mining eth. Now, I am building different clusters for AI.
- chpmrc 2y ago
  I don't mean to generalize but every time I had to deal with a DevOps team shipping velocity was much slower compared to when I was able to handle infrastructure myself through a vendor like Heroku, Vercel or even plain AWS. I find myself agreeing with the part about "scaling", meaning a (good) DevOps team makes it easier to integrate new projects into an existing infrastructure that's built in house. The point where relying on the vendors above becomes more expensive than having a full time DevOps team only happens once you react a certain scale.
  - dijksterhuis 2y ago
    Ops person(s) embedded within the Dev team dealing with/helping with/teaching about that one team's "Ops stuff" --> DevOps --> team gets faster because no Ops team hoops to jump through. A separate DevOps team --> corporate rebrand of the separate Ops team --> no real change, or even slower because more hoops to jump through. DevOps was always about meant to be about breaking down the separate / silo'd teams and combining them together. Ownership and responsibility is with that single team for their code from development through to production. The corporate rebrand of Ops teams is what you're coming up against. It does my nut in and I'm sorry to that you have to deal with it.
akira2501 2y ago
And also get a hot spare for that big relational database. And take good snapshot backups and verify they work and verify you can access them when required. Maybe your internal IT /can/ do all of this, in production, without making you want to cry on a daily basis. We didn't really need the scale. We just didn't want to deal with any of those problems. Often there's a little checkbox you can check that solves one or more of these problems, the cost of checking the box is dependent on the size of the data itself. This is convenient _and_ predictable. We like that.

BobbyTables2 2y ago

I’ve always felt the same. Though “scale” seems to mean 10 concurrent users supported by a Kubernetes cluster of 50 systems in order to host a simple web application…

sailingparrot 2y ago

DevOps has never been about scaling. It’s about shipping faster. How do we design systems and processes that allow us to go from idead to production very fast. Everyone needs that.

latchkey 2y ago
> DevOps has never been about scaling. How do you support tens of thousands of GPUs in a cluster?
- sailingparrot 2y ago
  However you want. I’m not saying no one need scale, I’m just saying that’s not what the DevOps movement is about. Just like agile also won’t help you managing your cluster.
- dijksterhuis 2y ago
  Why do you need thousands of GPUs in a cluster?
  - latchkey 2y ago
    Previously, I ran 150k gpus for mining eth. Now, I am building different clusters for AI.
chpmrc 2y ago
I don't mean to generalize but every time I had to deal with a DevOps team shipping velocity was much slower compared to when I was able to handle infrastructure myself through a vendor like Heroku, Vercel or even plain AWS. I find myself agreeing with the part about "scaling", meaning a (good) DevOps team makes it easier to integrate new projects into an existing infrastructure that's built in house. The point where relying on the vendors above becomes more expensive than having a full time DevOps team only happens once you react a certain scale.
- dijksterhuis 2y ago
  Ops person(s) embedded within the Dev team dealing with/helping with/teaching about that one team's "Ops stuff" --> DevOps --> team gets faster because no Ops team hoops to jump through. A separate DevOps team --> corporate rebrand of the separate Ops team --> no real change, or even slower because more hoops to jump through. DevOps was always about meant to be about breaking down the separate / silo'd teams and combining them together. Ownership and responsibility is with that single team for their code from development through to production. The corporate rebrand of Ops teams is what you're coming up against. It does my nut in and I'm sorry to that you have to deal with it.

akira2501 2y ago

And also get a hot spare for that big relational database. And take good snapshot backups and verify they work and verify you can access them when required. Maybe your internal IT /can/ do all of this, in production, without making you want to cry on a daily basis. We didn't really need the scale. We just didn't want to deal with any of those problems. Often there's a little checkbox you can check that solves one or more of these problems, the cost of checking the box is dependent on the size of the data itself. This is convenient _and_ predictable. We like that.