4 ms·

Start with a monolith, that will take you VERY far. When the organization gets big enough (AND ONLY THEN), add an additional domain oriented service. FULLY imp

Start with a monolith, that will take you VERY far. When the organization gets big enough (AND ONLY THEN), add an additional domain oriented service. FULLY implement deployment and infra. Only once you do that can you think about adding another (using the pattern you just built out). Micro-monoliths. Organizations explode the number of services, half ass the infrastructure (the hard part of microservices), and then crumble under the organizational complexity.

hot_gril 4y ago
My org did this, and it ended in disaster because that monolith was shoving everything in the world into a single database the whole time. This created horrible APIs: one team writing into tables that another team is expected to read. They tried to split this later on and created an even bigger mess. There are reasonable places before then to stop and say, we need to keep X new features in a separate service.
- John23832 4y ago
  That’s still not a microservices vs monolith problem. That’s a bad data stewardship problem. If your data is a mess before you decided to break out functionality, then it’s gonna be hard regardless. You should have good schemas and db organization always.
  - hot_gril 4y ago
    This issue is about microservices because the one alternative to this DB-level data sharing is having proper RPCs (or more specialized things like pubsub in some cases) between cleanly separated services. If logically separate things are sharing data through the DB itself, you will get a mess even if you're very careful, which they were.
    - John23832 4y ago
      You should have a well curated DB regardless of whether one or many domain specific services sit in front of it. That is what would enable you to break a monolith up. Good code and architecture is the result of discipline. Your data is your most valuable asset. What you're describing is a mess. You mentioned RPC's. Your service interface has nothing to do with the data organization. But if you think microservices is what would work for you, then you should pursue that next time. My original post was a path to a multiple service architecture that approached service expansion with technical rhyme and reason. It really wasn't aimed at your organizations messy database.
      - hot_gril 4y ago
        > You mentioned RPC's. Your service interface has nothing to do with the data organization. I find data organization to be a direct consequence of service interface. If two things aren't talking over RPCs or pubsub, they're talking through the database. It's not just my org. Pretty common for monoliths to end up with an obscene reliance on a single DB and start looking for a huge machine to support it. There isn't a clear definition of what a separate "service" is, but I think it's fair to say that separate services won't have identical consistent views of the same DB. They'll be more independent than that, each with authority only over its own data, and use each other's data in an eventually-consistent manner through a well-abstracted API. And that does bring some overhead.
        roflyear 4y ago
        > I find data organization to be a direct consequence of service interface. Then, you will not like microservices. Microservices make it harder, not easier, to organize data. You have to worry about problems such as eventual consistency, and figure out how to join data across multiple data sources. It compounds the problem significantly, and the only thing it gives you is that it forces you to silo data. That can be a good thing, but it doesn't solve the data organization problem.
        hot_gril 4y ago
        Usually the service structure will mirror the team structure, e.g. one team of 2-6 SWEs per service. I've enjoyed doing things this way now that we're out of the monolith. BTW, monolith DB has its own form of eventual consistency. Process A puts data into DB, process B picks it up later and affects the DB. There's no reasonable way that everything in such a multi-use DB is always logically in agreement. You're just guaranteeing that B sees what A writes immediately, which comes at a cost. > the only thing it gives you is that it forces you to silo data It gives you a smaller blast radius when something goes wrong, avoids over-stressing a single DB, alleviates single points of human dependency like the DB curator, lets you scale separate pieces independently, and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time.
Sohcahtoa82 4y ago
> Micro-monoliths. Would those be the same as macroservices?

hot_gril 4y ago

My org did this, and it ended in disaster because that monolith was shoving everything in the world into a single database the whole time. This created horrible APIs: one team writing into tables that another team is expected to read. They tried to split this later on and created an even bigger mess. There are reasonable places before then to stop and say, we need to keep X new features in a separate service.

John23832 4y ago
That’s still not a microservices vs monolith problem. That’s a bad data stewardship problem. If your data is a mess before you decided to break out functionality, then it’s gonna be hard regardless. You should have good schemas and db organization always.
- hot_gril 4y ago
  This issue is about microservices because the one alternative to this DB-level data sharing is having proper RPCs (or more specialized things like pubsub in some cases) between cleanly separated services. If logically separate things are sharing data through the DB itself, you will get a mess even if you're very careful, which they were.
  - John23832 4y ago
    You should have a well curated DB regardless of whether one or many domain specific services sit in front of it. That is what would enable you to break a monolith up. Good code and architecture is the result of discipline. Your data is your most valuable asset. What you're describing is a mess. You mentioned RPC's. Your service interface has nothing to do with the data organization. But if you think microservices is what would work for you, then you should pursue that next time. My original post was a path to a multiple service architecture that approached service expansion with technical rhyme and reason. It really wasn't aimed at your organizations messy database.
    - hot_gril 4y ago
      > You mentioned RPC's. Your service interface has nothing to do with the data organization. I find data organization to be a direct consequence of service interface. If two things aren't talking over RPCs or pubsub, they're talking through the database. It's not just my org. Pretty common for monoliths to end up with an obscene reliance on a single DB and start looking for a huge machine to support it. There isn't a clear definition of what a separate "service" is, but I think it's fair to say that separate services won't have identical consistent views of the same DB. They'll be more independent than that, each with authority only over its own data, and use each other's data in an eventually-consistent manner through a well-abstracted API. And that does bring some overhead.
      - roflyear 4y ago
        > I find data organization to be a direct consequence of service interface. Then, you will not like microservices. Microservices make it harder, not easier, to organize data. You have to worry about problems such as eventual consistency, and figure out how to join data across multiple data sources. It compounds the problem significantly, and the only thing it gives you is that it forces you to silo data. That can be a good thing, but it doesn't solve the data organization problem.
        hot_gril 4y ago
        Usually the service structure will mirror the team structure, e.g. one team of 2-6 SWEs per service. I've enjoyed doing things this way now that we're out of the monolith. BTW, monolith DB has its own form of eventual consistency. Process A puts data into DB, process B picks it up later and affects the DB. There's no reasonable way that everything in such a multi-use DB is always logically in agreement. You're just guaranteeing that B sees what A writes immediately, which comes at a cost. > the only thing it gives you is that it forces you to silo data It gives you a smaller blast radius when something goes wrong, avoids over-stressing a single DB, alleviates single points of human dependency like the DB curator, lets you scale separate pieces independently, and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time.

Sohcahtoa82 4y ago

> Micro-monoliths. Would those be the same as macroservices?