Live data from Hacker News

We built a modern data stack from scratch and reduced our bill by 70%

jchandra.com

51–60 of 60 posts

Re: We built a modern data stack from scratch and reduced our bill by 70%

#51
post #34

Earlier quoted context omitted.

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.

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 depen…

> 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

Re: We built a modern data stack from scratch and reduced our bill by 70%

#52

These just seems like over engineered solutions trying to guarantee their job security. When the dataflows are so straight forward, just replicate into pick your OLAP, and transform there.

What is the current state of the art (open source) when doing oltp to olap pipelines in these days? I don’t mean a one-off etl style load at night but a continuous process with relatively low latency?

I would say clickhouse

Re: We built a modern data stack from scratch and reduced our bill by 70%

#53
post #51

Earlier quoted context omitted.

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 depen…

> 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

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.

Re: We built a modern data stack from scratch and reduced our bill by 70%

#54

AKA The Monty Hall Rewrite https://alexsexton.com/blog/2014/11/the-monty-hall-rewrite

This is a great concept and of course implies the very real idea that you should just rewrite a lot of your stuff anyway …

> you should just rewrite a lot of your stuff anyway

Continuously refactoring when adding features, fixing bugs, or dealing with external changes keeps code fresh and free of cruft. Also removing dead code, deprecating and removing little-used features, refining behavior to remove unused edge cases ensures focused and useful systems.

Re: We built a modern data stack from scratch and reduced our bill by 70%

#55
post #51

Earlier quoted context omitted.

> 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

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.

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.

Re: We built a modern data stack from scratch and reduced our bill by 70%

#56
post #34

Earlier quoted context omitted.

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.

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 depen…

Although my company isn’t recognizable as a startup given its age, I can say confidently that the typical advice to avoid rolling your own is not a given.

Many new founders and businesses fail to consider the supporting systems they need outside the code their product or service is comprised of. This can cause a lot of unnecessary re-engineering later.

As we built our company we had to make a number of decisions about whether to build our own or go with a third party. At various points we did both, and for us the DIY approach has continuously been the better option over time. That doesn’t mean we write our own code for everything but it does mean we sometimes do, and it means we don’t just go with whatever is the most convenient. An increasing amount of our IT estate is self-hosted applications rather than SaaS apps, for example.

By way of example, we had started off with a really popular accounting package that everyone uses for everything but which isn’t very customizable (and which doesn’t provide backups). That became untenable after only a few years because we our service demanded a more bespoke approach to linking service and financial data. We knew that going in but we took the same “it’ll do for now” attitude. That ended up creating more pain later. We moved to an ERP platform that we can host (and backup!) and haven’t looked back.

We almost did the same with our infrastructure management. We had evaluated and used a number of proprietary products and services from AWS, Hashicorp, CI/CD, and RMM vendors.

Ultimately we created our own stack on the back of FOSS and custom code which took a lot longer to mature but which has proven to be much better for our needs.

Re: We built a modern data stack from scratch and reduced our bill by 70%

#57

Earlier quoted context omitted.

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 depen…

Although my company isn’t recognizable as a startup given its age, I can say confidently that the typical advice to avoid rolling your own is not a given. Many new founders and businesses fail to consider the supporting systems they need outside the code their product or service is comprised of. This can cause a lot of unnecessary re-engineering later. As we built our company we had to make a number of decisions abou…

There's pros and cons to everything.

One advantage of rolling your own:

-minimalism: no code designed for othere -security: not necessarily more secure, but a different risk profile. You are safe from a lot of spearphishing vulns like log4j, but may be open to custom attacks, I think this is an advantage but ymmv. - system knowledge: you can answer questions about your system, to clients and regulators.

- system flexibility: you understand your system you can modify it as needed. Which is not true if you import 1000 dependencies.

Re: We built a modern data stack from scratch and reduced our bill by 70%

#58
post #51

Earlier quoted context omitted.

> 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

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.

You should work in reading comprehension, try reading what's actually there instead of trying to find a hidden meaning

Re: We built a modern data stack from scratch and reduced our bill by 70%

#60

I know it's easy to be critical, but I'm having trouble seeing the ROI on this. This is a $20k/year savings. Perhaps, I'm not aware of the pricing in the Indian market (where this startup is), but that simply doesn't seem like a good use of time. There's an actual cost of doing these implementations. Both in hard financial dollars (salaries of the people doing the work) and the trade-offs of de prioritizing other oth…

High per-unit costs lock you into certain workflows, and a lot of systems have much higher value at much larger scale.

For example, think of the value generated from a fraud detection system that alerts you on a nightly batch job, vs. a fraud detection system that runs once per minute. If you're spending $20k/y on the batch job, you're never even going to consider the 1/min option. If you can decost sufficiently to run it 1/min, whole new market opportunities open up.

Post reply on HN