Hacker News new | past | comments | ask | show | jobs | submit login

This article would be much more useful if the author discussed alternatives. As it stands, he's not really telling us anything most serious API developers don't already know. We choose technologies like Amazon SQS because it provides the durability and scalability we need for services to talk to one another. The author fails to say why this is a bad thing, other than to talk about coupling. There is always coupling in such a system, whether it's monolithic or microservice-based; the real discussion is what either choice buys us. Don't mind scaling vertically? Build a monolithic API. Want to scale horizontally? Build microservices.



Honest question: What does “scaling horizontally” and “scaling vertically” mean? I assume that “scaling” means “do more/less work of the same kind in the same amount of time”.


Scaling horizontally is basically "we can add machines to make it go faster" and "scaling vertically" means "getting a faster or more disk/memory/CPU/etc. makes it go faster". In horizontal scaling you're usually talking about adding "commodity" hardware, though that's not actually that true any longer (I believe AWS at least uses customized boards, form factors, etc. to achieve better economy of scale.)


Vertical scaling is where you add more resources to a machine. E.g; more RAM or processing power.

Horizontal scaling is where you add more machines to your pool of resources (servers).

Examples;

Horizontal scaling would be adding more web servers behind the load balancer to facilitate more traffic.

Vertical scaling would be adding more RAM to your database server to keep all the data (or just the indexes if your database is that big) in memory.


The short version: scaling horizontally means getting many more boxes scaling vertically means getting a bigger box (replacing the one you have)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: