[almighty] Monorepo

[Travis Brown]

I think my point was missed (probably not worded clearly). I am not mixing
microservices and many-repo but relating them.

I don't think it's feasible with open source tools today to efficiently
scale many microservices in a many-repo approach. In ALR's Push It Real
Good presentation, the complexity and startup costs for a new idea were
listed, and these are prohibitive (or at least inefficient) for you to take
on for each small project.

I was hoping ALMighty would solve this problem so that many-repo could
become a better option. And if it does solve the problem, then possibly the
arguments in favor of mono-repo are not as strong since I assume ALMighty
will eventually be maintained inside of ALMighty.


Regards,
Travis Brown



On Thu, Sep 22, 2016 at 12:41 AM, Baiju Muthukadan <bmuthuka at redhat.com>
wrote:

> 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
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160922/a0eccc89/attachment.htm>