Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I tried Fargate and found it to be crappy. It is very hard to use. It is proprietary, so your app will not be portable, and your knowledge and experience will not be portable either. If you use Kubernetes there is tons of tutorials, your app becomes portable across clouds and your knowledge is portable from cloud to cloud too. GKE only costs around $60 per month for a single-machine "cluster".


I use fargate and pretty happy with it. Don't need big scale out - it supports $1M/year revenue so not huge, but LOVE the simplicity.

I just have the CLI commands in my dockerfiles as comments, so once I get things sorted locally using docker I update the task with some copy / paste. I only update occasionally when I need to make some changes (locally do a lot more).

The one thing I'd love to get my DOCKER image sizes down - they seem way too big for what they do but it's just easier to start with full fat images. I tried alpine images and couldn't get stuff to install / compile etc.


You should look into multistage docker builds, that lets you still use a full fat image for your build but then leave all the build tools out of your final image

I liked jpetazzo's post on the subject but there are plenty to choose from https://www.ardanlabs.com/blog/2020/02/docker-images-part1-r...


Someone else suggested the same thing actually. Easy to get lazy when it "just works" and internet is 1gig home and office - you can see how bloat just builds up.


What is proprietary about Fargate? It's containers. I did not find any experience/knowledge (other than the basic knowledge of navigating the AWS console) that wouldn't transfer to any other container service.


AWS console is the crappy part. Azure and Google have much better GUIs. And here's the proprietary part: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...

For contrast, you can manage a Kubernetes deployment using standardized yaml and kubectl commands, regardless of whether the application is running on localhost (minikube), on Azure or on GKE.

BTW, AWS Lightsail has decent GUI. Alas, it doesn't support containers out of the box. The best support for Docker image-based deployment is Azure App Service.


I'm still not seeing the difference. As pointed out, what you linked is for ECS. That has nothing to do with Kubernetes, so I'm not sure why you're comparing the things on that page to kubectl commands on GKE or Azure. Of course you cannot use kubectl on ECS, because ECS has nothing to do with kube.

When you are using actual EKS (with or without Fargate), you certainly can use standardized kubectl commands.

The only "proprietary" things I see in your link is the specific AWS CLI commands used to set up the cluster before you can use kubectl, but both Azure and GCP require using the Azure CLI and gcloud CLI for cluster deployment, too. There's also setting up AWS-specific security groups and IAM roles, but you have to do those same things on GCP or Azure, too, and both of those have their own "proprietary" ways of setting up networking and security, so I don't see the differentiating factor.


> here's the proprietary part: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/....

That's ECS, not EKS. Two different products.

The EKS documentation is at https://docs.aws.amazon.com/eks/latest/userguide/fargate.htm...

> For contrast, you can manage a Kubernetes deployment using standardized yaml and kubectl commands, regardless of whether the application is running on localhost (minikube), on Azure or on GKE.

Likewise for EKS.


I was replying to this:

> At the low end it’s worth considering Fargate distinct from EKS.


Right, and you linked to the documentation for ECS on Fargate rather than the documentation for Kubernetes Fargate, which is what was being talked about. Again, two different products.


How is Fargate “proprietary”? It runs a Docker containers.

But if you are at any type of scale, the last thing on your to do list is “cloud migration”.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: