4 ms·

Is this an April Fools' joke or not? If it is, can someone explain the joke? If it is not, it seems to me that it contradicts with the current "wisdom" of micro

by js8 10y ago

Is this an April Fools' joke or not? If it is, can someone explain the joke? If it is not, it seems to me that it contradicts with the current "wisdom" of microservices.

vidarh 10y ago
It doesn't contradict that much of it. Consider that the context was an environment where people tried to shove CORBA down our throats and insist it didn't matter where the objects lived (apparently latency wasn't a thing). He is arguing against distributing objects along class boundaries or similar granualr splits, and to avoid distribution internally in a backend service when possible. Microservices, meanwhile is a reaction to ballooning applications, increasingly containing many orthogonal services / APIs, and in favour of splitting them up, with common advice seeking to avoid splitting on boundaries that will require coordination between the resulting services. Microservices takes the consequence of the problems Fowler complains about in the linked article by trying to split applications into individual services while keeping interdependencies minimal, so that we ideally only pay the latency cost at the user<->service boundary where we have to pay it anyway, instead of all over the system, which was one of the major ongoing problems with the CORBA craze.
- js8 10y ago
  I don't understand. If I compare this (courtesy of klochner): "In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies." To this: "Distributing an application by putting different components on different nodes sounds like a good idea, but the performance cost is steep. [..] How, then, do you effectively use multiple processors? In most cases, the way to go is clustering (see “A Better Way”). Put all the classes into a single process and then run multiple copies of that process on the various nodes." It looks like a direct contradiction. Personally, I think microservices are indeed a bit crazy and the latter is a good advice, but I am no MF.
  - tcopeland 10y ago
    To me microservices work when you split out things that the core app doesn't always need. So "promocodes" becomes its own microservice because not all purchases need a promo code. And now the main app isn't cluttered with promo code admin logic and UI.
    - joshmarlow 10y ago
      Another example that I'm fond of: Central authentication service that authenticates on user login and passes back and API token to be used to access other services. With something like a JWT you don't need to check the User database for every API call.
      - vidarh 10y ago
        Exactly. This is how I see microservices as most valuable: When communication is mediated by the client. And tokens can be great for that in all kinds of circumstances to allow the client to mediate communications even when trust is required.
    - unscaled 10y ago
      Exactly. I've seen many monoliths which were bloated with pieces of functionality developed for specific needs that other parts of the company had. So your shopping cart API would get promocodes, and coupons, and express delivery, donation offers, credit card selection, support for legacy authentication and so on. And then you had to convert this behemoth from Java 5 or PHP 5 into something modern, but it ended up being too messy and you're stuck. Yes, implementing all these features as microservice won't simplify the architecture, but you'll at least be able to easily migrate upgrade, remove, replace or scale up pieces of it.
      - js8 10y ago
        > you'll at least be able to easily migrate upgrade, remove, replace or scale up pieces of it IMHO, you're painting a very rosy picture here. There is a big assumption that you will want to preserve existing interfaces (REST APIs?) between those microservices. In reality, they probably will be bloated and obsolete just like everything else you have. And being forced to update "microservice" at a time rather than as a whole, the whole process will actually become more complicated.
- bartread 10y ago
  That sounds ideal when you say it like that. The reality is often far removed in my experience, with services calling back and forth hither and thither, which is to say that all you've done is taken the spaghetti that often characterises enterprise software and stretched it out a bit in places. And in so doing what you've done is add a bunch of latency. The one virtue of the former, non-microservice, situation is that at least you don't have the latency overhead because all that spaghetti is contained in one, or a small number of, processes, rather than spread around all over the place between a large number of processes and instances. I'm not saying it's ideal but people who write crap software in monolithic form are only going to do a worse job when faced with the additional complexity of having it all chopped up into little pieces. Just my two cents, and obviously not a trendy point of view. I'd be quite interested to see how Martin Fowler's view changes over the next 11 years, assuming he doesn't retire.
  - vidarh 10y ago
    And if they do call back and forth, then all of the advice Fowler gave in the initial article still holds. So my point is his earlier views are for the most part not in contradiction with the microservices patterns - if anything, the latter is a evolution of the former, and the combination can basically be distilled down to: If you must/want to split, split along service boundaries where communication is mostly with the client, and minimise communications surfaces between services. If you do that, you gain ability to scale services separately, and develop them separately. If there are lots of interdependencies, you have bought yourself lots of latency and reliability issues for little gain elsewhere. > I'm not saying it's ideal but people who write crap software in monolithic form are only going to do a worse job when faced with the additional complexity of having it all chopped up into little pieces. I agree with that, and those people should probably start with articles like the linked one to learn to think about latency issues first.

by js8 10y ago

Is this an April Fools' joke or not? If it is, can someone explain the joke? If it is not, it seems to me that it contradicts with the current "wisdom" of microservices.

vidarh 10y ago

It doesn't contradict that much of it. Consider that the context was an environment where people tried to shove CORBA down our throats and insist it didn't matter where the objects lived (apparently latency wasn't a thing). He is arguing against distributing objects along class boundaries or similar granualr splits, and to avoid distribution internally in a backend service when possible. Microservices, meanwhile is a reaction to ballooning applications, increasingly containing many orthogonal services / APIs, and in favour of splitting them up, with common advice seeking to avoid splitting on boundaries that will require coordination between the resulting services. Microservices takes the consequence of the problems Fowler complains about in the linked article by trying to split applications into individual services while keeping interdependencies minimal, so that we ideally only pay the latency cost at the user<->service boundary where we have to pay it anyway, instead of all over the system, which was one of the major ongoing problems with the CORBA craze.

js8 10y ago
I don't understand. If I compare this (courtesy of klochner): "In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies." To this: "Distributing an application by putting different components on different nodes sounds like a good idea, but the performance cost is steep. [..] How, then, do you effectively use multiple processors? In most cases, the way to go is clustering (see “A Better Way”). Put all the classes into a single process and then run multiple copies of that process on the various nodes." It looks like a direct contradiction. Personally, I think microservices are indeed a bit crazy and the latter is a good advice, but I am no MF.
- tcopeland 10y ago
  To me microservices work when you split out things that the core app doesn't always need. So "promocodes" becomes its own microservice because not all purchases need a promo code. And now the main app isn't cluttered with promo code admin logic and UI.
  - joshmarlow 10y ago
    Another example that I'm fond of: Central authentication service that authenticates on user login and passes back and API token to be used to access other services. With something like a JWT you don't need to check the User database for every API call.
    - vidarh 10y ago
      Exactly. This is how I see microservices as most valuable: When communication is mediated by the client. And tokens can be great for that in all kinds of circumstances to allow the client to mediate communications even when trust is required.
  - unscaled 10y ago
    Exactly. I've seen many monoliths which were bloated with pieces of functionality developed for specific needs that other parts of the company had. So your shopping cart API would get promocodes, and coupons, and express delivery, donation offers, credit card selection, support for legacy authentication and so on. And then you had to convert this behemoth from Java 5 or PHP 5 into something modern, but it ended up being too messy and you're stuck. Yes, implementing all these features as microservice won't simplify the architecture, but you'll at least be able to easily migrate upgrade, remove, replace or scale up pieces of it.
    - js8 10y ago
      > you'll at least be able to easily migrate upgrade, remove, replace or scale up pieces of it IMHO, you're painting a very rosy picture here. There is a big assumption that you will want to preserve existing interfaces (REST APIs?) between those microservices. In reality, they probably will be bloated and obsolete just like everything else you have. And being forced to update "microservice" at a time rather than as a whole, the whole process will actually become more complicated.
bartread 10y ago
That sounds ideal when you say it like that. The reality is often far removed in my experience, with services calling back and forth hither and thither, which is to say that all you've done is taken the spaghetti that often characterises enterprise software and stretched it out a bit in places. And in so doing what you've done is add a bunch of latency. The one virtue of the former, non-microservice, situation is that at least you don't have the latency overhead because all that spaghetti is contained in one, or a small number of, processes, rather than spread around all over the place between a large number of processes and instances. I'm not saying it's ideal but people who write crap software in monolithic form are only going to do a worse job when faced with the additional complexity of having it all chopped up into little pieces. Just my two cents, and obviously not a trendy point of view. I'd be quite interested to see how Martin Fowler's view changes over the next 11 years, assuming he doesn't retire.
- vidarh 10y ago
  And if they do call back and forth, then all of the advice Fowler gave in the initial article still holds. So my point is his earlier views are for the most part not in contradiction with the microservices patterns - if anything, the latter is a evolution of the former, and the combination can basically be distilled down to: If you must/want to split, split along service boundaries where communication is mostly with the client, and minimise communications surfaces between services. If you do that, you gain ability to scale services separately, and develop them separately. If there are lots of interdependencies, you have bought yourself lots of latency and reliability issues for little gain elsewhere. > I'm not saying it's ideal but people who write crap software in monolithic form are only going to do a worse job when faced with the additional complexity of having it all chopped up into little pieces. I agree with that, and those people should probably start with articles like the linked one to learn to think about latency issues first.