Do you move your legacy or behemoth systems to containers? | Hacker News Reader

Do you move your legacy or behemoth systems to containers?

I work in IT but has never been responsible for the operations of a large information system (say, PeopleSoft installation, or some legacy systems).

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/CD system (in my case on GitLab).

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).

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?

Or something else?

View on HN

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.

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.

Reply on news.ycombinator.com