5 ms·

> installing ~50ish microservices on their machine Ouch. Where they using macOS at the time with laptops having not-enough-ram? I've seen that go poorly on m

> installing ~50ish microservices on their machine Ouch. Where they using macOS at the time with laptops having not-enough-ram? I've seen that go poorly on macOS with java based microservices. Largely due to java VMs wanting ram pre-assigned for each, which really chews though ram that mostly sits around unused. This was a few years ago though, at the tail end of Intel based mac's where 32GB ram in a mac laptop wasn't really an option.

themanmaran 2y ago
I bet it's less of a RAM issue, and more of an orchestration problem. Making sure you have the latest version of every microservice and it's configuration. "Oh it's not running locally, you need to also run service_18_v2.js, and include the right env variables"
- skydhash 2y ago
  This + k8s magic that seem to make thing coupled tighter.
  - KronisLV 2y ago
    > This + k8s magic that seem to make thing coupled tighter. I think nobody really talks about this, but unless you have a docker-compose.yml that includes everything you need for local development, it's increasingly more likely that you'll end up coupling things to Kubernetes to such a degree that running without it (and its abstractions) will become more effort than a person can muster. So while people try to create services that are decoupled from one another, they end up instead coupling them to Kubernetes concepts and a service mesh, service discovery, configuration and secret management mechanisms, persistent storage abstractions and so on. Which you can obviously do if you want to, but which might make running things locally in a minimalistic fashion that much more complex. It's the same as with for example using a web server as a reverse proxy for my applications and ending up putting some logic in there (e.g. route rewrites, headers etc.) and then realizing that I must also run a similar web server locally for 1:1 compatibility because something like Vue dev server proxy to the locally running API won't be able to give me all that.
    - chipdart 2y ago
      > I think nobody really talks about this, but unless you have a docker-compose.yml that includes everything you need for local development (...) Is this a problem? I mean, in this scenario docker compose serves two main purposes: launch a few mock services, and configure those services according to your needs. This means configuring them to consume services already deployed to a cloud environment of your choice. This is something you control. Then all that's left is the service (or set if services) you need to modify. You run those locally and configure them to consume a mix of the mocked services and the services deployed to a cloud environment. > (...) it's increasingly more likely that you'll end up coupling things to Kubernetes to such a degree that running without it (and its abstractions) will become more effort than a person can muster. That coupling can only happen if you intentionally add it yourself. If you need to run your services in isolation, you will be more mindful of the need to not introduce that sort of coupling.
- justinclift 2y ago
  No, it was definitely a ram issue in this case. The laptops had 16GB of ram, the maximum available at the time. With the java VM overhead that ran things straight into swap and then some. Running the dev environments remotely (or rewriting in Go) were the options being considered before the whole project was canned and people redistributed to other things.
  - sdenton4 2y ago
    I do the great majority of my work on a beefy desktop with a phat GPU, which I mostly run via ssh and a browser.
  - pjmlp 2y ago
    Given some Kubernetes workloads, even writing everything in Assembly might not help.
- Cthulhu_ 2y ago
  If you have to have the latest version etc of every microservice, it's a distributed monolith.
  - consteval 2y ago
    Right, the crux here is bad architects are building distributed systems that are essentially monoliths. It's the worst of both worlds. You get none of the guarantees and visibility of a monolith, and you get all the friction of a distributed system.
    - themanmaran 2y ago
      This is the first time I've heard the term distributed monolith and it's just clicked that every microservice application I've worked on has been exactly that.
throwaway2037 2y ago
> Largely due to java VMs wanting ram pre-assigned for each Do you mean the JVM min heap size was rather later? Otherwise, there is no need for a very large min heap size on a modern JVM (11+).
- justinclift 2y ago
  Pretty sure it was a mix of java 8 (yeah, very outdated even then) and more modern stuff.
liveoneggs 2y ago
why would run multiple JVMs?
- justinclift 2y ago
  One per microservice.
  - liveoneggs 2y ago
    This is a bad idea. It defeats a major feature of the jvm.
    - chipdart 2y ago
      > This is a bad idea. Not really. It all depends on what are your needs. > It defeats a major feature of the jvm. You're confusing things. Just because Java addressed the deployability problem for Java applications before containerization was even a word, this does not mean that deploying a JVM per service is a bad idea. Just think about it for a second. Why do you need to deploy and scale services independently? Do you mention the JVM in your response? No.
      - liveoneggs 2y ago
        We were talking about dev enviroments on desktops, not independently scalable components. I did mention the jvm in my response. You quoted me doing so, in fact.
        chipdart 2y ago
        > We were talking about dev enviroments on desktops, not independently scalable components. Your dev environment is expected to mimick your production environment, not the other way around.

themanmaran 2y ago

I bet it's less of a RAM issue, and more of an orchestration problem. Making sure you have the latest version of every microservice and it's configuration. "Oh it's not running locally, you need to also run service_18_v2.js, and include the right env variables"

skydhash 2y ago
This + k8s magic that seem to make thing coupled tighter.
- KronisLV 2y ago
  > This + k8s magic that seem to make thing coupled tighter. I think nobody really talks about this, but unless you have a docker-compose.yml that includes everything you need for local development, it's increasingly more likely that you'll end up coupling things to Kubernetes to such a degree that running without it (and its abstractions) will become more effort than a person can muster. So while people try to create services that are decoupled from one another, they end up instead coupling them to Kubernetes concepts and a service mesh, service discovery, configuration and secret management mechanisms, persistent storage abstractions and so on. Which you can obviously do if you want to, but which might make running things locally in a minimalistic fashion that much more complex. It's the same as with for example using a web server as a reverse proxy for my applications and ending up putting some logic in there (e.g. route rewrites, headers etc.) and then realizing that I must also run a similar web server locally for 1:1 compatibility because something like Vue dev server proxy to the locally running API won't be able to give me all that.
  - chipdart 2y ago
    > I think nobody really talks about this, but unless you have a docker-compose.yml that includes everything you need for local development (...) Is this a problem? I mean, in this scenario docker compose serves two main purposes: launch a few mock services, and configure those services according to your needs. This means configuring them to consume services already deployed to a cloud environment of your choice. This is something you control. Then all that's left is the service (or set if services) you need to modify. You run those locally and configure them to consume a mix of the mocked services and the services deployed to a cloud environment. > (...) it's increasingly more likely that you'll end up coupling things to Kubernetes to such a degree that running without it (and its abstractions) will become more effort than a person can muster. That coupling can only happen if you intentionally add it yourself. If you need to run your services in isolation, you will be more mindful of the need to not introduce that sort of coupling.
justinclift 2y ago
No, it was definitely a ram issue in this case. The laptops had 16GB of ram, the maximum available at the time. With the java VM overhead that ran things straight into swap and then some. Running the dev environments remotely (or rewriting in Go) were the options being considered before the whole project was canned and people redistributed to other things.
- sdenton4 2y ago
  I do the great majority of my work on a beefy desktop with a phat GPU, which I mostly run via ssh and a browser.
- pjmlp 2y ago
  Given some Kubernetes workloads, even writing everything in Assembly might not help.
Cthulhu_ 2y ago
If you have to have the latest version etc of every microservice, it's a distributed monolith.
- consteval 2y ago
  Right, the crux here is bad architects are building distributed systems that are essentially monoliths. It's the worst of both worlds. You get none of the guarantees and visibility of a monolith, and you get all the friction of a distributed system.
  - themanmaran 2y ago
    This is the first time I've heard the term distributed monolith and it's just clicked that every microservice application I've worked on has been exactly that.

throwaway2037 2y ago

> Largely due to java VMs wanting ram pre-assigned for each Do you mean the JVM min heap size was rather later? Otherwise, there is no need for a very large min heap size on a modern JVM (11+).

justinclift 2y ago
Pretty sure it was a mix of java 8 (yeah, very outdated even then) and more modern stuff.

liveoneggs 2y ago

why would run multiple JVMs?

justinclift 2y ago
One per microservice.
- liveoneggs 2y ago
  This is a bad idea. It defeats a major feature of the jvm.
  - chipdart 2y ago
    > This is a bad idea. Not really. It all depends on what are your needs. > It defeats a major feature of the jvm. You're confusing things. Just because Java addressed the deployability problem for Java applications before containerization was even a word, this does not mean that deploying a JVM per service is a bad idea. Just think about it for a second. Why do you need to deploy and scale services independently? Do you mention the JVM in your response? No.
    - liveoneggs 2y ago
      We were talking about dev enviroments on desktops, not independently scalable components. I did mention the jvm in my response. You quoted me doing so, in fact.
      - chipdart 2y ago
        > We were talking about dev enviroments on desktops, not independently scalable components. Your dev environment is expected to mimick your production environment, not the other way around.