6 ms·

We do this, with a few hundred apps all loosely linked to each other, for many of the same benefits (and drawbacks!) as micro services. Teams being able to own

by shados 7y ago

We do this, with a few hundred apps all loosely linked to each other, for many of the same benefits (and drawbacks!) as micro services. Teams being able to own their stuff without needing permission from the rest of the org, being able to punt on some architectural decisions (since the blast radius is much smaller), being able to rewrite most apps in a pinch as need be (since they're small), much simpler tooling (off the shelf open source stuff work fine, without needing to scale it to hundreds of millions of LoC), and so on and so forth. The same drawbacks apply: cross app changes can be tricky (if you find a security issue in a lib used by 150 apps, its not fun), lack of cascading pull request support in github is annoying, sharing actual business logic through libraries is often a bad idea (which is unintuitive to most). Some challenges are FE specific: unlike micro-services, FE apps are in your customer's face. Being separate apps often means page refresh between apps if you want the full benefits of total separation, which in turn can be a perf issue (vs client side routing). The second is that unlike micro-services, people don't know about this kind of architecture, and every other new hire will wonder wtf you're doing. Overall, if your product is more horizontal than vertical (tons of completely distinct features, vs a few very advanced features), it's great.

akl_bh 7y ago
Just curious, do you use monorepos as well ?
- shados 7y ago
  Yes and no. No in the sense that we have several thousands repos. Yes in the sense that some of these repos frequently contain several packages, both apps and libraries, when they're closely related and owned by the same group. The goal though is for repos to map to team ownership (a team should be able to own its stuff, as I mentioned above), and teams are a very malleable thing (they merge and split all the time). Having repos be very small helps a lot with that (and helps tools scale without needing to do anything special)
  - LASR 7y ago
    Are you Amazon?
  - ottobonn 7y ago
    Do you find that managing versions between the different repos causes overhead? Besides allowing independent main branch management, what are the advantages of having many small repos instead of one that contains all of your apps?
    - shados 7y ago
      Version management is a fallacy as far as benefits of mono vs poly repos. You can do one way or another either way. You can have 1 version of everything in poly repos or you can have mixed versions in monorepos. We follow an eventually consistent model. That is, we strive to have 1 version of dependencies for everything, but allow temporary deviation. Sometimes those deviations are less temporary, but usually for reasons that would have prevented upgrades altogether for everyone if we enforced a single version for everything. The main benefits are around ownership (people can do whatever the hell they want to their repos) and tooling/scaling (whatever works for your tiny personal project will work for any of our apps without needing to scale them). Those are separate benefits from monolith app to micro apps (because again, you can do either with either model). You also have some minor benefits that would be easy to work around but are nice to get for free (eg: Github's default history is actually useful in the web UI) The only tooling you need to manage poly repos is something to do pull requests at scale when something needs to happen everywhere. You can everything else (eg: build management scoped to individual projects) basically for free, you can always clone the entire repo without issues, etc etc etc.
tobr 7y ago
> sharing actual business logic through libraries is often a bad idea (which is unintuitive to most). Seems unintuitive to me too, would be curious to hear if you have more to say about it!
- dwohnitmok 7y ago
  Not parent, but I can share my own experiences as to why you might not want to share business logic. The short answer is you couple your microservices together and bring yourself one step closer to a distributed monolith with all its attendant pros and cons. This is especially so if you're in an OO world where data and logic are coupled together so that sharing business libraries often entails sharing business data models. This is also aggravated by the fact that the nature of business logic makes backwards-compatibility difficult to achieve (behavior often changes even if the programming API remains the same). This means changes to business logic libraries often require all downstream users to upgrade immediately or risk inconsistency (which negates the purpose of using a single library in the first place). Shared libraries when using microservices really only work well if it's reasonable to have multiple versions of that library running across different services. In other words, to some degree the sharing is only coincidental in nature. The conventional wisdom around microservices as far as I'm aware is to try to segregate services by business function (rather than e.g. segments of your domain model) to minimize sharing of business logic. Extensive sharing of business logic is a good indication your services are not split across proper lines. Of course getting these divisions down is really hard and therein lies the heart of why getting microservices right is hard.
  - maxxxxx 7y ago
    "Of course getting these divisions down is really hard and therein lies the heart of why getting microservices right is hard. " I think you can only get this right if you deal with pretty mature processes that are well understood.
- shados 7y ago
  Imagine you have a React/Redux app with Rest endpoints. You have a dumb "Button" component. You share that with all the other apps. The Button is in React. You now tie your entire ecosystem to React. Not having individual apps have to agree on dependencies is one of the benefits of micro apps, and you lost that. However, you only lost that for React, which many people agree is pretty darn good and not going anywhere. That's a tradeoff we take. Pure React components are also well encapsulated, so whatever the opinions are behind the Button doesn't pollute the apps. App owners are still free to architect their apps however they want: their only hard requirement is React. Now, imagine you have a Medium style text editor built with React, Redux, and rest endpoints, complete with automatic draft save, a working publish button, onboarding experience, etc. If you share that, now all your apps have to agree on: backend, authentication, I18n, Redux, state management architecture, it probably uses local storage and cookies, is opinionated on what you do when logged out, and so on and so forth. If you bring that editor in an app, you're now tied to all of this. If 100 apps use that editor, and they want to upgrade Redux in the editor, they all have to upgrade to get back to the same version. If you change the backend, you have to also upgrade all apps or keep the old endpoint forever. If you want to add an I18n language, you will have to rebuild/redeploy everything. If you don't encapsulate your state, its architecture will pollute the app, but if you do you're likely going to have a much more bloated library (more bytes, slower download). Apps are no longer free to make their own decisions. It gets worse if you have transitive dependencies. Your app depends on A that depends on B that depends on C. Your app also depends on C. C releases a new version that your app wants. You now need to either bundle two versions of C, or upgrade the world. If C has global side effects, bundling 2 versions of C might not even be possible at all. These kind of "full stack components" are tech debt the moment they hit your apps. As the other reply to your post stated: you end up with the worse of both worlds. All the costs of micro-apps, with all the costs of a coupled monolith TOO. Its much worse than if you had picked either one or the other.
marcosdumay 7y ago
> sharing actual business logic through libraries is often a bad idea (which is unintuitive to most). Having being there and done that, I would only like to put some extra emphasis on that "often" word. Yes, it mostly does not work, but there are exceptions.
cheez 7y ago
A few hundred apps? What problem are you guys solving?
- shados 7y ago
  All the problems :) We have a lot of products falling under the same umbrella. But keep in mind a lot of these are small (a few thousand lines of code), and that includes internal apps (built on the same stack).
  - thdespou 7y ago
    100s times a few thousand == a few million. Thats a lot!
KuhlMensch 7y ago
Nice write up. How big is your team?
- shados 7y ago
  A few hundreds.

by shados 7y ago

akl_bh 7y ago

Just curious, do you use monorepos as well ?

shados 7y ago
Yes and no. No in the sense that we have several thousands repos. Yes in the sense that some of these repos frequently contain several packages, both apps and libraries, when they're closely related and owned by the same group. The goal though is for repos to map to team ownership (a team should be able to own its stuff, as I mentioned above), and teams are a very malleable thing (they merge and split all the time). Having repos be very small helps a lot with that (and helps tools scale without needing to do anything special)
- LASR 7y ago
  Are you Amazon?
- ottobonn 7y ago
  Do you find that managing versions between the different repos causes overhead? Besides allowing independent main branch management, what are the advantages of having many small repos instead of one that contains all of your apps?
  - shados 7y ago
    Version management is a fallacy as far as benefits of mono vs poly repos. You can do one way or another either way. You can have 1 version of everything in poly repos or you can have mixed versions in monorepos. We follow an eventually consistent model. That is, we strive to have 1 version of dependencies for everything, but allow temporary deviation. Sometimes those deviations are less temporary, but usually for reasons that would have prevented upgrades altogether for everyone if we enforced a single version for everything. The main benefits are around ownership (people can do whatever the hell they want to their repos) and tooling/scaling (whatever works for your tiny personal project will work for any of our apps without needing to scale them). Those are separate benefits from monolith app to micro apps (because again, you can do either with either model). You also have some minor benefits that would be easy to work around but are nice to get for free (eg: Github's default history is actually useful in the web UI) The only tooling you need to manage poly repos is something to do pull requests at scale when something needs to happen everywhere. You can everything else (eg: build management scoped to individual projects) basically for free, you can always clone the entire repo without issues, etc etc etc.

tobr 7y ago

> sharing actual business logic through libraries is often a bad idea (which is unintuitive to most). Seems unintuitive to me too, would be curious to hear if you have more to say about it!

dwohnitmok 7y ago
Not parent, but I can share my own experiences as to why you might not want to share business logic. The short answer is you couple your microservices together and bring yourself one step closer to a distributed monolith with all its attendant pros and cons. This is especially so if you're in an OO world where data and logic are coupled together so that sharing business libraries often entails sharing business data models. This is also aggravated by the fact that the nature of business logic makes backwards-compatibility difficult to achieve (behavior often changes even if the programming API remains the same). This means changes to business logic libraries often require all downstream users to upgrade immediately or risk inconsistency (which negates the purpose of using a single library in the first place). Shared libraries when using microservices really only work well if it's reasonable to have multiple versions of that library running across different services. In other words, to some degree the sharing is only coincidental in nature. The conventional wisdom around microservices as far as I'm aware is to try to segregate services by business function (rather than e.g. segments of your domain model) to minimize sharing of business logic. Extensive sharing of business logic is a good indication your services are not split across proper lines. Of course getting these divisions down is really hard and therein lies the heart of why getting microservices right is hard.
- maxxxxx 7y ago
  "Of course getting these divisions down is really hard and therein lies the heart of why getting microservices right is hard. " I think you can only get this right if you deal with pretty mature processes that are well understood.
shados 7y ago
Imagine you have a React/Redux app with Rest endpoints. You have a dumb "Button" component. You share that with all the other apps. The Button is in React. You now tie your entire ecosystem to React. Not having individual apps have to agree on dependencies is one of the benefits of micro apps, and you lost that. However, you only lost that for React, which many people agree is pretty darn good and not going anywhere. That's a tradeoff we take. Pure React components are also well encapsulated, so whatever the opinions are behind the Button doesn't pollute the apps. App owners are still free to architect their apps however they want: their only hard requirement is React. Now, imagine you have a Medium style text editor built with React, Redux, and rest endpoints, complete with automatic draft save, a working publish button, onboarding experience, etc. If you share that, now all your apps have to agree on: backend, authentication, I18n, Redux, state management architecture, it probably uses local storage and cookies, is opinionated on what you do when logged out, and so on and so forth. If you bring that editor in an app, you're now tied to all of this. If 100 apps use that editor, and they want to upgrade Redux in the editor, they all have to upgrade to get back to the same version. If you change the backend, you have to also upgrade all apps or keep the old endpoint forever. If you want to add an I18n language, you will have to rebuild/redeploy everything. If you don't encapsulate your state, its architecture will pollute the app, but if you do you're likely going to have a much more bloated library (more bytes, slower download). Apps are no longer free to make their own decisions. It gets worse if you have transitive dependencies. Your app depends on A that depends on B that depends on C. Your app also depends on C. C releases a new version that your app wants. You now need to either bundle two versions of C, or upgrade the world. If C has global side effects, bundling 2 versions of C might not even be possible at all. These kind of "full stack components" are tech debt the moment they hit your apps. As the other reply to your post stated: you end up with the worse of both worlds. All the costs of micro-apps, with all the costs of a coupled monolith TOO. Its much worse than if you had picked either one or the other.

marcosdumay 7y ago

> sharing actual business logic through libraries is often a bad idea (which is unintuitive to most). Having being there and done that, I would only like to put some extra emphasis on that "often" word. Yes, it mostly does not work, but there are exceptions.

cheez 7y ago

A few hundred apps? What problem are you guys solving?

shados 7y ago
All the problems :) We have a lot of products falling under the same umbrella. But keep in mind a lot of these are small (a few thousand lines of code), and that includes internal apps (built on the same stack).
- thdespou 7y ago
  100s times a few thousand == a few million. Thats a lot!

KuhlMensch 7y ago

Nice write up. How big is your team?

shados 7y ago
A few hundreds.