If you’re going to migrate a monolith to containers and run it with Kubernetes, do your due diligence on refactoring the application to maximize the benefits of such a move.
“Containers can be used for ‘lifting and shifting’ existing applications, but in order to enjoy their benefits, you should consider refactoring them,” says Rani Osnat, VP of strategy at Aqua Security. “Start with simpler, smaller applications. Taking a 2GB monolithic application and containerizing it as is will create issues in deployment and runtime since the container stack wasn’t made for this use case. Try breaking up your application into smaller logical services, so that you’ll benefit from better speed of deployment, resilience, and updatability.”
Similarly, Mugrage advises seeing this less as a migration and more as a breakup. That typically entails breaking up the larger application into smaller components, aka microservices (or at least a microservice-like approach).
“Don’t think of it as moving to containers and Kubernetes; think of it as decomposing the application,” Mugrage says. (Mugrage points to this article by his colleague Zhamak Dehghani for some additional advice on doing this.) “The real gains to speed of delivery, allowing evolution of your architecture, and all of the other reasons for moving to containers and Kubernetes are realized not from that movement, but the architecture which enabled it.”
