Is it appropriate to use layers in an application using microservices?

I'm not a micro-service expert, but I like to point out how microsoft services are not useful in the vast majority of cases, and it only adds complexity without giving real gains, except in cases of extreme domain complexity, need for absurdly high scale, and where the micro-service fits naturally.

But I understand that micro-services is a technique transvestite architecture to manage complexity. If it really does this, why use another technique to manage complexity, what is the case of layering? Not that it can not, but it seems to me that it is a case of the person or to understand why these techniques are adopted.

If the service is really micro it is so simple that layering becomes less necessary or totally unnecessary. The adoption of the microservice should be accompanied by a new way of programming, thinking that you have small jobs , as it was in the past in mainframes and the codes were too small to create need to manage complexity. If this does not happen it is probably not doing exactly microservice. The same goes for object orientation that was created to handle large and not small applications.

Note that in part the layer can already be a micro or at least a media service. The presentation itself is usually on the client and not on the server, so it is already a service, in a certain way (of course it depends on how it was set up).

I already say that using MVC in most cases is a cannon to kill bird. In many cases it is the adoption of layers only to duplicate efforts without a clear gain. But it makes sense in something complex.

Most new technologies and methodologies are created very informally. There is no canonical document that says what you can and can not do in micro-services. I see many people using layers just as they do in the monolithic, I see even more people adopting micro-services without needing, without understanding the problems they bring, without realizing that in most cases it will end up creating a platform for something that was already ready if the monolith, that is, trying to "simplify" complicates immensely what he was doing.

And I've seen people duplicating their efforts to make micro-services. Then I saw at least one case where they would probably handle the problem with less than 100 programmers and went to over 1000 after adopting the microservice. But they think they're doing it right, and they're mostly fashionable.

And when I talk about scale I'm talking about a lot of scale, remember that you are now in one of the 50 most accessed sites in the world and they reject the microservice, and that's exactly why they are so good. Just to give a comparison, the example mentioned in the previous paragraph does not get close to that whole traffic, but they have thousands of servers, this site here can run on only one server if you want (not to give more reliability, especially in times of attack DDOS).

Microservices are built based on features and do not say anything about layers, you can use them if you want. Some people say that each layer should be a service, some call it nanoservice.

So you have to ask yourself why you're going to adopt micro-service. And because it will adopt layer. If you can not justify these choices and clearly demonstrate that there will be advantages, just do not adopt them. Do not do it because everyone is doing it.