6 ms·

The interesting thing about microservices is not that it lets you split up your code on module boundaries. Obviously you can (and should!) do that inside any co

The interesting thing about microservices is not that it lets you split up your code on module boundaries. Obviously you can (and should!) do that inside any codebase. The thing about microservices is that it breaks up your data and deployment on module boundaries. Monoliths are monoliths not because they lack separation of concerns in code (something which lacks that is not a ‘monolith’, it is what’s called a ‘big ball of mud’) Monoliths are monoliths because they have - one set of shared dependencies - one shared database - one shared build pipeline - one shared deployment process - one shared test suite - one shared entrypoint As organizations and applications get larger these start to become liabilities. Microservices are part of one solution to that (not a whole solution; not the only one).

Retric 5y ago
Monoliths don’t actually look like that at scale. For example you can easily have multiple different data stores for different reasons, including multiple different kinds of databases. Here’s this tiny little internal relational database used internally, and there’s the giant tape library that’s archiving all this scientific data we actually care about. Here’s the hard real time system, and over there’s the billing data etc etc. The value of a monolith is it looks like a single thing from outside that does something comprehensible, internally it still needs to actually work.
- jameshart 5y ago
  But all those data sources are connected to from the same runtime, right? And to run it locally you need access to dev versions of all of them. And when there’s a security vulnerability in your comment system your tape library gets wiped.
  - jacinda 5y ago
    > But all those data sources are connected to from the same runtime, right? Yes, this is an accurate assessment from what I've seen. > And to run it locally you need access to dev versions of all of them. In my experience, no. If the runtime never needs to access it because you're only doing development related to datastore A, it shouldn't fall over just because you haven't configured datastore B. Lots of easy ways to either skip this in the runtime or have a mocked interface. > And when there’s a security vulnerability in your comment system your tape library gets wiped. This one really depends but I think can be an accurate criticism of many systems. It's most true, I think, when you're at an in-between scale where you're big enough to be a target but haven't yet gotten big enough to afford more dedicated security testing at an application code level.
  - KronisLV 5y ago
    This actually feels like a good example of the modularity that i talked about and feature flags. Of course, in some projects, it's not what one would call a new architecture (like in my blog post), but rather just careful usage of feature flags. > But all those data sources are connected to from the same runtime, right? Surely you could have multiple instances of your monolithic app: # Runs internally app_instance_1_admin_interface: environment: FEATURE_ENABLE_ADMIN_INTERFACE=true # Runs interally app_instance_2_tape_backup_job: environment: FEATURE_ENABLE_TAPE_BACKUP_JOB=true # Exposed externally through LB app_instance_3_comment_system: environment: FEATURE_ENABLE_COMMENT_SYSTEM=true If the actual code doesn't violate the 12 Factor App principles, there should be no problems with these runtimes working in parallel: https://12factor.net/ https://12factor.net/ (e.g. storing data in memory vs in something external like Redis, or using the file system for storage vs something like S3) > And to run it locally you need access to dev versions of all of them. With the above, that's no longer necessary. Even in the more traditional monolithic profiles without explicit feature flags at work, i still have different run profiles. Do i want to connect to a live data source and work with some of the test data on the shared dev server? I can probably do that. Do i want to just mock the functionality instead and use some customizable data generation logic for testing? Maybe a local database instance that's running in a container so i don't have to deal with the VPN slowness? Or maybe switch between a local service that i have running locally and another one on the dev server, to see whether they differ in any way? All of that is easily possible nowadays. > And when there’s a security vulnerability in your comment system your tape library gets wiped. Unless the code for the comment system isn't loaded, because the functionality isn't enabled. This last bit is where i think everything falls apart. Too many frameworks out there are okay with "magic" - taking away control over how your code and its dependencies are initialized, oftentimes doing so dynamically with overcomplicated logic (such as DI in the Spring framework in Java), vs the startup of your application's threads being a matter of a long list of features and their corresponding feature flag/configuration checks in your programming language of choice. Personally, i feel that in that particular regard, we'd benefit more from a lack of reflection, DSLs, configuration in XML/YAML etc., at least when you're trying to replace writing code in your actual programming language with those, as opposed to using any of them as simple key-value stores for your code to process.
    - 5y ago
  - Retric 5y ago
    > But all those data sources are connected to from the same runtime, right? Not always directly, often a modern wrapper is setup around a legacy system that was never designed for network access. This can easily mean two different build systems etc, but people argue about what is and isn’t a monolith at that point. Nobody counts the database or OS as separate systems in these breakdowns so IMO the terms are somewhat flexible. Plenty of stories go “In the beginning someone built a spreadsheet … shell script … and the great beast was hidden behind a service. Woe be unto thee who dare dare disturb his slumber.”
zemo 5y ago
that's not at all accurate of any of the monoliths I've worked on. This in particular describes exactly zero of them: - one shared database Usually there's one data access interface, but behind that interface there are multiple databases. This characterization doesn't even cover the most common of upgrades to data storage in monoliths: adding a caching layer to an existing database layer.
- jameshart 5y ago
  Okay, great. But you get that ten shared databases behind a shared caching layer isn't any better right? It's still all shared dependencies.
phs318u 5y ago
I'd like to challenge one part of your comment - that microservices break up data on module boundaries. Yes, they encapsulate the data. However, the issue that causes spaghettification (whether internal to some mega monolith, across modules, or between microservices), is the semantic coupling related to needing to understand data models. Dependency hell arises when we need to share an agreed understanding about something across boundaries. When that agreed understanding has to change - microservices won't necessarily make your life easier. This is not a screed against microservices. Just calling out that within a "domain of understanding", semantic coupling is pretty a fact of life.
addicted 5y ago
.NET Remoting, from 2002, was expressly designed to allow objects to be created either locally or on a different machine altogether. I’m sure Java also had something very similar. Monolith frameworks we’re always designed to be distributed. The reason distributed code was not popular was because the hardware at the time did not justify it. Further, treating hardware as cattle and not pets was not easy or possible because of the lack of a variety of technologies such as better devops tools, better and faster compilers, containerization, etc.

Retric 5y ago

Monoliths don’t actually look like that at scale. For example you can easily have multiple different data stores for different reasons, including multiple different kinds of databases. Here’s this tiny little internal relational database used internally, and there’s the giant tape library that’s archiving all this scientific data we actually care about. Here’s the hard real time system, and over there’s the billing data etc etc. The value of a monolith is it looks like a single thing from outside that does something comprehensible, internally it still needs to actually work.

jameshart 5y ago
But all those data sources are connected to from the same runtime, right? And to run it locally you need access to dev versions of all of them. And when there’s a security vulnerability in your comment system your tape library gets wiped.
- jacinda 5y ago
  > But all those data sources are connected to from the same runtime, right? Yes, this is an accurate assessment from what I've seen. > And to run it locally you need access to dev versions of all of them. In my experience, no. If the runtime never needs to access it because you're only doing development related to datastore A, it shouldn't fall over just because you haven't configured datastore B. Lots of easy ways to either skip this in the runtime or have a mocked interface. > And when there’s a security vulnerability in your comment system your tape library gets wiped. This one really depends but I think can be an accurate criticism of many systems. It's most true, I think, when you're at an in-between scale where you're big enough to be a target but haven't yet gotten big enough to afford more dedicated security testing at an application code level.
- KronisLV 5y ago
  This actually feels like a good example of the modularity that i talked about and feature flags. Of course, in some projects, it's not what one would call a new architecture (like in my blog post), but rather just careful usage of feature flags. > But all those data sources are connected to from the same runtime, right? Surely you could have multiple instances of your monolithic app: # Runs internally app_instance_1_admin_interface: environment: FEATURE_ENABLE_ADMIN_INTERFACE=true # Runs interally app_instance_2_tape_backup_job: environment: FEATURE_ENABLE_TAPE_BACKUP_JOB=true # Exposed externally through LB app_instance_3_comment_system: environment: FEATURE_ENABLE_COMMENT_SYSTEM=true If the actual code doesn't violate the 12 Factor App principles, there should be no problems with these runtimes working in parallel: https://12factor.net/ https://12factor.net/ (e.g. storing data in memory vs in something external like Redis, or using the file system for storage vs something like S3) > And to run it locally you need access to dev versions of all of them. With the above, that's no longer necessary. Even in the more traditional monolithic profiles without explicit feature flags at work, i still have different run profiles. Do i want to connect to a live data source and work with some of the test data on the shared dev server? I can probably do that. Do i want to just mock the functionality instead and use some customizable data generation logic for testing? Maybe a local database instance that's running in a container so i don't have to deal with the VPN slowness? Or maybe switch between a local service that i have running locally and another one on the dev server, to see whether they differ in any way? All of that is easily possible nowadays. > And when there’s a security vulnerability in your comment system your tape library gets wiped. Unless the code for the comment system isn't loaded, because the functionality isn't enabled. This last bit is where i think everything falls apart. Too many frameworks out there are okay with "magic" - taking away control over how your code and its dependencies are initialized, oftentimes doing so dynamically with overcomplicated logic (such as DI in the Spring framework in Java), vs the startup of your application's threads being a matter of a long list of features and their corresponding feature flag/configuration checks in your programming language of choice. Personally, i feel that in that particular regard, we'd benefit more from a lack of reflection, DSLs, configuration in XML/YAML etc., at least when you're trying to replace writing code in your actual programming language with those, as opposed to using any of them as simple key-value stores for your code to process.
  - 5y ago
- Retric 5y ago
  > But all those data sources are connected to from the same runtime, right? Not always directly, often a modern wrapper is setup around a legacy system that was never designed for network access. This can easily mean two different build systems etc, but people argue about what is and isn’t a monolith at that point. Nobody counts the database or OS as separate systems in these breakdowns so IMO the terms are somewhat flexible. Plenty of stories go “In the beginning someone built a spreadsheet … shell script … and the great beast was hidden behind a service. Woe be unto thee who dare dare disturb his slumber.”

zemo 5y ago

that's not at all accurate of any of the monoliths I've worked on. This in particular describes exactly zero of them: - one shared database Usually there's one data access interface, but behind that interface there are multiple databases. This characterization doesn't even cover the most common of upgrades to data storage in monoliths: adding a caching layer to an existing database layer.

jameshart 5y ago
Okay, great. But you get that ten shared databases behind a shared caching layer isn't any better right? It's still all shared dependencies.

phs318u 5y ago

I'd like to challenge one part of your comment - that microservices break up data on module boundaries. Yes, they encapsulate the data. However, the issue that causes spaghettification (whether internal to some mega monolith, across modules, or between microservices), is the semantic coupling related to needing to understand data models. Dependency hell arises when we need to share an agreed understanding about something across boundaries. When that agreed understanding has to change - microservices won't necessarily make your life easier. This is not a screed against microservices. Just calling out that within a "domain of understanding", semantic coupling is pretty a fact of life.

addicted 5y ago

.NET Remoting, from 2002, was expressly designed to allow objects to be created either locally or on a different machine altogether. I’m sure Java also had something very similar. Monolith frameworks we’re always designed to be distributed. The reason distributed code was not popular was because the hardware at the time did not justify it. Further, treating hardware as cattle and not pets was not easy or possible because of the lack of a variety of technologies such as better devops tools, better and faster compilers, containerization, etc.