I think you're right, but scales will shift in a surprising way; also, it's possible to refactor to microservices bit by bit (not all at once). (1) Easy scalin

I think you're right, but scales will shift in a surprising way; also, it's possible to refactor to microservices bit by bit (not all at once). (1) Easy scaling allow for worse coding (and therefore quicker developement). For "webscale" you're right, and if you can run it all on a single cheap server, then no need to worry about it - small servers are so cheap, the cost per month is insignificant relative to, say, ramen cost per month. But what if you write your app incredibly inefficiently? Perhaps because you develop it quickly; you're not highly skilled (or not even a "developer"); it's difficult to optimise. It's very slow, seconds per request. That's fine for getting started, but you need to scale it far before it gets to "webscale". You could just upgrade to a better server; but at some point, the costs becomes prohibitive. The key thing about microservices is that they should be cheaper (because vendors can better utilise capacity; and customers only buy what they need, when they need it). (2). You don't have to architect the whole project for microservices from the get go. e.g. If there's a single resource-heavy function, factor it out into a microservice. Your main code becomes super cheap to host; the microservice only uses expensive resources as needed: when and if it runs. === At the moment, microservices are a pain to set up and manage. But with tools, it will become very easy to factor out a module into a microservice. That is, assuming that code is already a separate module - microservices aren't magic pixie dust!