5 ms·

I think almost everyone was expecting this, still, it's great to see it happen. Amazon truly listens to their customers and delivers what they want, even if th

by Rezo 9y ago

I think almost everyone was expecting this, still, it's great to see it happen. Amazon truly listens to their customers and delivers what they want, even if they have their own competing in-house solution as well. I do think that for new projects, you'll see EKS being the more popular pick over ECS, which never reached quite the same mind-share as Kubernetes.

mk89 9y ago
ECS will slowly be replaced, it doesn't make any sense anymore, and AWS was totally smart to "kill" their own product. Either you do like this, or you are out. Google and Azure provide K8 since months now... Companies want more and more solutions which allow them to "easily" migrate from one cloud to another - having everything based on a proprietary solution is no go...
- andrewstuart2 9y ago
  ECS always felt rushed to me. The semantics of day-to-day operations always felt really awkward. Common things like rolling updates were a 3-step operation (or they were for us), and node replacement was a pain. It could be that we were using it wrong, but I never felt motivated to find out the right way. Kubernetes came along, I played with it briefly, and never wanted to go back. I think ECS will, and should, be retired. It was a lurch in the right general direction, but ultimately missed the mark.
  - zenlikethat 9y ago
    It WAS rushed. Amazon has customers banging on their door demanding container support in 2014 and they got ECS out the door, fast. Now it’s 2017 and Kubernetes seems to be the winner of the “orchestration wars” so they’re pivoting to that. Smart move of them to ship something and patch it up later if needed, they successfully defended against GKE’s assault and are vying to stay on top.
    - toomuchtodo 9y ago
      > Smart move of them to ship something and patch it up later if needed, they successfully defended against GKE’s assault and are vying to stay on top. If you had to release a product to support the open source front runner, you did not successfully defend against it; you conceded after your tooling adoption failed. As long as Kubernetes leads the way, lock in at any cloud provider is prevented (can even move back on-prem when the winds shift again). Kudos to Google for enabling that, but they have their own motives (ie disrupting AWS uptake).
      - zenlikethat 9y ago
        Kubernetes wasn't the front runner when ECS was released. Nobody knew what would happen. There was a distinct chance ECS could own everything, or Mesos, or Docker’s orchestration, or something else altogether.
      - tyingq 9y ago
        >As long as Kubernetes leads the way, lock in at any cloud provider is prevented That might be a little strong. They still have lots of other proprietary offerings you might use along with K8S. Cloudwatch, various database services, Lambda, SQS, S3, etc.
        toomuchtodo 9y ago
        Don’t rely on primitives without open alternatives unless you want to be chained to your vendor. Today it’s roasting Oracle during the keynote, tomorrow it’ll be today’s “underdog”. It’s easy to talk customer success when the money firehose flows. MariaDB and PostgreSQL both work well outside of RDS.
        tyingq 9y ago
        I suppose, but there's some stuff that's just hard to avoid. Like tooling to break down cloud costs, or network configuration, monitoring, provisioning block storage, etc. You can get to less lock-in, but it's hard to get to none. Last I saw, "pets" like databases, were not optimal in K8S either. You can make it work, but it's higher effort.
  - sickmate 9y ago
    >Common things like rolling updates were a 3-step operation (or they were for us), and node replacement was a pain I had the same experience until I created an ECS stack using CloudFormation, which made it much easier to manage.
  - wearer_of_hats 9y ago
    Considering that Fargate, also announced today, is essentially managed ECS, I don't think it's likely that ECS is going away any time soon. Fargate seems like a pretty substantial investment.
corg890 9y ago
They resisted vehemently for a long time, even when it was painfully obvious it was wrong, and you’d just end up having these totally surreal conversations with their ECS product manager that would make your head spin they made so little sense. Glad that’s over.
- zenlikethat 9y ago
  That’s cause it’d be way better for them if ECS “won”, but it didn’t, so they adapted. Similar to how Docker now has had to add Kubernetes support after being combative and dragging their feet for years.
  - corg890 9y ago
    It was just pride since google is their rival, didn’t make any sense otherwise.
    - yebyen 9y ago
      I'm glad that I can run Kubernetes on AWS now (again), but I still can't run ECS on my laptop... hello Amazon? Are you home?
      - zenlikethat 9y ago
        I thought that’s what Blox is for https://github.com/blox/blox/blob/dev/README.md https://github.com/blox/blox/blob/dev/README.md
        yebyen 9y ago
        Thank you!
        yebyen 9y ago
        Does this just use a tool that runs on your laptop, to schedule and manage ECS clusters on Amazon? That's really not what I was looking for... I was hoping to prototype ECS-based solutions without spending money on cloud resources. I have a laptop with 8GB+ RAM and a fast SSD, it doesn't have any trouble running fairly complex constellations on Minikube and I could later rebuild and/or install them on a production Kubernetes cluster, without any changes. Can I do something like that with Blox, or is this another different way to consume ECS and spend money on EC2 nodes to run containers? Edit: I would be satisfied if you told me, I still need to consume some AWS services like SNS and CloudWatch to use this toolkit, but that with Blox, I don't actually need to run my containers on ECS unless I want to expose them to the world. I haven't found any tutorial or guide that indicates this is anything other than a different scheduler for ECS.
manojlds 9y ago
They are at least a year late with this though. People were expecting this last year as well. And it's still a preview.

by Rezo 9y ago

mk89 9y ago

ECS will slowly be replaced, it doesn't make any sense anymore, and AWS was totally smart to "kill" their own product. Either you do like this, or you are out. Google and Azure provide K8 since months now... Companies want more and more solutions which allow them to "easily" migrate from one cloud to another - having everything based on a proprietary solution is no go...

andrewstuart2 9y ago
ECS always felt rushed to me. The semantics of day-to-day operations always felt really awkward. Common things like rolling updates were a 3-step operation (or they were for us), and node replacement was a pain. It could be that we were using it wrong, but I never felt motivated to find out the right way. Kubernetes came along, I played with it briefly, and never wanted to go back. I think ECS will, and should, be retired. It was a lurch in the right general direction, but ultimately missed the mark.
- zenlikethat 9y ago
  It WAS rushed. Amazon has customers banging on their door demanding container support in 2014 and they got ECS out the door, fast. Now it’s 2017 and Kubernetes seems to be the winner of the “orchestration wars” so they’re pivoting to that. Smart move of them to ship something and patch it up later if needed, they successfully defended against GKE’s assault and are vying to stay on top.
  - toomuchtodo 9y ago
    > Smart move of them to ship something and patch it up later if needed, they successfully defended against GKE’s assault and are vying to stay on top. If you had to release a product to support the open source front runner, you did not successfully defend against it; you conceded after your tooling adoption failed. As long as Kubernetes leads the way, lock in at any cloud provider is prevented (can even move back on-prem when the winds shift again). Kudos to Google for enabling that, but they have their own motives (ie disrupting AWS uptake).
    - zenlikethat 9y ago
      Kubernetes wasn't the front runner when ECS was released. Nobody knew what would happen. There was a distinct chance ECS could own everything, or Mesos, or Docker’s orchestration, or something else altogether.
    - tyingq 9y ago
      >As long as Kubernetes leads the way, lock in at any cloud provider is prevented That might be a little strong. They still have lots of other proprietary offerings you might use along with K8S. Cloudwatch, various database services, Lambda, SQS, S3, etc.
      - toomuchtodo 9y ago
        Don’t rely on primitives without open alternatives unless you want to be chained to your vendor. Today it’s roasting Oracle during the keynote, tomorrow it’ll be today’s “underdog”. It’s easy to talk customer success when the money firehose flows. MariaDB and PostgreSQL both work well outside of RDS.
        tyingq 9y ago
        I suppose, but there's some stuff that's just hard to avoid. Like tooling to break down cloud costs, or network configuration, monitoring, provisioning block storage, etc. You can get to less lock-in, but it's hard to get to none. Last I saw, "pets" like databases, were not optimal in K8S either. You can make it work, but it's higher effort.
- sickmate 9y ago
  >Common things like rolling updates were a 3-step operation (or they were for us), and node replacement was a pain I had the same experience until I created an ECS stack using CloudFormation, which made it much easier to manage.
- wearer_of_hats 9y ago
  Considering that Fargate, also announced today, is essentially managed ECS, I don't think it's likely that ECS is going away any time soon. Fargate seems like a pretty substantial investment.

corg890 9y ago

They resisted vehemently for a long time, even when it was painfully obvious it was wrong, and you’d just end up having these totally surreal conversations with their ECS product manager that would make your head spin they made so little sense. Glad that’s over.

zenlikethat 9y ago
That’s cause it’d be way better for them if ECS “won”, but it didn’t, so they adapted. Similar to how Docker now has had to add Kubernetes support after being combative and dragging their feet for years.
- corg890 9y ago
  It was just pride since google is their rival, didn’t make any sense otherwise.
  - yebyen 9y ago
    I'm glad that I can run Kubernetes on AWS now (again), but I still can't run ECS on my laptop... hello Amazon? Are you home?
    - zenlikethat 9y ago
      I thought that’s what Blox is for https://github.com/blox/blox/blob/dev/README.md https://github.com/blox/blox/blob/dev/README.md
      - yebyen 9y ago
        Thank you!
      - yebyen 9y ago
        Does this just use a tool that runs on your laptop, to schedule and manage ECS clusters on Amazon? That's really not what I was looking for... I was hoping to prototype ECS-based solutions without spending money on cloud resources. I have a laptop with 8GB+ RAM and a fast SSD, it doesn't have any trouble running fairly complex constellations on Minikube and I could later rebuild and/or install them on a production Kubernetes cluster, without any changes. Can I do something like that with Blox, or is this another different way to consume ECS and spend money on EC2 nodes to run containers? Edit: I would be satisfied if you told me, I still need to consume some AWS services like SNS and CloudWatch to use this toolkit, but that with Blox, I don't actually need to run my containers on ECS unless I want to expose them to the world. I haven't found any tutorial or guide that indicates this is anything other than a different scheduler for ECS.

manojlds 9y ago

They are at least a year late with this though. People were expecting this last year as well. And it's still a preview.