3 ms·

So you saved just $20k per year? Not sure the context of your company but I’m not sure if this turns out to be a net win given the cost of engineering resources

So you saved just $20k per year? Not sure the context of your company but I’m not sure if this turns out to be a net win given the cost of engineering resources to produce this infra gain

TZubiri 2y ago
If it's only for cost savings it's a hard sell. But generally rolling your own has other benefits.
- vood 2y ago
  Rolling your own generally has mainly downsides in the context they are in. 1. This is clearly a small team with very little spend 2. Tomorrow someone leaves and next engineer will have to manage all of this. 3. I don't think they realize that they actually increased cost of this service not decreased it. Now they need to manage their own Kafka monthly. Engineering time is expensive.
  - TZubiri 2y ago
    Yes, rolling your own X has downsides and it has upsides. Welcome to tradeoff engineering.
- crazygringo 2y ago
  > But generally rolling your own has other benefits. Not for startups it doesn't. The only rolling-your-own they should be doing is their main product. Once you get bigger with many hundreds of employees, and existing software starts becoming a measurable blocker, then you can gradually build your own stuff once the tradeoffs actually make sense. But it generally takes a while for that to become the case. For startups, premature optimization isn't the root of all evil, but it's the root of a lot of it.
  - TZubiri 2y ago
    You might argue that it is never worth it to roll anything on your own (which is already an extreme proposition), but to argue that it has no benefits (other than cost?), I think it's either bad reading comprehension or overzeal to jump into the keyboard and type dogma that you should never roll your own and that you should download 1000 dependencies and a dependency manager to manage all those version conflicts.
    - crazygringo 2y ago
      It's not being overzealous. If you're a startup and you need something and it already exists, why would you write your own instead? Even if it's clunky, it saves you time. And for startups, speed and runway is everything. Rolling your own is not a luxury you have. Especially when you consider how much of the startup experience is changing requirements, pivoting, throwing out code, etc. And I've never seen 1,000 dependencies in my life. Sure maybe you have 50. That's entirely manageable. Think how much time you'd lose writing and testing all that stuff yourself...
      - TZubiri 2y ago
        > I've never seen 1,000 dependencies in my life. Sure maybe you have 50. That's entirely manageable. 50 immediate dependencies add up to much more than 1000 total dependencies. If you install a linux OS you are already at 1k. Check your packages
        crazygringo 2y ago
        So... you're suggesting startups should roll their own operating system before building their product? Because I don't see any other way of interpreting your comment.
        TheNewsIsHere 2y ago
        That was surely an example to illustrate how easily you can end up with 1,000 dependencies. Actual numbers vary of course, but the point that I got was about how dependencies spiral. They do. Especially for web based applications built on frameworks and libraries that make it easy to pull in dependencies through package management. I used to work for a company that wrote a stack in Go with a TypeScript front end. When you compiled the whole thing there were easily 900 dependencies resolved, and 885 of those weren’t written internally. An OS and its package manager are no different, but are a more accessible and less specific example to cite.
nijave 2y ago
It can sometimes make sense. If you're trying to optimize cost per customer, for instance. The usual assumption is you want financials to look more attractive to raise funds or you expect to scale customer count and want to keep costs flat-ish

So you saved just $20k per year? Not sure the context of your company but I’m not sure if this turns out to be a net win given the cost of engineering resources to produce this infra gain

TZubiri 2y ago

If it's only for cost savings it's a hard sell. But generally rolling your own has other benefits.

vood 2y ago
Rolling your own generally has mainly downsides in the context they are in. 1. This is clearly a small team with very little spend 2. Tomorrow someone leaves and next engineer will have to manage all of this. 3. I don't think they realize that they actually increased cost of this service not decreased it. Now they need to manage their own Kafka monthly. Engineering time is expensive.
- TZubiri 2y ago
  Yes, rolling your own X has downsides and it has upsides. Welcome to tradeoff engineering.
crazygringo 2y ago
> But generally rolling your own has other benefits. Not for startups it doesn't. The only rolling-your-own they should be doing is their main product. Once you get bigger with many hundreds of employees, and existing software starts becoming a measurable blocker, then you can gradually build your own stuff once the tradeoffs actually make sense. But it generally takes a while for that to become the case. For startups, premature optimization isn't the root of all evil, but it's the root of a lot of it.
- TZubiri 2y ago
  You might argue that it is never worth it to roll anything on your own (which is already an extreme proposition), but to argue that it has no benefits (other than cost?), I think it's either bad reading comprehension or overzeal to jump into the keyboard and type dogma that you should never roll your own and that you should download 1000 dependencies and a dependency manager to manage all those version conflicts.
  - crazygringo 2y ago
    It's not being overzealous. If you're a startup and you need something and it already exists, why would you write your own instead? Even if it's clunky, it saves you time. And for startups, speed and runway is everything. Rolling your own is not a luxury you have. Especially when you consider how much of the startup experience is changing requirements, pivoting, throwing out code, etc. And I've never seen 1,000 dependencies in my life. Sure maybe you have 50. That's entirely manageable. Think how much time you'd lose writing and testing all that stuff yourself...
    - TZubiri 2y ago
      > I've never seen 1,000 dependencies in my life. Sure maybe you have 50. That's entirely manageable. 50 immediate dependencies add up to much more than 1000 total dependencies. If you install a linux OS you are already at 1k. Check your packages
      - crazygringo 2y ago
        So... you're suggesting startups should roll their own operating system before building their product? Because I don't see any other way of interpreting your comment.
        TheNewsIsHere 2y ago
        That was surely an example to illustrate how easily you can end up with 1,000 dependencies. Actual numbers vary of course, but the point that I got was about how dependencies spiral. They do. Especially for web based applications built on frameworks and libraries that make it easy to pull in dependencies through package management. I used to work for a company that wrote a stack in Go with a TypeScript front end. When you compiled the whole thing there were easily 900 dependencies resolved, and 885 of those weren’t written internally. An OS and its package manager are no different, but are a more accessible and less specific example to cite.

nijave 2y ago

It can sometimes make sense. If you're trying to optimize cost per customer, for instance. The usual assumption is you want financials to look more attractive to raise funds or you expect to scale customer count and want to keep costs flat-ish