[almighty] Monorepo

[Baiju Muthukadan]

Hi Travis,

On Thu, Sep 22, 2016 at 10:45 AM, Travis Brown <tkbrown at gmail.com> wrote:
[...snip...]
> If the ALMighty project claims to make it easy to go from new
> project (and usually new repo) to production microservice but was in
> turn developed with a model that does not fit the goal it is
> enabling, then we are not eating our own dog food.

I think it's not a good idea to mix Monorepo and Microservices.
Monorepo is all about how we are going to organize source code in a
single repository.  Whereas Microservices is an architectural style.

Martin Fowler describe it this way [1]:

  The microservice architectural style 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.


> I think the problems favouring a monorepo are possibly the same
> problems this project should help solve.

That's a good thought!

I would like to quote the entire comment by my friend Sajith in FB
post [2]:

  Found Conway's Law to be true in almost all the cases -
  http://www.melconway.com/research/committees.html - "Organizations
  which design systems are constrained to produce designs which are
  copies of the communication structures of these organizations"

  Would one team be responsible for all the microservices or would you
  have multiple small teams, each one with responsibility for a small
  part of the overall system?  Also how would your delivery pipleline
  look like? Would each service have it's own build/test/deploy
  pipeline?

  If you have independent teams owning the services like
  https://gotocon.com/.../KevinGoldsmith..., Netlfix,
  https://sudo.hailoapp.com/.../journey-into-a.../ etc - organizing
  each service as a folder or git submodule brings with it a lot of
  other questions (versioning together, tight coupling)

  The definition of a service, microservice, macroservice,
  mediumservice vary wildly depending on who you talk to these days :)

  Guess it depends a lot on how you slice your services up and how
  that reflects your team structure - The complexity could be either
  in modules or in the interstitial glue.

  If you want to build, test, tag/version and deploy services
  independently, how would a monorepo work?

  Independently deployable services brings with it further complexity
  (discovery, increased surface area for failure etc) - but if your
  team structure supports that, you could rely on tooling to make it
  less painful


[1] http://martinfowler.com/articles/microservices.html
[2] https://www.facebook.com/baijum/posts/10154503962859641

Regards,
Baiju M