5 ms·

it depends on your reasons. - if you need to scale the number of teams working on the same product you need to introduce microservices to make the teams work i

by je42 9y ago

it depends on your reasons. - if you need to scale the number of teams working on the same product you need to introduce microservices to make the teams work independently from each other. - if you need to scale the (monolith) service and it is too expensive to just scale it n times. microservices can help because you can scale each microservice independently. - that's said the overhead is real. There have been quite a few publications and advocates (like Randy Shoup) that staying monolith is fine until you have pain that a microservice architecture can ease.

friendly_chap 9y ago
Exactly! I think we completely agree. All those reasons are very fine ones - but it's still a dangerous move to go microservice style. You have to know what you are doing, and in our buzzword driven industry that's not the case usually. Little insidious time wasters will creep into your work flow and they will lurk there eat away dollars and you won't even notice. I constantly switch back and forth between working on monolithic and microservice apps and for the majority of companies sticking to a monolith until the pain points you mentioned become unbearable is the good call. Even then, just break down your apps to bigger sized services, and stop when the pain goes away. Microservices is a catchy name but if anything micro is the poison there.
- je42 9y ago
  yeah good to point to make it explicit. splitting to smaller (but not micro) is a very good transition, that might already help.
- afpx 9y ago
  Given that I have been part of a team that independently invented micro-services, and that since knowing that, I’ve met several other people who have done similarly, it can’t imagine that it’s all that hard. To me, it was just a natural evolution. What do you consider as the most important things that people are do wrong? Also, could you enumerate the time-wasters? Off hand, besides occasionally having to re-consolidate the architecture, I can’t think of many. It would be good to know how much the time-wasters cost in contrast to the alternatives.
marcosdumay 9y ago
> if you need to scale the number of teams working on the same product You can do that by several different ways. Overall, if one wants a "one size fits all" answer to how to break code into teams, it is by breaking the code into libraries, not services. Services are a niche tech here, to be considered when the others won't suffice. > if you need to scale the (monolith) service and it is too expensive to just scale it n times. Again, nearly every time this happens, the correct answer is to refactor the monolith so replicating it scales. Services are only for those cases where this won't suffice. I don't think I disagree with how you think. But I do think your comment is easily misunderstood and harmful without those qualifiers.
- je42 9y ago
  1) Agreed, the split into libraries can be fine. At some point, you want teams to deploy independently of other teams. 2) agreed ! thanks for adding the qualifiers !
- philwelch 9y ago
  I’ve seen the library approach in practice. It is works to a certain point, but it isn’t too long until having a single deployable[1] artifact becomes as much of a bottleneck as having a single codebase, if not more. Taking this approach makes it harder to do other things that are just as important, such as continuous delivery, empowering development teams to take ownership of operational excellence, or even ship updates in a reliable and timely fashion. Most of the hatred towards microservices is probably better directed at REST, which is a good paradigm for serving documents to web browsers but is overcomplicated for microservices. RPC is a good alternative, and gRPC is a good implementation of it. [1] My phone autocorrected this to “deplorable”, which is also a good adjective for a monolithic web application that contains lots of libraries and is only deployable as one artifact.
- imtringued 9y ago
  A service can be deployed independently from other services. If you release a new version 1.1.0 of a library you have to update and redeploy all applications that use this library.
- 9y ago
0x445442 9y ago
Yeah, I've not seen much in the way of definitions about what the bounds of a "micro" service are or how much scope each one includes. It sounds like you're saying that a single micro service maps to a team. Do you think each team should manage many micro services and how many do you think each team should manage? I'm generally interested but having been the guy on dev teams to handle most of the configuration management stuff I've not really been willing to listen to micro service advocates. Depending on runtime environments/architectures the CM costs sound prohibitive at best.
- foobarian 9y ago
  One per team sounds about right, unless there are some components that don't fit together in the same runtime (e.g. a data lookup with a little business logic might not fit with a module sending out emails). That said libraries go a long way to reduce the dependency graph and prevent developers from creating unnecessary edges by randomly autocompleting code.
  - daotoad 9y ago
    IME we had multiple services for each team. But we were in the process of carving several mutually incompatible whales into common, shared services, YMMV. So we had one team maintaining each whale, and our senior engineers would collaborate to identify pieces that could be cut from each and replaced with a common service. If the innards of one whale matched our service better than the others, that whale's team got to write the service. Eventually all the teams would port their products to the new, resulting service. This meant, for example, that my team, had our whale, an audio transcoding service, an automated transcription service, a post-phone-call messaging service, and several data integrations. If you need a whole team to do nothing but maintain a service, it seems to me like you built it to do too much.
  - dreamfactored 9y ago
    So you would hard couple your architecture to your current org structure?
    - 9y ago
abraae 9y ago
Or microservices are strongly indicated if you are in a SaaS industry as we are (HR software), where individual customers want choice over the components making up their own stack.
- hodgesrm 9y ago
  This is perhaps off-topic but why would you let your SaaS customers dictate the composition of the stack? This seems to obviate one of the major benefits for customers, namely that they don't sweat the details.
  - abraae 9y ago
    Very relevant. The nature of software for managing humans is that it's very fuzzy, fashion/tend driven, diverse. E.g a recent trend is for companies to try and reduce the number of undesirable applicants they get for jobs (since in a big e.g retailer, saying no to a candidate is likely also saying no to a customer). So customer now needs to inject an e.g culture fit quiz into the candidate experience, which only unlocks the apply button once the candidate has "passed". This kind of tweaking and evolvement is not possible within a monolith, so good APIs allowing vendors of the customer's choice to inject functionality are essential. That functionality can then be injected in the form of a small app that does one thing and does it well, has it's own database, i.e has many of the characteristics of what people think of as microservices.
    - icebraining 9y ago
      I don't think it's helpful to conflate "microservices" with "dynamically-loaded code". Many, many programs have a plugin system that can completely alter their behavior while having all the characteristics of a monolith - single process, function calls rather than a message bus, central control of flow rather than decentralized, etc.
      - abraae 9y ago
        Well, this can be a fruitless discussion without a shared understanding of what a microservice is. To Martin Fowler: > 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. Assembling HR ecosystems from separate apps certainly meets all of the points above.
D_Guidi 9y ago
> quite a few publications "Monolith First", Martin Fowler
- je42 9y ago
  also this: https://www.slideshare.net/RandyShoup/goto-aarhus2014-enterprisearchitecturemicroservices https://www.slideshare.net/RandyShoup/goto-aarhus2014-enterp...

by je42 9y ago

friendly_chap 9y ago

Exactly! I think we completely agree. All those reasons are very fine ones - but it's still a dangerous move to go microservice style. You have to know what you are doing, and in our buzzword driven industry that's not the case usually. Little insidious time wasters will creep into your work flow and they will lurk there eat away dollars and you won't even notice. I constantly switch back and forth between working on monolithic and microservice apps and for the majority of companies sticking to a monolith until the pain points you mentioned become unbearable is the good call. Even then, just break down your apps to bigger sized services, and stop when the pain goes away. Microservices is a catchy name but if anything micro is the poison there.

je42 9y ago
yeah good to point to make it explicit. splitting to smaller (but not micro) is a very good transition, that might already help.
afpx 9y ago
Given that I have been part of a team that independently invented micro-services, and that since knowing that, I’ve met several other people who have done similarly, it can’t imagine that it’s all that hard. To me, it was just a natural evolution. What do you consider as the most important things that people are do wrong? Also, could you enumerate the time-wasters? Off hand, besides occasionally having to re-consolidate the architecture, I can’t think of many. It would be good to know how much the time-wasters cost in contrast to the alternatives.

marcosdumay 9y ago

> if you need to scale the number of teams working on the same product You can do that by several different ways. Overall, if one wants a "one size fits all" answer to how to break code into teams, it is by breaking the code into libraries, not services. Services are a niche tech here, to be considered when the others won't suffice. > if you need to scale the (monolith) service and it is too expensive to just scale it n times. Again, nearly every time this happens, the correct answer is to refactor the monolith so replicating it scales. Services are only for those cases where this won't suffice. I don't think I disagree with how you think. But I do think your comment is easily misunderstood and harmful without those qualifiers.

je42 9y ago
1) Agreed, the split into libraries can be fine. At some point, you want teams to deploy independently of other teams. 2) agreed ! thanks for adding the qualifiers !
philwelch 9y ago
I’ve seen the library approach in practice. It is works to a certain point, but it isn’t too long until having a single deployable[1] artifact becomes as much of a bottleneck as having a single codebase, if not more. Taking this approach makes it harder to do other things that are just as important, such as continuous delivery, empowering development teams to take ownership of operational excellence, or even ship updates in a reliable and timely fashion. Most of the hatred towards microservices is probably better directed at REST, which is a good paradigm for serving documents to web browsers but is overcomplicated for microservices. RPC is a good alternative, and gRPC is a good implementation of it. [1] My phone autocorrected this to “deplorable”, which is also a good adjective for a monolithic web application that contains lots of libraries and is only deployable as one artifact.
imtringued 9y ago
A service can be deployed independently from other services. If you release a new version 1.1.0 of a library you have to update and redeploy all applications that use this library.
9y ago

0x445442 9y ago

Yeah, I've not seen much in the way of definitions about what the bounds of a "micro" service are or how much scope each one includes. It sounds like you're saying that a single micro service maps to a team. Do you think each team should manage many micro services and how many do you think each team should manage? I'm generally interested but having been the guy on dev teams to handle most of the configuration management stuff I've not really been willing to listen to micro service advocates. Depending on runtime environments/architectures the CM costs sound prohibitive at best.

foobarian 9y ago
One per team sounds about right, unless there are some components that don't fit together in the same runtime (e.g. a data lookup with a little business logic might not fit with a module sending out emails). That said libraries go a long way to reduce the dependency graph and prevent developers from creating unnecessary edges by randomly autocompleting code.
- daotoad 9y ago
  IME we had multiple services for each team. But we were in the process of carving several mutually incompatible whales into common, shared services, YMMV. So we had one team maintaining each whale, and our senior engineers would collaborate to identify pieces that could be cut from each and replaced with a common service. If the innards of one whale matched our service better than the others, that whale's team got to write the service. Eventually all the teams would port their products to the new, resulting service. This meant, for example, that my team, had our whale, an audio transcoding service, an automated transcription service, a post-phone-call messaging service, and several data integrations. If you need a whole team to do nothing but maintain a service, it seems to me like you built it to do too much.
- dreamfactored 9y ago
  So you would hard couple your architecture to your current org structure?
  - 9y ago

abraae 9y ago

Or microservices are strongly indicated if you are in a SaaS industry as we are (HR software), where individual customers want choice over the components making up their own stack.

hodgesrm 9y ago
This is perhaps off-topic but why would you let your SaaS customers dictate the composition of the stack? This seems to obviate one of the major benefits for customers, namely that they don't sweat the details.
- abraae 9y ago
  Very relevant. The nature of software for managing humans is that it's very fuzzy, fashion/tend driven, diverse. E.g a recent trend is for companies to try and reduce the number of undesirable applicants they get for jobs (since in a big e.g retailer, saying no to a candidate is likely also saying no to a customer). So customer now needs to inject an e.g culture fit quiz into the candidate experience, which only unlocks the apply button once the candidate has "passed". This kind of tweaking and evolvement is not possible within a monolith, so good APIs allowing vendors of the customer's choice to inject functionality are essential. That functionality can then be injected in the form of a small app that does one thing and does it well, has it's own database, i.e has many of the characteristics of what people think of as microservices.
  - icebraining 9y ago
    I don't think it's helpful to conflate "microservices" with "dynamically-loaded code". Many, many programs have a plugin system that can completely alter their behavior while having all the characteristics of a monolith - single process, function calls rather than a message bus, central control of flow rather than decentralized, etc.
    - abraae 9y ago
      Well, this can be a fruitless discussion without a shared understanding of what a microservice is. To Martin Fowler: > 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. Assembling HR ecosystems from separate apps certainly meets all of the points above.

D_Guidi 9y ago

> quite a few publications "Monolith First", Martin Fowler

je42 9y ago
also this: https://www.slideshare.net/RandyShoup/goto-aarhus2014-enterprisearchitecturemicroservices https://www.slideshare.net/RandyShoup/goto-aarhus2014-enterp...