14 ms·

My observation is that much of industry does not care about any of these technical or security issues. In theory microservices are technical artifacts, but wha

My observation is that much of industry does not care about any of these technical or security issues. In theory microservices are technical artifacts, but what they tend to be are cultural artifacts. Microservice adoption is often driven by cargo culting, or (better) a considered decision to work around a lack of organisational cohesion. What microservices let you do is ship your org chart directly, and also map back from some functionality to an owning team. You know who to page when there's a problem and it's easier to tell who is late delivering and whose code is slow. In cultures with "lax" technical leadership (aka no everyone uses same thing mandate, I'm not judging) it lets teams use their favourite tools, for better or worse. Other org related things are the ability to have independent (per team) release schedules. Separable billing. Ability to get metrics on performance, cost and failures that can be used as indicators of team performance and promotion material. Microservices can also act as "firewalls", limiting the impact a bad hire or team can have across your codebase. None of this is intended to be negative judgement; microservices can (among other things), help teams feel a sense of agency and ownership that can be hard to maintain as org size scales up.

inopinatus 6y ago
Yes. Conway’s law is socially inevitable, align with it. Hari Seldon approves this message. NB: one may also just call them “services” with no practical loss of generality and sounding less like technobabble to everyone else.
- goatinaboat 6y ago
  NB: one may also just call them “services” with no practical loss of generality and sounding less like technobabble to everyone else. Problem is that SOA has been around for decades whereas “microservices” sounds hip and cutting-edge
  - ebiester 6y ago
    I think the SOA/microservices distinction has to do with the patterns of architecture more than anything else. (For example, the enterprise service bus is... well, ignore that if you squint it looks a bit like the service mesh and Kafka in a sufficiently complex microservice system.)
    - dasil003 6y ago
      There’s no distinction anymore , just like DevOps is now a role not a movement, and hacker is a criminal not a maker. You can’t fight the natural language evolution when it’s buzzwords that people get hired on.
  - lovegoblin 6y ago
    > “microservices” sounds hip and cutting-edge Maybe 8 years ago it did.
    - diroussel 6y ago
      I was definitely contemplating the definition of microservices back in 2012. I think Netflix had been blogging about it then, or just before.
- staticassertion 6y ago
  > NB: one may also just call them “services” with no practical loss of generality and sounding less like technobabble to everyone else. This is completely untrue, and I think it's part of the problem with discussions about microservices. People think it means "lots of small services". That is not what it means. That would be closer to SOA. Microservices is not SOA, and it is not "technobabble". It has defined constructs, methodologies, and patterns.
  - lmb 6y ago
    You're arguing that the majority of people use the term differently than you and are therefore wrong. Sounds like the definition of technobabble to me.
    - staticassertion 6y ago
      I think that tech has this extreme, albeit well-earn, revulsion to hype that makes them reject things based on terminology and community over actually understanding the thing. I see it all the time. It's simply wrong to say that microservices is just "services". Many people being wrong changes nothing.
  - rzzzt 6y ago
    What _are_ microservices? </DavidDuchovny>
  - tsss 6y ago
    Then what is the difference?
    - staticassertion 6y ago
      https://www.oreilly.com/content/a-quick-and-simple-definition-of-microservices/ https://www.oreilly.com/content/a-quick-and-simple-definitio... I feel like you could just google SOA and Microservice architecture, pick up a book, and answer that for yourself.
      - 6y ago
pjmlp 6y ago
They can do exactly the same when shipping libraries into the company's central library repository, NuGET, Maven, Gems, Eggs, whatever.
deleted 6y ago
[deleted]
Benjammer 6y ago
Isn't the only thing here that is enabled by microservices the separate tooling part? Couldn't the rest of it be achieved somewhat easier with a standard service-oriented architecture in a monolith? Why do we need to insert network calls between everything?
- pydry 6y ago
  It allows different teams to write in different languages, have different deployment cadences and different testing mechanisms. The overhead of network calls and its attendant problems can be a worthwhile price to pay if you need to loosely couple your teams. This is why my yardstick of "should it be a micro service?" is "could it work as an entirely separate business?" I was a massive skeptic of micro services until I saw that it actually solved some people problems pretty well despite incurring a technical cost. I'm pretty convinced it's an anti pattern in small startups though.
- hcarvalhoalves 6y ago
  I believe network calls are a looser contract than function calls that would be checked at compile time, so it allows a softer decoupling between multiple teams. Compatibility or intermittent failures are handled with different strategies (rollout, rollback, deadletter queues) instead of impacting release cycles.
gizzlon 6y ago
> You know who to page when there's a problem .. I don't believe that's true in practice. Having many services moves a lot of complexity from 1 program to "the system" as a whole. All the stuff outside the services themselves. Who do you call when the incoming requests are failing, but each service is working fine in isolation?
- scottious 6y ago
  Further, I think microservices can encourages devs to stay in their own little walled garden and they're quick to say "everything's working on my end, must be somebody else's problem". Very few people, if any, have a complete understanding of the system and this is often by design which may not necessarily be a good thing. Reasoning between microservices feels harder to me than reasoning within a monolith.
- mekkkkkk 6y ago
  You call your resident "cloud team" or "infrastructure team" for help. Unfortunately, those guys are busy having an existential crisis looking into the abyss of machines, queues, cache layers and databases that are supposedly enabling "smooth team based development". So you get adventurous and open up XRay or Application Insights or whatever the fuck. After a few hours you realize that the erroneous response code that you thought was the culprit is there by "by design" "intentionally". So you say fuck it and add another microservice or cache layer that "fixes" the problem and call it a day. You can hear screams of agony from the infrastructure team, but who cares. When you leave for the day, the boss pats you on the shoulder. "Nice work today, handling that incident", he says.
lilactown 6y ago
And this is a real killer w.r.t. startups adopting microservices: if you're shipping your org chart, but your org chart needs to change frequently to adapt to different contexts as you pivot, arrange, create and eject use cases, microservices cause frequent friction because the relationship between the way you want to organize, and the way the boundaries are established in code, are so different. I even see the reverse happening, org chart changes made based on service boundaries, due to this friction.
- pas 6y ago
  Is this really a problem though? Departments, shifts, brigades have been organized based on plant layout, machines, manufacturing lines, mine shafts, routes, regions and so on for ages. Microservices or not, above a certain headcount there's no escaping this reality, there's an overhead due to communication, organization, etc. As long as the throughput is greater this way (than without organization, or without the increased headcount) it makes sense to do it.

inopinatus 6y ago

Yes. Conway’s law is socially inevitable, align with it. Hari Seldon approves this message. NB: one may also just call them “services” with no practical loss of generality and sounding less like technobabble to everyone else.

goatinaboat 6y ago
NB: one may also just call them “services” with no practical loss of generality and sounding less like technobabble to everyone else. Problem is that SOA has been around for decades whereas “microservices” sounds hip and cutting-edge
- ebiester 6y ago
  I think the SOA/microservices distinction has to do with the patterns of architecture more than anything else. (For example, the enterprise service bus is... well, ignore that if you squint it looks a bit like the service mesh and Kafka in a sufficiently complex microservice system.)
  - dasil003 6y ago
    There’s no distinction anymore , just like DevOps is now a role not a movement, and hacker is a criminal not a maker. You can’t fight the natural language evolution when it’s buzzwords that people get hired on.
- lovegoblin 6y ago
  > “microservices” sounds hip and cutting-edge Maybe 8 years ago it did.
  - diroussel 6y ago
    I was definitely contemplating the definition of microservices back in 2012. I think Netflix had been blogging about it then, or just before.
staticassertion 6y ago
> NB: one may also just call them “services” with no practical loss of generality and sounding less like technobabble to everyone else. This is completely untrue, and I think it's part of the problem with discussions about microservices. People think it means "lots of small services". That is not what it means. That would be closer to SOA. Microservices is not SOA, and it is not "technobabble". It has defined constructs, methodologies, and patterns.
- lmb 6y ago
  You're arguing that the majority of people use the term differently than you and are therefore wrong. Sounds like the definition of technobabble to me.
  - staticassertion 6y ago
    I think that tech has this extreme, albeit well-earn, revulsion to hype that makes them reject things based on terminology and community over actually understanding the thing. I see it all the time. It's simply wrong to say that microservices is just "services". Many people being wrong changes nothing.
- rzzzt 6y ago
  What _are_ microservices? </DavidDuchovny>
- tsss 6y ago
  Then what is the difference?
  - staticassertion 6y ago
    https://www.oreilly.com/content/a-quick-and-simple-definition-of-microservices/ https://www.oreilly.com/content/a-quick-and-simple-definitio... I feel like you could just google SOA and Microservice architecture, pick up a book, and answer that for yourself.
    - 6y ago

pjmlp 6y ago

They can do exactly the same when shipping libraries into the company's central library repository, NuGET, Maven, Gems, Eggs, whatever.

deleted 6y ago

[deleted]

Benjammer 6y ago

Isn't the only thing here that is enabled by microservices the separate tooling part? Couldn't the rest of it be achieved somewhat easier with a standard service-oriented architecture in a monolith? Why do we need to insert network calls between everything?

pydry 6y ago
It allows different teams to write in different languages, have different deployment cadences and different testing mechanisms. The overhead of network calls and its attendant problems can be a worthwhile price to pay if you need to loosely couple your teams. This is why my yardstick of "should it be a micro service?" is "could it work as an entirely separate business?" I was a massive skeptic of micro services until I saw that it actually solved some people problems pretty well despite incurring a technical cost. I'm pretty convinced it's an anti pattern in small startups though.
hcarvalhoalves 6y ago
I believe network calls are a looser contract than function calls that would be checked at compile time, so it allows a softer decoupling between multiple teams. Compatibility or intermittent failures are handled with different strategies (rollout, rollback, deadletter queues) instead of impacting release cycles.

gizzlon 6y ago

> You know who to page when there's a problem .. I don't believe that's true in practice. Having many services moves a lot of complexity from 1 program to "the system" as a whole. All the stuff outside the services themselves. Who do you call when the incoming requests are failing, but each service is working fine in isolation?

scottious 6y ago
Further, I think microservices can encourages devs to stay in their own little walled garden and they're quick to say "everything's working on my end, must be somebody else's problem". Very few people, if any, have a complete understanding of the system and this is often by design which may not necessarily be a good thing. Reasoning between microservices feels harder to me than reasoning within a monolith.
mekkkkkk 6y ago
You call your resident "cloud team" or "infrastructure team" for help. Unfortunately, those guys are busy having an existential crisis looking into the abyss of machines, queues, cache layers and databases that are supposedly enabling "smooth team based development". So you get adventurous and open up XRay or Application Insights or whatever the fuck. After a few hours you realize that the erroneous response code that you thought was the culprit is there by "by design" "intentionally". So you say fuck it and add another microservice or cache layer that "fixes" the problem and call it a day. You can hear screams of agony from the infrastructure team, but who cares. When you leave for the day, the boss pats you on the shoulder. "Nice work today, handling that incident", he says.

lilactown 6y ago

And this is a real killer w.r.t. startups adopting microservices: if you're shipping your org chart, but your org chart needs to change frequently to adapt to different contexts as you pivot, arrange, create and eject use cases, microservices cause frequent friction because the relationship between the way you want to organize, and the way the boundaries are established in code, are so different. I even see the reverse happening, org chart changes made based on service boundaries, due to this friction.

pas 6y ago
Is this really a problem though? Departments, shifts, brigades have been organized based on plant layout, machines, manufacturing lines, mine shafts, routes, regions and so on for ages. Microservices or not, above a certain headcount there's no escaping this reality, there's an overhead due to communication, organization, etc. As long as the throughput is greater this way (than without organization, or without the increased headcount) it makes sense to do it.