9 ms·

This article absolutely nails it. Finally, recognition that microservices are a technical tool for solving a people and organizational problem. We need to under

This article absolutely nails it. Finally, recognition that microservices are a technical tool for solving a people and organizational problem. We need to understand that a lot of "new" technology paradigms (especially those coming down from FAANG or other large organizations) are often designed to solve the organizational problems of operating at scale, not to provide some kind of technical panacea we should all aspire to built towards.

burade 6y ago
People are godamn hopeless. I just saw a guy trying to argue that writing functional-style Java is the "new" way to write Java, and that not using functional interfaces means you're writing "old" style code.
- akmarinov 6y ago
  I don’t know about Java, but we’re seeing a shift to functional in the mobile space, where non functional code is definitely “old” code. In Swift with Combine and in Kotlin with their thing.
  - burade 6y ago
    "Old" in what sense though? In the style/fashion sense?
    - akmarinov 6y ago
      In the “writing non-functional code in 2 years will be the same as writing Objective-C today” sense.
    - rualca 6y ago
      > "Old" in what sense though? In the style/fashion sense? If you take the time to look into it, you'll discover that the functional style is only a change in the "fashion sense" to those who are totally oblivious to their advantages. I get how the pedantic take on monads turns people away from the functional side of programming, but you'd be hard pressed to find anything to criticize how returning either/result monads from promises is not a huge improvement over the boilerplate-rich/pure OO approach to Java.
- Animats 6y ago
  I feel guilty when I write a FOR statement in Rust.
  - Spartan-S63 6y ago
    Me too. Mostly because it’s a smell to me that I’m mutating some internal state. I try to avoid that as much as possible because it quickly becomes soup.
  - refactor_master 6y ago
    I feel guilty when my C# method isn’t immediately returning a LINQ expression.
- mumblemumble 6y ago
  That seems like an unnecessarily confrontational way to put it. What I would say is that, from a 10km perspective, functional interfaces are just where the Interface Segregation Principle takes you when you really lean into it, and that dependency injection can be thought of as just a convenient way to do partial application in bulk, and that CQRS encourages you to create an ever-wider separation between your commands and your queries, and that, in general, once you get far along where clean object-oriented design wants to lead you, the whole functional vs OO debate often starts to feel like it's quibbling about syntax as much as anything else.
- coding123 6y ago
  People are still using Java?
  - maya24 6y ago
    Yes Java is uqititous and it's not going away for 30 years at least. See Cobol. Java also has had significant improvements in the language so that there is less incentive to use other JVM languages like kotlin and it's fully interoperable with heartland code bases as far as I know
    - gnat 6y ago
      Forgive my ignorance: what's a "heartland" code base?
  - cmdshiftf4 6y ago
    >People are still using Java? C'mon, you've been around here long enough to know better than to be making such comments https://insights.stackoverflow.com/survey/2020#most-popular-technologies https://insights.stackoverflow.com/survey/2020#most-popular-... https://octoverse.github.com/ https://octoverse.github.com/
  - eitland 6y ago
    Whenever possible, yes. Sane language. Fantastic tooling. Huge ecosystem. Backwards and forwards compatible like few other things.
  - imtringued 6y ago
    The number of flaws that make Java inferior to other JVM languages is surprisingly small. By far the worst parts are excessively verbose "Beans", nullpointer by default, the JEE ecosystem (there are good alternatives) and the high RAM consumption (a JVM flaw). Honestly 80% of the value I derive from using a different JVM language come from avoiding NPEs, getters and setters. The remaining 20% can be very useful but they are certainly not essential nor can they be considered mandatory.
  - rualca 6y ago
    > People are still using Java? Yes, pretty much the whole world is using Java. Some FAANGs use it as basically their default software stack, and at most have introduced some Kotlin along the way. The world doesn't revolve around flavor of the month tech stacks.
- ConcernedCoder 6y ago
  The contortions I see used day-to-day to write code in the latest/greatest pardigm du-jour is criminal... I routinely have to revisit "functional masterpieces" of "easy to grok" code, and completely re-write to minimize CPU and/or memory consumption.
- lmm 6y ago
  > I just saw a guy trying to argue that writing functional-style Java is the "new" way to write Java, and that not using functional interfaces means you're writing "old" style code. Sounds right to me. (Of course not having first-class functions was just as bad 20 years ago, but fewer people had realised it back then).
jzoch 6y ago
I would say 99% of all articles on this site and r/programming on reddit have someone say exactly what you have - that microservices are an organizational tool. At this point your view is not an unpopular one. However, microservices can also serve actual technical purposes too. But the nuances of accepting two viewpoints often placed in juxtaposition to one another is not internet friendly. Microservices, service oriented architecture, whatever you call it depends on your level of cynicism i suppose (or optimism?).
- eightysixfour 6y ago
  I agree, I don't think my view is unusual or controversial, which is why it surprises me that the writers of the blog posts that get submitted to here or on r/programming rarely acknowledge both the technical and organizational aspects. Just yesterday there was the article "Back to the '70s with Serverless" which compared smalltalk and its fast feedback loops to the complexity of cloud and serverless computing and argued it was about good marketing. So I will keep commenting that it isn't just about technical issues and it isn't just about organizational ones, and you must look at both to really understand what is going on. But I probably did get a little too excited that a technical post acknowledged and made it an important point in their article.
- rualca 6y ago
  > I would say 99% of all articles on this site and r/programming on reddit have someone say exactly what you have - that microservices are an organizational tool. At this point your view is not an unpopular one. Microservices have been from the start an organizational tool, with reliability and the ability to scale horizontally to avoid constraints of vertical scaling trailing at second place. The rationale is that the first bottleneck that is hit by a growing organization is developer's throughput (i.e., the ability to deploy bugfixes and features without hitting blockers due to multiple teams being affected by a changeset). After that point, a service has to grow a tad more until reaching a point where the requests bounded to a subset of features justifies peeling them out to independent services.
humanrebar 6y ago
> ...microservices are a technical tool for solving a people and organizational problem They're also available to solve technical problems. For instance, it's hard to run some python3.5 and some python3.9 in a python monolith. A monolith must choose one python version and cut over en masse at some point. Microservices allow more gradual adoption (in production, not just in test suites!) of low level technology changes.
- danielheath 6y ago
  Right, but you can also eg run both versions of python on different machines and switch between them at the load balancer layer. That also lets you eg quickly roll back the upgrade from a single area. You can do all these things either way. The question is which way suits your tools and organisational structure.
  - rualca 6y ago
    > Right, but you can also eg run both versions of python on different machines and switch between them at the load balancer layer. That sounds to me like you are complementing the downsides of running a monolith with the downsides of operating a distributed system, without any noticeable upside.
    - danielheath 6y ago
      I should clarify; that technique doesn’t work if there are calls between systems on different versions unless they are tested on both. I wouldn’t run a system where the two servers call one another. This is a technique for reducing risk via toggles at the load balancer. The reduction is achieved by making it possible to deploy smaller changes to users, and by reducing the latency of rollback. These are only useful if you have the ability to introspect the system state in production and confirm whether a new version is working correctly.
      - rualca 6y ago
        I still fail to see the point of your approach. It sounds like you're referring to blue/green deployments without using it's name, for some reason, and while failing to present any case of why a monolith provides an advantage. You're just showing downsides without any upside as a tradeoff. I mean, with microservices you can also do blue/green deployments, and they are not all-in like monoliths. Each deployment only covers a subset of features that can gradually be rolled in and out with the only risk of causing partial failures.
drewcoo 6y ago
I think you missed part of this, from the article (emphasis mine): > Microservices Solve >Both< Technical and People Problems
- eightysixfour 6y ago
  I'd love some additional examples of technical problems microservices solve that are unrelated to scaling the organization. I've mainly come across the occasional one-off where a different language is significantly better suited to the problem at hand, so that has been broken out as its own service, and there's another one here in the comments about migrating a python application between versions (I could argue the semantics of microservice here, but I'll roll with it), but I have not come across many where a microservice was the "right" solution to a purely technical problem.
  - felixhuttmann 6y ago
    Examples: 1) Long-living connections. One part of your application offers large file downloads, so that your users sometimes take significant amount of time to download, and the error rate shall be low. Think people doing `curl -L https://github.com/.../some-commit-hash.zip https://github.com/.../some-commit-hash.zip` in CI. I'd guess this is not served by github's ruby monolith. Or you use websockets. Redeployments typically stop all running tcp connections. Splitting this part off allows you to redeploy the main application frequently without disrupting websockets or downloads. 2) Reduce startup time. For some languages/ecosystems, startup time is significant and scales with the size of the codebase. For example, a typical java enterpise app like keycloak has half a million lines of code and takes about 1 minute only for startup. This is even more relevant when running things in AWS Lambda or google cloud run, and can also be relevant for integration tests. Having several deployables each handling a subset of the functionality may give you better cold start times than having one that contains all code. 3) Resiliency toward resource exhaustion. If two functionalities are served in the same process or VM, and one of them * has a memory leak * uses the connection pool to the database inefficiently and thereby clogs it up * has an endpoint that is overloaded by a misbehaving client then the other functionality is also affected, which can be avoided by putting them into separate processes/containers/VMs. Splitting services allows to reduce the effort spent on resource hygiene and rate limiting. 4) Binary size. It is often convenient to compile static info or asset-like things into the application, think geoinformation on timezones. This bloats the binary, splitting that part off into an independent deployable can give you a much smaller binary for the main application.

burade 6y ago

People are godamn hopeless. I just saw a guy trying to argue that writing functional-style Java is the "new" way to write Java, and that not using functional interfaces means you're writing "old" style code.

akmarinov 6y ago
I don’t know about Java, but we’re seeing a shift to functional in the mobile space, where non functional code is definitely “old” code. In Swift with Combine and in Kotlin with their thing.
- burade 6y ago
  "Old" in what sense though? In the style/fashion sense?
  - akmarinov 6y ago
    In the “writing non-functional code in 2 years will be the same as writing Objective-C today” sense.
  - rualca 6y ago
    > "Old" in what sense though? In the style/fashion sense? If you take the time to look into it, you'll discover that the functional style is only a change in the "fashion sense" to those who are totally oblivious to their advantages. I get how the pedantic take on monads turns people away from the functional side of programming, but you'd be hard pressed to find anything to criticize how returning either/result monads from promises is not a huge improvement over the boilerplate-rich/pure OO approach to Java.
Animats 6y ago
I feel guilty when I write a FOR statement in Rust.
- Spartan-S63 6y ago
  Me too. Mostly because it’s a smell to me that I’m mutating some internal state. I try to avoid that as much as possible because it quickly becomes soup.
- refactor_master 6y ago
  I feel guilty when my C# method isn’t immediately returning a LINQ expression.
mumblemumble 6y ago
That seems like an unnecessarily confrontational way to put it. What I would say is that, from a 10km perspective, functional interfaces are just where the Interface Segregation Principle takes you when you really lean into it, and that dependency injection can be thought of as just a convenient way to do partial application in bulk, and that CQRS encourages you to create an ever-wider separation between your commands and your queries, and that, in general, once you get far along where clean object-oriented design wants to lead you, the whole functional vs OO debate often starts to feel like it's quibbling about syntax as much as anything else.
coding123 6y ago
People are still using Java?
- maya24 6y ago
  Yes Java is uqititous and it's not going away for 30 years at least. See Cobol. Java also has had significant improvements in the language so that there is less incentive to use other JVM languages like kotlin and it's fully interoperable with heartland code bases as far as I know
  - gnat 6y ago
    Forgive my ignorance: what's a "heartland" code base?
- cmdshiftf4 6y ago
  >People are still using Java? C'mon, you've been around here long enough to know better than to be making such comments https://insights.stackoverflow.com/survey/2020#most-popular-technologies https://insights.stackoverflow.com/survey/2020#most-popular-... https://octoverse.github.com/ https://octoverse.github.com/
- eitland 6y ago
  Whenever possible, yes. Sane language. Fantastic tooling. Huge ecosystem. Backwards and forwards compatible like few other things.
- imtringued 6y ago
  The number of flaws that make Java inferior to other JVM languages is surprisingly small. By far the worst parts are excessively verbose "Beans", nullpointer by default, the JEE ecosystem (there are good alternatives) and the high RAM consumption (a JVM flaw). Honestly 80% of the value I derive from using a different JVM language come from avoiding NPEs, getters and setters. The remaining 20% can be very useful but they are certainly not essential nor can they be considered mandatory.
- rualca 6y ago
  > People are still using Java? Yes, pretty much the whole world is using Java. Some FAANGs use it as basically their default software stack, and at most have introduced some Kotlin along the way. The world doesn't revolve around flavor of the month tech stacks.
ConcernedCoder 6y ago
The contortions I see used day-to-day to write code in the latest/greatest pardigm du-jour is criminal... I routinely have to revisit "functional masterpieces" of "easy to grok" code, and completely re-write to minimize CPU and/or memory consumption.
lmm 6y ago
> I just saw a guy trying to argue that writing functional-style Java is the "new" way to write Java, and that not using functional interfaces means you're writing "old" style code. Sounds right to me. (Of course not having first-class functions was just as bad 20 years ago, but fewer people had realised it back then).

jzoch 6y ago

I would say 99% of all articles on this site and r/programming on reddit have someone say exactly what you have - that microservices are an organizational tool. At this point your view is not an unpopular one. However, microservices can also serve actual technical purposes too. But the nuances of accepting two viewpoints often placed in juxtaposition to one another is not internet friendly. Microservices, service oriented architecture, whatever you call it depends on your level of cynicism i suppose (or optimism?).

eightysixfour 6y ago
I agree, I don't think my view is unusual or controversial, which is why it surprises me that the writers of the blog posts that get submitted to here or on r/programming rarely acknowledge both the technical and organizational aspects. Just yesterday there was the article "Back to the '70s with Serverless" which compared smalltalk and its fast feedback loops to the complexity of cloud and serverless computing and argued it was about good marketing. So I will keep commenting that it isn't just about technical issues and it isn't just about organizational ones, and you must look at both to really understand what is going on. But I probably did get a little too excited that a technical post acknowledged and made it an important point in their article.
rualca 6y ago
> I would say 99% of all articles on this site and r/programming on reddit have someone say exactly what you have - that microservices are an organizational tool. At this point your view is not an unpopular one. Microservices have been from the start an organizational tool, with reliability and the ability to scale horizontally to avoid constraints of vertical scaling trailing at second place. The rationale is that the first bottleneck that is hit by a growing organization is developer's throughput (i.e., the ability to deploy bugfixes and features without hitting blockers due to multiple teams being affected by a changeset). After that point, a service has to grow a tad more until reaching a point where the requests bounded to a subset of features justifies peeling them out to independent services.

humanrebar 6y ago

> ...microservices are a technical tool for solving a people and organizational problem They're also available to solve technical problems. For instance, it's hard to run some python3.5 and some python3.9 in a python monolith. A monolith must choose one python version and cut over en masse at some point. Microservices allow more gradual adoption (in production, not just in test suites!) of low level technology changes.

danielheath 6y ago
Right, but you can also eg run both versions of python on different machines and switch between them at the load balancer layer. That also lets you eg quickly roll back the upgrade from a single area. You can do all these things either way. The question is which way suits your tools and organisational structure.
- rualca 6y ago
  > Right, but you can also eg run both versions of python on different machines and switch between them at the load balancer layer. That sounds to me like you are complementing the downsides of running a monolith with the downsides of operating a distributed system, without any noticeable upside.
  - danielheath 6y ago
    I should clarify; that technique doesn’t work if there are calls between systems on different versions unless they are tested on both. I wouldn’t run a system where the two servers call one another. This is a technique for reducing risk via toggles at the load balancer. The reduction is achieved by making it possible to deploy smaller changes to users, and by reducing the latency of rollback. These are only useful if you have the ability to introspect the system state in production and confirm whether a new version is working correctly.
    - rualca 6y ago
      I still fail to see the point of your approach. It sounds like you're referring to blue/green deployments without using it's name, for some reason, and while failing to present any case of why a monolith provides an advantage. You're just showing downsides without any upside as a tradeoff. I mean, with microservices you can also do blue/green deployments, and they are not all-in like monoliths. Each deployment only covers a subset of features that can gradually be rolled in and out with the only risk of causing partial failures.

drewcoo 6y ago

I think you missed part of this, from the article (emphasis mine): > Microservices Solve >Both< Technical and People Problems

eightysixfour 6y ago
I'd love some additional examples of technical problems microservices solve that are unrelated to scaling the organization. I've mainly come across the occasional one-off where a different language is significantly better suited to the problem at hand, so that has been broken out as its own service, and there's another one here in the comments about migrating a python application between versions (I could argue the semantics of microservice here, but I'll roll with it), but I have not come across many where a microservice was the "right" solution to a purely technical problem.
- felixhuttmann 6y ago
  Examples: 1) Long-living connections. One part of your application offers large file downloads, so that your users sometimes take significant amount of time to download, and the error rate shall be low. Think people doing `curl -L https://github.com/.../some-commit-hash.zip https://github.com/.../some-commit-hash.zip` in CI. I'd guess this is not served by github's ruby monolith. Or you use websockets. Redeployments typically stop all running tcp connections. Splitting this part off allows you to redeploy the main application frequently without disrupting websockets or downloads. 2) Reduce startup time. For some languages/ecosystems, startup time is significant and scales with the size of the codebase. For example, a typical java enterpise app like keycloak has half a million lines of code and takes about 1 minute only for startup. This is even more relevant when running things in AWS Lambda or google cloud run, and can also be relevant for integration tests. Having several deployables each handling a subset of the functionality may give you better cold start times than having one that contains all code. 3) Resiliency toward resource exhaustion. If two functionalities are served in the same process or VM, and one of them * has a memory leak * uses the connection pool to the database inefficiently and thereby clogs it up * has an endpoint that is overloaded by a misbehaving client then the other functionality is also affected, which can be avoided by putting them into separate processes/containers/VMs. Splitting services allows to reduce the effort spent on resource hygiene and rate limiting. 4) Binary size. It is often convenient to compile static info or asset-like things into the application, think geoinformation on timezones. This bloats the binary, splitting that part off into an independent deployable can give you a much smaller binary for the main application.