3 ms·

Yea. Once you have good domain boundaries you can use microservices to make the split more visible for less thoughtful devs and use the associated tooling (con

Yea. Once you have good domain boundaries you can use microservices to make the split more visible for less thoughtful devs and use the associated tooling (contract testing, ... ) to reduce operational coupling around deployments and tests. But aside from that, anything you can do with microservices you can also do in monoliths.

pydry 6y ago
Some people think that if you start creating micro services you will magically just "get" those boundaries.
- kenniskrag 6y ago
  and magically get the problem of distributed transactions. :)
  - heavenlyblue 6y ago
    I am yet to see a single monolith that doesn't deal with exactly the same issue itself.
    - pc86 6y ago
      Aren't monoliths by definition not distributed?
      - caogecym 6y ago
        monolithic source code can be deployed across multiple servers.
      - heavenlyblue 6y ago
        A true monolith is like a true function - it's absolutely useless because everything it does is pure and therefore it can't interact with reality at all. In less metaphorical terms: you still need to sync external APIs, sync filesystem with the database, deploy to S3 as you don't want to saturate your web workers, or have conflicts in your parallel red-blue deployments. If your monolith doesn't do anything I had just described then you probably aren't doing anything exciting anyway so it's quite unlikely that you've got a lot to say about software architecture.
- konschubert 6y ago
  Oh, you don't know how true this is.
tsss 6y ago
> But aside from that, anything you can do with microservices you can also do in monoliths. Microservices can give you some things that a modular monolith can't provide: independent deployments, different tech stacks, independent scaling and better resiliency.
chris_j 6y ago
I'd be interested to hear about the sorts of systems that you've worked on and how anything you can do with microservices you can do with a monolith. Some problems that I've had to solve in recent years: - Urgently deploying a fix in one part of the system without having to deploy the _whole_ system. - Updating the framework or the language (my favourite: updating from Java 8 to Java 11, which broke a lot of things and which we would have hated to have to do all in one go, if we'd had a monolith). - Scaling different parts of the system independently (both in terms of running different services on different numbers of nodes and in terms of using different hardware for application nodes and DBs). - Load testing different parts of the system independently. - Trialling a new language or framework in a small part of the system without affecting the rest of the system. I personally wasn't aware of how much of a big deal some of these problems would have been until our system grew to the size that it is now, with a dozen or so development teams working on at least as many services. I personally have no idea how you could solve these problems on a system this size without splitting it into independently deployable services, without incurring a massive cost.

pydry 6y ago

Some people think that if you start creating micro services you will magically just "get" those boundaries.

kenniskrag 6y ago
and magically get the problem of distributed transactions. :)
- heavenlyblue 6y ago
  I am yet to see a single monolith that doesn't deal with exactly the same issue itself.
  - pc86 6y ago
    Aren't monoliths by definition not distributed?
    - caogecym 6y ago
      monolithic source code can be deployed across multiple servers.
    - heavenlyblue 6y ago
      A true monolith is like a true function - it's absolutely useless because everything it does is pure and therefore it can't interact with reality at all. In less metaphorical terms: you still need to sync external APIs, sync filesystem with the database, deploy to S3 as you don't want to saturate your web workers, or have conflicts in your parallel red-blue deployments. If your monolith doesn't do anything I had just described then you probably aren't doing anything exciting anyway so it's quite unlikely that you've got a lot to say about software architecture.
konschubert 6y ago
Oh, you don't know how true this is.

tsss 6y ago

> But aside from that, anything you can do with microservices you can also do in monoliths. Microservices can give you some things that a modular monolith can't provide: independent deployments, different tech stacks, independent scaling and better resiliency.

chris_j 6y ago

I'd be interested to hear about the sorts of systems that you've worked on and how anything you can do with microservices you can do with a monolith. Some problems that I've had to solve in recent years: - Urgently deploying a fix in one part of the system without having to deploy the _whole_ system. - Updating the framework or the language (my favourite: updating from Java 8 to Java 11, which broke a lot of things and which we would have hated to have to do all in one go, if we'd had a monolith). - Scaling different parts of the system independently (both in terms of running different services on different numbers of nodes and in terms of using different hardware for application nodes and DBs). - Load testing different parts of the system independently. - Trialling a new language or framework in a small part of the system without affecting the rest of the system. I personally wasn't aware of how much of a big deal some of these problems would have been until our system grew to the size that it is now, with a dozen or so development teams working on at least as many services. I personally have no idea how you could solve these problems on a system this size without splitting it into independently deployable services, without incurring a massive cost.