;
;

Kubernetes on AWS… Cool Your Jets

When AWS joined the CNCF everyone got so excited for hosted Kubernetes, and the clickbait articles were produced en masse.  As much as I would love an AWS managed K8s, I am not holding my breath. I have a couple reasons for these reservations.

The CNCF is not Kubernetes

Kubernetes is definitely a high profile tool in the CNCF, but it is not synonymous with the CNCF.  A quick perusal of their charter shows it to be an organization based around the idea of being cloud native with three core principals:

  • Container packaged
  • Dynamically managed
  • Micro-services oriented

This is why so many tools fall under their rubric and I would not be surprised to see AWS contributing to the ones it is interested in as they did with Containerd. They may also be interested in making K8s easier to run on EC2, but I wouldn’t see them making huge strides towards that end aside from contributing to Kops. AWS has at least some interest in another CNCF project Etcd, a core component of their Blox framework.

AWS Almost Has All The Things

AWS has a lot of powerful tools that can be cobbled together to reach a close approximation of the features that K8s offers. The core building block is the EC2 Container System, which is a simple orchestrator that you can integrate with other AWS tools. The problem is, you need a thorough understanding of all the tools and it takes a lot of manual configuration. Overall it is an incredibly unwieldy and tedious process, but that doesn’t mean that this could not be greatly improved with a little tooling. Here are some things that should probably be fixed first.

Service Discovery

Sure you can add a network plugin, but that needs to be maintained and updated.  You can use ALBs if all you use is http and want to pay for them, but they are also very clunky, where you have an ALB per service or path based routing on the ALB for each service.  I don’t know the future of the ECS networking but it may try to address some of these issues.

Managing Volumes

The abstraction K8s built into Persistent Volume Claims is a great method for managing persistent data in a microservice environment. It would be great if we could see the same thing within ECS using EBS and EFS.  As it stands now these must be manually managed on your EC2 instances and your containers.

Managing Secrets

Parameter store is a great tool but the fact that you can’t assign secrets as environment variables and need to actually interact with AWS (CLI or SDK) to retrieve the values, is unfortunate. It seems like it would be a small fix since all tooling around permissions and such is already there.

Almost There

If AWS was able to improve the above and make coordination between their underlying core services and their task definitions easier, ECS would become a much more formidable tool in the orchestration space. Business wise it would also seem more prudent to make these small improvements in ECS as the K8s landscape is rapidly developing, and AWS has little control to steer it in the direction that serves them best.

Adrian Cockcroft’s Blog

There has been an ongoing debate within Container Solutions about AWS offering hosted K8s. I even have a €50 bet that they won’t be offering hosted K8s. That being said I was under the impression when AWS joined the CNCF I would have to buy the office €50 worth of beer. Many of us, myself included, believed that this move could mean AWS hosted K8s was on the horizon. My conclusion was further buoyed by the fact that around March Blox development had really stagnated (that seems to be changing).

Then we all read Adrian Cockcrofts’s blog

The key take away from his blog for many of us was the fact that they planned on releasing the aforementioned ECS Task Networking plugin.

Our forthcoming ECS Task Networking capabilities are written as a CNI plugin, and we expect CNI to be the basis for all container-based networking on AWS.

To myself and others this was a sign that AWS was not only sticking with ECS, but they may also be looking to address some core issues that ECS poses.

Let’s Wait And See

I personally don’t think AWS has any plan to provide hosted Kubernetes, but I could easily be wrong. I am pretty sure this November this debate will be put to rest. I expect at re:Invent AWS will drop some big announcements around containers and container orchestration. Until then we will just have to wait and see, and probably cool our jets.

The following two tabs change content below.
Jason is an architect who has 10 years of experience in building integrations, who still doesn't hate SOAP. He is a devout student of the K.I.S.S. philosophy. He has become focused on the building cloud native systems from all the tools. He is also a certified AWS Solutions Architect, and runs the Docker Randstad meetup.

Latest posts by Jason Smith (see all)

1 Comment

  1. My money is on AWS launching a Hybrid K8s deployment/management service at re:Invent, which (using an AWS analogy) will be more like OpsWorks than Elastic Beanstalk i.e. the service will most likely deploy K8s on AWS resources (using something like Kops), allow you to manage/upgrade the service (maybe with kube-adm), and then you can deploy ECS task definitions as pods (with tight integration with IAM and other AWS offerings). Fundamentally this will be a non-managed service though…

    At the same time as this is launched, I would also bet the ECS gets polished as mentioned above, and becomes a managed service with a focus on single-click deploy and operate – i.e. more like Elastic Beanstalk 🙂

    This offers the best of both worlds: people who are threatening to walk away AWS if they don’t offer K8s will be addressed (and the tight integration with IAM and other AWS services will keep people on the platform), but it won’t be an offering that is as easy to use as something like GCP’s GKE – and hence people that want a container platform that is more “managed” on AWS will use ECS

Leave a Reply

Your email address will not be published. Required fields are marked *