5 ms·

With respect to the author, who probably is a much smarter person than I am, this is yet another in a long, long series of HN articles that should be grouped un

With respect to the author, who probably is a much smarter person than I am, this is yet another in a long, long series of HN articles that should be grouped under "I don't know what the hell X is, but I was an expert in it, and I can tell you it sucks" I've seen X be a dozen things: UML, databases, User Stories, Functional Programming, Testing... It's too much to list. Yes. If you do it that way it will hurt, and you should stop. I don't know this author, but I suspect that many people who jump into microservices are not getting the foundations they need to successful. The idea that microservices are just broken-up monoliths is a big clue. They're spot on about marketing and spend, though. In this community we're quick to hype and sell things to one another whether it's a good idea or not. I've seen some great criticisms of microservices, some of which made me pause. Now, however, I think there's a reasonable way through the obstacles. It doesn't have to be a mess. Nothing is a magic bullet, but about anything will work if your game is good enough. You don't buy a bright and shiny to make your game better. Doesn't work like that.

davidy123 7y ago
Kelsey Hightower is a rather pivotal person in the Kubernetes world. It's unusual that he's basically cautioning people not to use the system he's so involved in. His point is that many people are doing microservices wrong
- DanielBMarkham 7y ago
  Kubernetes is a deployment strategy. It should be orthogonal to microservices. I'll delete the comment if I was unnecessarily cruel or missed the sarcasm. It was not intentional. But it is important to understand that you want to think of persistence and deployment coupling as independently of your microservices strategy as possible. The vast majority of problems we see with people implementing microservices is people carrying baggage over from some previous project or pet technology. K8S's great. It's just not relevant here.
  - davidy123 7y ago
    You're right, though k8s is often associated with microservices you can deploy a monolith with it. But there's a disconnect where as an expert in associated areas he's saying people aren't doing microservices properly, and you're saying just do them properly.
    - deleted 7y ago
      [deleted]
  - cc81 7y ago
    >K8S's great. It's just not relevant here. It is very relevant though as it has become so tightly connected with microservices and if you are one of the most well known people in the Kubernetes world you will see a lot of applications that should not be microservices.
- bdcravens 7y ago
  I think Kubernetes can be used well with monoliths that are actually more monorepos. You keep the code and dependencies in one place, and then use the service definitions within your cluster to define your boundaries. (Imagine an application where your front end, back end, and background workers all share some objects, but not all of them)
bdcravens 7y ago
The author is essentially Google's chief Kubernetes evangelist, and extremely active in the Kubernetes ecosystem outside of Google.
wvenable 7y ago
Yes, the problem is that all these things are sold as magic bullets -- or worse -- that you current solution is sold as obsolete garbage. The word "monolith" has a negative connotation so obviously you can't have that and so you need something else. When microservices started to catch on, it was just a name given to a really good solution to a specific problem. And there are plenty of problems for which creating an independent service is a great way to manage both technological and organizational issues. But it doesn't just magically solve those issues -- you can't apply that model to everything just because -- it has to fit the problem space. I had a conversation on Reddit with a developer whose application had over 3,000 independent micro-services. He was very proud of this solution. But I can't imagine that could be anything but a monolith with function calls replaced with network I/O.
- DanielBMarkham 7y ago
  Yes. It wouldn't surprise me if it's reached the point where 90%+ of people saying they're doing microservices are making disasters. There's just so much stuff you have to un-learn, and that's uncomfortable. I consulted with a team last year that was moving to microserivces. They bought BigToolX and had already created a disaster ... and they weren't even through their design. Most all of what they were doing was just best practices in some other paradigm. It was painful. Whenever I fall in love too much with a technology, I get paranoid. There's usually something I'm missing.
andrew_n 7y ago
A typical UML-bashing article/comment doesn’t suggest some potentially superior alternative, but takes the “everything is awful” stance. The text of the article reads in that same vein, but given that the title is “Monoliths are the Future” I think the author’s original intent was to describe the advantages of monoliths and point out that microservices have advantages only in relatively rare cases. Too bad they made the article about microservices instead of monoliths. Sounds to me like a good opportunity for the author to write a followup post.
Ididntdothis 7y ago
“Nothing is a magic bullet, but about anything will work if your game is good enough. You don't buy a bright and shiny to make your game better. Doesn't work like that.” This 100x. If you aren’t able to maintain a monolith you will most likely mess up microservices too. Every approach has its own set of trade offs and problems. if you know what you are doing you can make things work.
rezeroed 7y ago
"who probably is a much smarter person than I am" -- I have a different take-away from the quality of that writing. I'm also no fan of the kubernetes code.
- mseepgood 7y ago
  > I have a different take-away from the quality of that writing. It's an excerpt from a podcast.
smoe 7y ago
In my opinion a lot of the problems i have seen people having with micro-services, is because they jump into it way too naively without a proper assessment, understanding of the tools and planning. As well as basically expecting magic to solve all the worlds problems. For example some time ago, I talked with devs that were about to change their monolith to micro-services. I pointed out that having decentralized the data is going to be tricky deal with. It got immediately dismissed as not a problem, because all the services are completely independent. Couple of months later they were struggling hard, because, turns out, a business needs to be able to ask questions about all its data, not just per service. Sure, a problem that can be fixed. But I got the impression that they haven't spent 10 minutes looking at potential downsides of their decision before making it. In a similar vain, people that equate monolith with spaghetti code and then end up with a spaghetti system almost immediately.
btilly 7y ago
I've seen some great criticisms of microservices, some of which made me pause. Now, however, I think there's a reasonable way through the obstacles. It doesn't have to be a mess. Nothing is a magic bullet, but about anything will work if your game is good enough. You don't buy a bright and shiny to make your game better. Doesn't work like that. With all due respect, the argument that microservices can work is not an argument for doing microservices instead of a monolith. By default a monolith is simpler, lower latency, has lower operational costs (RPCs are not actually free!), tends to be easier to refactor, leads to less duplication of code, and has better tools for traceability. (Do not underestimate the value of stack backtraces!) With best practices (that few do), all of these problems except the latency one are solvable with microservices. But you should not expect to solve them in most organizations. Given this, you should only adopt microservices if they solve a real problem. For example if your codebase is too big for a single server to hold it, or you need extreme horizontal scalability, microservices can be wonderful. But most people using microservices do not actually have those problems. Most organizations that are trying to use microservices would be better off with monoliths. Eventually reality will settle in and they will realize it. Incidentally this is not a new debate. At its heart microservices vs monolithic is the same as microkernel vs monolithic kernel. It is worth reading https://yarchive.net/comp/microkernels.html https://yarchive.net/comp/microkernels.html for Linus' criticism of microkernels - much if it applies directly to most microservices deployments.
- baq 7y ago
  I work on a project where dev teams (plural) occupy time zones spanning 16h. Having a very hard boundary between service concerns helps immensely with remaining sane even if the project could be rolled into a monolith from the perspective of code or data complexity.
  - btilly 7y ago
    There are ways to get such boundaries without having separate microservices. Also having dev teams across time zones is itself a challenge. The devs are cheaper, but integration is worse. In Steve McConnell's book Software Estimation the industry average seems to be that development is over 40% longer, and defect rates also go up. That, however, is a debate for another day.

davidy123 7y ago

Kelsey Hightower is a rather pivotal person in the Kubernetes world. It's unusual that he's basically cautioning people not to use the system he's so involved in. His point is that many people are doing microservices wrong

DanielBMarkham 7y ago
Kubernetes is a deployment strategy. It should be orthogonal to microservices. I'll delete the comment if I was unnecessarily cruel or missed the sarcasm. It was not intentional. But it is important to understand that you want to think of persistence and deployment coupling as independently of your microservices strategy as possible. The vast majority of problems we see with people implementing microservices is people carrying baggage over from some previous project or pet technology. K8S's great. It's just not relevant here.
- davidy123 7y ago
  You're right, though k8s is often associated with microservices you can deploy a monolith with it. But there's a disconnect where as an expert in associated areas he's saying people aren't doing microservices properly, and you're saying just do them properly.
  - deleted 7y ago
    [deleted]
- cc81 7y ago
  >K8S's great. It's just not relevant here. It is very relevant though as it has become so tightly connected with microservices and if you are one of the most well known people in the Kubernetes world you will see a lot of applications that should not be microservices.
bdcravens 7y ago
I think Kubernetes can be used well with monoliths that are actually more monorepos. You keep the code and dependencies in one place, and then use the service definitions within your cluster to define your boundaries. (Imagine an application where your front end, back end, and background workers all share some objects, but not all of them)

bdcravens 7y ago

The author is essentially Google's chief Kubernetes evangelist, and extremely active in the Kubernetes ecosystem outside of Google.

wvenable 7y ago

Yes, the problem is that all these things are sold as magic bullets -- or worse -- that you current solution is sold as obsolete garbage. The word "monolith" has a negative connotation so obviously you can't have that and so you need something else. When microservices started to catch on, it was just a name given to a really good solution to a specific problem. And there are plenty of problems for which creating an independent service is a great way to manage both technological and organizational issues. But it doesn't just magically solve those issues -- you can't apply that model to everything just because -- it has to fit the problem space. I had a conversation on Reddit with a developer whose application had over 3,000 independent micro-services. He was very proud of this solution. But I can't imagine that could be anything but a monolith with function calls replaced with network I/O.

DanielBMarkham 7y ago
Yes. It wouldn't surprise me if it's reached the point where 90%+ of people saying they're doing microservices are making disasters. There's just so much stuff you have to un-learn, and that's uncomfortable. I consulted with a team last year that was moving to microserivces. They bought BigToolX and had already created a disaster ... and they weren't even through their design. Most all of what they were doing was just best practices in some other paradigm. It was painful. Whenever I fall in love too much with a technology, I get paranoid. There's usually something I'm missing.

andrew_n 7y ago

A typical UML-bashing article/comment doesn’t suggest some potentially superior alternative, but takes the “everything is awful” stance. The text of the article reads in that same vein, but given that the title is “Monoliths are the Future” I think the author’s original intent was to describe the advantages of monoliths and point out that microservices have advantages only in relatively rare cases. Too bad they made the article about microservices instead of monoliths. Sounds to me like a good opportunity for the author to write a followup post.

Ididntdothis 7y ago

“Nothing is a magic bullet, but about anything will work if your game is good enough. You don't buy a bright and shiny to make your game better. Doesn't work like that.” This 100x. If you aren’t able to maintain a monolith you will most likely mess up microservices too. Every approach has its own set of trade offs and problems. if you know what you are doing you can make things work.

rezeroed 7y ago

"who probably is a much smarter person than I am" -- I have a different take-away from the quality of that writing. I'm also no fan of the kubernetes code.

mseepgood 7y ago
> I have a different take-away from the quality of that writing. It's an excerpt from a podcast.

smoe 7y ago

In my opinion a lot of the problems i have seen people having with micro-services, is because they jump into it way too naively without a proper assessment, understanding of the tools and planning. As well as basically expecting magic to solve all the worlds problems. For example some time ago, I talked with devs that were about to change their monolith to micro-services. I pointed out that having decentralized the data is going to be tricky deal with. It got immediately dismissed as not a problem, because all the services are completely independent. Couple of months later they were struggling hard, because, turns out, a business needs to be able to ask questions about all its data, not just per service. Sure, a problem that can be fixed. But I got the impression that they haven't spent 10 minutes looking at potential downsides of their decision before making it. In a similar vain, people that equate monolith with spaghetti code and then end up with a spaghetti system almost immediately.

btilly 7y ago

I've seen some great criticisms of microservices, some of which made me pause. Now, however, I think there's a reasonable way through the obstacles. It doesn't have to be a mess. Nothing is a magic bullet, but about anything will work if your game is good enough. You don't buy a bright and shiny to make your game better. Doesn't work like that. With all due respect, the argument that microservices can work is not an argument for doing microservices instead of a monolith. By default a monolith is simpler, lower latency, has lower operational costs (RPCs are not actually free!), tends to be easier to refactor, leads to less duplication of code, and has better tools for traceability. (Do not underestimate the value of stack backtraces!) With best practices (that few do), all of these problems except the latency one are solvable with microservices. But you should not expect to solve them in most organizations. Given this, you should only adopt microservices if they solve a real problem. For example if your codebase is too big for a single server to hold it, or you need extreme horizontal scalability, microservices can be wonderful. But most people using microservices do not actually have those problems. Most organizations that are trying to use microservices would be better off with monoliths. Eventually reality will settle in and they will realize it. Incidentally this is not a new debate. At its heart microservices vs monolithic is the same as microkernel vs monolithic kernel. It is worth reading https://yarchive.net/comp/microkernels.html https://yarchive.net/comp/microkernels.html for Linus' criticism of microkernels - much if it applies directly to most microservices deployments.

baq 7y ago
I work on a project where dev teams (plural) occupy time zones spanning 16h. Having a very hard boundary between service concerns helps immensely with remaining sane even if the project could be rolled into a monolith from the perspective of code or data complexity.
- btilly 7y ago
  There are ways to get such boundaries without having separate microservices. Also having dev teams across time zones is itself a challenge. The devs are cheaper, but integration is worse. In Steve McConnell's book Software Estimation the industry average seems to be that development is over 40% longer, and defect rates also go up. That, however, is a debate for another day.