4 ms·

> The most critical thing is being able to use any services locally or remotely without knowing the difference or changing the code. I thought we all agreed CO

by hartror 11y ago

> The most critical thing is being able to use any services locally or remotely without knowing the difference or changing the code. I thought we all agreed CORBA style location transparency was a bad idea? https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture#Problems_and_criticism https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

charlieflowers 11y ago
That was my 1st reaction too ... but hold on. If you design the 2 components to be non-chatty and have robust error handling, then it can be safe to make it location transparent. In other words, the problem in the past was, we designed it as if it would be used locally, then we naively made it remote. But now, we're talking about designing it for remote use, but then using it locally. Interesting.
- ddoscampaign 11y ago
  Top-down configuration (as opposed to discovery like UDDI) via something like zookeeper or dns solves this problem. And APIs shouldn't do WSDL either, the code and docs should document the API. It's possible to add so many over-engineered layers of YAGNI flexibility that almost no one can understand what the heck is going on or how to hack on it, e.g., Eclipse plugins. Keep it really simple, until it breaks too often.
  - lsm 11y ago
    Really good suggestion for the API doc. I admit that writing documentation is much harder than code;)
- iofj 11y ago
  It still has all the other disadvantages of remote services, like consistency problems (everybody always assumes that RPC calls are as reliable as 2 phase commit, and they're not), more and more complex code that's harder to change, less flexibility on all fronts except for the one, ... Things like distribution are a tradeoff, an optimization : you should never split a monolithic application into 2 communicating parts until you have good reason to do so. A monolithic system executing a given function is pretty much guaranteed to be simpler than a distributed system doing the same function. A small amount of microservices is easier on the guy doing ops work for the system, because they can be individually replaced, upgraded or changed (IF the developers put in the constant amounts of efforts needed to make that possible. Every release should be able to deal with past versions of everything it talks to). These guys are also usually the ones doing load balancing and the like, so bonus points for being able to spread them over the network. Of course, numbers of microservices always grow, and grow, and grow some more. Soon it's not easier anymore on the ops guy, and becomes a constant drag on progress for everyone.
  - lsm 11y ago
    I agree, the consistency problems should be handled inside each individual services and the layer before all the services should be as simple as normal balancer.
  - gbog 11y ago
    > A monolithic system executing a given function is pretty much guaranteed to be simpler than a distributed system doing the same function. And what about a monolithic system executing thousands of different functions? If your app is a simple todo list, sure, go monolithic (but you should still delegate storage to some other tool). If it is much more complex than a todo list, then it is very likely that you have many packages containing many modules developped and maintained by many programmers. And if one glitch on one side of the monolith affects a remote module and functionalities depending on it, or even breaks down the whole monolith, then you should go microservices. Or split your code base. Or do whatever is needed so the thing can still move forwards, if slowly, without breaking apart at each little step.
    - aikah 11y ago
      > If it is much more complex than a todo list, See , that's the problem with you people advocating micro-services , RIGHT HERE. Your statement is ridiculous and make it hard for people like me to take micro service advocates seriously.
      - gbog 11y ago
        I'm sorry, I do not understand why you find this statement ridiculous (I'm not native English-speaker). Would you mind explaining a bit?
        kasey_junk 11y ago
        Because we have decades of examples of monolithic apps more complicated than a to do list, but very little time with micro services. If you honestly believe you can't write robust & scalable monoliths at all, that is an extreme position that is hard to square with many peoples experience.
- lsm 11y ago
  Yes, you got the idea. We focus on providing developer the "ability to switch or mix between microservice and monolithic styles" so people get flexibility they need for different circumstances (e.g. development vs deployment vs testing).
- roel_v 11y ago
  People could (and did) design robust CORBA and (D)COM objects, but the overhead was too high in some (many?) cases. Overhead in development time, but also run time. If I can pass a const pointer to a bunch of data (if I know the consumer will live in the same memory space), then that's way faster (in development and run speed) than having to marshal that data into a common byte-order and alignment etc., most likely requiring copying, keeping track of who changed what when, ... Now that I have my old fogey hat on anyway, I might as well state the 'old wine in new bags' feeling I get with articles like this. Encapsulation and separation of concerns is good you say? But inconvenient because there is overhead? So infrastructure to manage dependencies and deployment of sets of loosely coupled components is useful? Whodathoughtthat!
  - hinkley 11y ago
    It's tough. Pass by reference became de rigeur for high performance systems when we agreed that the message passing overhead represented the plurality of computation time. But pass by reference is shared state, and as we started trying to build systems with threading and for multiple cores the ugly truth about memory coherence on modern processors came out. It was pretty bad. Java and later C had to come up with some pretty odd looking compromises to get safety without throwing away all of the speed advantages.
hliyan 11y ago
I don't think the failure of one (or even two) implementations invalidates the concept itself. I see nothing fundamentally wrong with the idea of location transparency (where it matters)
hinkley 11y ago
And then we agreed that location transparency was bad in RMI, and then again in EJB. It's regular as the tides. In a couple years you'll hear everyone talking about how stupid the Cloud is and everyone will be buying their own servers. Then we'll decide that peer-peer is the way and the light. Didn't Vonnegut have a line about how it affects you to see the same mistakes repeat over and over?
- JoeAltmaier 11y ago
  Its more about bandwidth vs capacity vs dollars. The optimum changes as the technologies change.
  - hinkley 11y ago
    Touché. Every time we hit a new balance in the inequalities we have to re-evaluate all our answers. I guess what bugs me is not the mind changing (I do that all the time myself). It's that those without a history lesson behave as if this is a bloody revolution, and they have to pick sides. And the people who think switching solutions will magically fix all of our problems.

by hartror 11y ago

charlieflowers 11y ago

That was my 1st reaction too ... but hold on. If you design the 2 components to be non-chatty and have robust error handling, then it can be safe to make it location transparent. In other words, the problem in the past was, we designed it as if it would be used locally, then we naively made it remote. But now, we're talking about designing it for remote use, but then using it locally. Interesting.

ddoscampaign 11y ago
Top-down configuration (as opposed to discovery like UDDI) via something like zookeeper or dns solves this problem. And APIs shouldn't do WSDL either, the code and docs should document the API. It's possible to add so many over-engineered layers of YAGNI flexibility that almost no one can understand what the heck is going on or how to hack on it, e.g., Eclipse plugins. Keep it really simple, until it breaks too often.
- lsm 11y ago
  Really good suggestion for the API doc. I admit that writing documentation is much harder than code;)
iofj 11y ago
It still has all the other disadvantages of remote services, like consistency problems (everybody always assumes that RPC calls are as reliable as 2 phase commit, and they're not), more and more complex code that's harder to change, less flexibility on all fronts except for the one, ... Things like distribution are a tradeoff, an optimization : you should never split a monolithic application into 2 communicating parts until you have good reason to do so. A monolithic system executing a given function is pretty much guaranteed to be simpler than a distributed system doing the same function. A small amount of microservices is easier on the guy doing ops work for the system, because they can be individually replaced, upgraded or changed (IF the developers put in the constant amounts of efforts needed to make that possible. Every release should be able to deal with past versions of everything it talks to). These guys are also usually the ones doing load balancing and the like, so bonus points for being able to spread them over the network. Of course, numbers of microservices always grow, and grow, and grow some more. Soon it's not easier anymore on the ops guy, and becomes a constant drag on progress for everyone.
- lsm 11y ago
  I agree, the consistency problems should be handled inside each individual services and the layer before all the services should be as simple as normal balancer.
- gbog 11y ago
  > A monolithic system executing a given function is pretty much guaranteed to be simpler than a distributed system doing the same function. And what about a monolithic system executing thousands of different functions? If your app is a simple todo list, sure, go monolithic (but you should still delegate storage to some other tool). If it is much more complex than a todo list, then it is very likely that you have many packages containing many modules developped and maintained by many programmers. And if one glitch on one side of the monolith affects a remote module and functionalities depending on it, or even breaks down the whole monolith, then you should go microservices. Or split your code base. Or do whatever is needed so the thing can still move forwards, if slowly, without breaking apart at each little step.
  - aikah 11y ago
    > If it is much more complex than a todo list, See , that's the problem with you people advocating micro-services , RIGHT HERE. Your statement is ridiculous and make it hard for people like me to take micro service advocates seriously.
    - gbog 11y ago
      I'm sorry, I do not understand why you find this statement ridiculous (I'm not native English-speaker). Would you mind explaining a bit?
      - kasey_junk 11y ago
        Because we have decades of examples of monolithic apps more complicated than a to do list, but very little time with micro services. If you honestly believe you can't write robust & scalable monoliths at all, that is an extreme position that is hard to square with many peoples experience.
lsm 11y ago
Yes, you got the idea. We focus on providing developer the "ability to switch or mix between microservice and monolithic styles" so people get flexibility they need for different circumstances (e.g. development vs deployment vs testing).
roel_v 11y ago
People could (and did) design robust CORBA and (D)COM objects, but the overhead was too high in some (many?) cases. Overhead in development time, but also run time. If I can pass a const pointer to a bunch of data (if I know the consumer will live in the same memory space), then that's way faster (in development and run speed) than having to marshal that data into a common byte-order and alignment etc., most likely requiring copying, keeping track of who changed what when, ... Now that I have my old fogey hat on anyway, I might as well state the 'old wine in new bags' feeling I get with articles like this. Encapsulation and separation of concerns is good you say? But inconvenient because there is overhead? So infrastructure to manage dependencies and deployment of sets of loosely coupled components is useful? Whodathoughtthat!
- hinkley 11y ago
  It's tough. Pass by reference became de rigeur for high performance systems when we agreed that the message passing overhead represented the plurality of computation time. But pass by reference is shared state, and as we started trying to build systems with threading and for multiple cores the ugly truth about memory coherence on modern processors came out. It was pretty bad. Java and later C had to come up with some pretty odd looking compromises to get safety without throwing away all of the speed advantages.

hliyan 11y ago

I don't think the failure of one (or even two) implementations invalidates the concept itself. I see nothing fundamentally wrong with the idea of location transparency (where it matters)

hinkley 11y ago

And then we agreed that location transparency was bad in RMI, and then again in EJB. It's regular as the tides. In a couple years you'll hear everyone talking about how stupid the Cloud is and everyone will be buying their own servers. Then we'll decide that peer-peer is the way and the light. Didn't Vonnegut have a line about how it affects you to see the same mistakes repeat over and over?

JoeAltmaier 11y ago
Its more about bandwidth vs capacity vs dollars. The optimum changes as the technologies change.
- hinkley 11y ago
  Touché. Every time we hit a new balance in the inequalities we have to re-evaluate all our answers. I guess what bugs me is not the mind changing (I do that all the time myself). It's that those without a history lesson behave as if this is a bloody revolution, and they have to pick sides. And the people who think switching solutions will magically fix all of our problems.