<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>Personally I think you should migrate your application to <code>container</code> format firstly as it is. It's more difficult than our thought in real work.
Yes, it's regardless of multithreading.</p>

<ul>
<li>First step (most important) : migration of application to <code>container</code> as it is.</li>
</ul>

<p>Then you start to refactor or to split info small services, this task should be proceed as other branch while operating the existing system which is migrated to <code>container</code> ways.</p>

<p>Rather more important thing is migration of your application or service to <code>container</code> manner. You can get the benefit of automation as of that time.</p>
