7 ms·

Have your teams use façade pattern and you no longer need microservices to "isolate it"

by qaq 3y ago

lijok 3y ago
Facade doesn't help with poor tests, scripts, new dependencies, cicd workflows, repo settings, etc
- monsieurbanana 3y ago
  If it's that bad, you might be better off paying extra to avoid shitty outsourcing companies. But you're probably not the person I should telling this, developers aren't usually in charge of that.
  - jacquesm 3y ago
    Who mentioned outsourcing?
    - andsoitis 3y ago
      > Who mentioned outsourcing? lijok wrote: When we get consultants in to speedboat a new system, we give them their own separate service. Saves a lot of time and de-risks our beautiful monolith.
  - lijok 3y ago
    You wont know how bad the product produced by consultants will be until it already had effect. And on pricing specifically, both shitty and good consultancies charge about the same. The ones that charge well below market are an outlier that will guarantee bad product - those are to be avoided.
- otikik 3y ago
  Micro services don’t solve any of those either.
  - lijok 3y ago
    What specifically do they not solve? Because in this thread we're, very specifically, discussing isolating the well maintained monolith from risky product produced by consultants, which microservices absolutely do solve.
    - LeBit 3y ago
      I think the hot trend these days is to bash on microservices. I hear that a lot here, random blogs, youtube videos by self proclaimed top guns. If hacker news is correct, microservices is the #1 worst idea of software engineering. And whoever promotes them is either a kid with no experience or a complete moron.
      - deleted 3y ago
        [deleted]
      - discreteevent 3y ago
        Well, speaking for myself, I was against them from the start. Maybe the rejection of distributed objects (when it came) was a hot trend also but it didn't make it wrong.
    - otikik 3y ago
      Any of the problems above. If you have a problem with bad consultants then solve that. Trying to solve it by jumping into microservices you will just have bad consultants writing your microservices equally badly, or even worse.
- qaq 3y ago
  Yep and people you do not trust should not have access to CI/CD workflows and repo settings. Your CI/CD workflows should prevent everything else you mentioned.
prakhar897 3y ago
Can your "facade" "isolate" interns making change in your service as well so that the whole service which powers the system doesn't go down. Microservices can.
- ahtihn 3y ago
  You let interns push to production without code review?
  - prakhar897 3y ago
    Totally missed the point. Even with Code reviews, Unit/Integration Testing, Automated CI/CD and more can a person broke the prod. One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it. If you think "why not restrict config actions" etc, it's because the dev can go there and tweak those actions too. And each step added means less velocity of development. It's a game of cat and mouse. With isolation, you can limit the blast radius and loss of revenue.
    - sapiogram 3y ago
      > Automated CI/CD [...] > One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it. These sound contradictory to me. Part of having automated CI/CD, is not having to manually deal with k8s to do a regular deploy.
    - ahtihn 3y ago
      > One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it. So you don’t have a staging environment to check config changes before deploying to prod? Or you don't put k8s manifests (or helm charts or whatever)in source control and just update prod through CLI? And you let interns do it alone? Your problem isn't interns, it's a terrible deployment processs with weak controls. Even senior engineers are going to break prod regularly in conditions like that.

Have your teams use façade pattern and you no longer need microservices to "isolate it"

by qaq 3y ago

Have your teams use façade pattern and you no longer need microservices to "isolate it"

lijok 3y ago

Facade doesn't help with poor tests, scripts, new dependencies, cicd workflows, repo settings, etc

monsieurbanana 3y ago
If it's that bad, you might be better off paying extra to avoid shitty outsourcing companies. But you're probably not the person I should telling this, developers aren't usually in charge of that.
- jacquesm 3y ago
  Who mentioned outsourcing?
  - andsoitis 3y ago
    > Who mentioned outsourcing? lijok wrote: When we get consultants in to speedboat a new system, we give them their own separate service. Saves a lot of time and de-risks our beautiful monolith.
- lijok 3y ago
  You wont know how bad the product produced by consultants will be until it already had effect. And on pricing specifically, both shitty and good consultancies charge about the same. The ones that charge well below market are an outlier that will guarantee bad product - those are to be avoided.
otikik 3y ago
Micro services don’t solve any of those either.
- lijok 3y ago
  What specifically do they not solve? Because in this thread we're, very specifically, discussing isolating the well maintained monolith from risky product produced by consultants, which microservices absolutely do solve.
  - LeBit 3y ago
    I think the hot trend these days is to bash on microservices. I hear that a lot here, random blogs, youtube videos by self proclaimed top guns. If hacker news is correct, microservices is the #1 worst idea of software engineering. And whoever promotes them is either a kid with no experience or a complete moron.
    - deleted 3y ago
      [deleted]
    - discreteevent 3y ago
      Well, speaking for myself, I was against them from the start. Maybe the rejection of distributed objects (when it came) was a hot trend also but it didn't make it wrong.
  - otikik 3y ago
    Any of the problems above. If you have a problem with bad consultants then solve that. Trying to solve it by jumping into microservices you will just have bad consultants writing your microservices equally badly, or even worse.
qaq 3y ago
Yep and people you do not trust should not have access to CI/CD workflows and repo settings. Your CI/CD workflows should prevent everything else you mentioned.

prakhar897 3y ago

Can your "facade" "isolate" interns making change in your service as well so that the whole service which powers the system doesn't go down. Microservices can.

ahtihn 3y ago
You let interns push to production without code review?
- prakhar897 3y ago
  Totally missed the point. Even with Code reviews, Unit/Integration Testing, Automated CI/CD and more can a person broke the prod. One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it. If you think "why not restrict config actions" etc, it's because the dev can go there and tweak those actions too. And each step added means less velocity of development. It's a game of cat and mouse. With isolation, you can limit the blast radius and loss of revenue.
  - sapiogram 3y ago
    > Automated CI/CD [...] > One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it. These sound contradictory to me. Part of having automated CI/CD, is not having to manually deal with k8s to do a regular deploy.
  - ahtihn 3y ago
    > One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it. So you don’t have a staging environment to check config changes before deploying to prod? Or you don't put k8s manifests (or helm charts or whatever)in source control and just update prod through CLI? And you let interns do it alone? Your problem isn't interns, it's a terrible deployment processs with weak controls. Even senior engineers are going to break prod regularly in conditions like that.