Amazon Elastic Kubernetes Service (EKS) vs. SUSE Rancher

It is well suited when you want to have a Kubernetes cluster in AWS Cloud and want to avoid all the management overhead of maintaining your own cluster in terms of the control plane. EKS seems to be lacking in features when compared with AKS and GKE. Backups, service mesh, and monitoring have a lot of room for improvements.

Incentivized

SUSE Rancher as a management tool becomes useful on a larger scale. Small deployments not so much. If someone also requires Kubernetes capacity or storage, Rancher is an excellent choice. Also, without Kubernetes' skills, it is unlikely that Rancher deployment is going to be a success. Then again if someone else is managing your Kubernetes capacity, setting up the software's capacity will yield greater control. Rancher is not a very integrated solution similar to others in the market.

Incentivized

• Managed control plane
• Autoscaling

Incentivized

• Public and private cloud infrastructure providers based on K8s CAPI
• REST API that can be used to integrate company services with Rancher
• GUI that is easy to learn and use in daily operations
• Builtin GitOps automation solution based on Fleet project
• It is fully open source

• AWSIAM integration with Kubernetes RBAC could be better.
• Enabling some add-ons like service mesh, and monitoring will be nice instead of having to install them yourself after the creation of the cluster.
• EKS bootstrap time could be faster ...

Incentivized

• No possibility to snapshot Projects. You can snapshot and restore the whole Kubernetes cluster, but not a Project or Namespace. For this, you have to use external tools.
• You cannot detach the Rancher-created Kubernetes clusters from Rancher management.

The usability and user experience are good in general, although sometimes some errors can cause confusion, especially for those users who are not experts.

Use cases can be complex hence support as well. Problems have been solvable, but not always easily. It's great that there is support!

Incentivized

It feels like AWS is behind the EKS race, the only advantage I'm able to see right now is the support of IPv6, however, trying to promote AWS alternatives that are different from the market and more like a vendor locking solutions like ECS/Fargate have kept AWS behind and focusing on the wrong things. EKS needs to really improve its integration with the Kubernetes ecosystem and have an enterprise solution for monitoring, backups, and service mesh.

Incentivized

As we use only AWS EKS Clusters originally we were using the AWS Console and CLI but that is too limited in scope. Also, we were using AWS IAM roles to provide access to users but that was lots of extra work to have them integrated into SSO while on Rancher we have just connected our GitHub login with the Alfresco organization and that uses, in turn, Okta for SSO so provisioning for access is automatic for any developer who has been assigned to GitHub.

Incentivized

The investment for small environments is quite significant. There has to be a compelling case to enhance the areas where SUSE Rancher brings in value to make such a financial leap. There is also a free version to test the value propositions, which will help support the user's buying decisions. More clusters, more volume, more tasks and more complexity in the environment equals more value that Rancher can provide.

Incentivized

• Migrating all our workloads from ec2 VMs to containers running in Kubernetes has been a huge improvement for the management and resilience of our Infrastructure.
• EKS Upgrade process to a new version seems to be taking very long ....
• EKS creation time usually takes over 10 minutes in us-east-1, we would like faster creation times to be under 5 minutes.

Incentivized

• Shortens "Time-to-Market" factor for new business applications or implementing new functionalities. From 1 to 50 microservices-based business applications in 6 years.
• 24/7 availability, generates more money. There are many infrastructure components that are regularly powered-off for maintenance or upgrade, bur we rarely are turning off our downstream Kubernetes clusters where our business applications lives.
• Single Point of Contact with platform maintenance and development Team, eases implementation of new business applications