3 ms·

In 8-12 months EKSA will either be very successful or will die, because it’s up against incumbent on-prem k8s so teams will either quickly see the benefits or i

In 8-12 months EKSA will either be very successful or will die, because it’s up against incumbent on-prem k8s so teams will either quickly see the benefits or it’ll quickly be dismissed as useless. The target market seems to be infrastructure admins who have on-prem VMs and an AWS account and don’t like running their own K8s clusters. No idea what that market looks like in terms of size or interest in something like this, but I’m sure AWS did their homework.

nwatson 5y ago
My company committed to AWS-native EKS, didn't want to deal with the management headache of on-prem or self-deployed Kubernetes in AWS/GCP, presumably AWS support is pretty good, DevOps is happy so far. One anecdotal win for Amazon.
- whoknowswhat11 5y ago
  Not directly related, but ECS Anywhere has been a pretty OK experience. Same - locally no one wants to run the admin plane, but folks are happy to see some beefy machines in their AWS account. Problem is usually if data is in AWS, you want compute locally - the on prem has the bandwidth charges so need to be careful there.
tyingq 5y ago
A cloud-hosted AWS console changing configs on an on-prem vSphere cluster doesn't sound like something that's going to appeal to a broad audience to me. There's also the option of having your on-prem EKSA cluster have a hard dependency on the cloud AWS IAM. Youch.
jon-wood 5y ago
I'm not convinced the target market is people who run their own data centres, those people are highly unlikely to migrate the control plane to AWS. To me the big target markets here are: * People running compute on AWS, but content distribution on their own hardware co-located at ISPs, those CDN nodes need to have the software running on them managed, and I can see the appeal of doing so with the same control plane everything else uses. * Organisations running heavily distributed compute, either for the purposes of latency or resilience. Many large retail chains have small remote nodes running the PoS systems at each site so that they can continue making sales and tracking inventory in the case of a central outage. Again, seems like it would be nice to just treat those nodes as an extension of the central servers on AWS. * (Somewhat more dubiously) IoT providers. AWS have a couple of services which are much better suited to managing IoT devices, but I could see some arguments for treating an IoT hub as a k8s node and just deploying new containers to it when updating.

nwatson 5y ago

My company committed to AWS-native EKS, didn't want to deal with the management headache of on-prem or self-deployed Kubernetes in AWS/GCP, presumably AWS support is pretty good, DevOps is happy so far. One anecdotal win for Amazon.

whoknowswhat11 5y ago
Not directly related, but ECS Anywhere has been a pretty OK experience. Same - locally no one wants to run the admin plane, but folks are happy to see some beefy machines in their AWS account. Problem is usually if data is in AWS, you want compute locally - the on prem has the bandwidth charges so need to be careful there.

tyingq 5y ago

A cloud-hosted AWS console changing configs on an on-prem vSphere cluster doesn't sound like something that's going to appeal to a broad audience to me. There's also the option of having your on-prem EKSA cluster have a hard dependency on the cloud AWS IAM. Youch.

jon-wood 5y ago

I'm not convinced the target market is people who run their own data centres, those people are highly unlikely to migrate the control plane to AWS. To me the big target markets here are: * People running compute on AWS, but content distribution on their own hardware co-located at ISPs, those CDN nodes need to have the software running on them managed, and I can see the appeal of doing so with the same control plane everything else uses. * Organisations running heavily distributed compute, either for the purposes of latency or resilience. Many large retail chains have small remote nodes running the PoS systems at each site so that they can continue making sales and tracking inventory in the case of a central outage. Again, seems like it would be nice to just treat those nodes as an extension of the central servers on AWS. * (Somewhat more dubiously) IoT providers. AWS have a couple of services which are much better suited to managing IoT devices, but I could see some arguments for treating an IoT hub as a k8s node and just deploying new containers to it when updating.