Comments by "Mikko Rantalainen" (@MikkoRantalainen) on "The Problem With Microservices" video.

I think having any design that is inmutable and cannot adapt to customer demands should be a definite no-go for any serious software project. Instead, having stable APIs means that once you create an API, you have to keep it running. To add new features, you introduce new APIs without breaking the old API. Some of the old APIs may be implemented as wrappers for the new API but the consumers of the microservice API don't need to mind about that.
3
@НиколайТарбаев-к1к I'd argue that if you continously modify the API in a way that requires consumers to be modified, too, you don't actually have an API at all. You just have fully custom protocol instead.
2
I mostly agree with this video. However, the biggest problem I see with microservices is that they very often increase the latency of the system because often the end user API sees bigger requests that some sort of gateway service splits to multiple backend microservices and the get extra latency for each hop in the sequence. In addition, some kind of access checking is needed in nearly every microservice so many microservices end up querying access from one central access checking microservice. And if you do that with zero trust design, many of those microservices are running on different physical computers and you have to pay for the encrypted network connection for every hop in the whole system. If there's a generic overall microsystem design that can avoid this latency (and encryption overhead in zero trust design), I've yet to see one. Sure, if you have a design where access is checked only once in the gateway and none of the actual microservices contain any security or access limits, then it gets much easier to implement. However, I think that the security of the whole system would be worse than monolithic design in that case.
2
@ContinuousDelivery I think the microservices makes this problem bigger because by definition each service in the whole system should be smaller – hence there will be more interconnects between the services. How do you think access checks should be usually implemented in system based on microservices? Should each microservice implement it's own access checks or use one "access validation" microservice? As an architechture it seems that having a single microservice for access checking would be the obvious way to proceed but in my experience, safe code requires a lot of access checking in actual logic and that would cause lots of traffic to access checking microservice which would cause extra latency. Of course, one solution is to decide that you don't have any fine grained access settings anywhere. That doesn't seem like very agile to me, though.
1
@ContinuousDelivery If you trust access-checks firewall-style, is the remaining system microservice based anymore? The microservices definitely cannot safely work independently anymore with a design like that.
1