Independent deployment: Rarely needed.
Multiple languages: No shared infrastructure.
A/B testing at deployment for small services: Feature flags.
Less dependency to software specific stack: More dependency to homegrown immature solutions.
Security compartmentalizations: Isolated half-assed solutions with few people responsible.
Strict programming by interface: Not unique to microservices, some people call this "static typing".
Failure isolation: No shared infrastructure, blindsides, definitely not unique to microservices.
Independent deployment: having deployed hundreds of microservices, I can tell you it is a godsend. Quickly iterating on a specific microservice without running risk of down-time is useful right from the start. We would sometimes deploy the same microservice multiple times a day to improve performance or fix a critical bug. Apart from scaling, this is my number one reason to stay with microservices.
Multiple languages: the shared infra in this case is your Kubernetes yaml files and Docker build files, both of which can be shared easily. The rest is either RESTful or Kafka consume/produce. Python/R/Scala/Java/C#/Haskell/OCaml can all interface with that.
Feature flags are a possible solution. I worked with them in the past and, applied correctly, they can offer a similar experience. However, one often needs more than just a boolean filter: you need to have the logic in your application to route the requests to, say, two different implementations of the same interface. Do this on the micro-service scale, and you get a nice SoC at the proxy level. It moves A/B testing to be part of the infra, not the application logic.
More dependency to homegrown immature solutions: care to elaborate?
Isolated half-assed solutions with few people responsible: care to elaborate? My little micro-service component needs the bare minimum of access, which I can precisely provide to it. No memory is shared, no storage is shared... Often it is much easier to prove that the system stays within confidentiality and availability limits. Networking allows me to transparently monitor all data flowing through my services.
Strict programming by interface vs. static typing. Oh yes, I totally agree with static typing! Such a big advantage over dynamic typing, read my other comments on HN. However, there is no static typing across versions of your same software. Forward compatibility is hard to achieve when all components need to be upgraded at the same time. I still dread the days when we would upgrade 'a major version' and all kinds of database tables had to be changed, causing chicken-and-eggs problems. Not saying that this problem is completely eliminated with a micro-service architecture, but it forces developers to think what can be reasonable isolated, causing a higher SoC. It also prevents the humongous unmaintainable 300+ tables large RDBMSs, which are often the primary cause of stagnated development.
Failure isolation: I don't understand your reasoning, sorry.
