4 ms·

> Monolithic apps can have a service based architecture internally Not only that, but if you absolutely must (for example different scaling requirements), fork

> Monolithic apps can have a service based architecture internally Not only that, but if you absolutely must (for example different scaling requirements), forking out a service from a monolith and deploying it as microservice is relatively straightforward. Provided source code interdependencies have been maintained cleanly before, which can be done with support from tools.

tonyarkles 3y ago
I definitely agree. More than once I've taken a monolith and sliced out a small piece of it to run as a separate service. That's been a significantly less painful task than trying to aggregate multiple microservices into a less expensive monolith, especially when multiple microservices use the same underlying packages but different conflicting versions or different global configuration.
- j45 3y ago
  The interesting thing about doing this is how things kind of end back at n-tier architecture, where one can have abstractions between each layers of the cake to more easily swap in/out technologies as well.
  - tonyarkles 3y ago
    Yeah, definitely. In my experience, the trick is that without doing analysis up front, you don't know exactly what the n-tiers are going to look like. Jumping right to microservices right off the bat is putting a lot of extra overhead at the start of the project (defining HTTP or gRPC or whatever APIs, working out the boilerplate for each project, etc.) without knowing whether the boundaries are appropriate or whether a given component is likely to end up being a hotspot that will need independent scaling. When you start with a monolith that isn't just a ball of spaghetti (e.g. clear module boundaries), you don't have to put as much work into the whole big picture and it's easier to evolve the internal architecture of one larger service than N smaller services. And if you do discover that one piece of it is appropriate to split off (hotspot, reasonably transactional instead of interactive calling, etc), then you just replace the guts of that module with whatever RPC mechanism you're using and the rest of the application doesn't really need to care about it.
    - j45 3y ago
      Analysis is important, if we don't know what the problem is, or how to solve it, finding the problem is the first undertaking, and the architecture for it often expands greatly to me. I often end up viewing the start of apps without a problem to solve might benefit from being a dynamically generated interface set by from a combination of feature flags from subscription to a plan. That degree of flexibility can seem extreme, but until the patterns from the chaos don't emerge, it can be pretty tough. As a total aside - Is there/why isn't there a discourse forum for architecture folks to chat about things like this? This has been one of the most enjoyable threads I've been a part of in HN in recent memory.
      - tonyarkles 3y ago
        > As a total aside - Is there/why isn't there a discourse forum for architecture folks to chat about things like this? Occasionally I see good discussions on Twitter. I just tried to find a couple of names of people and sadly I can't seem to remember any of them. Sorry. Otherwise... the discourse generally seems to be "this is The One True Way of doing things and if you're not you should feel bad". And that's not helpful :)
gadflyinyoureye 3y ago
How do you work around DB transactions? For example, in many Spring apps the transaction is common across all DB calls for an HTTP request. Would you put @RequiresNew? Many data sources don’t support this for a singular DB.

tonyarkles 3y ago

I definitely agree. More than once I've taken a monolith and sliced out a small piece of it to run as a separate service. That's been a significantly less painful task than trying to aggregate multiple microservices into a less expensive monolith, especially when multiple microservices use the same underlying packages but different conflicting versions or different global configuration.

j45 3y ago
The interesting thing about doing this is how things kind of end back at n-tier architecture, where one can have abstractions between each layers of the cake to more easily swap in/out technologies as well.
- tonyarkles 3y ago
  Yeah, definitely. In my experience, the trick is that without doing analysis up front, you don't know exactly what the n-tiers are going to look like. Jumping right to microservices right off the bat is putting a lot of extra overhead at the start of the project (defining HTTP or gRPC or whatever APIs, working out the boilerplate for each project, etc.) without knowing whether the boundaries are appropriate or whether a given component is likely to end up being a hotspot that will need independent scaling. When you start with a monolith that isn't just a ball of spaghetti (e.g. clear module boundaries), you don't have to put as much work into the whole big picture and it's easier to evolve the internal architecture of one larger service than N smaller services. And if you do discover that one piece of it is appropriate to split off (hotspot, reasonably transactional instead of interactive calling, etc), then you just replace the guts of that module with whatever RPC mechanism you're using and the rest of the application doesn't really need to care about it.
  - j45 3y ago
    Analysis is important, if we don't know what the problem is, or how to solve it, finding the problem is the first undertaking, and the architecture for it often expands greatly to me. I often end up viewing the start of apps without a problem to solve might benefit from being a dynamically generated interface set by from a combination of feature flags from subscription to a plan. That degree of flexibility can seem extreme, but until the patterns from the chaos don't emerge, it can be pretty tough. As a total aside - Is there/why isn't there a discourse forum for architecture folks to chat about things like this? This has been one of the most enjoyable threads I've been a part of in HN in recent memory.
    - tonyarkles 3y ago
      > As a total aside - Is there/why isn't there a discourse forum for architecture folks to chat about things like this? Occasionally I see good discussions on Twitter. I just tried to find a couple of names of people and sadly I can't seem to remember any of them. Sorry. Otherwise... the discourse generally seems to be "this is The One True Way of doing things and if you're not you should feel bad". And that's not helpful :)

gadflyinyoureye 3y ago

How do you work around DB transactions? For example, in many Spring apps the transaction is common across all DB calls for an HTTP request. Would you put @RequiresNew? Many data sources don’t support this for a singular DB.