4 ms·
We moved all our apps to AWS ECS. Developers happy. Kube was installed by hired consultants, after they left it was real struggle. Then we moved to ECS.
by nuker 5y ago
We moved all our apps to AWS ECS. Developers happy. Kube was installed by hired consultants, after they left it was real struggle. Then we moved to ECS.
- StreamBright 5y agoI did the same for every project where k8s was used and started with ECS where k8s was proposed. Even ECS is too complex for my taste, but who am I to dictate what clients want.
- k8sToGo 5y agoECS or EKS?
- nuker 5y agoECS. EC2 and Fargate types.
- ericbarrett 5y agoI am a huge fan of ECS. It just works. You have to write a tiny bit of tooling, but it's the kind of glue code you'd probably write on top of kube anyway. Failures are straightforward and visible. There's no debugging layer after layer of network redirects. It's much harder for an errant config to "helpfully" punch a hole through your firewall. You get the same uptime and scalability benefits as k8s or EKS. Everything is still a container.
- d0gsg0w00f 5y agoI agree. I don't understand why you would use k8s on AWS. It's an abstraction on top of an abstraction doing nothing but adding complexity. If your k8s pods have to interact with S3 buckets, IAM profiles, and load balancers anyway then you can't ignore the platform. It's just somebody chasing the cloud agnosticism fallacy or doing resume driven development.
- kgeist 5y agoWe have to support cloud providers in other countries due to local data protection laws (not every country has an AWS data center); doesn't it make sense to make your infrastructure management more-less uniform no matter where it's hosted? In some countries, providers may have only a single availability zone (in reality), or they can get very unstable from time to time (everything is down and god knows for how long), so it's natural for us in such countries to migrate our whole production between completely different providers several times a year. As an ordinary engineer whose job sometimes involves investigating problems in production or configuring something here and there (I'm not a full-time DevOps or SRE myself), I don't have to learn the details of whatever is the current cloud provider this week in the affected country N, I access the production system through a familiar interface which looks more-less same everywhere (k8s), including our test environments, too. Am I missing something? I am pretty curious what "cloud agnosticism fallacy" means. How would you do it differently?
- d0gsg0w00f 5y agoIn your case it makes sense because you don't run primarily on AWS. I work with people who only host in AWS and still use k8s + other native AWS constructs.
- mountainriver 5y agoHuh, we are moving our apps from ECS to kube and are super happy with it. I’m not sure why anyone would use ECS. Their APIs are terrible and the tooling is no where near what k8s offers. Want to have a rapid development experience like tilt/scaffold/devspace? Have fun Want to add Prometheus and Grafana? Have fun Want to create development environments where an app declared its dependencies and they are installed alongside and can communicate? Also have fun There are many more of these… Kube is cloud Linux, and ECS, in classic Amazon style, is just a terrible version of it.
- nuker 5y ago> Want to have a rapid development experience like tilt/scaffold/devspace? Have fun Wtf is tilt? I made it so after code is pushed to repo, CI/CD updates ECS Service in about a minute. Rapid enough. No third party tools used. > Kube is cloud Linux Nah. Kube smells like Google, looks like Google and is fat like Google.
- c0brac0bra 5y agotilt is a local development tool for containerized apps that handles things like file watching, auto-rebuilds, etc. It can do k8s, multiple docker-compose setups, whatever. We've liked it so far: https://tilt.dev/ https://tilt.dev/