Ask HN: Resources to learn boring architecture for a small startup?
10 comments
I glanced at the two links you shared and I wouldn't call those architectures boring, in fact they're quite involved. "I personally can't even answer with confidence what a single reasonably fat server can handle" - this is too ambiguous of a question anyway, since it depends on the workload. HN still runs on a single server, for instance.
The good news is you should stop worrying about this stuff, and just build. You'll eventually run into bottlenecks and can address them then. That's how best learning happens anyways. Premature optimization is fun and intellectually stimulating, but rarely gets you closer to delivering value.
My rules of thumb for starting out:
The good news is you should stop worrying about this stuff, and just build. You'll eventually run into bottlenecks and can address them then. That's how best learning happens anyways. Premature optimization is fun and intellectually stimulating, but rarely gets you closer to delivering value.
My rules of thumb for starting out:
- Start with a monolith (microservices are great for certain problems, but it's very unlikely you'll have those problems in the beginning, and they add quite a bit of complexity)
- Use a relational DB (same caveats as above for NoSQL, RDBMS can handle search well enough early on as well)
- Use managed services as much as possible (cloud > managing your own hardware, RDS > managing your Postgres instance, etc). They typically have sensible defaults, provide greater security/scalability/availability, and let you focus on the product.
- The fewer independent moving parts in your architecture and infrastructure, the better. Let the complexity add over time, as needed.> this is too ambiguous of a question anyway, since it depends on the workload
yep, how much data is queried and how are queries written, I'd guess it's good to strech your muscles on tiny instances so you get a feel how different queries can consume available resources.
yep, how much data is queried and how are queries written, I'd guess it's good to strech your muscles on tiny instances so you get a feel how different queries can consume available resources.
Laravel can let you start very small and still get you very far. You can easily start with a single server running both the app and the db, and then add specialized servers for higher performance cache and queues later on by simply changing the configuration.
I think you can learn a basic LAMP/LEMP stack in a few hours or days. You can spin one up on bare metal or a VM using XAMPP or similar, then connect it to various other layers like a DNS provider, Varnish or redis, a commercial CDN, etc. That shows you the basic functionality of each part of the system and how they connect, without the overlying complexity of containers and such.
You can replace each part of it as you need to (like using postgres instead of MySQL or Ruby or Python instead of PHP).
This definitely can't hyperscale, but it's how small and medium websites all used to be made. Good way to learn by doing if that works for you.
You can replace each part of it as you need to (like using postgres instead of MySQL or Ruby or Python instead of PHP).
This definitely can't hyperscale, but it's how small and medium websites all used to be made. Good way to learn by doing if that works for you.
> like using postgres instead of MySQL or Ruby or Python instead of PHP
I guess it's great advice for newcommers who have enough time at hand, but would it not be better to pick one stack and stick to it?
I guess it's great advice for newcommers who have enough time at hand, but would it not be better to pick one stack and stick to it?
Oh definitely! I just meant that they don't have to use PHP or MySQL of they felt those were too old fashioned or whatever.
I strongly recommend this overview of what "software architecture" actually includes by Kevlin Henney.
It's long, but extremely useful. It is full of wisdom.
https://youtu.be/aCK-Pu80EEs?si=e7a6ssIaNJy2VTfk
It's long, but extremely useful. It is full of wisdom.
https://youtu.be/aCK-Pu80EEs?si=e7a6ssIaNJy2VTfk
Simplicity is ... hard, so hard that the whole industry favor make things complicated for the job security reason.
Give me your interpretation of what does "microservice" mean, then i could give you more clear context.
Give me your interpretation of what does "microservice" mean, then i could give you more clear context.
[deleted]
https://www.listennotes.com/blog/the-boring-technology-behind-a-one-person-23/
https://anthonynsimon.com/blog/one-man-saas-architecture/
There are a lot of resources on distributed systems and interview preparation where the focus is on FAANG scale, distributed setups, exobytes of data, which is cool if you are working on such a project but most likely you are not. I am not, for example.
I really admire these articles because their authors have such a great understanding of many different aspects of development.
While reading them, I noted to myself that I personally can't even answer with confidence what a single reasonably fat server can handle with just a web server and Postgres.
I have also always worked with managed DBs because it so happened that the companies I worked for are active cloud users.
Even worse, even at mid sized companies, a lot of complexities like load balancing and DNS are handled by dedicated teams and you just have to read the documentation and hope that K8s managed by the admin team does everything for you.
It really makes me feel incompetent to realize that what the authors of these posts implemented on their own, is not something I could do.
On the bright side, I really think I'd like to fill the gaps.
Maybe, there are some resources that build things up incrementally with a focus on simplicity but at the same time do not take anything for granted?
I have read Designing Data Intensive Applications, it's my favorite book but, honestly speaking, even the title says that it's about large scale.