15 ms·

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. An

by sisve 4y ago

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request. Or maybe you are, because context matters and I'm wrong in your particular case. Could be. My advice would be to split your application up into enough pices so that; 1.your engineers feels like they have control over the code and are not afraid of doing changes. 2. if you get uptime issues. Get the heavy / unrealiable services over to new node. Don't let one service/endpoint take down other endpoints. Think and act according to the problems you have in front of you. Don't go extreme in any direction. Context context context

chucksta 4y ago
>Context matters so much. Well that point that just makes %90 of web articles moot.
avip 4y ago
Like any other well reasoned, balanced and pragmatic POV, the problem with your boring approach is you can’t wrap it in a clickbaitable blog and no flame war can emerge from it.
- hinkley 4y ago
  In no public debate do you get the participation of people who think everyone involved is a lunatic. We presume there are two extremes in any decision making process and ignore the third option, no matter how reasonable.
- username135 4y ago
  lol
- nullsense 4y ago
  It turns out the One Weird Trick is just considering the context.
jonhohle 4y ago
I agree completely. The current FAA outage is a good example of this. What if the system responsible for NOTAMs was the same system responsible for sending system outage messages. They weren’t so that status could be communicated while mitigation was done on a system with unrelated concerns. At the same time, a few person startup should probably focus on what allows them to deliver the fastest. I’ve seen that work with relatively monolithic systems and with SOA, tooling choice makes a huge impact.
- hinkley 4y ago
  We had a major cockup at work a few years ago caused by bad organizational choices and Conway’s Law. We had a disk array go sideways, which is when we learned that some dumb motherfucker had put our wiki on the same SAN with production traffic. You know, the wiki where you keep all your run books for solving production issues? Everyone was furious and that team lost some prestige that day. How dumb do you have to be?
  - francis-io 4y ago
    Seems a little harsh. We all overlook things like this. Things like storage are so reliable we expect them to always be available. When you lay it out like you did, it does sound silly.
    - namaria 4y ago
      Two is one and one is none. This is not hard. But it's costly. The main problem with security and reliability is that they are expensive. Those operating in high margins, highly specced spaces need to do it right or they lose. Everyone else is cargo culting, box-checking for stakeholders or selling snake oil. There is a fundamental tension between optimizing for cost and doing things right, and short term gains will always come at the cost of mounting operational risks.
      - hinkley 4y ago
        “mounting operational risks” is my main complaint with the “there is no maintenance” thread that was here the other day. Maintenance is looking at all of the probability < 10^-4 issues that are just waiting for you to roll the dice enough times to eventually lose to the birthday problem. Every day you’re lowering the odds that tomorrow will be the day everything burns, because doing nothing is just a waiting game.
naasking 4y ago
I think the article describes exactly this. Use modules to enforce domain boundaries within a program, and split into services where it makes sense.
SergeAx 4y ago
> Should you have absolutely everything in 1 system? As long as you physically able to do that - absolutely yes.
Kinrany 4y ago
An important part of programming as a discipline is coming up with things that work regardless of context.
- fndex 4y ago
  Could you give some non trivial examples of architectures or techniques in software engineering that work regardless of the context?
  - gwright 4y ago
    good naming Maybe that is not "architecture" or "technique" but is is definitely not trivial and is important in almost any context -- but also probably not what you were going for.
    - sophacles 4y ago
      Good naming is context dependent. ed: or rather what constitutes a good name is
  - Kinrany 4y ago
    Binary search works on git commits and on shelves with differently sized T-shirts equally well.
- sakjur 4y ago
  This sounds interesting, how do you mean? To me it seems like context is perhaps the key element that we should concern ourselves with to further the engineering or scientific aspect of programming. Let's say we're deciding between floating point arithmetics, fixed decimal numbers, or rational numbers. All three of which are very well-established and useful solutions to the problem of subdividing integers. We have some context already here, and we'll need to provide a bit more context to know which solution to choose. Would you agree with that?
  - Kinrany 4y ago
__MatrixMan__ 4y ago
You're right, and I think most engineers know it. The debate persists as a proxy for a separate debate: E > I want to reorganize this because it's ugly and hard to work with as it is M > I want you focusing on this list of features/bugs and not introducing risk by making changes for other reasons Something doesn't feel right about: E > I'm the expert, you have to take my word that this change is necessary So if depending on whether E wants to join or separate, they put on their I-hate/heart-microservices hat and rehash whichever side of the tired old debate serves them. People who agree or disagree dust off their I-hate/heart-microservices hats, and we go to town for a while. We're not actually arguing for micro vs macro, we're talking about the context specific details, we just dress it up in those terms because M is in this meeting and M isn't close enough to the code to keep up with a conversation about the details. If enough energy is not expended in this process, whoever lost the debate goes and writes a blog about why they were right. Except nobody will read a blog about their specific codebase, so it ends up being about whether they heart/hate microservices.
BSerhere 4y ago
[dead]
yowlingcat 4y ago
Agreed. I would add an extra thought around "Try to go monolith until things really breakdown" but you get at that in so far as the point where things breakdown is where either: a) engineers are afraid of or find making changes difficult b) uptime issues result in heavy endpoints/services taking down others To your point, microservices should be introduced expressly to solve those two problems, and not before.
tasuki 4y ago
> Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. I might think that, depending on the context. Are you a multinational with thousands of monkeys at thousands of typewriters? Of course you shouldn't have everything in one system! Are you a five person startup, out of which only three write code? Knowing nothing else, I'd suggest everything in one system.
- jgust 4y ago
  I think that's covered under "context".
ch_sm 4y ago
> enough pieces so that; 1. your engineers … are not afraid of doing changes. I don’t really understand that argument, and I don’t really feel safer making a change to a microservice inside a large system, as opposed to making a change to a monolith — the consequences of a mistake are equal in both cases (although harder to observe/debug in a microservice architecture) — am I missing something?
- tanseydavid 4y ago
  If you read Kent Beck's book Test-Driven-Development By Example you will find that a major theme is this idea of developer fear or reticence. From the Amazon book description: Quite simply, test-driven development is meant to eliminate fear in application development. While some fear is healthy (often viewed as a conscience that tells programmers to "be careful!"), the author believes that byproducts of fear include tentative, grumpy, and uncommunicative programmers who are unable to absorb constructive criticism.
- rudnevr 4y ago
  Thinking through the inter-service interface is costlier and more transparent than calling the function in the same monolyth. That said, interfaces between services are inherently better than function calls. Also, making mistake in microservice is more easily isolated, fixed and redeployed. Other than that, microservices are business entities, rather than just tech entities. They can be scoped, evaluated and managed on business level. After all, you can ask another team rewrite the specific microservice. You can't do that with monolyth. And the problem wouldn't be just buried in tech details and opinions.
JAlexoid 4y ago
> Should you have absolutely everything in 1 system. Yes, you should build your system initially like that. One team builds one system and splits it out as necessary.
- sisve 4y ago
  For your core service. I think you are right most of the time. But you are probably not talking about the website marketing wants to build. And you are maybe using S3 or similar for documents storage? And your logging system are probably not on the same machine? But if by "system" you mean the main API + SaaS website or similar yeah. Sounds reasonable. in reality we do so much more now. That I think some part of what was the monolith years ago is now just SaaS the company use. That the development department do not even need to know about.
  - JAlexoid 4y ago
    Using S3 to store and serve documents, RDBMS and Datadog for monitoring+logs - doesn't make a microservice architecture. That's quite typical "monolith", as the term monolith never means that literally everything is in the codebase.
    - sisve 4y ago
      I agree that I took it "a bit" far to make a point… that just ruined my case. I do think that in a monolith you try to do most things yourself. Take Auth for example. It's huge. And I think we more and more are excepting that even for a monolith we do not want to do that ourself. If you start from scratch and your spec say that they want OIDC and SAML then most ppl will look for a saas service to get help. Same with storing files, we would make use of S3 or similar. But if we go to pre 2010. I think most people would try to both of these themself. Im not saying that this is microservice at all, but I'm saying we are moving stuff that are commodity's out from the monolith compare to what we did 10-15 years ago. Because there are services that does a much better job for us. And that was part of my point with the original comment. That trying to keep everything in one place is probably not the right choices. Sorry for not being more precise on my previous reply.
Stranger43 4y ago
Insnt the problem that nobody have ever developed an complex system using modern programming languages where "engineers feels like they have control over the code and are not afraid of doing changes." And that trying to have it as a goal only results in the project getting fragmented in a messy ball of micro-components(services/classes/libraries) with complex inter dependencies that nobody feels like they have control over the code and are not afraid of doing changes to? It's almost as if there is no real solution to complexity that avoids having to deal directly with the complexity inherent to a problem domain, and that means developing documentation and testing that allows people to touch/change scary systems.
tetha 4y ago
Agreed. I very much like my workplaces approach atm, which I jokingly call medium-sized services, mostly. Due to acquisitions, we have 6 or 7 big messy monoliths and actually, 3-5 infrastructure stacks. This in turn means, we have something like 12 different user management systems (because each monolith contains a few layers of legacy user management, it'd be boring otherwise), 4-5 different file and image stores (some products just don't have one), 4-5 different search implementations. It's a bit of a messy zoo. Our path out of that mess is to either extract, or re-implement functionality common to the products in smaller scale, standalone services - for example so you end up with a centralized user management, or a centralized attachment system. And these things certainly aren't micro, user management does a bit of search, a bit of SAML, a lot of OIDC, some CRUD for users, groups and such. If you wanted to be silly, this could be 5-6 "micro-services". But realistically, why? We do gain advantages by having this in a smaller service - we can place a bit of extremely critical functionality in a small service and we can manage that service very, very gently. And we can reduce redundant efforts, even if migrations to this service takes some work. But what would some dedicated SAML-integration-spring-app improve, besides moving 1-2 tables into another database/schema?
- turtleyacht 4y ago
  From your advantages: > smaller service... extremely critical... manage... gently > reduce redundant efforts Versus > dedicated SAML-integration-spring-app What if the effort were spent automating the disparate systems to stay in sync? Granted, the data model reflects multiple systems, but each user could use their preferred "set of apps," and changes get reflected by some headless Windows container or browser.
hot_gril 4y ago
One decent rule of thumb is to have one service per 1-3 closely grouped SWEs, like Conway's Law, then likely split them up more to ensure no two services share a database.
Zaskoda 4y ago
When discussing turning our monolith into microservices at a previous job: My Boss: "I'm convinced this is the right architecture." Also my boss: "Now how do we break this app up?" He was certain we needed to shatter our monolith into lots of little pieces, but had no clear vision as to what those pieces would be. From my point of view, the "architecture" he was certain of wasn't an architecture at all. It was just a general notion of doing what he thought everyone else was doing without considering anything about our app. Total cargo cult mentality.
- __MatrixMan__ 4y ago
  Sounds like an org chart problem. The first piece to focus on is the piece that your team is responsible for. Less of a shattering of the monolith and more of a spore ejection.
UltraViolence 4y ago
Microservices are merely just another hype in the IT world. Everyone ran with it and now we're stuck with thousands of fragile and unmaintainable systems which will ruin companies in the coming decades.
hbrn 4y ago
> I really do not understand the debate on monoliths and microservice anymore. > Don't go extreme in any direction. Context context context That is exactly why debate occurs. All religions, be it microservices or TDD, are taking some good ideas to an extreme and removing context from the decision making process. Otherwise the term "microservices" wound never be invented: people were doing "services" since the dawn of time. But you can't create hype out of common sense, you have to go to the extremes.
- mmcnl 4y ago
  At this point I think microservices architectures don't exist. As if a "micro"service is a goal on its own. I think any sane organization strives for a healthy trade-off between manageable code and separation of concerns.
mananaysiempre 4y ago
If that’s indeed the most useful general thing that can be said about this question, then it means the microservices crowd has won, at least insofar as it deserved to win. The point is not that everything needs to be a micro-est possible service, the point is that we all now have applications built out of loosely-coupled services as a primitive in our reasoning toolbox. (In a world where microservices haven’t yet won, we think RPC is obviously always a good idea and build our web apps as ISAPI modules and AOLserver extensions.) I think very similar things when I hear Casey Muratori’s opinions on OOP[1], which he titled “getting rid of the OOP mindset” but I’d summarize as “absolutely do make an object or two if that fits your problem domain, but remember that it doesn’t have to and use your judgment”: that’s what OOP winning feels like, from the inside, once you’ve internalized it. Once people can look at a thing and think “you know what, that looks like an object”, OOP has won, even though people won’t always be right and not literally all the things are best modelled as objects. (In a world where OOP—or lexical scope—hasn’t yet won, we read papers about Actors, struggle to understand what the authors could possibly mean, and implement a small language in order to have a version of those ideas we can play with. The language ends up being called Scheme.) The same probably applies to structured programming, though it seems that structured programming deserved to win quite a bit more than the others, and though I don’t have easy access to pre-structured programming lore the same way I do to pre-OOP or pre-microservices lore. In hindsight, old, good, now-accepted reasoning frameworks always seem to consist entirely out of trivially right stuff on one hand and outrageously wrong stuff on the other. That’s entirely by design and doesn’t mean the ancients were stupid—this is culture working correctly and well. It means that you, who has before only ever been in contact with the consensus that emerged out of their bitter struggles, have such a deep and implicit knowledge of that consensus that the good points that were once revolutionary sound obvious to you. You’re only seeing the bad points because those are the ones that didn’t find their way into the culture. Scott Alexander’s metaphor of “philosophy in the water supply”[2,3,4] is the best explanation of this that I know. [1] https://youtu.be/GKYCA3UsmrU https://youtu.be/GKYCA3UsmrU [2] https://slatestarcodex.com/2019/01/08/book-review-the-structure-of-scientific-revolutions/ https://slatestarcodex.com/2019/01/08/book-review-the-struct... [3] https://slatestarcodex.com/2013/04/11/read-history-of-philosophy-backwards/ https://slatestarcodex.com/2013/04/11/read-history-of-philos... [4] https://slatestarcodex.com/2015/07/16/cbt-in-the-water-supply/ https://slatestarcodex.com/2015/07/16/cbt-in-the-water-suppl...
pantsforbirds 4y ago
I tend to split things up based on the resources required. We had a decent sized data pipeline that was entirely microservice and serverless and it was a real joy to work with. - Our NLP code lived in a service that ran on GPUs - our ingest service used a high ram, but relatively simple CPU service to do in-memory joins cheaply and efficiently - we had a bunch of specialized query services that were just direct requests to AWS services, or a light lambda wrapper around a call to a service. Coordinated things with airflow and it was very easy to maintain and scaling was pretty efficient since we just scaled the pieces that needed it without wasting money on unneeded compute.
- sisve 4y ago
  A great example on that context matters. Seems very reasonable to do.
herdcall 4y ago
Yeah, "it depends" is almost always the right answer but not a very useful one. The devil is in the details, and I don't see any issue in discussing the nuances so people can apply them to their own situation to make their own decision.
jredwards 4y ago
> My advice would be to split your application up into enough pices so that; > 1.your engineers feels like they have control over the code and are not afraid of doing changes. I'd add: split your team up into a similar number of pieces. Your application will come to resemble the shape of your teams, over time. Design your teams based on where you want the boundaries of your application to fall.

by sisve 4y ago

chucksta 4y ago

>Context matters so much. Well that point that just makes %90 of web articles moot.

avip 4y ago

Like any other well reasoned, balanced and pragmatic POV, the problem with your boring approach is you can’t wrap it in a clickbaitable blog and no flame war can emerge from it.

hinkley 4y ago
In no public debate do you get the participation of people who think everyone involved is a lunatic. We presume there are two extremes in any decision making process and ignore the third option, no matter how reasonable.
username135 4y ago
lol
nullsense 4y ago
It turns out the One Weird Trick is just considering the context.

jonhohle 4y ago

I agree completely. The current FAA outage is a good example of this. What if the system responsible for NOTAMs was the same system responsible for sending system outage messages. They weren’t so that status could be communicated while mitigation was done on a system with unrelated concerns. At the same time, a few person startup should probably focus on what allows them to deliver the fastest. I’ve seen that work with relatively monolithic systems and with SOA, tooling choice makes a huge impact.

hinkley 4y ago
We had a major cockup at work a few years ago caused by bad organizational choices and Conway’s Law. We had a disk array go sideways, which is when we learned that some dumb motherfucker had put our wiki on the same SAN with production traffic. You know, the wiki where you keep all your run books for solving production issues? Everyone was furious and that team lost some prestige that day. How dumb do you have to be?
- francis-io 4y ago
  Seems a little harsh. We all overlook things like this. Things like storage are so reliable we expect them to always be available. When you lay it out like you did, it does sound silly.
  - namaria 4y ago
    Two is one and one is none. This is not hard. But it's costly. The main problem with security and reliability is that they are expensive. Those operating in high margins, highly specced spaces need to do it right or they lose. Everyone else is cargo culting, box-checking for stakeholders or selling snake oil. There is a fundamental tension between optimizing for cost and doing things right, and short term gains will always come at the cost of mounting operational risks.
    - hinkley 4y ago
      “mounting operational risks” is my main complaint with the “there is no maintenance” thread that was here the other day. Maintenance is looking at all of the probability < 10^-4 issues that are just waiting for you to roll the dice enough times to eventually lose to the birthday problem. Every day you’re lowering the odds that tomorrow will be the day everything burns, because doing nothing is just a waiting game.

naasking 4y ago

I think the article describes exactly this. Use modules to enforce domain boundaries within a program, and split into services where it makes sense.

SergeAx 4y ago

> Should you have absolutely everything in 1 system? As long as you physically able to do that - absolutely yes.

Kinrany 4y ago

An important part of programming as a discipline is coming up with things that work regardless of context.

fndex 4y ago
Could you give some non trivial examples of architectures or techniques in software engineering that work regardless of the context?
- gwright 4y ago
  good naming Maybe that is not "architecture" or "technique" but is is definitely not trivial and is important in almost any context -- but also probably not what you were going for.
  - sophacles 4y ago
    Good naming is context dependent. ed: or rather what constitutes a good name is
- Kinrany 4y ago
  Binary search works on git commits and on shelves with differently sized T-shirts equally well.
sakjur 4y ago
This sounds interesting, how do you mean? To me it seems like context is perhaps the key element that we should concern ourselves with to further the engineering or scientific aspect of programming. Let's say we're deciding between floating point arithmetics, fixed decimal numbers, or rational numbers. All three of which are very well-established and useful solutions to the problem of subdividing integers. We have some context already here, and we'll need to provide a bit more context to know which solution to choose. Would you agree with that?
- Kinrany 4y ago

__MatrixMan__ 4y ago

You're right, and I think most engineers know it. The debate persists as a proxy for a separate debate: E > I want to reorganize this because it's ugly and hard to work with as it is M > I want you focusing on this list of features/bugs and not introducing risk by making changes for other reasons Something doesn't feel right about: E > I'm the expert, you have to take my word that this change is necessary So if depending on whether E wants to join or separate, they put on their I-hate/heart-microservices hat and rehash whichever side of the tired old debate serves them. People who agree or disagree dust off their I-hate/heart-microservices hats, and we go to town for a while. We're not actually arguing for micro vs macro, we're talking about the context specific details, we just dress it up in those terms because M is in this meeting and M isn't close enough to the code to keep up with a conversation about the details. If enough energy is not expended in this process, whoever lost the debate goes and writes a blog about why they were right. Except nobody will read a blog about their specific codebase, so it ends up being about whether they heart/hate microservices.

BSerhere 4y ago

[dead]

yowlingcat 4y ago

Agreed. I would add an extra thought around "Try to go monolith until things really breakdown" but you get at that in so far as the point where things breakdown is where either: a) engineers are afraid of or find making changes difficult b) uptime issues result in heavy endpoints/services taking down others To your point, microservices should be introduced expressly to solve those two problems, and not before.

tasuki 4y ago

> Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. I might think that, depending on the context. Are you a multinational with thousands of monkeys at thousands of typewriters? Of course you shouldn't have everything in one system! Are you a five person startup, out of which only three write code? Knowing nothing else, I'd suggest everything in one system.

jgust 4y ago
I think that's covered under "context".

ch_sm 4y ago

> enough pieces so that; 1. your engineers … are not afraid of doing changes. I don’t really understand that argument, and I don’t really feel safer making a change to a microservice inside a large system, as opposed to making a change to a monolith — the consequences of a mistake are equal in both cases (although harder to observe/debug in a microservice architecture) — am I missing something?

tanseydavid 4y ago
If you read Kent Beck's book Test-Driven-Development By Example you will find that a major theme is this idea of developer fear or reticence. From the Amazon book description: Quite simply, test-driven development is meant to eliminate fear in application development. While some fear is healthy (often viewed as a conscience that tells programmers to "be careful!"), the author believes that byproducts of fear include tentative, grumpy, and uncommunicative programmers who are unable to absorb constructive criticism.
rudnevr 4y ago
Thinking through the inter-service interface is costlier and more transparent than calling the function in the same monolyth. That said, interfaces between services are inherently better than function calls. Also, making mistake in microservice is more easily isolated, fixed and redeployed. Other than that, microservices are business entities, rather than just tech entities. They can be scoped, evaluated and managed on business level. After all, you can ask another team rewrite the specific microservice. You can't do that with monolyth. And the problem wouldn't be just buried in tech details and opinions.

JAlexoid 4y ago

> Should you have absolutely everything in 1 system. Yes, you should build your system initially like that. One team builds one system and splits it out as necessary.

sisve 4y ago
For your core service. I think you are right most of the time. But you are probably not talking about the website marketing wants to build. And you are maybe using S3 or similar for documents storage? And your logging system are probably not on the same machine? But if by "system" you mean the main API + SaaS website or similar yeah. Sounds reasonable. in reality we do so much more now. That I think some part of what was the monolith years ago is now just SaaS the company use. That the development department do not even need to know about.
- JAlexoid 4y ago
  Using S3 to store and serve documents, RDBMS and Datadog for monitoring+logs - doesn't make a microservice architecture. That's quite typical "monolith", as the term monolith never means that literally everything is in the codebase.
  - sisve 4y ago
    I agree that I took it "a bit" far to make a point… that just ruined my case. I do think that in a monolith you try to do most things yourself. Take Auth for example. It's huge. And I think we more and more are excepting that even for a monolith we do not want to do that ourself. If you start from scratch and your spec say that they want OIDC and SAML then most ppl will look for a saas service to get help. Same with storing files, we would make use of S3 or similar. But if we go to pre 2010. I think most people would try to both of these themself. Im not saying that this is microservice at all, but I'm saying we are moving stuff that are commodity's out from the monolith compare to what we did 10-15 years ago. Because there are services that does a much better job for us. And that was part of my point with the original comment. That trying to keep everything in one place is probably not the right choices. Sorry for not being more precise on my previous reply.

Stranger43 4y ago

Insnt the problem that nobody have ever developed an complex system using modern programming languages where "engineers feels like they have control over the code and are not afraid of doing changes." And that trying to have it as a goal only results in the project getting fragmented in a messy ball of micro-components(services/classes/libraries) with complex inter dependencies that nobody feels like they have control over the code and are not afraid of doing changes to? It's almost as if there is no real solution to complexity that avoids having to deal directly with the complexity inherent to a problem domain, and that means developing documentation and testing that allows people to touch/change scary systems.

tetha 4y ago

Agreed. I very much like my workplaces approach atm, which I jokingly call medium-sized services, mostly. Due to acquisitions, we have 6 or 7 big messy monoliths and actually, 3-5 infrastructure stacks. This in turn means, we have something like 12 different user management systems (because each monolith contains a few layers of legacy user management, it'd be boring otherwise), 4-5 different file and image stores (some products just don't have one), 4-5 different search implementations. It's a bit of a messy zoo. Our path out of that mess is to either extract, or re-implement functionality common to the products in smaller scale, standalone services - for example so you end up with a centralized user management, or a centralized attachment system. And these things certainly aren't micro, user management does a bit of search, a bit of SAML, a lot of OIDC, some CRUD for users, groups and such. If you wanted to be silly, this could be 5-6 "micro-services". But realistically, why? We do gain advantages by having this in a smaller service - we can place a bit of extremely critical functionality in a small service and we can manage that service very, very gently. And we can reduce redundant efforts, even if migrations to this service takes some work. But what would some dedicated SAML-integration-spring-app improve, besides moving 1-2 tables into another database/schema?

turtleyacht 4y ago
From your advantages: > smaller service... extremely critical... manage... gently > reduce redundant efforts Versus > dedicated SAML-integration-spring-app What if the effort were spent automating the disparate systems to stay in sync? Granted, the data model reflects multiple systems, but each user could use their preferred "set of apps," and changes get reflected by some headless Windows container or browser.

hot_gril 4y ago

One decent rule of thumb is to have one service per 1-3 closely grouped SWEs, like Conway's Law, then likely split them up more to ensure no two services share a database.

Zaskoda 4y ago

When discussing turning our monolith into microservices at a previous job: My Boss: "I'm convinced this is the right architecture." Also my boss: "Now how do we break this app up?" He was certain we needed to shatter our monolith into lots of little pieces, but had no clear vision as to what those pieces would be. From my point of view, the "architecture" he was certain of wasn't an architecture at all. It was just a general notion of doing what he thought everyone else was doing without considering anything about our app. Total cargo cult mentality.

__MatrixMan__ 4y ago
Sounds like an org chart problem. The first piece to focus on is the piece that your team is responsible for. Less of a shattering of the monolith and more of a spore ejection.

UltraViolence 4y ago

Microservices are merely just another hype in the IT world. Everyone ran with it and now we're stuck with thousands of fragile and unmaintainable systems which will ruin companies in the coming decades.

hbrn 4y ago

> I really do not understand the debate on monoliths and microservice anymore. > Don't go extreme in any direction. Context context context That is exactly why debate occurs. All religions, be it microservices or TDD, are taking some good ideas to an extreme and removing context from the decision making process. Otherwise the term "microservices" wound never be invented: people were doing "services" since the dawn of time. But you can't create hype out of common sense, you have to go to the extremes.

mmcnl 4y ago
At this point I think microservices architectures don't exist. As if a "micro"service is a goal on its own. I think any sane organization strives for a healthy trade-off between manageable code and separation of concerns.

mananaysiempre 4y ago

If that’s indeed the most useful general thing that can be said about this question, then it means the microservices crowd has won, at least insofar as it deserved to win. The point is not that everything needs to be a micro-est possible service, the point is that we all now have applications built out of loosely-coupled services as a primitive in our reasoning toolbox. (In a world where microservices haven’t yet won, we think RPC is obviously always a good idea and build our web apps as ISAPI modules and AOLserver extensions.) I think very similar things when I hear Casey Muratori’s opinions on OOP[1], which he titled “getting rid of the OOP mindset” but I’d summarize as “absolutely do make an object or two if that fits your problem domain, but remember that it doesn’t have to and use your judgment”: that’s what OOP winning feels like, from the inside, once you’ve internalized it. Once people can look at a thing and think “you know what, that looks like an object”, OOP has won, even though people won’t always be right and not literally all the things are best modelled as objects. (In a world where OOP—or lexical scope—hasn’t yet won, we read papers about Actors, struggle to understand what the authors could possibly mean, and implement a small language in order to have a version of those ideas we can play with. The language ends up being called Scheme.) The same probably applies to structured programming, though it seems that structured programming deserved to win quite a bit more than the others, and though I don’t have easy access to pre-structured programming lore the same way I do to pre-OOP or pre-microservices lore. In hindsight, old, good, now-accepted reasoning frameworks always seem to consist entirely out of trivially right stuff on one hand and outrageously wrong stuff on the other. That’s entirely by design and doesn’t mean the ancients were stupid—this is culture working correctly and well. It means that you, who has before only ever been in contact with the consensus that emerged out of their bitter struggles, have such a deep and implicit knowledge of that consensus that the good points that were once revolutionary sound obvious to you. You’re only seeing the bad points because those are the ones that didn’t find their way into the culture. Scott Alexander’s metaphor of “philosophy in the water supply”[2,3,4] is the best explanation of this that I know. [1] https://youtu.be/GKYCA3UsmrU https://youtu.be/GKYCA3UsmrU [2] https://slatestarcodex.com/2019/01/08/book-review-the-structure-of-scientific-revolutions/ https://slatestarcodex.com/2019/01/08/book-review-the-struct... [3] https://slatestarcodex.com/2013/04/11/read-history-of-philosophy-backwards/ https://slatestarcodex.com/2013/04/11/read-history-of-philos... [4] https://slatestarcodex.com/2015/07/16/cbt-in-the-water-supply/ https://slatestarcodex.com/2015/07/16/cbt-in-the-water-suppl...

pantsforbirds 4y ago

I tend to split things up based on the resources required. We had a decent sized data pipeline that was entirely microservice and serverless and it was a real joy to work with. - Our NLP code lived in a service that ran on GPUs - our ingest service used a high ram, but relatively simple CPU service to do in-memory joins cheaply and efficiently - we had a bunch of specialized query services that were just direct requests to AWS services, or a light lambda wrapper around a call to a service. Coordinated things with airflow and it was very easy to maintain and scaling was pretty efficient since we just scaled the pieces that needed it without wasting money on unneeded compute.

sisve 4y ago
A great example on that context matters. Seems very reasonable to do.

herdcall 4y ago

Yeah, "it depends" is almost always the right answer but not a very useful one. The devil is in the details, and I don't see any issue in discussing the nuances so people can apply them to their own situation to make their own decision.

jredwards 4y ago

> My advice would be to split your application up into enough pices so that; > 1.your engineers feels like they have control over the code and are not afraid of doing changes. I'd add: split your team up into a similar number of pieces. Your application will come to resemble the shape of your teams, over time. Design your teams based on where you want the boundaries of your application to fall.