3 ms·

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 applica

by 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.
vidarh 10y ago
Consider that the application generally includes includes a client element that has to communicate with the services via HTTP anyway. In that case it often makes little difference if they communicate with a single app or 10. Often you can hide that it is communicating with more than one with a simple load balancer in front of the services. If the microservices has to do lots of internal communication using HTTP, then you should consider if you've split them along the right boundaries or not. Sometimes it may not be avoidable, but if there are lots of dependencies between them, then the rationale for splitting them into separate services rapidly drops. The two things you quote are consistent assuming the services are mostly independent on the server side and it is the client that handles the coordination.
- js8 10y ago
  > The two things you quote are consistent assuming the services are mostly independent on the server side and it is the client that handles the coordination. And if this assumption ceases to hold during the life of the product? For example, I might suddenly want to do some of the client calls from within the server. What then, you scrap the microservice architecture and rebuild it as a monolith? To me this looks really contrary to YAGNI principle. Also, I think handling coordination between internal application stuff on the client is a security can of worms. You are exposing your client to information that he would never see if everything was hidden behind one service.

by js8 10y ago

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.

vidarh 10y ago

Consider that the application generally includes includes a client element that has to communicate with the services via HTTP anyway. In that case it often makes little difference if they communicate with a single app or 10. Often you can hide that it is communicating with more than one with a simple load balancer in front of the services. If the microservices has to do lots of internal communication using HTTP, then you should consider if you've split them along the right boundaries or not. Sometimes it may not be avoidable, but if there are lots of dependencies between them, then the rationale for splitting them into separate services rapidly drops. The two things you quote are consistent assuming the services are mostly independent on the server side and it is the client that handles the coordination.

js8 10y ago
> The two things you quote are consistent assuming the services are mostly independent on the server side and it is the client that handles the coordination. And if this assumption ceases to hold during the life of the product? For example, I might suddenly want to do some of the client calls from within the server. What then, you scrap the microservice architecture and rebuild it as a monolith? To me this looks really contrary to YAGNI principle. Also, I think handling coordination between internal application stuff on the client is a security can of worms. You are exposing your client to information that he would never see if everything was hidden behind one service.