4 ms·

All the Hacker News kids are crazy about microservices right now. In three years, people will have realized it wasn't such a good idea, and moved on to the nex

by jblow 10y ago

All the Hacker News kids are crazy about microservices right now. In three years, people will have realized it wasn't such a good idea, and moved on to the next "this will solve everything" fad. Once you have seen enough of these fads go by, it's pretty obvious. I'd be careful about extrapolating future directions of computer science from something that seems cool this year.

bsder 10y ago
> All the Hacker News kids are crazy about microservices right now. > In three years, people will have realized it wasn't such a good idea, and moved on to the next "this will solve everything" fad. Microservices are simply the youngsters rediscovering that encapsulation is a damn good idea. As I explain to people, microservices do NOT make your life easier. If you can exist in a monolith, that's way easier to implement. However, once things start getting complicated, microservices make certain things possible.
- neeleshs 10y ago
  And if its a business application, and the company survives long enough, it will invariably get complicated.
- jeffdavis 10y ago
  Microservices go beyond encapsulation in important ways, and regress in other ways. Build/deploy/release cycles become independent with microservices, which can be great. Also you can write microservices in different languages. But the APIs can become less rich. Try passing callbacks between microservices written in different languages. And it can be more of a pain to change APIs. And if there's any state to worry about, you need to manage that and maybe use a stateful protocol (which are harder to get right).
  - acveilleux 10y ago
    The independence of microservice is not always achieved. You often end up with a mess of interrelated services depending on fairly narrow version ranges to retain compatibility. The more homogeneous your production environment is, the less that's a problem. The worst case is when you have a dozen (or hundreds...) of production clusters that are all independent and not necessarily in-synch as far as deployed version goes.
    - jeffdavis 10y ago
      Absolutely. Developers often gloss over how truly difficult it is to make good API choices. And when the wrong choices are made, it goes wrong quickly. Microservices probably amplify this effect, but it's hard to say.
  - twic 10y ago
    > Build/deploy/release cycles become independent with microservices, which can be great. I accept that coarse-grained services can have independent lifecycles, but not microservices. I'm working on a microservice-based project, and two things we've learned are that there are almost no features we can implement in just one microservice, and that if we don't test microservices together, we get bugs. So, in practice, their lifecycles are tightly coupled. Some people ding this for being a 'distributed monolith' rather than some kind of 'true microservices', but i don't see how we could factor this application into micro-sized bits that would not be tightly coupled. > Also you can write microservices in different languages. I worked somewhere that tried that for a while (although small services, rather than microservices). It turns out that it makes it really hard to share people, libraries, and learning between teams, and that the task-specific advantages of particular languages mostly aren't great enough to make that worthwhile. We managed okay with some bits in Java and some in Scala, but adding Clojure and Groovy was too much. I think there are some bits in R now, but they're owned by a completely separate part of the organisation, so Conway's law allows it.
    - braveo 10y ago
      > It turns out that it makes it really hard to share people, libraries, and learning between teams The idea is that you don't do that. It's a matter of duplicating functionality across teams so that each team isn't beholden to another team. pushing that library doesn't suddenly break things, for example. Whether you agree with it or not, when you choose microservices, you choose to avoid sharing libraries like that. In the small it's probably ok (across microservices in 1 team, depending on circumstances), but in the large the gain isn't worth the added maintenance hassle.
      - twic 10y ago
        Libraries, sure. But if you've chosen an approach where you can't move people and learning between teams, you've chosen failure.
        braveo 10y ago
        I don't even know what that means.
SixSigma 10y ago
Do they still use FastCGI ? I doubt it You want to make your way in the CS field? Simple. Calculate rough time of amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the dusty archives, dig out something fun, and go for it. It’s worked for many people, and it can work for you. — Ron Minnich If you don't know Ron - http://www.socallinuxexpo.org/scale8x/blog/interview-ron-minnich-coreboot.html http://www.socallinuxexpo.org/scale8x/blog/interview-ron-min... People today could do well reading Computer Architecture and Parallel Processing Paperback – International Edition, January 1, 1986 by Kai Hwang (Author) https://www.amazon.com/Computer-Architecture-Parallel-Processing-Hwang/dp/0070663548 https://www.amazon.com/Computer-Architecture-Parallel-Proces...
user5994461 10y ago
Services are a good idea. SOA (serviced oriented architecture) has been out for more than 20 years and it's not going away. Micro-services is just a new hype buzzword. Classic case of "smaller is cuter" http://www.smbc-comics.com/?id=2932 http://www.smbc-comics.com/?id=2932

by jblow 10y ago

bsder 10y ago

> All the Hacker News kids are crazy about microservices right now. > In three years, people will have realized it wasn't such a good idea, and moved on to the next "this will solve everything" fad. Microservices are simply the youngsters rediscovering that encapsulation is a damn good idea. As I explain to people, microservices do NOT make your life easier. If you can exist in a monolith, that's way easier to implement. However, once things start getting complicated, microservices make certain things possible.

neeleshs 10y ago
And if its a business application, and the company survives long enough, it will invariably get complicated.
jeffdavis 10y ago
Microservices go beyond encapsulation in important ways, and regress in other ways. Build/deploy/release cycles become independent with microservices, which can be great. Also you can write microservices in different languages. But the APIs can become less rich. Try passing callbacks between microservices written in different languages. And it can be more of a pain to change APIs. And if there's any state to worry about, you need to manage that and maybe use a stateful protocol (which are harder to get right).
- acveilleux 10y ago
  The independence of microservice is not always achieved. You often end up with a mess of interrelated services depending on fairly narrow version ranges to retain compatibility. The more homogeneous your production environment is, the less that's a problem. The worst case is when you have a dozen (or hundreds...) of production clusters that are all independent and not necessarily in-synch as far as deployed version goes.
  - jeffdavis 10y ago
    Absolutely. Developers often gloss over how truly difficult it is to make good API choices. And when the wrong choices are made, it goes wrong quickly. Microservices probably amplify this effect, but it's hard to say.
- twic 10y ago
  > Build/deploy/release cycles become independent with microservices, which can be great. I accept that coarse-grained services can have independent lifecycles, but not microservices. I'm working on a microservice-based project, and two things we've learned are that there are almost no features we can implement in just one microservice, and that if we don't test microservices together, we get bugs. So, in practice, their lifecycles are tightly coupled. Some people ding this for being a 'distributed monolith' rather than some kind of 'true microservices', but i don't see how we could factor this application into micro-sized bits that would not be tightly coupled. > Also you can write microservices in different languages. I worked somewhere that tried that for a while (although small services, rather than microservices). It turns out that it makes it really hard to share people, libraries, and learning between teams, and that the task-specific advantages of particular languages mostly aren't great enough to make that worthwhile. We managed okay with some bits in Java and some in Scala, but adding Clojure and Groovy was too much. I think there are some bits in R now, but they're owned by a completely separate part of the organisation, so Conway's law allows it.
  - braveo 10y ago
    > It turns out that it makes it really hard to share people, libraries, and learning between teams The idea is that you don't do that. It's a matter of duplicating functionality across teams so that each team isn't beholden to another team. pushing that library doesn't suddenly break things, for example. Whether you agree with it or not, when you choose microservices, you choose to avoid sharing libraries like that. In the small it's probably ok (across microservices in 1 team, depending on circumstances), but in the large the gain isn't worth the added maintenance hassle.
    - twic 10y ago
      Libraries, sure. But if you've chosen an approach where you can't move people and learning between teams, you've chosen failure.
      - braveo 10y ago
        I don't even know what that means.

SixSigma 10y ago

Do they still use FastCGI ? I doubt it You want to make your way in the CS field? Simple. Calculate rough time of amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the dusty archives, dig out something fun, and go for it. It’s worked for many people, and it can work for you. — Ron Minnich If you don't know Ron - http://www.socallinuxexpo.org/scale8x/blog/interview-ron-minnich-coreboot.html http://www.socallinuxexpo.org/scale8x/blog/interview-ron-min... People today could do well reading Computer Architecture and Parallel Processing Paperback – International Edition, January 1, 1986 by Kai Hwang (Author) https://www.amazon.com/Computer-Architecture-Parallel-Processing-Hwang/dp/0070663548 https://www.amazon.com/Computer-Architecture-Parallel-Proces...

user5994461 10y ago

Services are a good idea. SOA (serviced oriented architecture) has been out for more than 20 years and it's not going away. Micro-services is just a new hype buzzword. Classic case of "smaller is cuter" http://www.smbc-comics.com/?id=2932 http://www.smbc-comics.com/?id=2932