4 ms·

I work for a small company that uses microservices architecture. The product is simple where a user registers, enters preferences, selects from courses and sub

I work for a small company that uses microservices architecture. The product is simple where a user registers, enters preferences, selects from courses and submits a form. A monolith would be doable with 5 good engineers. Instead we have about 50 engineers+QA releasing bug filled code. The company's design philosophy is based more on what is fashionable that what is suitable.

dboreham 6y ago
> we have about 50 engineers The plan worked.
- sk5t 6y ago
  Clearly something is working if you've got 50 engineers turning out bug-filled code and systems, and yet the business keeps on living.
  - 0xbadcafebee 6y ago
    > and yet the business keeps on living Sure, they just change the business plan. Move into as many new markets as possible, focus more on new sales than maintaining customers, ship more features/products than you can maintain, etc. If the company gets twice as big but revenue/growth remains the same, that's a sinking ship.
lucideer 6y ago
Anec-contra-data: I worked for a while at a small startup, initially as the sole developer and eventually growing to 3. We had an architecture I would describe as at least being "microservices-esque": a single large "monolithic" backend service, with a number of smaller consumer services, webapps, UIs. The distinction between microservices and monoliths may be debatable but I believe monoliths as described by Martin Fowler typically involve your primary service logic and your UI coexisting. I've found that splitting these at least is usually fruitful. I think this approach is sometimes called "fan-out", though I've seen that term used to describe other different things too; namely the opposite where there's a single monolithic UI layer fanning out to many micro upstreams. TL;DR: Fowler's opening 2 bullet points seem likely to be a false dichotomy as he's force-classifying all architectures into two buckets.
- 1penny42cents 6y ago
  We currently have this approach. One graphql backend-for-frontend server in front of an arbitrary number of BE servers. The UI always has a consistent interface and the BE can focus on its business logic instead of how the FE should display it. The two layers can change fairly independently. We're still early in the project, but in theory I love this architecture and would use it again.
thewarrior 6y ago
There’s too much funding in the industry. Hilarious to think that if interest rates rose we would have fewer micro service implementations.

dboreham 6y ago

> we have about 50 engineers The plan worked.

sk5t 6y ago
Clearly something is working if you've got 50 engineers turning out bug-filled code and systems, and yet the business keeps on living.
- 0xbadcafebee 6y ago
  > and yet the business keeps on living Sure, they just change the business plan. Move into as many new markets as possible, focus more on new sales than maintaining customers, ship more features/products than you can maintain, etc. If the company gets twice as big but revenue/growth remains the same, that's a sinking ship.

lucideer 6y ago

Anec-contra-data: I worked for a while at a small startup, initially as the sole developer and eventually growing to 3. We had an architecture I would describe as at least being "microservices-esque": a single large "monolithic" backend service, with a number of smaller consumer services, webapps, UIs. The distinction between microservices and monoliths may be debatable but I believe monoliths as described by Martin Fowler typically involve your primary service logic and your UI coexisting. I've found that splitting these at least is usually fruitful. I think this approach is sometimes called "fan-out", though I've seen that term used to describe other different things too; namely the opposite where there's a single monolithic UI layer fanning out to many micro upstreams. TL;DR: Fowler's opening 2 bullet points seem likely to be a false dichotomy as he's force-classifying all architectures into two buckets.

1penny42cents 6y ago
We currently have this approach. One graphql backend-for-frontend server in front of an arbitrary number of BE servers. The UI always has a consistent interface and the BE can focus on its business logic instead of how the FE should display it. The two layers can change fairly independently. We're still early in the project, but in theory I love this architecture and would use it again.

thewarrior 6y ago

There’s too much funding in the industry. Hilarious to think that if interest rates rose we would have fewer micro service implementations.