Every web application that may need scale later should be a distributed system
5 comments
Keep your servers stateless so you can distribute traffic between many instances. It's a very easy model to wrap your head around, I think pioneered by a YC startup a very long time ago called Heroku.
All it really means in practice is you wouldn't store things like session state on your web server, server #1 can't hold your information because server #2 or #3 or #85 might receive your next HTTP request. I think dev in general shifted to this model about 15 years ago anyway!
All it really means in practice is you wouldn't store things like session state on your web server, server #1 can't hold your information because server #2 or #3 or #85 might receive your next HTTP request. I think dev in general shifted to this model about 15 years ago anyway!
Even if you’ve already learned distributed system design, it makes things much more complicated, is easier to break and harder to maintain. Getting new developers to the project is harder as most lack the experience working with distributed systems.
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.
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.
[deleted]
Distributed design is not that complicated in small scales. It's not that difficult to write. It's not that difficult to manage when the scale is small. If you think it's much more complicated, then you are not a software engineer, or you are an entry-level developer who just started learning things.
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.
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.
If you genuinely want to become a software entrepreneur for the rest of your life, you just have to pay the price of learning horizontal scalability once and reuse your knowledge for the rest of your life. Thus, my opinion only applies to dedicated software entrepreneurs.
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.
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.
However, learning distribtued system design is not that complicated unless you are an entry-level developer.
I guess people who tell others to not care about scalability for a software startup are probably marketers, hustlers, or financiers who consider product building as someone else's responsibility and are willing to discard failing products and hire developers for a new product. They typically try to fail quickly, discard companies, and start new ones. That's why these types love starting with agency businesses which don't require product development. You can learn a lot from them, but if you are a solo software entrepreneur, product development is your responsibility, and you should learn distributed system design before writing code or starting a business. You wouldn't hire entry-level engineers for your business, would you?
I think it's valuable to learn distributed system design and basic software engineering techniques like unit tests and documentation and functional programming and simplcity-oriented software design(rich hickey's simple made easy).
After you learn basic software engineering and distributed system design, you can reuse these design patterns over and over for the rest of your life and move quickly as a solo software entrepreneur.
It's a one-time cost that pays for the rest of your life. Design is cheap. Fixing a production system that has a fundamentally broken design that can't scale is very expensive. Solo software entrepreneurs should start with a solid distributed system design instead of trying to bolt scalability and solid software engineering practices onto production web applications. Many other online businesses suffered scalability issues so that you don't have to. You don't have to learn from your own mistakes when you can learn from other people's mistakes.
You can be a marketer or a hustler as a solo software entrepreneur once you learn distributed system design and basic software engineering.
Solo software entrepreneurs shouldn't try to copy marketers and financiers who have money to hire quality engineers.
I also recommend not using SaaS frameworks because the cost will snowball if you try to grow. AWS lambda isn't really free of infrastructure management. If you use SaaS, use ones that you can easily migrate away from. You don't want to be locked into specific vendors.