
Do you move your legacy or behemoth systems to containers? - BrandoElFollito
I work in IT but has never been responsible for the operations of a large information system (say,  PeopleSoft installation, or some legacy systems).<p>I do a lot of amateur containerization (also for non critical production systems and a lot at home) and I find it fantastic to drive everything through a checked-in Dockerfile which is handled by a CI&#x2F;CD system (in my case on GitLab).<p>While I understand to a point the advantages, I am wondering what kind of roadblocks there are to move existing large systems to that paradigm (the ones which are rebuilt and upgraded anyway, usually with all fingers crossed).<p>Is this a performance issue? Deep incompatibility? Fear of going into a non supported space? The fact that experts in these systems, as good as they are, never cared to peek outside of their comfort zone?<p>Or something else?
======
BrentOzar
What’s the pain you’re trying to solve?

Start by asking the users and managers of the large legacy system, “what are
your pain points?” Typically you’ll find that the pains have nothing to do
with the ability to deploy quickly or start up lots of little containers in
different places.

These large legacy systems are rarely installed from scratch, and have all
kinds of complex setup configurations that we’re done by outside consultants
or vendor employees. Folks may not even know what it would take to rebuild and
redeploy the system from scratch. There’s no ROI for the company to take risks
by redeploying it in a different way.

It’s like asking, “Drones are awesome. Why don’t train companies switch over
to them?” You have to first understand the problems that train companies need
to solve. If you really wanna get drones into that market space, you don’t
talk to the train companies: you talk to the train customer’s companies, find
THEIR pain points, and use new technologies to win the customers over.

That’s exactly what containers are doing: they’re being used by brand new apps
that disrupt legacy systems.

~~~
nmcfarl
On the other hand after asking the managers of an actively developed legacy
system you might find bringing on new devs, or up new testing or integration
environments is a major pain point.

That the skills to rebuild are in house - it's just that the process takes so
long that bringing up a new environment stops other tasks. (The users here
might say that bringing new features on line is taking too long)

In which dockerizing, at least for development, might be a very good thing.

But starting with the pain and talking to the managers and users is absolutely
the right first step.

