(no title)
stefanfis | 10 months ago
And most of the projects started by small companies will never have the need for scaling. Should they once need scaling, the project is typically so successful they can easily pay for experts to help them.
stefanfis | 10 months ago
And most of the projects started by small companies will never have the need for scaling. Should they once need scaling, the project is typically so successful they can easily pay for experts to help them.
unknown|10 months ago
[deleted]
doojin|10 months ago
It's possible to design a relatively simple distributed system.
If I want to write a web application that can scale later, I would rather start with a small-scale distributed design which can be scaled easily later.
If you actually understand distributed design, you can teach it to those who are willing to learn.
Figma was funded by a huge financier and could afford to spend more than 5 million dollars on horizontal scalability alone. Figma's horizontal scalability design isn't particularly good because it started with vertical scaling. I also wouldn't count on being given more than 100 million dollars in investment.
If you really had a lot of money, you could pay for rewrite of the entire backend, but you will have to stop the service.
I don't like the idea of bolting horizontal scalability on top of a vertically scaled "live" production system on the fly. Figma spent 9 months and millions of dollars on such a live surgery. Even if I had money to pay for that, I prefer not to do that. I'd rather avoid performing a complex surgery on a live system on the fly. Training developers on distributed design from the beginning is cleaner and simpler. My aesthetic sense doesn't allow me to choose a months-long messy live surgery. That's why everything in my life, including my room is clean. The months-long messy live surgery feels like seeing a messy room.
Other companies already pioneered distributed system design so that I don't have to. It's not like I have to spend 10 years on researching a distributed system design before I can write a line of code.
Usually, if you can pay the costs upfront without losing speed, you should do that. I wouldn't pick a business model that forces me to do things at break-neck speed and thus accept a lot of mess. I understand that nothing can be slow in business, but I also don't want to sacrifice neatness to get break-neck speed that allows me to churn so fast I can run a company that loses money for years. I'd sacrifice initial speed to a degree in order to gain speed later. I believe I can maintain neatness and enough speed if I genuinely try hard.
I fully aceept the fact that it's going to be harder to take on more initially, but if I postpone certain concerns, I will have to work harder later. I'd rather work harder now. I don't believe starting with a distributed design is going to hurt my company a lot or kill it. I'm a decent software engineer, and I can retain a person like me without paying too much. I believe any software engineer who is not stupid can learn distributed system design quickly if they are given the right learning materials. I'm not a super genius who can't be replaced.
Usually, you have to deliver at break-neck speed because you have employees without any revenue or a deep financial reserve. If you are starting alone while you do a part-time job or spend your own fund, you still want to be fast, but you don't require breakneck speed in order to pay employees as soon as possible.
doojin|10 months ago
In my experience, horizontal scalability isn't difficult if you are actually a software engineer. Actually, I wouldn't hire any programmer who can't understand horizontal scalability quickly. I'm saying this as someone who's not particularly smart.
You don't have to implement everything in the early stages, but you have to know distributed design and implement some of it so that your software isn't hindered severely later when you actually need to implement more scalability techniques.
Definitely, learn distributed design, and implement it gradually over time. Don't paint yourself into a corner by implementing things that can't be scaled later.
For example, you don't have to deploy a load balancer from the beginning, but make sure your software can work with a load balancer later. That means stateless design. Stateful design can't work with a load balancer.