If you’re still not convinced about Kubernetes yet, Caylent has discussed the benefits of the platform at length here, here, and here. Amazon’s recent announcement that EKS—AWS’ Kubernetes managed service offering—is now generally available (as of June 5th) will have turned heads in the container world. Those who have been waiting with baited breath to see just what AWS is weighing into the container environment battle with can relax. So, how does EKS hold up against the Azure Container Service (AKS) and Google’s own Google Kubernetes Engine (GKE)?
Amazon EKS (EKS)
Given that 63 percent of container users are using AWS—according to a survey by Kubernetes—EKS is well-positioned to become a popular way to manage containers. However, what AWS makes up for with its 140+ products and services, seems to be sadly lacking in its EKS offering. That being said though, it’s only just out of beta and its very early days.
- AWS has an extensive, comprehensive collection of well-written documentation and the backing of a large community who can provide high-level expertise—which is to be expected as the largest provider of the three.
- A plethora of well-established services that integrate through AWS products easily.
- EKS helps provision Kubernetes management infrastructure across multiple Availability Zones (AZs), replace unhealthy infrastructure, and removes any worry about downtime.
- Not just click-and-play:
- The cluster parameters form has a couple of elements which require you to go elsewhere to set-up (i.e., creating an IAM role manual; easy if you know-how, but I couldn’t see a reason this isn’t automated).
- During CloudFormation, I also had to copy properties from help documents to the parameters form. Why not make this default?
- Pricing is high: $0.20 per hour x 750 hours in a month = $150 + worker nodes for a cluster per month.
- Worker nodes need to be added in through CloudFormation: This is great for role separation, but not for a simple integrated setup.
- Slow build time: Creating the management plane alone took over 7 minutes, and a further 5 minutes to add a node pool in.
- Interface is bare-bones: Can’t access any deep level elements of my cluster.
Need to switch between services to locate information: Which is fine, as long as you know exactly where to look—EKS is not very novice-friendly.
Azure Container Service (AKS)
If you have a heavy focus on Microsoft and their tools, then AKS makes sense as a natural solution. Plus, Microsoft is continually attempting to improve its services. Furthermore, as Azure supports Linux well, it’s possible to deploy hybrid containers—though this comes with some limitations.
- Improved interface: Azure offers more than AKS in the way of its interface. However, it’s still not as clear and concise as GKE.
- Azure has some great business intelligence tools, and like all their offerings AKS plays nicely with all of them with no problems.
- Cost: Free service, you pay for resources used.
- The GUI interface and the CLI interactions: For me, these are two of the biggest drawbacks with using AKS.
- Unnecessary steps to achieve elements of the process: Azure provides two tools, Azure CLI and the Azure PowerShell. As a Linux user, I sometimes have to switch between the two to get the best possible results according to online documentation. For example, I created an SSL certificate recently on Azure PowerShell which cost $300. Except I can’t export it from the console or from the CLI I have on Ubuntu. I have to find a Microsoft machine to do it. And I have strong feelings about Microsoft. Few of them positive.
- In AWS and GKE, it feels like I’m only forced from the console CLI 3-5% of the time. For Azure, the percentage feels like it’s at least 10-20% of the time.
- Kubernetes adoption is higher on AWS and GKE: Larger support communities available there.
I’m trying not to be biased here, but who am I kidding? I’m a big fan of GKE—I recommend its use to a large portion of our clients. Google is responsible for the creation of Kubernetes, which gives working with this platform several immediate advantages. The largest of those being that service upgrades and new versions are instantly available while other platforms play catch up. Here’s a list of the other benefits in favor of GKE.
- Google is a pro-DevOps platform: Making it attractive to organizations that want to better automate deployments and integrate the cloud into its internal network.
- 2-click deployment: What more do you need to say really.
- Fast cluster creation: Create a working cluster in 3-5 mins max.
- Cost-effective: $0.19 per hour, and offers up to 30% discount for sustained use.
There are some downsides though for GKE—see, I can be impartial.
- Great interface and working integration with other Kube objects: This includes all the following:
- Can deep-dive into all the components of the cluster.
- Can fully edit YAMLs.
- Easy connection to Kube.
- Supporting services aren’t as well-integrated as AWS’ through the entire platform.
- No comparative integration of IAM with AWS or Active Directory with Azure.
- Documentation is often missing crucial elements of supportive information.
- Doesn’t have the same level of small business support that AWS and Azure can provide.
Admittedly, EKS is still the new kid on the block when it comes to weighing into a saturated container environment of Kubernetes-support offerings. If you’re already tied into AWS or Azure then it makes sense to use the offerings they both provide. It all depends on what platform you’re comfortable. As a preference, under no outside influence, I will continue to advise using GKE for greenfield projects. Until AKS parries with a better solution.
Caylent provides a critical DevOps-as-a-Service function to high growth companies looking for expert support with microservices, containers, cloud infrastructure, and CI/CD deployments. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases, learn how we work with clients, and profit from our DevOps-as-a-Service offering too.