3 ms·
I know a mid-sized company who have a team of 3 people dedicated to managing their Kubernetes clusters. For a small company that can't afford the overhead of th
by bcoughlan 8y ago
I know a mid-sized company who have a team of 3 people dedicated to managing their Kubernetes clusters. For a small company that can't afford the overhead of that, it's an extra layer of risk and complexity.
Amazon EKS launched last month in the EU west region, which I was excited about. But each cluster is $150 per month (20c per hour) before you even add any servers. To have a dev, qa and production cluster we're looking at $450 per month before the cost of EC2 instances to actually run the application. Our EC2 costs for backend services are about $800 per month, so it instantly negates the selling point that we can use reduce costs by using resources more efficiently.
Our current deployment setup is groups of Docker services deployed to a set of EC2 instances via Docker Compose with a load balancer in front of each server group. Having isolated server groups means that outages are isolated to particular areas. I don't know how long we'd be down if there was an issue with the Kubernetes cluster. If we introduced Kubernetes it would be left in the hands of a couple of developers to manage, which is the opposite of the DevOps culture we strive for.
We stay cloud-agnostic so it's easy for a developer to spin up a stack of dependent services with Docker Compose (Nginx, Redis, RabbitMQ etc.) when working on changes to a service. For a developer to run services locally with Kubernetes, they need to set up MiniKube. Many corporate environments have tight integration with Windows and our developers run Linux in a VM. I experimented with getting MiniKube to run in a VM but found it hard to get going with the vm-driver=none option, and it's something I definitely didn't want to add to our onboarding process.
Kubernetes has a serious hype train at the moment reminiscent of the MongoDB days. My inner conspiracy theorist says that this is because Google has a vested interest in preventing vendor lock-in on cloud providers. It solves a Google-sized problem and introduces some complexity with the promise of removing more complexity than it adds. For small to mid sized companies, however, it adds far more complexity than it removes.
- StavrosK 8y agoTo be fair, you don't need three clusters, you only need one and you can namespace things.
- bcoughlan 8y agoMaybe I'm oldschool but I'd be quite wary about mixing anything in production, qa and dev environments.
- matwood 8y agoThat's not old school, it's pragmatic. For example, if all your environments are namespaces in the same cluster, how do you test cluster changes before running them on prod?
- geerlingguy 8y agoAlso, how do you test cluster K8s upgrades, cluster instance type changes, etc. These things aren't just magic and could definitely impact production systems, so you have to have at least one non-prod cluster running.