10 ms·

A good rule of thumb is that if you’re starting a new project and immediately implement microservices, you’ve already failed. Never seen it work, don’t think I

by Zanfa 3y ago

A good rule of thumb is that if you’re starting a new project and immediately implement microservices, you’ve already failed. Never seen it work, don’t think I ever will. The only way microservices can ever work is if they’re extracted over time as the monolith gets fleshed out, likely over the course of years. And even they’re probably a bad idea.

NohatCoder 3y ago
I think that splitting things can be a good idea once in a while. The important part is that you only make a new service because some job fits being its own service. The microservice syndrome begin once you start splitting services simply because you arbitrarily declare them too large.
- KyeRussell 3y ago
  > because some job fits being its own service Determining this at all takes skill. Determining it that far ahead of time requires so much skill and foresight that suggesting that people try is bad advice.
- ProZsolt 3y ago
  But you can make a "new service" in code in the same binary communicating through memory. You can then separate it to a separate binary, when the network and serialisation overhead worth it. 80% of the time it will never come.
  - selcuka 3y ago
    Microservices are not only "function calls over TCP" though. There are other concerns such as database per service vs a single shared database. There are also security implications that you don't have with a monolity. Designing it that way from the beginning could easily be as complicated as making them separate services.
    - roflyear 3y ago
      I wouldn't call that microservices.
tinco 3y ago
I've never done it myself, but it seems startups are succesfully deploying using for example auth0. Outsourcing auth like that is using microservices right?
- tracker1 3y ago
  Kinda... it's breaking off the domain into a different service (SaaS in this case). I usually separate auth out even for localized authentication, as stronger passphrase hashing is a relatively low bar for DDoS attacks in practice. If hashing a passphrase takes 0.5s of a single core, then it wouldn't take THAT many authentication requests to overload a system... and even then if you use other mitigations, that can have its' own design overhead. So I generally try to design with a separated authentication from the beginning. I'll start with a "dev" auth service that will just have a form you can fill out whatever you want for the "user" and permissions, then sign a token to get into your local/dev environment application. From there it's really easy to create a more robust system or wrappers for external systems (Auth0, Okta, Azure AD, etc). In general, however, MicroServices is about completely separating a given context domain from other services in a larger system. Account Management is separate from Assets, etc. In practice this means you will have a much more complex orchestration, deployment and communications system in place, often with some sort of Distributed RPC, Queue or other layers on top. You also have to be much more concerned with communications between teams and service versioning and availability. This complexity isn't less complex, it just shifts the complexity, which can help with larger organizations, but for smaller teams it can really bottleneck everything. This is why the general concensus is to start with a more monolithic codebase designed to still scale horizontally, then break off systems as the need arizes. The exception being if you are in an organization that has already paid the overhead/debt of setting up for microservice orchestrations.
- roflyear 3y ago
  That's a different thing really. It's like using sendgrid.
tracker1 3y ago
Or... if you're working in an organization that already has a Microservice based infrastructure in place. Otherwise, I generally agree... I'll usually take a monolith approach and break things off in ways that make sense. Usually starting with long running processes that can simply be workers off of queues. Sometimes potential bottlenecks that have higher compute overhead, such as passphrase hashing and comparison which is relatively easy to DDoS, but if broken off only effects new logins and password changes.
- charrondev 3y ago
  Isn’t something paraphrase hashing something that should be heavily rate limited? In order to DoS your typical site through passphrase hashing you would need to be: - have a ton of valid usernames/emails of accounts that need to be checked (because a typical password check will rate limit by account) - send in a massive torrent of traffic from a ton of IP addresses (because a typical password check will be rate limited by IP, even more than typical IP based rate limiting) While this is not impossible if you had those resources it still might be easier to just DoS the site though standard pages/ endpoints by sheer traffic.
  - roflyear 3y ago
    Correct microservices don't magically prevent DDOS attacks. They can actually make things much worse.

by Zanfa 3y ago

NohatCoder 3y ago

I think that splitting things can be a good idea once in a while. The important part is that you only make a new service because some job fits being its own service. The microservice syndrome begin once you start splitting services simply because you arbitrarily declare them too large.

KyeRussell 3y ago
> because some job fits being its own service Determining this at all takes skill. Determining it that far ahead of time requires so much skill and foresight that suggesting that people try is bad advice.
ProZsolt 3y ago
But you can make a "new service" in code in the same binary communicating through memory. You can then separate it to a separate binary, when the network and serialisation overhead worth it. 80% of the time it will never come.
- selcuka 3y ago
  Microservices are not only "function calls over TCP" though. There are other concerns such as database per service vs a single shared database. There are also security implications that you don't have with a monolity. Designing it that way from the beginning could easily be as complicated as making them separate services.
  - roflyear 3y ago
    I wouldn't call that microservices.

tinco 3y ago

I've never done it myself, but it seems startups are succesfully deploying using for example auth0. Outsourcing auth like that is using microservices right?

tracker1 3y ago
Kinda... it's breaking off the domain into a different service (SaaS in this case). I usually separate auth out even for localized authentication, as stronger passphrase hashing is a relatively low bar for DDoS attacks in practice. If hashing a passphrase takes 0.5s of a single core, then it wouldn't take THAT many authentication requests to overload a system... and even then if you use other mitigations, that can have its' own design overhead. So I generally try to design with a separated authentication from the beginning. I'll start with a "dev" auth service that will just have a form you can fill out whatever you want for the "user" and permissions, then sign a token to get into your local/dev environment application. From there it's really easy to create a more robust system or wrappers for external systems (Auth0, Okta, Azure AD, etc). In general, however, MicroServices is about completely separating a given context domain from other services in a larger system. Account Management is separate from Assets, etc. In practice this means you will have a much more complex orchestration, deployment and communications system in place, often with some sort of Distributed RPC, Queue or other layers on top. You also have to be much more concerned with communications between teams and service versioning and availability. This complexity isn't less complex, it just shifts the complexity, which can help with larger organizations, but for smaller teams it can really bottleneck everything. This is why the general concensus is to start with a more monolithic codebase designed to still scale horizontally, then break off systems as the need arizes. The exception being if you are in an organization that has already paid the overhead/debt of setting up for microservice orchestrations.
roflyear 3y ago
That's a different thing really. It's like using sendgrid.

tracker1 3y ago

Or... if you're working in an organization that already has a Microservice based infrastructure in place. Otherwise, I generally agree... I'll usually take a monolith approach and break things off in ways that make sense. Usually starting with long running processes that can simply be workers off of queues. Sometimes potential bottlenecks that have higher compute overhead, such as passphrase hashing and comparison which is relatively easy to DDoS, but if broken off only effects new logins and password changes.

charrondev 3y ago
Isn’t something paraphrase hashing something that should be heavily rate limited? In order to DoS your typical site through passphrase hashing you would need to be: - have a ton of valid usernames/emails of accounts that need to be checked (because a typical password check will rate limit by account) - send in a massive torrent of traffic from a ton of IP addresses (because a typical password check will be rate limited by IP, even more than typical IP based rate limiting) While this is not impossible if you had those resources it still might be easier to just DoS the site though standard pages/ endpoints by sheer traffic.
- roflyear 3y ago
  Correct microservices don't magically prevent DDOS attacks. They can actually make things much worse.