[jmarchello]

You should start with a single monolithic application on a single server that you scale vertically as much as possible before even thinking of scaling horizontally. Most apps won’t ever need architecture more complex than this.

[necovek]

One thing to remember is that SOA solves two problems: one of organizational scalability, and another of product scalability (with the usual caveat of "if done well").

Monoliths and traditional databases can take a beating before you need something else. It's trickier for rapid growth organizations where you are trying to take on many new members, but there are other solutions there too.

I'd also note that traditional web monoliths really have multiple services too (usually a reverse proxy + CDN, web application, and a data store). There is plenty of business logic on each of these layers too (this also explains the traditional split between Ops, Dev and DBAs), and this actually allows the setup to scale big.

[jmarchello]

> organizational scalability

I’m also of the opinion that most engineering/product orgs are extremely bloated and could move much faster with higher quality if they were cut 50-90%.

[mattbillenstein]

I like this - have started to think more this way, but I'd almost always deploy three boxes instead of one. I like the flexibility of having something that can auto-failover should an az or instance die or disk die.

That being said, I've seen VMs with multiple years of uptime on various clouds, so ymmv.

[jmarchello]

Yeah redundancy and HA are good practices. My point in spirit is more that we usually don’t need 90% of the complexity.