I've just started working at a large traditional hosting provider, and I'm facing a major cultural and technical hurdle. Our main business is setting up custom server environments for various clients, mostly relying on virtual machines. This includes everything from database clusters to web servers and mail servers, all done through mostly manual setups. While this method works, it's super inefficient—simple configurations can take a whole day, and major upgrades can take several days of manual work.
The company is growing quickly, but I can't see how we can scale efficiently without rooting out these inefficiencies. Every time I mention containerization as a way to improve our processes, I get pushback from senior engineers and management due to concerns about security risks, particularly around shared kernel vulnerabilities, and the fear of a single point of failure with container runtimes.
We do have an internal Kubernetes team, but they're not deploying customer apps for the same reasons the rest of the team is hesitant about containers. I want to be a positive force for change instead of just frustrated. So how should I approach this situation? Have you introduced containerization in a similar environment? How can I address the shared kernel security concerns and create a compelling case that management will consider?
6 Answers
By the way, does the internal Kubernetes team fully understand Kubernetes? It could help to get some training or insights for both sides if there's a knowledge gap.
If you're directly facing these concerns, focus on the financial aspect. When proposing new methods, frame them in terms of cost savings and efficiency gains. Management is often more receptive when they see the monetary benefit. Nobody wants to take unnecessary risks, so make sure to address that part head-on in your discussions!
What about KubeVirt? It may not be the most popular solution, but it could provide a middle ground where you can run containers within VMs and alleviate some of those risks. If you can show that you'd still use Ansible for deployment but with a more efficient structure, that might help convince them.
Honestly, they do have a point with their security concerns. Breaking out of a container can be easier than a VM. But remember, AWS Fargate runs containers securely, and you could run individual VMs while using containers within them. Focus on automating the tasks that slow you down the most. A DB upgrade is a pain, but if it only happens occasionally, it might not need priority. Instead, target the frequent, repetitive tasks to showcase the improvements. Document everything and create a compelling presentation that quantifies the benefits so the business sees the value!
Good idea! Demonstrating the efficiency improvements with clear cost benefits could help sway management's opinion.
Just be aware that selling these ideas might be tough since there are established teams that rely on current processes. However, if you can create a proof of concept or replicate what you do now in a container format in a testing environment, it could be a strong argument.
That's true, getting buy-in from existing teams is crucial. It might help to involve them early in any trials.
Automate your tasks! Everything you're dealing with can be managed as Infrastructure as Code (IaaC) using tools like Ansible, Terraform, or OpenStack's Heat. This will help you cut down on manual work significantly. And don't overlook Packer for building your images!
Absolutely! Automation is key; it helps streamline processes and reduce errors.
Yeah, KubeVirt could be an option! Just make sure you present it well; any shift like that needs to be clear and justified.