<div dir="ltr">There's a bit of fashion and some technical aspects, too.<div><br></div><div>If you know the advantages and disadvantages of both approaches, putting a whole stack into a container can be a good option, but because of the fashion thing, you could draw fire from folks who know less than you but have heard the "one process per container is good and right" dogma. You'll have to defend your decision against the views of those who are less experienced.</div><div><br></div><div>And as things change, you might wind up breaking apart your monolithic stack to accommodate change. Folks might see that as an "I told you so" moment and not as evidence of your ability to handle changing circumstances.</div><div><br></div><div>So I think I'm going to tend toward breaking things apart from the outset in future projects.  The docker-compose tooling has become pretty convenient, and multi-layer builds make it easier to create containers that do just what is needed for specific jobs.  It will reduce the need for me to explain myself and will also avoid growing pains if later it turns out broken-apart services are warranted.  The cost of starting out with a more modular, multi-container architecture has gone way down in the last few years, and doing what people expect can be a win.</div><div><br></div><div>But a modular, multi-container system is not necessarily running on multiple hosts.  High availability is a whole different question.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 3, 2020 at 8:55 AM Jim Kinney via Ale <<a href="mailto:ale@ale.org">ale@ale.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why one application per container? Why not one container per project?<br><br>Take the basic web pile: web gui front end , logic layer, and backend database. The only part that changes in use is the data stored by the backend. Pre-container days it all ran on a single host. Or virtual host. Or maybe the database ran on a beefy system and multiple front/logic layers fed it.<br><br>If the project requires multiple parts to run, why not put them all in a single container? Assuming, of course, the size of things makes sense.<br><br>I ask because I've run into the issue where a critical application, composed of multiple containers across multiple hosts fails because a host is rebooted, a network issue, other normal problems. <br>-- <br>Computers amplify human error<br>Super computers are really cool_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="https://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">  Ed Cashin <<a href="mailto:ecashin@noserose.net" target="_blank">ecashin@noserose.net</a>></div></div>