AWS's Kubernetes dilemma: It's a burden and a pleasure Amazon Web Services became the 800-pound cloud gorilla by catering to developers. It expects to own the container crown with the exact same strategy, touting convenience and productivity gains to users of its EC2 Container Service (ECS). There are signs, however, that this fight won’t be as simple, and that a cross-cloud …
Kubernetes has its specific uses, but it's by no means a developer-friendly container orchestrator. It's really intended for legacy style application architecture where services need tight integration.
It's more suited to migrating existing stacks into containers rather than a system to allow developers to develop their new whizzy containers easily.
Have you looked at the heavy, complicated architecture for Kubernetes? I'm sure most devs wouldn't want to roll that out in a hurry. Sure, things like Rancher allow you to spin it up more easily, but "easily" is still relative.
Compare that to Docker which has it's own built-in, easily clustered orchestration (Swarm). Sure, perhaps not as feature-rich as Kubernetes or yet as scalable, but again that's something only very large outfits are interested in at that point it'll be the systems team that implements it, not the developers.
So I wouldn't call Kubernetes the common standard - not by a long shot.
Slight misunderstanding from your side I see how it is ment to work.
Developers should not them self set up a Kubernetes cluster. They should consume and use an existing cluster by it's API. It's operations and devops engineers job to run and operate the cluster.
Developers never need to touch any of complex parts that makes it tick, just be consumers of the service.
Swarm is very very meh.
Also re the complexities of Kubernetes tools like kubeadm are becoming very good at abstracting them away. You've also got minikube for local development. You go to pretty much any devops meet up and Kubernetes is the tool of choice for container orchestration, with Mesos coming second place. I've barely heard Swarm mentioned.
No, I understood fully well. You're saying that developers shouldn't know/care which orchestrator they're using. The article says that AWS should use Kubernetes because that's what devs want. I agree with you - devs shouldn't be mucking with stuff like Kubernetes. If they honestly have no 'devops' resources and really, really need an orchestrator then Swarm is a good choice because it's part of Docker and re-uses the same API that they're using anyway.
So my point is that the article is wrong - it's not devs clamouring for Kubernetes on AWS.
Kubernetes provides a greater degree of operational automation than ECS, and as the article points out, has become the de-facto open-source framework of choice.
Most importantly, Kubernetes abstracts and therefore commoditized underlying infrastructure. Therein lies AWS' dilemma: embrace the layer on top that also makes hybrid (non-AWS) deployments more compelling, or resist it and hope it remains a niche?
For now, customers looking to run Kubernetes on AWS can use solutions such as CoreOS Tectonic or Platform9 Managed Kubernetes.
The problem is Amazon is adding adding containers on top of their infrastructure. Their chief competitor, Google, built their entire infrastructure based on containers and therefore can run them on bare metal instead of VMs.
Google is now extending out beyond their cloud to the client. So transparently they will have the container being the unit of work from client, servers, cloud, even iOT!
Amazon needs to quickly think about their approach. Amazon is using the exact same kernel as Google in all of their stuff. Their cloud, Fire devices, Alexa, etc.
The container is just a far better abstraction then VMs.
BTW, Kubernetes is just the next generation of Borg which is what Google has been using for over a decade. Amazon is really fallen behind in this aspect.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
