Why do we need a new term for this? Isn't this just Unix philosophy applied to SaaS? No need to learn about "micro services" when you can learn about Unix/Linux and why it's built the way it is, then apply that knowledge to your SaaS product.
First, a key part of the Unix philosophy is the pipes. Programs do not really communicate without them. The closes thing I have seen in a microservice architecture is some magical bus, which is not easy to implement well, thanks to the fun of distributed systems: We don't spent time wondering if grep is going to get the data twice, or not at all, do we?
A second difference is that, in the unix world, we fully accept the concept of glue. Along with the reusable tools of the world, we have all the code that we know is not going to be reusable, that lets us do the task at hand. Depending on how hard it is, we might use something from bash to Perl. In a microservice architecture, such glue, if created, would be the actual logic of your application! So the moment you start adding glue, then the attention will quickly go to the glue, like the C gets pretty big in MVC.
Now, personally I am no believer in microservices as the panacea. The big advantage of the unix world is the reusable components. In a typical business application, the one we tend to get paid to do, how much code is actually stable enough, and reusable enough, that we really believe that its interface will last us a long time? In my experience, it's very little.
Where I have seen microservice-like architectures pull their weight is in actor systems, as a way to handle massive parallelism. But, just like many NoSQL implementations, they are solving a problem that many people would love to have, and very few people actually do. So we see startups building architectures in semi-exotic languages to handle hundreds of thousands of connections a second, when their actual volume of work could be handled with a boring Java app pointing to a Postgres database.
At least that case kept the same names, I think.