4 ms·

Why would you keep rebuilding the container constantly though?

kasey_junk 7y ago
Typically build flows don’t mount the js with volumes they embed it in the image. I’m not cognizant enough of the trade offs to know why.
- bpicolo 7y ago
  Optimizing your local workflows is worth the effort at every team size. I think the attempts to make local workflows mirror production 1:1 (local k8s, for example) are misguided. They miss too hard on the productivity story. Especially once you start having to swap out local debugging for remote debugging (which only a handful of languages support effectively). This is the biggest miss for many companies striving for microservice architecture. The local development story is terrible, and it stays terrible, without a lot of opinionated decisions around what your dev workflow needs to look like past the ~3-5 services mark. At a past gig I had to change 5 different repositories (5 separate PRs, all needing approval) to send an email. In a rails app that would have been a trivial task.
  - inapis 7y ago
    > At a past gig I had to change 5 different repositories (5 separate PRs, all needing approval) to send an email. In a rails app that would have been a trivial task. That sounds like no thought was put in the system before development. Well thought out scopes & contracts between services should not create a situation like that. Reminds me of a commenter on HN who were rolling back changes to all microservices if one service needed a rollback. These kinds of issues are dead giveaways that devs are paying lip-service to "microservices." Also, devs need to understand that they don't need to be on microservices or on the latest fad. Use what works for the team. A 10-team of devs cannot necessarily adopt workflows of a FAANG.
    - bpicolo 7y ago
      Here's the complexity story, if you're curious. 1. Terraform repo for AWS deploy 2. Step functions application logic (server-side polling daemon) 3. Email service template 4. Feature flag configuration 5. (Something in the monolith to trigger the workflow, probably?) This wasn't an entirely small engineering org - 300-400+ devs? I agree, though, is the point. I think folk don't put enough thought into the development story when going this route. I think monorepos are the only sensible way to go about it once folk have cross-service work to accomplish, and monoliths are a _good_ way to build applications for longer than folk give them credit. That said, some monoliths are more productive than others. Slow startup/compilation can destroy productivity.
ehutch79 7y ago
kasey: For deployment that makes sense, but for development, that seems like a lot of work to be happening. If you change a small bit of css, the whole container is rebuilt? That seems super inefficient to me? My backends arn't JS, but I still couldn't imagine rebuilding a container everytime I changed a piece of code. Right now I change a file, django picks up the change and reloads. No noticeable delay.
- nikanj 7y ago
  Because JS. And somehow we the developers convinced each other that -any- attention to performance whatsoever is "premature optimization".
  - inapis 7y ago
    This has got nothing to do with JS. Plenty of devs (me included) work on frontend and backend JS without containers and everything is instant for us. OP has a special use case or build pipeline necessitating such complexity.

Typically build flows don’t mount the js with volumes they embed it in the image. I’m not cognizant enough of the trade offs to know why.

bpicolo 7y ago
Optimizing your local workflows is worth the effort at every team size. I think the attempts to make local workflows mirror production 1:1 (local k8s, for example) are misguided. They miss too hard on the productivity story. Especially once you start having to swap out local debugging for remote debugging (which only a handful of languages support effectively). This is the biggest miss for many companies striving for microservice architecture. The local development story is terrible, and it stays terrible, without a lot of opinionated decisions around what your dev workflow needs to look like past the ~3-5 services mark. At a past gig I had to change 5 different repositories (5 separate PRs, all needing approval) to send an email. In a rails app that would have been a trivial task.
- inapis 7y ago
  > At a past gig I had to change 5 different repositories (5 separate PRs, all needing approval) to send an email. In a rails app that would have been a trivial task. That sounds like no thought was put in the system before development. Well thought out scopes & contracts between services should not create a situation like that. Reminds me of a commenter on HN who were rolling back changes to all microservices if one service needed a rollback. These kinds of issues are dead giveaways that devs are paying lip-service to "microservices." Also, devs need to understand that they don't need to be on microservices or on the latest fad. Use what works for the team. A 10-team of devs cannot necessarily adopt workflows of a FAANG.
  - bpicolo 7y ago
    Here's the complexity story, if you're curious. 1. Terraform repo for AWS deploy 2. Step functions application logic (server-side polling daemon) 3. Email service template 4. Feature flag configuration 5. (Something in the monolith to trigger the workflow, probably?) This wasn't an entirely small engineering org - 300-400+ devs? I agree, though, is the point. I think folk don't put enough thought into the development story when going this route. I think monorepos are the only sensible way to go about it once folk have cross-service work to accomplish, and monoliths are a _good_ way to build applications for longer than folk give them credit. That said, some monoliths are more productive than others. Slow startup/compilation can destroy productivity.

ehutch79 7y ago

kasey: For deployment that makes sense, but for development, that seems like a lot of work to be happening. If you change a small bit of css, the whole container is rebuilt? That seems super inefficient to me? My backends arn't JS, but I still couldn't imagine rebuilding a container everytime I changed a piece of code. Right now I change a file, django picks up the change and reloads. No noticeable delay.

nikanj 7y ago
Because JS. And somehow we the developers convinced each other that -any- attention to performance whatsoever is "premature optimization".
- inapis 7y ago
  This has got nothing to do with JS. Plenty of devs (me included) work on frontend and backend JS without containers and everything is instant for us. OP has a special use case or build pipeline necessitating such complexity.