<p>My company has a poorly designed system that runs several services in WebSphere.  The services currently communicate directly with each other causing poor performance.  To address this, they have added several areas of multithreaded code throughout the services that make up the system.  I realize that this is not the best solution.</p>

<p>Now, the company has decided it's time to move to a more modern set of tools, and we will be migrating all of these services to run in Docker containers managed by Open Shift / Kubernetes.  (I hope I'm saying that right)  </p>

<p>My worry is that all of this multithreaded code is buggy and difficult to maintain.  I'd rather use a Messaging type of design that eliminates a lot of our service to service communications.</p>

<p>Can someone with some experience in these areas give me some good talking points as to why it's a bad idea to implement your own multithreaded code in the environment like the one we are moving to?</p>

twindham
<p>I cannot think of any inherent downside of running a multithreaded application on a single JVM instance (which is what a Docker container will translate) regardless of the environment. A lot of Frameworks, like Spring are already multithreaded.</p>

<p>I must say that your problem statement is a bit too broad to identify what you need help with, but, herewith nonetheless: I get the sense that the concurrency implementation in the application itself is the main concern here. In that case, I would say first look at the dangerous multithreading violations like race conditions, thread starvation, deadlocks, objects that are not Thread-Safe objects, etc. In my experience, these are some of the underlying issues with multithreaded applications. Once these are fixed, there should not be any reason to worry about moving to a different runtime environment like a Docker container, etc</p>
