I've seen both, but it's hard to say how much of each happens exactly -- I think jumping straight into microservices before you know what the product really is is a symptom of the latter at least.
You can get a long way with a monolithic architecture and a reasonably good database that you don't abuse nowadays (40-vcore servers, hundreds of gigs of RAM, terabytes of fast SSD). And in the face of getting a product out as quick as possible, not making hugely awful decisions in how to store and access your data is key. 10% more time thinking about these problems saves you several orders of magnitude down the line fixing and solving scaling problems.
If you really scale, you're going to rewrite most of it eventually anyway, but having the data stored in a sane manner makes all that easier anyhow.
I'll second this. I have built a lot of ideas and prototypes over the last year or two. I used to spend a lot of time focusing on the architecture design of these things, building in microservices using the latest technology wherever possible. I figured this was the best way to go about it, until the day I realized I was spending 50% of my time trying to set up a distributed microservices environment, 40% of my time fighting with the tools I was trying to use to build my prototype, and 10% of my time actually building my prototype.
This is the biggest problem with trying to scale too early - you take the focus away from your product. The reality is that most businesses will not work out. Instead of focusing on scaling something that may never sell, you should use the tools that allow you to iterate on your product as quickly as possible - where reasonable.
As stated above, if you end up needing to grow the business, all the code will eventually be rewritten. The data, however, will likely be much more expensive to change. Put some time into thinking about your data model, but otherwise focus on building your product.
2 comments
[ 3.0 ms ] story [ 13.5 ms ] threadYou can get a long way with a monolithic architecture and a reasonably good database that you don't abuse nowadays (40-vcore servers, hundreds of gigs of RAM, terabytes of fast SSD). And in the face of getting a product out as quick as possible, not making hugely awful decisions in how to store and access your data is key. 10% more time thinking about these problems saves you several orders of magnitude down the line fixing and solving scaling problems.
If you really scale, you're going to rewrite most of it eventually anyway, but having the data stored in a sane manner makes all that easier anyhow.
This is the biggest problem with trying to scale too early - you take the focus away from your product. The reality is that most businesses will not work out. Instead of focusing on scaling something that may never sell, you should use the tools that allow you to iterate on your product as quickly as possible - where reasonable.
As stated above, if you end up needing to grow the business, all the code will eventually be rewritten. The data, however, will likely be much more expensive to change. Put some time into thinking about your data model, but otherwise focus on building your product.