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

Asked

Viewed 138 times

6

Structuring a layered web application is used only in monolithic applications or also in microservices?

  • Presentation layer
  • Application layer
  • Business Logic layer
  • Data access layer
web-application software-architecture microservices

  • Also in micro-services.

  • @Jeffersonquesado each service implements the four layers or each service is one layer?

  • That’s not how you think about micro-service. In one of the micro-service architectures I know, home service is responsible for a logic/resource. So I can have a customer service more back to the access layer, and an order service that, in turn, is more in the business layer. Particularly me I don’t know the application layer. And the presentation layer is another conversation, usually monolithic. But it has at least 1 JS framework that allows micro-architecting the presentation.

  • Interesting reading (in SE.SE): https://softwareengineering.stackexchange.com/questions/361272/does-layered-architecture-still-to-be-implemented-inside-all-other-architecture

1 answer

5


I’m not an expert in microservices, at best I like to indicate how microservices 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, absurdly high scale need, or where the microservice fits naturally.

But I understand that microservices are a travesty of architecture technique to manage complexity. If it really does this, why use another technique to manage complexity, which is the case of layered separation? Not that I can not, but it seems to me that it is a case of the person nor understand why it is adopted these techniques.

If actually the service is micro it is so simple that the separation in layers becomes less or totally unnecessary. The adoption of 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 very small. If that doesn’t happen, you’re probably not doing exactly microservice. The same goes for object orientation that was created to manage large applications and not small.

Note that in part the layer can already be a micro or at least a mediosservice. 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 assembled).

I already say that the use of MVC in most cases is a cannon to kill bird. In many cases it is the adoption of layers just 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 tells you what you can and cannot do in microservices. I see many people using equal layers do in the monolithic, I see even more people adopting microservices without needing, without understanding the problems they bring, without realizing that in most cases will end up creating a platform of something that was already ready if adopted the monolith, ie trying to "simplify" greatly complicates what was doing.

And I’ve seen people doubling their efforts to be able to do microservices. Then I saw at least one case where they would probably realize the problem with less than 100 programmers and went to more than 1000 after adopting the microservice. But they think they’re doing it right, and mostly they’re in fashion.

And when I talk about scale I’m talking about a lot of scale, remember that you are now on one of the 50 most accessed sites in the world and they reject microservice, and that’s why they’re so good. Just for a comparison, the example quoted in the previous paragraph doesn’t even come close to all this traffic, but it has thousands of servers, while this site here can run on just one server if you want (does not do it to give more reliability, especially in moments of DDOS attack).

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

Then you should ask yourself why you are going to adopt microservice. And why you are going to adopt layer. If you cannot justify these choices and clearly demonstrate that there will be advantages, simply do not adopt them. Don’t do it 'cause everybody’s doing it.

Tomada com gambiarras para encaixar o plugue de energia em vez de colocar o pino diretamente

  • In a case that is not so complex what could be used in place of MVC?

  • In C# Microsoft recommends https://docs.microsoft.com/en-us/aspnet/core/razor-pages/? view=aspnetcore-2.2&tabs=visual-studio.

  • Know some for Java?

  • No, Java always tends to do things the hard way :D But you can always do them in a simpler way without using these framewoks crazy people. Actually the problem is not finding something ready that is simpler, it is understanding the problem and knowing what the solution is. Exchanging one cake recipe for another might even help, but it’s not the final solution yet. Interestingly PHP programmers did simple things very well, then one day they invented that it was too simple and began to complicate :D Take the old way of doing PHP, this is the way to most cases.

  • That’s why PHP is called the nephew language, right? Because of its simplicity :)

  • Interestingly, it got a lot worse when they started making it more complicated. In fact it is so "nephew" that people do not even know more than the way it is done in it today is not simpler. The simple way practically died (of course, you can still do it, but you don’t even find examples, you have to figure it out, you have to start learning programming before learning the language to get to that point. Today most only learn the language, only cake recipe, do not understand what is real programming.

Show 1 more comment

Browser other questions tagged web-application software-architecture microservices

You are not signed in. Login or sign up in order to post.