Is it necessary to divide the system into services for which at least one person is fully responsible?

Question

Software design

I refer more to a service-oriented architecture, where a separate part (allocated according to business sub-goals, and not technologically) is more independent both on the server side and on the client side.
In microservice architecture, there is often an approach in which microservices are spinning on the back in separate processes, but they communicate with the user through one API Gateway and one client application. If you go further, you can come across approaches with the allocation of parts of the client application to microservices (frontend microservices). In fact, the microservice will provide the client and server parts within its boundaries (it becomes unrealistic to break something on the client or API of another microservice).
An idea is brewing: to put responsibility for each service on one person (at least).
In my opinion this has the following advantages:

• in the role of a front-end developer, the developer does not have to take care of the business task that other services solve.
  
• no frequent communication between frontender and backender (since they are the same person)
  
• shifting responsibility to the front-end/back-end is excluded (it's easier to make a minimal API and offer the front-end to convert data on the client as it needs, but this complicates its work and degrades the performance of the application)
  
• you can write code in your own style (especially for the client-side, where you can talk about kebab-case vs. camelCase for style class names)
  

Disadvantages:

• full track skills required
  
• it is difficult to continue supporting the service if the only developer left it (temporarily or permanently), because apart from him, few people have an idea how the service works inside
  

What else can be difficult with this? Any real cases?
All these points are not based on practical experience (rather on the experience of the opposite approach with a monolithic "everything :)"), so I'm interested in learning about real cases in which this approach is applied. It is assumed that the problems with the deployment of a large number of services and their binding are already known and taken for granted :)

Answer 1

Firstly, FullStack for service architecture is a complete ass, sorry. It is necessary to have separate people for the front and back. The problem that you don't know about yet is that people tend to change and in this way you can lose a very significant unit. The backend must have a clear specification and correspond to the logic of the microservice / service (in secret - they only differ in size).
Microservices and their integration appear in the system at different speeds and they are built in completely different ways. Moreover, in this approach, you definitely need someone who designs all this together and separately. Usually the architect

Answer 2

You are right about the shortcomings. Moreover, not only full-stack skills are necessary, but also you will have to invest in the training of developers in order to bring their skills in non-core specializations to the desired level.
The first three pluses you have because of incorrectly set current processes. With the right processes, they will be in the division of labor.
And the fourth alleged plus is a huge minute, there is no place for your own style in corporate development.

Answer 3

Splitting into microservices is not done so that one person is responsible for the microservice (there is OOP for this), but so that the application can easily scale horizontally when individual microservices are launched on different hosts, and possibly even in several instances with a load balancer.

Answer 4

I share my personal experience)
Being a single backend developer in the company, I am also a database architect and design the architecture of the application itself (in my case, this is a REST API, and I had to design the front structure in Angular 6).
So - all this is complete nonsense, one person cannot do everything qualitatively (if he is already in this area for 15+ years)
Now I have the task of designing a system that looks like a microservice architecture, and I have been asking questions here for the second day I’m looking for advice from knowledgeable people, since I haven’t done this before)
Therefore, I speak purely from my own experience - if a business task and loads do not require services (microservices), it’s better not to design it like that.
If you are alone, then you will simply get a lot of responsibilities, this is the automatic deployment of systems, their testing, their administration.
I was lucky to talk with a senior developer, so he said - the longer you have everything on a monolith, the better for you, otherwise you will rake in full later