Why the Kubernetes Kids can't hurt Bezos' Amazon beast Kubernetes may be the hawtest thing in container orchestration, but Redmonk analyst James Governor has a different label for it: the "Anyone but Amazon" club. It's an interesting name for a club that includes, ironically, Amazon, but as AWS continues its march to enterprise IT domination, Kubernetes increasingly looks like a …
... but you've missed a trick here. One of the key features of Kubernetes from where I am standing is its developer convenience. The transition from minikube to kops to on-prem is pretty much seamless - I can develop on my laptop and it looks exactly the same as if I deploy to AWS. The convenience of YAML all tied up in a single deployment driver is a productivity boon. I can even do it on my Windows 10 box at home using WSL and the same YAML as I use on my OSX laptop. A big part of the puzzle is how good docker has got on local environments but it's also the way Kubernetes has been designed. I don't believe it's going away any time soon.
Except you can't, for anything non-trivial. Networking breaks, so you need something to manage firewall rules and port forwarding. You can't keep passwords in your container deployment (if you want them secure) so you need something to deploy secrets. All of a sudden you've got many of the problems of a conventional deployment.
Or you just make everything horribly insecure, which is the default option for most node.js developers anyway.
I agree with the article, and its take on some spin... I also agree with AndyPiper to a point.
Its not about developer convenience but more on lowering the cost of development and time to value.
You can build and test in small dev environments and then deploy anywhere. I can give developers a decent MacBook Pro, and then a small cluster to test local, cluster deployment. Then I can move to production either on prem or at cloud provider.
The thing about lock in... its the high cost of moving data out of the cloud or around the globe w your cloud provider.
Funny thing... IBM's new mainframe... X14 could be a game changer depending on costs.
The article somehow maanges to avoid almost all mention of Docker.
Kubernetes is a platform for deploying Docker containers, and the "consistent developer deployment model" comes entirely from Docker.
You can package up your applications in Docker, and then you can deploy the same images in a bunch of different environments (Docker Swarm, Rancher, Kubernetes, Amazon ECS, Mesos, ...)
So really it doesn't matter too much if Kubernetes dies or not: you can just move your applications on to another platform. This has already happened: CoreOS used to have a Docker deployment platform called "fleet", but they recently decided to abandon it (in favour of Kubernetes as it happens)
Not anymore I’m afraid....
Kubernetes as a project has long since recognised that docker inc is yearnon year closing up the docker ecosystem.
They’ve been shifting to an OCI model for a long time. They also support rkt as well.
This enables companies to exlmplerely avoid the vendor lock in that docker is slowly becoming bad at.
I wouldn’t be surprised if in a couple of years k8s by default starts using systemd-containerd with an oci implantation of rkt as it’s default rather than docker and supporting it only for “legacy” reasons.
Talking a bit about vendor lock it it annoys me a bit that the article focused on red hats openshift. For starters openshift is a PaaS as well as a CaaS and is very much vendor lock in in its own form. Sure; if you use openshkft just for containers then that lock-in is minimalised but they change some things in their use of k8s that make your manifests and projects incompatible completely with all the other main vendors.
If you choose to use openshift as a PaaS then you’re locking yourself into 1 vendor.
The article should of mentioned Suse. Their new CaaS Kubernetes product is entirely compatible with opstram and is a serious contender against openshift as well as coreos tectonic and rancher.
It’s also by far the most simple on premise k8s distribution to set up. You can go from nothing to a fully functioning large k8s cluster without doing anything special such as deploying matchbox. It integrates perfectly with your existing infrastructure devices as well (dns/dhcp).
Heck: with openshift you can only deploy it on top of their OpenStack! Who the hell in their right mind would deploy OpenStack if all you wanted was containers???
That’s just for CaaS needs as well.
If we’re talking about PaaS then Suse is launching their cloudfoindry based pass running on top of Kubernetes later this year. Unlike with openshift where you have to trust red hat as the sole developer of openshift with cloud foundry there are many many other different vendors allowing you to make your app development truly portable in case you decide to switch PaaS vendor. Cloud foundry is the way forward in the on premise PaaS world don’t waste (subsfanfional) money on openshift when the alternatives are cheaper, more open, avoid vendor lock in and don’t require you to deploy opensfack as a dependency of your CaaS/PaaS Platform
This post has been deleted by its author
I do not agree with the article that Kubernetes competes with AWS. Kubernetes is about containers and AWS is about fat Virtual Machines. Kubernetes in an application that floats on top of AWS or any other IaaS operator.
Kubernetes work very well on top of AWS and it would not surprise me if Amazon offers an Kuberntes-as-a-Service in the future.
Companies are gyrating towards Kubernetes because it enables true hybrid-cloud where work-loads can float freely between cloud operators.
Kubernetes was the best way google, at #3, could blow up cloud. Google has awesome infra and global scale and presense AND they know how to write original software. From android, to app store, to youtube, to search, to adwords, to docs/sheets, drive, you name it, they do this eventually get it right and take over model well.
When kubernetes was born this was not brokenstack/openstack. It was a glimpse on how google does things that work. And when you start doing stuff that matters going from kubernetes to gcp is rational. Now azure has a bill by the second container service that makes sense and I think we will see AWS abandon ecs/blox and go the kubernetes route. It was called borg for a reason. Resistance is futile. While docker ruins itself by closing up and becoming anti-standard and meso/DCOS languishes kubernetes isnt the next brokenstack for a good reason:
The production version of kubernetes is gcp! Brokenstack OPenstack had no public cloud for itself. One could argue rackspace but they couldnt keep up in public cloud with amazon and friends and died out. With brokenstack, there is no public / production cloud version of it. You own it.
But with kubernetes, get sick of it all and want to push the help me button? You dont call pivotal, IBM, you dont wait for dummies like Vmware to "help" you, you dont care - you go with gcp or with azure container service with by the second billing and be done with it.
Google's best long term troll ever was to release borg onto the world so people would use it, get tired of trying to do what gcp does and just use gcp and move on.
This is one where even amazon let it get away from them.
And frankly, anyone but scamazon. IF YOU USE AMAZON YOU WILL FACE COMPETITION FROM AMAZON ITSELF IF YOUR BUSINESS MODEL WORKS.
Did anybody actaully try to deploy and run Kubernetes on google cloud? With google's native offering. They supposed to have an amazing offering and tight integration with all their services, right?
Well, not so much.
Upgrading of the cluster works great, an engineer can do full cycle upgrade to a next k8s version in half an hour. However, the master node will go down for 1-2 minutes (!) when a manually issued cli command applied. Yup, that's right - there is no way to version-control this process. Nothing like CloudFormation.
Now, running services is a breeze. Except passing traffic in (so-called "ingress"). Sure, you can create a load-balancer for each service, that's pretty easy. But there is no DNS integration, no logs, no metrics out of that loadbalancer. And for each little micro-service running you'll need a new loadbalancer provisioned.
But that's not all that bad. There is Cloud Endpoints ("API Gateway") - where services from kubernetes can be integrated with managed API. But look up the docs of that integration for kubernetes and compare it with AWS API gateway integration for pretty much anything.
And these are just a few issues you'll run into immediately. Sure, if you're a startup - not a big deal. Each team can manage own kubernetes cluster. But if you're an enterprise that requires proper configuration management, version control of changes, availability, documentation, integration with all other systems, support - then kubernetes will be a very hard to sell.
It like openstack - but for containers.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
