• Ephera@lemmy.ml
    link
    fedilink
    arrow-up
    42
    arrow-down
    2
    ·
    6 months ago

    The problem is that all projects start small, and frankly most of them die small. Aiming for microservices architecture right away is a surefire way to get the project killed before anyone would benefit off of the microservices.

    • whoisearth@lemmy.ca
      link
      fedilink
      arrow-up
      48
      ·
      6 months ago

      The other angle is the majority of Devs are just… Not good…

      A good Dev in the situation you mention will design the solution needed now not the one you hope for later.

      I’m saying this as someone who has been mired in scope creep and over engineering solutions many times in my life because “what if 5000 people need to use it at once?!”

      In most cases all you need is a database, a single thread and a simple API. Build it and then as the problems come grow with them. Try to take into account issues of scale but realize you can’t and shouldn’t solve every scenario because there are too many variables which may never exist.

      • Korne127@lemmy.world
        link
        fedilink
        arrow-up
        30
        arrow-down
        1
        ·
        6 months ago

        A good Dev in the situation you mention will design the solution needed now not the one you hope for later.

        Maintainability is one of the most important if not the most important goal when programming. If a dev only designs a solution that fits for exactly the current situation but doesn’t allow any changes, it’s not a good dev.
        But yeah, if you start small, a solution that’s made for that is preferable. You can still refactor things when you get magnitudes larger and have the budget.

        • floofloof@lemmy.ca
          link
          fedilink
          English
          arrow-up
          21
          ·
          edit-2
          6 months ago

          The tricky thing about software development is this balance: you don’t want to hobble your system by designing only for today, because that could waste a whole lot of time later when needs change, but you also mustn’t paralyze the project by designing for all possible tomorrows. Finding a middle path is the art, and the only proof that you got it somewhat right is that things get done with relatively few crises.

          • reflectedodds@lemmy.world
            link
            fedilink
            arrow-up
            6
            ·
            6 months ago

            Microservice from the start may be a lot of overhead, but it should at least be made with that scalability in mind. In practice to me, that just means simple things like make sure you can configure it via environment vars, run it out of docker compose or something because you need to be able install it on all your dev systems and your prod server. That basic setup will let you scale if/when you need to, and doesn’t add anything extra when planned from the start.

            Allocating infrastructure on a cloud service with auto scaling is the hard part imo. But making the app support the environment from the start isn’t as hard.

        • magic_lobster_party@kbin.run
          link
          fedilink
          arrow-up
          19
          ·
          6 months ago

          Often a simple solution is the most maintainable solution. In my experience, the code that’s most difficult to maintain are often made by devs who tried to plan ahead. The code turns over engineered to allow for stuff that never materialized.

        • Potatos_are_not_friends@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          edit-2
          6 months ago

          If a dev only designs a solution that fits for exactly the current situation but doesn’t allow any changes, it’s not a good dev.

          I don’t think anybody is arguing this. Nobody (in my decade-plus in this industry) actively codes in a way to not allow any changes.

          • floofloof@lemmy.ca
            link
            fedilink
            English
            arrow-up
            4
            ·
            6 months ago

            You evidently haven’t met my colleagues. There are always people who go for the quickest hack despite the trouble it stores up for later, and they’re usually encouraged by management.

    • Potatos_are_not_friends@lemmy.world
      link
      fedilink
      arrow-up
      20
      ·
      6 months ago

      I always lump microservices architecture as premature optimization, one that should be used when you’re maxed out of resources or everything is too spaghetti.

      I love the idea. And I even pitched it for a specific project. But I had to eat humble pie when the devops nerds threw more servers at the problem and it worked better than I expected.

      • lemmyvore@feddit.nl
        link
        fedilink
        English
        arrow-up
        4
        ·
        6 months ago

        Sounds like that thing was already designed to be horizontally scalable. Was your error related to not realizing that? Or what was the problem being solved by microservices?