<div dir="ltr"><div><div>Perhaps this is out of scope for Almighty, I was first contributing to the discussion merely based on</div><div>thoughts I had coming from the Catapult idea.</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span></div><div>Catapult demonstrated how a process of configuring tools, CI/CD pipeline, etc. for a new project </div><div>could be reduced from days (or more) to minutes. One way for me to consider the potential benefits</div><div>of this capability is to compare it to Maven. To list some of the benefits that Maven brought to</div><div>Java in a more-digestible convention-over-configuration way:</div><div>- archetypes for easy kickstart</div><div>- coordination of build dependencies between modules (local and remote) and their versions</div><div>- standard configuration format to enable better 3rd party tooling</div><div>- possibility of performing build, executing all tests, and even deploying to environment in a single command</div><div><br></div><div>Relate that to microservices today. It would be nice to have</div><div>- an efficient way to create a new repo for language X that includes a default build/test/deploy</div><div>- a simple, standard way to describe relationships between repos and external services</div><div>- language agnostic builds (e.g., via Jenkins) that trigger downstream builds based on repo dependencies</div><div>- repeat for language Y</div><div><br></div><div>This is more complex than Java since rather than a native API call the communication between modules may be </div><div>RESTful or messaging-based or other, but tools like Arquillian allowed us to perform the same even within a single</div><div>"mvn install" build: spin up an environment and perform integration testing.</div><div><br></div><div>Certainly the same tooling could be applied to a mono-repo but without an approach to reduce the start-up time for</div><div>the build/test/deploy pipeline and to simplify the inter-repo dependencies, it seems too costly to scale many repo.</div><div><br></div><div>This would be most valuable for loosely coupled services with well defined APIs since you must give up the </div><div>ACIDity that's inherent in a hg or git mono repo.</div><div><br></div><div>Regards, Travis</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 26, 2016 at 4:33 AM, Max Rydahl Andersen <span dir="ltr"><<a href="mailto:manderse@redhat.com" target="_blank">manderse@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<div style="font-family:sans-serif"><div style="white-space:pre-wrap"><div dir="auto">Hi Travis!
</div><div dir="auto">
</div><div dir="auto">I agree that today many-repo are problematic at a large scale.
</div><div dir="auto">
</div><div dir="auto">I'm not sure the issue can be "fixed" at Almighty level alone since I think
</div><div dir="auto">the main issue around this is the limits of git (does not have good composition/submodule support)
</div><div dir="auto">and the whole infrastructure around the "one project=one repo" idea.
</div><div dir="auto">
</div><div dir="auto">But I'm all ears for suggestions on how we could help improve it - it sounds
</div><div dir="auto">like you have some thoughts on it. Care to share ?
</div><div dir="auto">
</div><div dir="auto">/max
</div><div dir="auto">
</div></div><div><div class="h5">
<blockquote style="border-left:2px solid #777;color:#777;margin:0 0 5px;padding-left:5px"><div dir="ltr">I think my point was missed (probably not worded clearly). I am not mixing microservices and many-repo but relating them.<div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Regards,</div><div>Travis Brown</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 22, 2016 at 12:41 AM, Baiju Muthukadan <span dir="ltr"><<a href="mailto:bmuthuka@redhat.com" target="_blank">bmuthuka@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Travis,<br>
<br>
On Thu, Sep 22, 2016 at 10:45 AM, Travis Brown <<a href="mailto:tkbrown@gmail.com" target="_blank">tkbrown@gmail.com</a>> wrote:<br>
[...snip...]<br>
<span>> If the ALMighty project claims to make it easy to go from new<br>
> project (and usually new repo) to production microservice but was in<br>
> turn developed with a model that does not fit the goal it is<br>
> enabling, then we are not eating our own dog food.<br>
<br>
</span>I think it's not a good idea to mix Monorepo and Microservices.<br>
Monorepo is all about how we are going to organize source code in a<br>
single repository. Whereas Microservices is an architectural style.<br>
<br>
Martin Fowler describe it this way [1]:<br>
<br>
The microservice architectural style is an approach to developing a<br>
single application as a suite of small services, each running in its<br>
own process and communicating with lightweight mechanisms, often an<br>
HTTP resource API.<br>
<span><br>
<br>
> I think the problems favouring a monorepo are possibly the same<br>
> problems this project should help solve.<br>
<br>
</span>That's a good thought!<br>
<br>
I would like to quote the entire comment by my friend Sajith in FB<br>
post [2]:<br>
<br>
Found Conway's Law to be true in almost all the cases -<br>
<a href="http://www.melconway.com/research/committees.html" rel="noreferrer" target="_blank">http://www.melconway.com/resea<wbr>rch/committees.html</a> - "Organizations<br>
which design systems are constrained to produce designs which are<br>
copies of the communication structures of these organizations"<br>
<br>
Would one team be responsible for all the microservices or would you<br>
have multiple small teams, each one with responsibility for a small<br>
part of the overall system? Also how would your delivery pipleline<br>
look like? Would each service have it's own build/test/deploy<br>
pipeline?<br>
<br>
If you have independent teams owning the services like<br>
<a href="https://gotocon.com/.../KevinGoldsmith.." rel="noreferrer" target="_blank">https://gotocon.com/.../KevinG<wbr>oldsmith..</a>., Netlfix,<br>
<a href="https://sudo.hailoapp.com/.../journey-into-a.../" rel="noreferrer" target="_blank">https://sudo.hailoapp.com/.../<wbr>journey-into-a.../</a> etc - organizing<br>
each service as a folder or git submodule brings with it a lot of<br>
other questions (versioning together, tight coupling)<br>
<br>
The definition of a service, microservice, macroservice,<br>
mediumservice vary wildly depending on who you talk to these days :)<br>
<br>
Guess it depends a lot on how you slice your services up and how<br>
that reflects your team structure - The complexity could be either<br>
in modules or in the interstitial glue.<br>
<br>
If you want to build, test, tag/version and deploy services<br>
independently, how would a monorepo work?<br>
<br>
Independently deployable services brings with it further complexity<br>
(discovery, increased surface area for failure etc) - but if your<br>
team structure supports that, you could rely on tooling to make it<br>
less painful<br>
<br>
<br>
[1] <a href="http://martinfowler.com/articles/microservices.html" rel="noreferrer" target="_blank">http://martinfowler.com/articl<wbr>es/microservices.html</a><br>
[2] <a href="https://www.facebook.com/baijum/posts/10154503962859641" rel="noreferrer" target="_blank">https://www.facebook.com/baiju<wbr>m/posts/10154503962859641</a><br>
<div><div><br>
Regards,<br>
Baiju M<br>
<br>
______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/almighty-public</a><br>
</div></div></blockquote></div><br></div></blockquote>
</div></div><div style="white-space:pre-wrap"><div><div class="h5"><div dir="auto">
</div><blockquote style="border-left:2px solid #777;color:#777;margin:0 0 5px;padding-left:5px"><div dir="auto">______________________________<wbr>_________________
</div><div dir="auto">almighty-public mailing list
</div><div dir="auto"><a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a>
</div><div dir="auto"><a href="https://www.redhat.com/mailman/listinfo/almighty-public" style="color:#777" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/almighty-<wbr>public</a>
</div></blockquote><div dir="auto">
</div><div dir="auto">
</div></div></div><div dir="auto">/max
</div><div dir="auto"><a href="http://about.me/maxandersen" style="color:#3983c4" target="_blank">http://about.me/maxandersen</a></div></div>
</div>
</div>
</blockquote></div><br></div></div>