3 ms·

500 services? Any choice of language? I can only imagine how much logic repeated amongst these services because "fuckit, I need this module over here and ther

by aantix 11y ago

500 services? Any choice of language? I can only imagine how much logic repeated amongst these services because "fuckit, I need this module over here and there's no great way to share it amongst all of these languages/services, so let's just copy/paste". This sounds more like the wild wild west of coding and less of an architecture.

eikenberry 11y ago
It could be modeled after the most largest, most successful system ever built. Standard protocols and APIs trump standard language/libraries every time. In my experiences, standard language/libraries always lead to complex, tightly coupled, and fragile systems. It'd probably be better to require that any one language can't make up more than say.. a third of your system, so as to avoid accidentally falling into a bad architecture.
- morgante 11y ago
  > It could be modeled after the most largest, most successful system ever built. What system would that be? (The internet?)
- aikah 11y ago
  > Standard protocols and APIs trump standard language/libraries every time. These 2 things are completely orthogonal. You can have 2 services that are totally unrelated(by definition) yet use the same libraries for these different tasks. > standard language/libraries always lead to complex, tightly coupled, and fragile systems. Don't blame "standard libraries" when you should blame developers. Do you think developers that write these fragile systems will magically write better systems with all your apis and protocols ? do you think they will magically get the proper discipline ? no they won't. They'll write bad apis and bad services, which will be even harder to refactor. I don't understand this need for "uber" complexity (no pun). It's obvious that the more languages used the more complex an architecture is. Same with micro-services which are just about shifting cost from dev to ops. I guess it will take an entire new generation of developers to understand that, the one that will have to maintain all that mess...
  - eikenberry 11y ago
    > These 2 things are completely orthogonal. Of course they are, yet I see people mix them up all the time and standardize on language/libraries when they mean to standardize on protocols and (having) APIs. > ... just about shifting cost from dev to ops. Yes. Dev is people, Ops is process. So by shifting the cost to Ops you are shifting it to something you can automate away.
outworlder 11y ago
The fact that they CAN technically use any language, doesn't mean the new hire is going to start implementing a new service in brainfuck on day one. In addition, if they are services, and you need some logic that's implemented in another service, why don't you, like, call it, instead of copy/paste? It's what services are for.
- eikenberry 11y ago
  +1. Services, not libraries. Standard libraries turn micro-services into components.
- aantix 11y ago
  So now I incur network latency for a method call that I could have made locally?

by aantix 11y ago

eikenberry 11y ago

It could be modeled after the most largest, most successful system ever built. Standard protocols and APIs trump standard language/libraries every time. In my experiences, standard language/libraries always lead to complex, tightly coupled, and fragile systems. It'd probably be better to require that any one language can't make up more than say.. a third of your system, so as to avoid accidentally falling into a bad architecture.

morgante 11y ago
> It could be modeled after the most largest, most successful system ever built. What system would that be? (The internet?)
aikah 11y ago
> Standard protocols and APIs trump standard language/libraries every time. These 2 things are completely orthogonal. You can have 2 services that are totally unrelated(by definition) yet use the same libraries for these different tasks. > standard language/libraries always lead to complex, tightly coupled, and fragile systems. Don't blame "standard libraries" when you should blame developers. Do you think developers that write these fragile systems will magically write better systems with all your apis and protocols ? do you think they will magically get the proper discipline ? no they won't. They'll write bad apis and bad services, which will be even harder to refactor. I don't understand this need for "uber" complexity (no pun). It's obvious that the more languages used the more complex an architecture is. Same with micro-services which are just about shifting cost from dev to ops. I guess it will take an entire new generation of developers to understand that, the one that will have to maintain all that mess...
- eikenberry 11y ago
  > These 2 things are completely orthogonal. Of course they are, yet I see people mix them up all the time and standardize on language/libraries when they mean to standardize on protocols and (having) APIs. > ... just about shifting cost from dev to ops. Yes. Dev is people, Ops is process. So by shifting the cost to Ops you are shifting it to something you can automate away.

outworlder 11y ago

The fact that they CAN technically use any language, doesn't mean the new hire is going to start implementing a new service in brainfuck on day one. In addition, if they are services, and you need some logic that's implemented in another service, why don't you, like, call it, instead of copy/paste? It's what services are for.

eikenberry 11y ago
+1. Services, not libraries. Standard libraries turn micro-services into components.
aantix 11y ago
So now I incur network latency for a method call that I could have made locally?