6 ms·

You don't need a damn network between two pieces of code just to "do one thing and do it well", for God's sake, I'm so sick of this rampant cluelessness in the

• lijok 3y ago
  > If you think that microservices solve the "spaghetti code problem", well, good luck to you, you'll need it. That is a very good point. In fact, good monolithic code layout is a precursor for microservices, as only once you have identified your boundaries and isolated your concerns can you begin splitting them out into their own services. I will say this however - microservices might not solve the "spaghetti code problem", but it definitely helps isolate it. 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.
  • 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.
  • renegade-otter 3y ago
    That is a very strategic and appropriate use of this pattern, and it's not even "microservices" - it's just goddamned "services"!
    • Kamq 3y ago
      It also seems like an intentional wielding of Conway's Law.
      • hinkley 3y ago
        Compartmentalization.
• hickelpickle 3y ago
  I also don't get the comparison to UNIX philosophy into the domain of service development. These are totally different domains with their own patterns of resource usage and interaction. Piping "fairly" simple input -> output code that is sharing machine resources and releasing them at the end of execution is total different than running a micro service architecture across multiple containers/hosts. Even if some of them share the same host there is still extra resource overhead from their allocations that will have a constant baseline.
  • jacquesm 3y ago
    Unix has a lot of services that listen to 'localhost'. It has had elements of a service oriented architecture since the first daemon was launched, even though the IPC endpoint wasn't always something listening to a socket.
• baz00 3y ago
  This. So much this. We are 5 years into a microservices wank-fest. So far the net ROI is negative, the user experience sucks more than ever, the complexity is so high that people can't get things done, nothing works properly any more and no one owns anything because they have washed their hands of it all. But this is still promoted as a success because no one wants to be accountable for the fuck up. Our team spend most of the time designing fucked up messes that run over poorly designed APIs, slowly, that impact customers. If it's not that it's upgrading 100 services worth of dependencies constantly, debugging contract violations and weirdness or performance issues.
  • renegade-otter 3y ago
    And if you say this at work, you are going to get a look as if you have grown three heads.
  • dgb23 3y ago
    One thing I wonder is this: There are companies that are very successful and have split their service architecture into domain entities, called microservices. Are they successful because or despite this decision? Is both true in some sense? A more natural way to split up a server architecture is to use computational boundaries. These are found by thinking of how data is processed and flows through the system as opposed to separation of high level domain concerns. But this requires a computational design and not a domain/feature centric one.
    • baz00 3y ago
      There are successful companies that this model applies to. But the problem is that they are outliers. The biggest problem with the whole IT industry is seeing outliers promoted as the successful path and people taking on faith arguments for technical decisions instead of rational decision making processes.
  • wazoox 3y ago
    The code reflects the organisation, that's one of the laws of computing (Fred Brook's law maybe?). Microservices work well in a sufficiently large org, with autonomous entities working on different parts of the system, extremely well-defined interfaces between the services, and someone high up having a bird's eye view of the system. If your organisation doesn't look like that, you can only fail at microservices. Either the company restructures around the code, or the code looks like the company. Trying to make pasta from mash potatoes is doomed to fail.
• MyAccountYo 3y ago
  I think you are misunderstanding the whole topic. Obviously it's about software at scale. Picking the right solution for a problem is kind of the whole job of software development. I have gone through the migration of monoliths to microservices (yes, at scale with multiple teams and requirements to scale individual components etc.) and it solved a lot of problems. The benefits outweigh the costs in my opinion (and drastically so). When people say "you can write well separated components in a monolith..." I can only say: of course you could, but you are not going to (and certainly not everybody at your giant ass company is going to).
  • ivanhoe 3y ago
    The problem is that most of people don't work in a giant ass company and so don't have the same problems you've had have, and thus they can achieve the same easier, faster and cheaper with monoliths - but they don't because of the hype.
  • deleted 3y ago
    [deleted]
  • deleted 3y ago
    [deleted]
• _shantaram 3y ago
  "grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug" -- https://grugbrain.dev https://grugbrain.dev
  • baz00 3y ago
    There is so much wisdom in here. Fundamentally, don't make life hard for yourself, or others.
    • marcosdumay 3y ago
      And yet defaulting into grug-mode is clearly self-defeating. The wisdom only applies to the places where it applies, and there is no wisdom there on telling where those places are.
      • baz00 3y ago
        It's not really. Grug solves problems. Grug does not create problems that need to be solved to solve other problems.
        • marcosdumay 3y ago
          > Grug solves problems. Well, except for the problem of too much grug.
    • sph 3y ago
      When a company measures developer productivity in code added and feature delivered, it creates a perverse incentive that attracts people that really love to write a lot of code and building mountains out of molehills. The best engineer (and not only, see that famous quote by Kurt von Hammerstein-Equord) often is the lazy one. It was a known notion that somehow disappeared around the turn of the millennium.
      • baz00 3y ago
• AugustoCAS 3y ago
  I agree with you. MS can be a solution to a few problems, and as you mentioned 'do one thing and do it well' is not one of them. In my head MS works well for - Teams with different approaches. - Different tech stacks I cannot think of another good reason in which MSs would be a better solution than a good monolith (and communication).
• JohnAaronNelson 3y ago
  Exactly what the article said. I feel like you are strongly asserting a key premise of the article as if you are saying something new.
• marcosdumay 3y ago
  > Do you saturate the resources of one machine and need to split things off? No, of course not. We divide a single machine in an uncountable number of virtual ones; write some code to make sure they don't talk to each other; write some code to make them able to talk to each other; write some code make more or fewer divisions on the run, automatically; and write some code so we can set them up automatically too every time we get a new split. That's how you use software scalability and create a simple, predictable ops environment.
  • dgb23 3y ago
    None of those things require you to introduce network calls.
  • renegade-otter 3y ago
    And what if a certain permutation of these hundreds of services goes down or slows down? What if one service starts generating tons of data and floods another service? Do you have backpressure figured out? Distributed systems introduce a whole new level of complexity and edge cases, but most companies never even hit the scale at which it matters. It's just a pointless, wasteful exercise in "how they do it over at Google".
    • marcosdumay 3y ago
      Nothing that can't be solved with more code and more splitting! That will make things simpler! The more problems your code causes, the more code, the more solutions! (Well, ok, I'm having a hard time solving the first one with more code, but did hear this claim applied to it more than once, so I'm keeping it general.) There is a huge amount of people that sees nothing wrong with my rationale up there. I don't get it either.
    • beebeepka 3y ago
      Ignoring the sarcasm?
  • deleted 3y ago
    [deleted]
• hinkley 3y ago
  I can’t even get people to make new web pages in a web app past year 1. Everyone wants to just cram new features into whichever page makes the most sense, and so average page load time just gets worse and worse because we still want ### milliseconds but now the page is doing twice as much.