3 ms·

Microservices trade development complexity for operational complexity. Write a monolith in Golang with Postgres instead. 99% of ordinary applications would nev

Microservices trade development complexity for operational complexity. Write a monolith in Golang with Postgres instead. 99% of ordinary applications would never be able to max out a modern server running this. Microservices are an anti pattern for most ordinary application needs.

theshrike79 2y ago
Also deployment will be completely trivial, just copy the one executable + configs (And not even those if your configs live in a central service)
arunix 2y ago
Why Golang / Postgres in particular?
- dukeyukey 2y ago
  Both scale well beyond the point of most applications, but aren't overly complex to get running.
  - sgarland 2y ago
    MySQL is equally easy to get running, and has FAR less maintenance overhead. It also scales better on its own, due to a threaded connection model vs. Postgres’ process model. The main trade-off is less extensibility, but IME Postgres’ more esoteric types are rarely used anyway. The other tradeoff (perhaps larger, actually) is poor performance if using a non-k-sortable PK, like a UUIDv4. Unfortunately this is extremely common.
    - ndriscoll 2y ago
      The process thing is irrelevant if you're using a decent database library with connection pooling. Mysql also performs/scales better when keeping connection count proportional to the hardware. I'm personally not a fan of golang (scala has similar performance while being much easier to maintain IMO), but at least pooling is normal/relatively transparent there. As with using many connections, a UUIDv4 PK is a case of "don't do that".
      - sgarland 2y ago
        I’d say greatly reduced in magnitude, but not irrelevant. I’d also prefer to use middleware like PgBouncer or PgCat rather than relying on a library’s connection pooler, mostly because the latter IME has a habit of causing fun surprises from people not properly handling transactions. > “don’t do that” If I could get people to use RDBMS properly, I’d be both thrilled and potentially out of a job.
    - andrewstuart 2y ago
      >> MySQL is equally easy to get running, and has FAR less maintenance overhead None of these ring true for me. >> It also scales better on its own, due to a threaded connection model vs. Postgres’ process model. My understanding is that Postgres has an excellent SMP design that gives almost linear vertical scale. Couldn't quickly find good backup docs. >> FAR less maintenance overhead What do you mean by "maintenance overhead"? I don't find Postgres needs much maintenance let along FAR less.
      - sgarland 2y ago
        > None of these ring true for me. In what way? > What do you mean by "maintenance overhead"? I don't find Postgres needs much maintenance let along FAR less. At small scale, you likely won’t notice. Once your tables get up to 10s or 100s of millions of rows, you will. Autovacuum will need tuning, both globally and per-table. Indices will need periodic re-indexing. Specific columns in tables may need custom statistics targets. TXID wraparound, though this isn’t so much maintenance as it is a waking nightmare that you have to monitor for. Don’t get me wrong, I quite like Postgres. However, IME from having ran large-ish (10s of TB) clusters of both, MySQL tends to Just Work.
    - KronisLV 2y ago
      Golang is great but depending on the job market in a given country, might be a little bit esoteric. If you were aiming for one of the more popular options that still scale pretty well, you might pair either PosgreSQL/MariaDB/MySQL with one of the JVM languages (e.g. Java) or one of the CLR languages (e.g. C#). Both runtimes and their languages are okay and have pretty big ecosystems. Then again, Node or even PHP might be enough for most apps, maybe even Python or Ruby with a bit of vertical (and simple horizontal) scaling down the line. Just be prepared for that monolith to grow into an eldritch nightmare of dependencies somewhere between 5 to 15 years later. Currently working on such a Java system, it makes the laptop thermal throttle regularly.
cedws 2y ago
But then how are AWS going to empty your pockets?
PittleyDunkin 2y ago
You're discussing two different design patterns as if they're exclusive—tight code coupling (monolith) and independent scaling (microservices). The idea you have to choose is a false dichotomy.
patmorgan23 2y ago
I thought the main benefit of micro services is they make the deployment unit smaller, so you can have more teams doing independent deployments, rather than everyone having to wait for the next version of the monolith to go out
- andrewstuart 2y ago
  Yes this is trading dev complexity for operations complexity.

theshrike79 2y ago

Also deployment will be completely trivial, just copy the one executable + configs (And not even those if your configs live in a central service)

arunix 2y ago

Why Golang / Postgres in particular?

dukeyukey 2y ago
Both scale well beyond the point of most applications, but aren't overly complex to get running.
- sgarland 2y ago
  MySQL is equally easy to get running, and has FAR less maintenance overhead. It also scales better on its own, due to a threaded connection model vs. Postgres’ process model. The main trade-off is less extensibility, but IME Postgres’ more esoteric types are rarely used anyway. The other tradeoff (perhaps larger, actually) is poor performance if using a non-k-sortable PK, like a UUIDv4. Unfortunately this is extremely common.
  - ndriscoll 2y ago
    The process thing is irrelevant if you're using a decent database library with connection pooling. Mysql also performs/scales better when keeping connection count proportional to the hardware. I'm personally not a fan of golang (scala has similar performance while being much easier to maintain IMO), but at least pooling is normal/relatively transparent there. As with using many connections, a UUIDv4 PK is a case of "don't do that".
    - sgarland 2y ago
      I’d say greatly reduced in magnitude, but not irrelevant. I’d also prefer to use middleware like PgBouncer or PgCat rather than relying on a library’s connection pooler, mostly because the latter IME has a habit of causing fun surprises from people not properly handling transactions. > “don’t do that” If I could get people to use RDBMS properly, I’d be both thrilled and potentially out of a job.
  - andrewstuart 2y ago
    >> MySQL is equally easy to get running, and has FAR less maintenance overhead None of these ring true for me. >> It also scales better on its own, due to a threaded connection model vs. Postgres’ process model. My understanding is that Postgres has an excellent SMP design that gives almost linear vertical scale. Couldn't quickly find good backup docs. >> FAR less maintenance overhead What do you mean by "maintenance overhead"? I don't find Postgres needs much maintenance let along FAR less.
    - sgarland 2y ago
      > None of these ring true for me. In what way? > What do you mean by "maintenance overhead"? I don't find Postgres needs much maintenance let along FAR less. At small scale, you likely won’t notice. Once your tables get up to 10s or 100s of millions of rows, you will. Autovacuum will need tuning, both globally and per-table. Indices will need periodic re-indexing. Specific columns in tables may need custom statistics targets. TXID wraparound, though this isn’t so much maintenance as it is a waking nightmare that you have to monitor for. Don’t get me wrong, I quite like Postgres. However, IME from having ran large-ish (10s of TB) clusters of both, MySQL tends to Just Work.
  - KronisLV 2y ago
    Golang is great but depending on the job market in a given country, might be a little bit esoteric. If you were aiming for one of the more popular options that still scale pretty well, you might pair either PosgreSQL/MariaDB/MySQL with one of the JVM languages (e.g. Java) or one of the CLR languages (e.g. C#). Both runtimes and their languages are okay and have pretty big ecosystems. Then again, Node or even PHP might be enough for most apps, maybe even Python or Ruby with a bit of vertical (and simple horizontal) scaling down the line. Just be prepared for that monolith to grow into an eldritch nightmare of dependencies somewhere between 5 to 15 years later. Currently working on such a Java system, it makes the laptop thermal throttle regularly.

cedws 2y ago

But then how are AWS going to empty your pockets?

PittleyDunkin 2y ago

You're discussing two different design patterns as if they're exclusive—tight code coupling (monolith) and independent scaling (microservices). The idea you have to choose is a false dichotomy.

patmorgan23 2y ago

I thought the main benefit of micro services is they make the deployment unit smaller, so you can have more teams doing independent deployments, rather than everyone having to wait for the next version of the monolith to go out

andrewstuart 2y ago
Yes this is trading dev complexity for operations complexity.