6 ms·

I agree, but I think the author is missing one big point: - microservices is not a tech concept, it's a management concept We (devs) like to think that micros

I agree, but I think the author is missing one big point: - microservices is not a tech concept, it's a management concept We (devs) like to think that microservices is all about tech, but in reality it's a disguised tech concept used by management to: - grow the team. We are going to need more devs to build more microservices! - have more things to manage. Like, do you really think managers want to say "yeah, I manage the delivery of... a library". At the end of the quarter they want to say: "yeah, I manage the delivery of a service that..." - get salary raises. See previous point That's it. The tech industry is shifting (has shifted already?) from a "tech people know better. Let them drive the big decisions" perspective to a "lean managers drive tech decisions because they know Agile and Agile is good" one. Microservices is all about management/organizational topics, not about tech.

ryanbrunner 6y ago
In my experience, engineers will be pushing for microservices as often if not more than tech management. The reasons are sometimes different - a lot of times it reduces down to "our existing services are all written with old, unsexy technology and I want to do something greenfields with new tech that looks good on my resume", but they're definitely not fighting against the tide of management insisting on microservices.
- sdevonoes 6y ago
  I see that as well, but only if microservices have been already "approved" in your organization (usually by upper tech management).
- devonkim 6y ago
  Another reason I’ve seen is “this project will be around for a while and we should skip past the growing pains to go into microservices.” If it’s a rewrite of an existing system, then it’s more justifiable because it’s about eliminating technical debt and is not a greenfield project. But for new efforts where an organization has never seen customer demand in X, Y, Z services being created it’s pure conjecture and premature optimization to essential refactor across service boundaries before a monolith with some usage metrics even exists
100011_100001 6y ago
I disagree. It appears that you are dealing with bad management. Most Business people think in terms of features and defects. In most cases they don't even know what microservice does what, they probably don't even know the names of most microservices. I consider microservices a natural extension of OOP on a service level. Each microservice functions like an abstract object that represents a thing. Of course it has the same drawback as OOP, do it too much, or implement it too little and you got problems.
- 100011_100001 6y ago
  I am perplexed by the downvotes. Which part of my statement is "wrong" enough to get downvotes? I am trying to understand if I have an opinion that's incorrect, or that people don't like it?
- jayd16 6y ago
  Striping your objects across processes and machines is a very different set of problems than OOP. But even ignoring that, you fail to see that OOP is also a form of management concept. Its still compartmentalization and abstraction such that no developer must understand the full state of the system to make sense of an api. OOP is much more a huaman management and communication concept than a technical one.
candiddevmike 6y ago
I don't know why this post has so many downvotes. Kingdom building has come to developer teams. You no longer see large dev teams that collaborate really well, instead you see silos and pizza teams. No one talks, everything becomes a political turf war, and the end result is everyone taking their ball and going home. Higher ups don't understand the complexity of the stack, they just hear we're constantly shipping new things--that has to be good? New is better than maintenance right? Microservices are just managers codifying the boundaries of their kingdom.
- pydry 6y ago
  It's hardly accurate to say it's come to developer teams - it's always been like this. This is simply human nature manifested in large groups. Large groups operating well together without clearly defined boundaries of responsibility is very much the exception rather than the norm and always has been.
  - candiddevmike 6y ago
    I would argue that a lot of the "famed agility" and effectiveness of startups is their flat structure and lack of middle management bloat, especially for the devs. As soon as you start splitting the dev teams apart, productivity grinds to a halt and you start hearing phrases like "this team owns that" and other territory marking behavior.
    - pydry 6y ago
      I think that well defined software teams that can integrate effectively with one another in large companies could spell the end of software startups. The dysfunctionality of middle management outweighed economies of scale for a long time but I doubt it will last forever.
    - jonfw 6y ago
      That's probably because startups are small organizations. Nobody is arguing that productivity increases linearly as you add 2 pizza teams. Productivity increases logarithmically. '2 pizza teams' are supposed to represent where the productivity gains of adding a dev to a team are marginal.
robertjp 6y ago
It's definitely a tech thing if you "need" the resource scalability. All it takes in certain types of work. If a customer can click a button and that ends up allocating a gig of memory or using 5 minutes of CPU, then scaling out is the only reasonable option.
- sdevonoes 6y ago
  Agree. But this is true only for a very few of the tech companies out there.

ryanbrunner 6y ago

In my experience, engineers will be pushing for microservices as often if not more than tech management. The reasons are sometimes different - a lot of times it reduces down to "our existing services are all written with old, unsexy technology and I want to do something greenfields with new tech that looks good on my resume", but they're definitely not fighting against the tide of management insisting on microservices.

sdevonoes 6y ago
I see that as well, but only if microservices have been already "approved" in your organization (usually by upper tech management).
devonkim 6y ago
Another reason I’ve seen is “this project will be around for a while and we should skip past the growing pains to go into microservices.” If it’s a rewrite of an existing system, then it’s more justifiable because it’s about eliminating technical debt and is not a greenfield project. But for new efforts where an organization has never seen customer demand in X, Y, Z services being created it’s pure conjecture and premature optimization to essential refactor across service boundaries before a monolith with some usage metrics even exists

100011_100001 6y ago

I disagree. It appears that you are dealing with bad management. Most Business people think in terms of features and defects. In most cases they don't even know what microservice does what, they probably don't even know the names of most microservices. I consider microservices a natural extension of OOP on a service level. Each microservice functions like an abstract object that represents a thing. Of course it has the same drawback as OOP, do it too much, or implement it too little and you got problems.

100011_100001 6y ago
I am perplexed by the downvotes. Which part of my statement is "wrong" enough to get downvotes? I am trying to understand if I have an opinion that's incorrect, or that people don't like it?
jayd16 6y ago
Striping your objects across processes and machines is a very different set of problems than OOP. But even ignoring that, you fail to see that OOP is also a form of management concept. Its still compartmentalization and abstraction such that no developer must understand the full state of the system to make sense of an api. OOP is much more a huaman management and communication concept than a technical one.

candiddevmike 6y ago

I don't know why this post has so many downvotes. Kingdom building has come to developer teams. You no longer see large dev teams that collaborate really well, instead you see silos and pizza teams. No one talks, everything becomes a political turf war, and the end result is everyone taking their ball and going home. Higher ups don't understand the complexity of the stack, they just hear we're constantly shipping new things--that has to be good? New is better than maintenance right? Microservices are just managers codifying the boundaries of their kingdom.

pydry 6y ago
It's hardly accurate to say it's come to developer teams - it's always been like this. This is simply human nature manifested in large groups. Large groups operating well together without clearly defined boundaries of responsibility is very much the exception rather than the norm and always has been.
- candiddevmike 6y ago
  I would argue that a lot of the "famed agility" and effectiveness of startups is their flat structure and lack of middle management bloat, especially for the devs. As soon as you start splitting the dev teams apart, productivity grinds to a halt and you start hearing phrases like "this team owns that" and other territory marking behavior.
  - pydry 6y ago
    I think that well defined software teams that can integrate effectively with one another in large companies could spell the end of software startups. The dysfunctionality of middle management outweighed economies of scale for a long time but I doubt it will last forever.
  - jonfw 6y ago
    That's probably because startups are small organizations. Nobody is arguing that productivity increases linearly as you add 2 pizza teams. Productivity increases logarithmically. '2 pizza teams' are supposed to represent where the productivity gains of adding a dev to a team are marginal.

robertjp 6y ago

It's definitely a tech thing if you "need" the resource scalability. All it takes in certain types of work. If a customer can click a button and that ends up allocating a gig of memory or using 5 minutes of CPU, then scaling out is the only reasonable option.

sdevonoes 6y ago
Agree. But this is true only for a very few of the tech companies out there.