‫All right.
‫See the next question.
‫Hill says right now I run five different war files and Jay boss when I which I then connect to Postgres
‫database is on some server I am looking at compose actually going through that course at the moment
‫to set it up.
‫The question I have is should I create multiple J Bos containers with compose or just continue running
‫all five in one in production we have five different J servers
‫so
‫I would say try both.
‫If you have five different war files and J boss without being a Java expert I mean you're the Java guy.
‫What do you think.
‫Yeah I can talk a little bit into this anyways.
‫So my recommendation is it's typically been all right don't don't boil the ocean and Bret says this
‫often fancy do what you're already comfortable with do what you already know.
‫If that's where you have lots of tooling and everything around we've got a single J Bar server that
‫has lots of war files in it and we know how to work with that we know how to instrument it and everything.
‫Great to get that containerized and start working from there.
‫Personally I'm a fan of splitting that out into multiple containers and so that would probably be a
‫long term approach because I imagine for the most part your if you update one do you need to redeploy
‫the other four.
‫And so if they're all in separate containers you can deploy one you can roll out updates to one without
‫having to bring down the others.
‫They're all independent from each other.
‫Yes that means you have additional overhead you're now running five day Vos servers instead of just
‫one but I think at the end of the day there's not that much difference.
‫I mean the jailhouse application server sure does have some overhead but I would and again I don't know
‫your app at least in my experience the amount of overhead from the application server in comparison
‫to the app itself is quite low that most of the CPU memory utilization all that stuff is coming from
‫the app not from the server itself so running multiple instances of J Bos probably using it to hurt
‫you.
‫But again I don't know your your exact situation too.
‫Yeah and I think that you know getting getting server resources for that is probably easier.
‫Probably less of an issue than the fact the game the abilities you gain by having the flexibility right
‫like you can have scale one without scaling the others you can replace one without replacing the others.
‫I think this is in general this question is very similar right to other questions we get about a couple
‫a couple weeks ago we had people asking well if I have a bunch of Apache Web sites should I run them
‫all in Apache virtual servers or should I split them out in the separate containers and my answer was
‫very similar to yours Michael that I would have video that it all would work in one but eventually I
‫would be splitting the mountain separate containers because containers provide that level of isolation
‫and artifacts.
‫That gives me the flexibility for distributed computing where I can you know we can't really ever get
‫to and to micro services and this necessary it doesn't mean that your boss is micro servers yet but
‫you know to me there is there's a there's a wide array of size of applications and as we start splitting
‫things up or making different you know applications that run separately whether it's a war file or something
‫else.
‫The more we split these and isolate these things out generally the more flexibility the easier it is
‫to get uptime the easier it is to troubleshoot it.
‫It's not perfect then not everything is better right.
‫You have sometimes duplication of effort you end up with more things you've got to manage.
‫You got maybe a little bit harder network troubleshooting depending on how your apps work it might affect
‫performance if they're across the network instead of in the same machine.
‫So there's lots of things to consider but in general we're all evolving into a way where we're splitting
‫things out more and more and more when it makes sense.
‫And yeah and from my experience too.
‫Again this may not be your experience or it's going on here.
‫But know we've had several Tomcat containers or a tomcat servers that had lots of war files in it and
‫we simply did that because it was convenient at the time to spin up a new machine dish up the new Tomcat
‫and since all that stuff was it was a lot of overhead in the past and so it's fine I don't want to do
‫that I'm just going to deploy another war files so this other one it's already running it's good enough
‫and so that was more to reduce the OPs overhead and the amount of time to speed things up but now as
‫you become more familiar with containers and everything that overhead doesn't really exist anymore because
‫now it's early in the process you're building these container images and it's easier to spend things
‫up.
‫So yeah that's yeah it is a good question.
‫Yeah I mean we get the same question about databases should I put all of my databases into one my sequel
‫server or should I have multiple my sequel containers and I would say this depends.
‫What is your motivation that the cheapest thing to do is to put them all in one because it's lower memory
‫overhead.
‫It's you know probably a little less redundancy in on in terms of the necessary things you need to run
‫but most of us are splitting things out when we can in order to gain flexibility.
‫Really.