like another commenter said, start small. if your application(s) follow the twelve-factor app methodology[1], containerizing them should not be challenging. tha

like another commenter said, start small. if your application(s) follow the twelve-factor app methodology[1], containerizing them should not be challenging. that is the first step. we are in the middle of a somewhat long rollout of Kubernetes by one engineer (me). by far the most time has been spent on making our applications work as twelve-factor applications, but a lot of that work happened before I even touched a Dockerfile. we're at the point that our development team is currently using Kubernetes locally as their development environment (but not yet in production). while at times I have had moments of self doubt and questioned our decision and approach, there have been many moments where the benefits have been made clear as day. the engineers are happy with the flexibility and consistency that Docker containers have brought to development, but it has come with more operational complexity. ultimately, you need to decide what your target scale is for your engineering organization in 3, 6, 12, 24 months.. we are in the beginning stages of a rapid growth phase for our engineering team, and developing complicated cross-cutting concerns for our products was becoming cost-prohibitive simply because our development environment was too complicated to setup, maintain and debug. containerizing it temporarily relieved that pain and bought us time to then focus on scaling up those changes to production when appropriate. [1]: https://12factor.net/ https://12factor.net/