5 ms·

Do you want a serious answer, or are you just here to insult people? If you edit your comment to remove the insults, I'd be glad to share my thoughts.

mattmanser 3y ago
Look, I've never seen microservices done well. I'm negative about it because people are implementing this architecture in applications that as far as I can tell should never even consider it. Maybe they're just doing it badly. But as far as far as I can tell it's a pretty awful architecture pattern. To implement microservices, one takes what is a service in a normal application, a handful of code files in a normal application. Maybe some model files, a service, validators and a repo file. A slice of an application. One creates a new project file, build files, etc. Maybe a new repo, maybe not. You then wrap that simple service in a bunch of boilerplate plumbing code so it can actually work on its own. So, basically, a ton of extra code, right off the bat. Each time. Then to do it right according to this thread, you duplicate the definition files between your services, multiple times, add JSON schema files that you didn't have to maintain before, and, someone else has mentioned, create an extra library on top of all this so your colleagues can implement it as if it were just a normal method call. Even more code! And that's your microservice. A lot of extra work. Busy work as far as I can see, no benefits. Just to do exactly what it used to do. But, worse still, it has huge drawbacks, including: 1. Very slow "method" calls. Normal method calls are obviously orders of magnitude faster than whatever you're doing. L1 Cache is always going to be massively faster. 2. Poor debugging 3. Complicated devops requirement 4. Hidden complexity in the interaction between services that is impossible to see I just don't get it. Never have. I tried to play along, but I personally think the emperor has no clothes. If a client is going to insist on microservices, so be it, but it's a massive waste of time and money in my opinion.
- mjr00 3y ago
  You're the first person in this thread to mention microservices. The discussion has been around broader service-oriented architecture. Sometimes those services can be quite large, in which case the boilerplate overhead is not nearly as onerous as you describe. I've worked on services that had 200+ engineers on them.
  - mattmanser 3y ago
    That's what the article is about. That's what this thread is about when the original poster says "you're doing services wrong". So, no, I'm not the first person to mention them. You just need to read the context of the discussion.
    - SgtBastard 3y ago
      Friend, do you not understand that not all services are Microservices? The article even states Microservices are not suitable for startups - the conversation in this thread has been able service oriented architectures which is a much broader topic.

mattmanser 3y ago

Look, I've never seen microservices done well. I'm negative about it because people are implementing this architecture in applications that as far as I can tell should never even consider it. Maybe they're just doing it badly. But as far as far as I can tell it's a pretty awful architecture pattern. To implement microservices, one takes what is a service in a normal application, a handful of code files in a normal application. Maybe some model files, a service, validators and a repo file. A slice of an application. One creates a new project file, build files, etc. Maybe a new repo, maybe not. You then wrap that simple service in a bunch of boilerplate plumbing code so it can actually work on its own. So, basically, a ton of extra code, right off the bat. Each time. Then to do it right according to this thread, you duplicate the definition files between your services, multiple times, add JSON schema files that you didn't have to maintain before, and, someone else has mentioned, create an extra library on top of all this so your colleagues can implement it as if it were just a normal method call. Even more code! And that's your microservice. A lot of extra work. Busy work as far as I can see, no benefits. Just to do exactly what it used to do. But, worse still, it has huge drawbacks, including: 1. Very slow "method" calls. Normal method calls are obviously orders of magnitude faster than whatever you're doing. L1 Cache is always going to be massively faster. 2. Poor debugging 3. Complicated devops requirement 4. Hidden complexity in the interaction between services that is impossible to see I just don't get it. Never have. I tried to play along, but I personally think the emperor has no clothes. If a client is going to insist on microservices, so be it, but it's a massive waste of time and money in my opinion.

mjr00 3y ago
You're the first person in this thread to mention microservices. The discussion has been around broader service-oriented architecture. Sometimes those services can be quite large, in which case the boilerplate overhead is not nearly as onerous as you describe. I've worked on services that had 200+ engineers on them.
- mattmanser 3y ago
  That's what the article is about. That's what this thread is about when the original poster says "you're doing services wrong". So, no, I'm not the first person to mention them. You just need to read the context of the discussion.
  - SgtBastard 3y ago
    Friend, do you not understand that not all services are Microservices? The article even states Microservices are not suitable for startups - the conversation in this thread has been able service oriented architectures which is a much broader topic.