Comments by "TheEvertw" (@TheEvertw) on "The Thing No One Tells You About Microservices" video.

@stephendgreen1502 Dude, what have you been smoking? I want some. OF COURSE there are over-arching designs, the various teams do not work in TOTAL isolation. They are guided by the overall design for the API's of the services, and by the requirements for the overall system. The users (consumers) of the various API's are stakeholders in the design, development & testing of each service, as is the Principal who is paying for the system, and the users he wants to sell the system to. That initial over-arching design of the API's is what the video was talking about when he said some things require more thought up-front than with monolithical systems. You don't have to get them perfect, but you do need have something to start with before you can delegate work to the teams. And during the project, each team needs to frequently present their service to the other teams (its users) to determine whether it is fit for purpose or needs improvement. The other teams do have the right to tell a team that they have made a mistake and need to change things. And each team has the responsibility to support each version of the API for as long as it is used by the others. They can't just go a different direction and break the system.
3
As the man said, it takes some thought up front to figure these things out. You could let the login service distribute tokens that can be attached to API requests, and verified by each service independent from the login service itself. For example bits of information signed with a private key that contain stuff like the user ID, time of authentication, time of revocation, authorization info, some random salt etc. that each service could decode with a public key and use for their own purposes without needing to bother the login service. The only point of contact between the various services is the public key that needs to be shared from the login service to the other services, and a description of the fields in the token and their meaning. If new functionality is needed, hopefully it can simply be added by adding new fields to the token. Breaking changes are more complex, requiring the token to contain a version number and/or each service specifying which version of token it expects.
1
@stephendgreen1502 Micro-service use some method / infrastructure of communication. That can be a queuing system, but not necessarily. Something like ZeroMQ, DDS, REST API or smoke signals works as well. A system can not be a system without some sort of communication between the parts. Micro-services minimize bottlenecks and coupling. A shared database is both a bottleneck and coupling, and you can do without it by duplicating (some) information. Communication infrastructure introduces coupling and a bottleneck that you can't do without. That is the difference.
1
@stephendgreen1502 Then Micro-services are not for you.
1
@stephendgreen1502 You seemed to ask a question in good faith, so in good faith you were answered. However, when you revert to trolling and absurd arguments then you are beyond help. Which is why I said that micro-services are not for you. They require an open mind willing to challenge presumptions like "needing" a database.
1
@stephendgreen1502 You kick the tires in a way that is not conducive to finding wisdom, but rather antagonize people whose ideas you might benefit from.
1