5 ms·

The big advantage of microservices, imho, isn't that their code is small (though that can be true), it's that their domain is small. If it takes 100,000 lines t

by mabbo 10y ago

The big advantage of microservices, imho, isn't that their code is small (though that can be true), it's that their domain is small. If it takes 100,000 lines to manage your user logins, then do so, but put it behind a simple API that the rest of the company can use. Now you've freed yourself doubly- everyone else can just trust that logins work, and the team focusing on logins can focus on just that one thing.

Retric 10y ago
The problem is if you need 100,000 lines of code for your login you can probably break that up. EX: Employee login vs. contractor login. So, where you might think microservices others may be thinking of your monolithic login service.
- Jtsummers 10y ago
  Perhaps the focus should be on how people interact with the services. If everyone interacts with the login service through the same interfaces, then they don't need to know how it breaks out internally or care. If, however, you use it through one set of API features, and I use it through another very disconnected set, then perhaps it's time to break it down further. At the end of the day, though, what does it contain? A list of users, their roles, and access control mechanisms. Does it make sense to have unified logins or multiple sets of logins across your company's services? If the latter, break it down to be run once per other application with specialised selection of features per application. If the former, let the login team handle control of the system and leave it a 100k monolith or break it down as they see fit.
awj 10y ago
If it takes 100k LOC to manage your user logins, I doubt you can really put it behind a "simple" API. You're still going to have intricate details that everyone needs to know, but now you're adding all of the issues of networked communication and (often) allowing teams to use different languages/stacks/etc which prohibit inspection to understand the system they're calling.
- mabbo 10y ago
  So break that logic up into smaller services yet, again splitting up the domain into smaller pieces. No one said a microservice can't call another microservice! Logins are a bad example because it really shouldn't take 100k lines to handle it, but replace 'logins' with any business domain logic that you need. And honestly, the biggest challenge often is building the simplest API possible without limiting your clients.

by mabbo 10y ago

Retric 10y ago

The problem is if you need 100,000 lines of code for your login you can probably break that up. EX: Employee login vs. contractor login. So, where you might think microservices others may be thinking of your monolithic login service.

Jtsummers 10y ago
Perhaps the focus should be on how people interact with the services. If everyone interacts with the login service through the same interfaces, then they don't need to know how it breaks out internally or care. If, however, you use it through one set of API features, and I use it through another very disconnected set, then perhaps it's time to break it down further. At the end of the day, though, what does it contain? A list of users, their roles, and access control mechanisms. Does it make sense to have unified logins or multiple sets of logins across your company's services? If the latter, break it down to be run once per other application with specialised selection of features per application. If the former, let the login team handle control of the system and leave it a 100k monolith or break it down as they see fit.

awj 10y ago

If it takes 100k LOC to manage your user logins, I doubt you can really put it behind a "simple" API. You're still going to have intricate details that everyone needs to know, but now you're adding all of the issues of networked communication and (often) allowing teams to use different languages/stacks/etc which prohibit inspection to understand the system they're calling.

mabbo 10y ago
So break that logic up into smaller services yet, again splitting up the domain into smaller pieces. No one said a microservice can't call another microservice! Logins are a bad example because it really shouldn't take 100k lines to handle it, but replace 'logins' with any business domain logic that you need. And honestly, the biggest challenge often is building the simplest API possible without limiting your clients.