> Problem One: No One Knows What a Microservice Is
They are massively specifically defined as a service designed, developed and deployed by a specific team that manages a domain. If you think you need a different docker image for a GET /images and POST /images/<image>, then you definitely should go back to school.
At a company like Nike a team that manages the product images might own the microservice for /images for downloading different formats, sizes, uploading, etc... Similarly, the /orderstatus microservice might server data on existing orders. This isn't hard.
> Problem One (b): The Lack of Discipline in Software Terminology
This is totally pointless. Each team that owns a microservice (or multiple) is responsible for the entire lifecycle. There is no team that specifically does the production deploy. It is JUST that team that manages from source to production deployment.
> Problem Two: Microservices Conversations Are Abstract and Unrelated from Business Goals
They are absolutely related to business goals. Microservices are much more tied to business means that technological means. They are designed to keep your teams ability to make releases and be agile because they are not touching any code that affects another teams microservice. If you're building a monolith, then if I introduce a memory leak in my image service, I'll eventually crash the entire product. Under microservices, it's more likely that the images microservice will crash (and probably restart in k8s) which may actually be totally transparent to a user. In a monolith, that crash for image optimization may cause a stripe transaction to fail in the payment module. If this doesn't make sense to you, you need to go back to school. That or get more jobs in companies that do microservices. You're definitely one of THOSE people.
> Problem Three: Microservices Without Organizational Change Is Pointless
Microservices are not for everyone. Most large companies, for example Nike, HAS to do microservices because there is no possible way to do a monolith for what they handle. There are already teams for each concept - team sports, orders, b2b, retail. Each of these teams already fits very well into a microservice culture.
If you're working at WalnutDistributionsLLC and you maintain a login page, and an order page for MORE WALNUTS, you probably don't need a microservice architecture.
Just in general, also, if you also an employee (you know a person paid to work with others at the company) and you just outright refuse to talk to specific people about specific topics at the company, you should be fired.
> Problem One: No One Knows What a Microservice Is
They are massively specifically defined as a service designed, developed and deployed by a specific team that manages a domain. If you think you need a different docker image for a GET /images and POST /images/<image>, then you definitely should go back to school.
At a company like Nike a team that manages the product images might own the microservice for /images for downloading different formats, sizes, uploading, etc... Similarly, the /orderstatus microservice might server data on existing orders. This isn't hard.
> Problem One (b): The Lack of Discipline in Software Terminology
This is totally pointless. Each team that owns a microservice (or multiple) is responsible for the entire lifecycle. There is no team that specifically does the production deploy. It is JUST that team that manages from source to production deployment.
> Problem Two: Microservices Conversations Are Abstract and Unrelated from Business Goals
They are absolutely related to business goals. Microservices are much more tied to business means that technological means. They are designed to keep your teams ability to make releases and be agile because they are not touching any code that affects another teams microservice. If you're building a monolith, then if I introduce a memory leak in my image service, I'll eventually crash the entire product. Under microservices, it's more likely that the images microservice will crash (and probably restart in k8s) which may actually be totally transparent to a user. In a monolith, that crash for image optimization may cause a stripe transaction to fail in the payment module. If this doesn't make sense to you, you need to go back to school. That or get more jobs in companies that do microservices. You're definitely one of THOSE people.
> Problem Three: Microservices Without Organizational Change Is Pointless
Microservices are not for everyone. Most large companies, for example Nike, HAS to do microservices because there is no possible way to do a monolith for what they handle. There are already teams for each concept - team sports, orders, b2b, retail. Each of these teams already fits very well into a microservice culture.
If you're working at WalnutDistributionsLLC and you maintain a login page, and an order page for MORE WALNUTS, you probably don't need a microservice architecture.
Just in general, also, if you also an employee (you know a person paid to work with others at the company) and you just outright refuse to talk to specific people about specific topics at the company, you should be fired.