4 ms·
My company (and sector for that matter) is typically 10 years behind the mainstream, so we're just transitioning a giant legacy monolith to kubernetes/micro-ser
by scottLobster 4y ago
My company (and sector for that matter) is typically 10 years behind the mainstream, so we're just transitioning a giant legacy monolith to kubernetes/micro-services now (literally installing Longhorn today).
To be honest, even with the technical overhead it'll probably solve a lot of problems for us from a workflow perspective. We've (the engineers) been arguing for more component-level testing for years (as opposed to the all-up E2E testing we're required do now, which typically turns into component-level testing anyway), and containerizing everything is a good excuse to push it into reality. It'll also make deployments a lot easier (just roll back to X image if there's a problem). Right now we have tens of thousands of lines of hand-written deployment scripts that manage everything and have to be maintained, and intimate knowledge of how they work is often limited to who wrote it (many of whom are no longer with the company), and if there's a problem you have to do surgery on the environment. Kubernetes will give us a unified deployment architecture with problems you can google.
- miscaccount 4y agoFrom my experience, making downgrade of a single component will not be easier with K8 unless you design for it. Also from my experience, people will start complaining as soon as the new deployment with k8 start failing and they have to fix it. But its a good opportunity to make the transition to more stable architecture. My suggestion is to take it slow and do changes one system at a time. Start with stateless application with less risky deployment and as you learn move others.