5 ms·

> I mean, that sounds pretty good. If you can do that why couple them? Because what is the point in separating each one into their own deployed service and hav

> I mean, that sounds pretty good. If you can do that why couple them? Because what is the point in separating each one into their own deployed service and having to deal with network issues when they could just be services inside a monolith?

jayd16 6y ago
OP just said they don't talk at all. They sound completely decoupled already. You could put them in the same app and share routes if you want and just separate by package or compilation unit if you really want to. The hard part is already done though. They could be managed and deployed by completely different teams with no overhead now. It really depends what we're tuning for.
- neuronic 6y ago
  Scaling is another factor that comes to mind, also resilience. If one part in the monolith goes haywire so will the entire application. If you can decouple and split the software into 4 applications with their own concerns, at least you have 3 applications left running (assuming they are decoupled). If app 1 wants 5000% more CPU than app 2, maybe you can have different instance types running and save costs/resources.
  - systematical 6y ago
    A good reason no doubt and if that comes to bear sure. But at least code in a monorepo and split to microservices in your pipeline. Cake and eat.
- systematical 6y ago
  Read my reply further up, they have a lot in common. We had to build a shared library that goes in as a dependency and even with that we have to still copy/paste code between services. Because a data structure change in one must often be reflected in another HELLO multiple PRs for one task.
blistex 6y ago
Having separate services does add additional overhead and maintenance, but it does provide the benefit of 1) Reducing the blast radius if issues occur, allowing for a degraded service instead of being totally down, and 2) Better scaling/ optimizations. For example, one service could need to support more TPS, or need more memory, CPU, etc.
crazy5sheep 6y ago
Developing with docker is not necessary a micro service, it's just a way of packaging, distributing and deploying your application in a clean way. And docker is not a virtual machine, there's not much overhead, you don't need kubernetes if it's just a simple app, but you can just take advantage of managed service like ECS, you get auto scaling right away, and you don't have manage your node and deal with the stupid thing like systemD
- eecc 6y ago
  Yup, I see docker (and K8s) as another Websphere.
- zorpner 6y ago
  > you get auto scaling right away Every time I see someone say something like this, or better yet use the word "magic", what I hear is that they don't understand how or why their system does the things it does. Nothing is free; nothing is magic; nothing "just works". You understand it or you don't, and nothing has contributed more to the plague of developers thinking they understand it when they don't than cloud-based containers (and the absurd associated costs!).
  - rualca 6y ago
    > Every time I see someone say something like this, or better yet use the word "magic", what I hear is that they don't understand how or why their system does the things it does. There is nothing magic about configuring a deployment to autoscale. You set resource limits, you configure your deployment to scale up if an upper limit is reached and you didn't maxed out, and you configure your deployment to scale down if a lower limit is reached and you didn't min out. What do you find hard to understand? > Nothing is free; nothing is magic; nothing "just works". You understand it or you don't, You're the only one claiming it's magic. The rest of the world doesn't seem to have a problem after having read a couple of pages into the tutorial on how to configure autoscale on whatever service/cloud provider. > and nothing has contributed more to the plague of developers thinking they understand it when they don't than cloud-based containers (and the absurd associated costs!). You're the only one posting a baseless assertion that other developers somehow don't understand autoscaling, as if everyone around you struggles with it.
aaronbrethorst 6y ago
Because it looks good on a resume.
- twic 6y ago
  Looks good to who? When i see all this kind of froth on a CV, that's a red flag to me, or at best, effectively empty space, where another candidate might be telling me about experience and skills that are actually valuable.
  - danjac 6y ago
    To you personally maybe, but not to recruiter filters.
EugeneOZ 6y ago
if they don't talk to each other, then you can run multiple instances of them without paying the price of intercommunications latency. It's a dream for scaling. In this example their teamlead is right.

jayd16 6y ago

OP just said they don't talk at all. They sound completely decoupled already. You could put them in the same app and share routes if you want and just separate by package or compilation unit if you really want to. The hard part is already done though. They could be managed and deployed by completely different teams with no overhead now. It really depends what we're tuning for.

neuronic 6y ago
Scaling is another factor that comes to mind, also resilience. If one part in the monolith goes haywire so will the entire application. If you can decouple and split the software into 4 applications with their own concerns, at least you have 3 applications left running (assuming they are decoupled). If app 1 wants 5000% more CPU than app 2, maybe you can have different instance types running and save costs/resources.
- systematical 6y ago
  A good reason no doubt and if that comes to bear sure. But at least code in a monorepo and split to microservices in your pipeline. Cake and eat.
systematical 6y ago
Read my reply further up, they have a lot in common. We had to build a shared library that goes in as a dependency and even with that we have to still copy/paste code between services. Because a data structure change in one must often be reflected in another HELLO multiple PRs for one task.

blistex 6y ago

Having separate services does add additional overhead and maintenance, but it does provide the benefit of 1) Reducing the blast radius if issues occur, allowing for a degraded service instead of being totally down, and 2) Better scaling/ optimizations. For example, one service could need to support more TPS, or need more memory, CPU, etc.

crazy5sheep 6y ago

Developing with docker is not necessary a micro service, it's just a way of packaging, distributing and deploying your application in a clean way. And docker is not a virtual machine, there's not much overhead, you don't need kubernetes if it's just a simple app, but you can just take advantage of managed service like ECS, you get auto scaling right away, and you don't have manage your node and deal with the stupid thing like systemD

eecc 6y ago
Yup, I see docker (and K8s) as another Websphere.
zorpner 6y ago
> you get auto scaling right away Every time I see someone say something like this, or better yet use the word "magic", what I hear is that they don't understand how or why their system does the things it does. Nothing is free; nothing is magic; nothing "just works". You understand it or you don't, and nothing has contributed more to the plague of developers thinking they understand it when they don't than cloud-based containers (and the absurd associated costs!).
- rualca 6y ago
  > Every time I see someone say something like this, or better yet use the word "magic", what I hear is that they don't understand how or why their system does the things it does. There is nothing magic about configuring a deployment to autoscale. You set resource limits, you configure your deployment to scale up if an upper limit is reached and you didn't maxed out, and you configure your deployment to scale down if a lower limit is reached and you didn't min out. What do you find hard to understand? > Nothing is free; nothing is magic; nothing "just works". You understand it or you don't, You're the only one claiming it's magic. The rest of the world doesn't seem to have a problem after having read a couple of pages into the tutorial on how to configure autoscale on whatever service/cloud provider. > and nothing has contributed more to the plague of developers thinking they understand it when they don't than cloud-based containers (and the absurd associated costs!). You're the only one posting a baseless assertion that other developers somehow don't understand autoscaling, as if everyone around you struggles with it.

aaronbrethorst 6y ago

Because it looks good on a resume.

twic 6y ago
Looks good to who? When i see all this kind of froth on a CV, that's a red flag to me, or at best, effectively empty space, where another candidate might be telling me about experience and skills that are actually valuable.
- danjac 6y ago
  To you personally maybe, but not to recruiter filters.

EugeneOZ 6y ago

if they don't talk to each other, then you can run multiple instances of them without paying the price of intercommunications latency. It's a dream for scaling. In this example their teamlead is right.