Live data from Hacker News

Amazon EKS – Now Generally Available

aws.amazon.com

101–110 of 140 posts

Re: Amazon EKS – Now Generally Available

#101
post #92

Earlier quoted context omitted.

Not really, the value of containers that most people have seen is that it's just a more portable package. It's easier to move between environments in a consistent way. If I do that with fancy orchestration, shell scripts, or configuration management largely doesn't matter. I can get most of the advantages with shell scripts.

As someone who has worked in an environment where thousands of machines were being deployed to, this is ridiculous. Orchestration is an area where good tooling makes an absolutely massive difference. Shell scripts are not a good tool for observability or handling rollbacks.

I didn't say orchestration provides no value. I've spent the last 15 years building orchestration systems, I believe in them. I'm merely saying the most value of containers is achieved without requiring the adoption of orchestration. What I mean by that is if you take your existing means of running non-containerized apps, and change nothing except putting your app in a container, you will see a large benefit. Now changing your existing means of deploying application and swapping that out to an orchestration engine such as k8s may or may not benefit you. If you have 1000 servers, you will mostly likely see benefit. If you have 20, you might not.

k8s or orchestration/clustering is not the only way to run containers. Amazon knows that. If I was to make a bet I say that Fargate or Lambda have much better chance of being a major money maker for AWS.

Re: Amazon EKS – Now Generally Available

#102
post #84
post #68

Earlier quoted context omitted.

Isn't it funny how Google announces free GKE stuff the day before EKS was announced AND made generally available? :-) Like Jobs issuing a press release that the App Store had hit 3B downloads the morning of the Nexus One launch.

I'd speculate that Google did it on purpose the first time (everyone knew there had to be an announcement coming, and the date of re:Invent was well known in advance.) Given what some are saying in this thread here today, I would not be the least bit surprised to learn that Google's announcement this time actually forced Amazon's hand, and that the folks on this afternoon's Amazon's twitch stream actually found out y…

Yeah, it was safe to assume they would announce something related at re:Invent, given that they had joined the CNCF a few months before, after simply ignoring Kubernetes for years.

Re: Amazon EKS – Now Generally Available

#103
post #92

Earlier quoted context omitted.

Not really, the value of containers that most people have seen is that it's just a more portable package. It's easier to move between environments in a consistent way. If I do that with fancy orchestration, shell scripts, or configuration management largely doesn't matter. I can get most of the advantages with shell scripts.

As someone who has worked in an environment where thousands of machines were being deployed to, this is ridiculous. Orchestration is an area where good tooling makes an absolutely massive difference. Shell scripts are not a good tool for observability or handling rollbacks.

Most environments (99.99%) don’t have thousands, hundreds, or frankly even dozens of machines to deploy to.

Re: Amazon EKS – Now Generally Available

#104
post #80
post #62

I find Amazon’s attitude towards the whole Kubernetes lukewarm at best. It seems they really wanted ECS to be the killer container service on AWS but when k8s took over the mindshare they reluctantly added Fargate and EKS at slow speed and with an underwhelming product. We worked with both AWS container solutions and GKE and find GKE far superior. We had to build Skycap as deployment solution for our applications on…

Amazon is extremely data driven. If their attitude is lukewarm at best then you might consider the market is lukewarm at best. People take for granted that the value of k8s has been proven. It has not. The value of containerizing your application is clear and has been realized over and over again. The jury is still out on k8s.

> The jury is still out on k8s

Not really. There aren't any real alternatives other than the dying Docker Swarm and some overlap with Nomad and Mesos. The "war" is over, Kubernetes has come out on top and is rapidly developing both as a platform and as offerings from Google's GKE and Azure AKS. Almost all Kubernetes deployments are using a managed solution of some sort, including OpenShift and the rest, so AWS is falling behind here badly with their current offerings.

Re: Amazon EKS – Now Generally Available

#105
post #95
post #86

Earlier quoted context omitted.

Do you have any actual data related to this claim or am I just supposed to assume that it's true by inferring things from Amazon's cloud offerings? Edit: Sorry for the aggressive tone, I overreacted a bit because it seems like every single day there's someone pushing an anti-Kubernetes agenda on HN. Often they don't even use it, they just glanced at the docs and said "it's too complicated", or something. Clearly, thi…

I don't mean to push an anti-k8s agenda. What I'm pointing out is that people have conflated the value of containers with the value of orchestration and clustering. They don't need to go hand in hand. Containers without orchestration has been proven to save money. It's hard at the moment to prove the real value of k8s. It's too early and there isn't enough adoption. When you look at most success cases of k8s they oft…

Makes sense. I suppose in my case it’s ease of service to service communication + deployment that’s the primary benefit. Consul could easily handle the first, but deployment could be a bit trickier. Ultimately I think if GKE didn’t exist I very likely would have ended up using Nomad and Consul for simplicity’s sake. To me it seems some sort of scheduler is necessary if you want to have an easy way to control the horizontal scalability and availability of your individual containers and not just your hosts. Unfortunately setting that up isn’t nearly as well documented as setting up a k8s cluster right now, but IMO the end result is a lot easier to comprehend. The lack of end to end documentation is really what kept me away from adopting Hashicorp’s tools instead, so hopefully that will improve and k8s can have some real competition.

All of this is in the context of a microservices architecture, though. Something I generally wouldn’t choose to do unless there were good reasons for it. Defaulting to a monolith is still the safer choice IMO, and if you are deploying existing monoliths, or a small number of services, then it’s very possible that you don’t have a need for an orchestrator at all.

Re: Amazon EKS – Now Generally Available

#106

Earlier quoted context omitted.

As someone who has worked in an environment where thousands of machines were being deployed to, this is ridiculous. Orchestration is an area where good tooling makes an absolutely massive difference. Shell scripts are not a good tool for observability or handling rollbacks.

Most environments (99.99%) don’t have thousands, hundreds, or frankly even dozens of machines to deploy to.

You're on hacker news, where technologists who run world class infrastructure congregate.

The average number of servers per people who commented this news is over one thousand.

Re: Amazon EKS – Now Generally Available

#108
post #41
post #37

Earlier quoted context omitted.

Yeah, none of the rest of the big three are asking you to pay anything for those masters at this point, though. "They're your nodes, you paid for them" seems like a reasonable position to take here.

> "They're your nodes, you paid for them" seems like a reasonable position to take here. If that were a reasonable position, you'd think AWS RDS and Google Cloud SQL would give you superuser access to your database instances to do things like installing Postgres extensions. It seems a lot of people are happy to pay for instances they can't even SSH into. :/

I don't even want to SSH to instances that I control and have provisioned, why would I want to SSH into instances managed by AWS?

Unless the point of your server is to provide SSH (you are using it as a development box, maybe?), having to SSH means that you are lacking in the tooling department.

At work we are guilty of that. We are actively trying to improve on this.

Re: Amazon EKS – Now Generally Available

#109
post #51
post #15

Earlier quoted context omitted.

ECS is their entirely custom container orchestrator. EKS is just hosted Kubernetes with AWS integrations.

Yes. ECS is better integrated into AWS. EKS is just what everyone uses plugged into AWS. Can't understand how this should be better.

Try both, you'll understand.

Re: Amazon EKS – Now Generally Available

#110
I've been so excited for experimenting with EKS ever since the announcement but this offering looks very underwhelming.

With kops [0] I can spin up a production cluster on AWS quickly and have just as much functionality (if not more control) without paying Amazon ~$150/mo for the pleasure (per cluster!). It doesn't really seem to be "managed" either.

Maybe now's the time to really start to look at GCP/GKE. I've used them for some GitLab CI stuff in the past but never invested too much time into really seeing how the transition from AWS to GCP is.

[0]: https://github.com/kubernetes/kops

Post reply on HN