A post on why using Kubernetes to scale would mean “doing mostly the same things but in a more complicated way” was so popular that the site hosting the article went down due to the sheer volume of traffic.
Maik Zumstrull is writer of code at Ably, a company which runs pub/sub (publish and subscribe) messaging services. He wrote a post titled “No, we don’t use Kubernetes” stating that the Google-invented container orchestration software is “very much at the peak of its hype cycle.”
However, he added that for what Ably does – “run a large scale production infrastructure that powers our customers’ real-time messaging applications around the world” – using Kubernetes would not help. His post appears to have been prompted by the fact that some customers and potential new recruits see this non-adoption as a problem. “We have even had interesting candidates walk away from job offers citing the fact that we don’t use Kubernetes as the reason,” Zumstrull said.
Ably seems on the face of it to be a good candidate for Kubernetes. “Our entire production environment exists on AWS,” said Zumstrull, with virtual machines running Docker and software deployed in containers.
He claimed that the features of Kubernetes were not required. Each VM instance is deployed to run a certain set of containers, which does not change for the life of the instance. Each set of containers maps to an AWS Auto Scaling group. There are “lightweight monitoring services” on each instance that monitor container health, respawn one that dies, and terminate the instance if a container goes out of date. “Because one autoscaling group equals one production service, we can use the normal AWS method of pointing one NLB [Network Load Balancer] at one autoscaling group as the target group, with no additional abstraction layer required,” he said.
The company has investigated Kubernetes and reckons it “would need at least ten clusters (one for each of ten regions).” Zumstrull said: “We would be doing mostly the same things, but in a more complicated way.” What about the benefits of Kubernetes, though, such as multi-cloud portability? Zumstrull is a multi-cloud sceptic. “The differences between the major cloud providers do matter, and Kubernetes does not succeed at abstracting them away,” he said.
Kubernetes would add cost, he argued, thanks to its complexity and the number of services that have to be configured on top of the platform.
It seems that Zumstrull’s post struck a nerve. Thanks to a discussion on Hacker News, the website was overwhelmed with traffic, causing Ably co-founder and CTO Paddy Byers to comment: “Ably CTO here. Well that went well…” Byers noted that although the website fell over (it was not just the blog), “the realtime service and website are different things. The blog post is talking about the service, which has been continuously available.”
As for the content of the post, opinions vary. “Perhaps my team runs a simpler cluster, but we have been running a Kubernetes cluster for 2+ years as a team of 2 and it has been nothing less than worth it,” said one comment; while another remarked that “my experiences with k8s have led me to never propose k8s in a new project. The k8s instances I have seen were bureaucratic and technical nightmares of unnecessary complexity. It doesn’t provide a common ground for deployments because everyone will use and configure it differently.”
The most telling comments, perhaps, were those about the benefits of standardisation and community. “Now live with your bad/good design patterns on your own for the life cycle of your product or service, you get none of the shared knowledge and advancement through the k8s community or platform,” said a Hacker News reader.
Even if Kubernetes is not the best solution now, if adoption and development continues at its present rate, it just might be in future.®