Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I recommended ECS instead of Kubernetes to my latest customer

leanercloud.beehiiv.com

Post reply on HN
Print view View original

71–80 of 126 posts

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#71

Post by jpgvm »

bdcravens wrote: post #69
honkycat wrote: post #36

I was not convinced by this article that ECS was the right choice. It felt more like a contrarian choice. > ECS is also relatively simple and not so far from their Docker-compose setup, but much more flexible and scalable. It also enables us to convert their somewhat stateful pets to identically looking stateless cattle that could be converted to Spot instances later. Have you ever built something in ECS? I have, and…

> What you DON'T get with ECS is awesome working-out-of-the-box open source software like External Secrets, External DNS, LetsEncrypt, the Amazon Ingress Controller, argo rollouts, services, ingresses, cronjobs... I could go on and on. The AWS ecosystem has much of this baked-in. (Parameter Store, Certificate Manager, etc) Vendor lock-in is of course a concern, but for many, a theoretical one.

The main problem with the AWS ecosystem is you generally need to code against it directly. Much of the OSS stuff is designed to have a much more drop-in feeling, especially if you are going with stuff like Spring Cloud etc to abstract over things for you.

If you can choose an option that is going to be way less work even if it's "more complex" that is often the right choice as long as you understand what that complexity is and can pierce through the covers if necessary.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#73

Post by bdcravens »

jpgvm wrote: post #71
bdcravens wrote: post #69

Earlier quoted context omitted.

> What you DON'T get with ECS is awesome working-out-of-the-box open source software like External Secrets, External DNS, LetsEncrypt, the Amazon Ingress Controller, argo rollouts, services, ingresses, cronjobs... I could go on and on. The AWS ecosystem has much of this baked-in. (Parameter Store, Certificate Manager, etc) Vendor lock-in is of course a concern, but for many, a theoretical one.

The main problem with the AWS ecosystem is you generally need to code against it directly. Much of the OSS stuff is designed to have a much more drop-in feeling, especially if you are going with stuff like Spring Cloud etc to abstract over things for you. If you can choose an option that is going to be way less work even if it's "more complex" that is often the right choice as long as you understand what that complex…

Local/cloud parity is a concern, though Localstack provides some options now that weren't available a few years ago.

https://localstack.cloud/

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#74

Post by what-the-grump »

Static host stuff on an S3 bucket / static web app. Blob storage account with a table, maybe an on-demand function app.

Sub $15/mo to run your thing until you get real demand, yeah. But its not new, the K8S shtick is coming from investors not tech people. And if its coming from the tech people throw them out of the door.

Why are you cooking for 8000 people when 6 are coming over? Why are you building a kitchen to cook for 8000 people. Why are you renting space to fit 8000 people.

You need a table and maybe 6 chairs who knows they might eat standing.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#75

Post by jmholla »

waffletower wrote: post #10
itsmemattchung wrote: post #2

> When looking at the cloud resources, we noticed many On-Demand EC2 instances with relatively low CPU utilization, which can be expected considering they don't have customers yet. As a software consultant myself, I'd probably stop the conversation right there and ask why they are building such a robust distributed system — SQS, SNS, etc — without any customers. Still want to be deployed in AWS? Toss the damn app on…

And in that case, why ec2, why not a more affordable provider?

Who would you recommend as a more affordable provider?

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#76

Post by HatchedLake721 »

itsmemattchung wrote: post #2

> When looking at the cloud resources, we noticed many On-Demand EC2 instances with relatively low CPU utilization, which can be expected considering they don't have customers yet. As a software consultant myself, I'd probably stop the conversation right there and ask why they are building such a robust distributed system — SQS, SNS, etc — without any customers. Still want to be deployed in AWS? Toss the damn app on…

What SQS has to do with EC2?

One is a queuing service, the other one is a VM.

So instead of using SQS that has $0 cost when there are no customers, you suggest I install, configure and run RabbitMQ on an EC2, to save $0 when there are no customers?

Or save $1 when I have 100 customers? SQS is dirt cheap.

The point of SQS or any other usage-based AWS _developer_ service compared to DIY is that you can be up and running in minutes at a minuscule cost.

I agree with you about over-engineering and building a distributed "microservices" architecture when you have no customers.

But I'll pick SQS any time of the day when I need queueing functionality to increase my developer velocity so I can focus on building value rather than wasting my life installing, configuring and running anything on EC2.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#77

Post by mediascreen »

I would almost always go with what the team or someone on it was most familiar with and can setup in less than a day. I think it should include an easy way to scale at least for a few months to come, a reasonable way to provision more capacity, a managed database, a CDN, backups, access and error logging and a simple but automatic deployment pipeline.

At work we use ECS Fargate, Aurora MySQL and Bitbucket pipelines to host a little over 100 client web applications. It takes about an hour to configure a new AWS account and staging/production environments for a new client using Cloudformation (and a number manual steps) and the monthly AWS cost is around $100. There are cheaper ways and probably easier ways, but we feel like we have reached a good balance between stability, ease of use, cost and features. And we are not that worried about being tied to AWS.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#78

Post by fnordpiglet »

mlhpdx wrote: post #68
fnordpiglet wrote: post #53

Earlier quoted context omitted.

Your muscles must be tuned to enormous amounts of IAM-fu ;-)

Indeed. One of the hard things to figure out is the keeping the number of roles small while avoiding stars (IAM ain’t GitHub).

Yes. Stars should be removed frankly. The fact they admit new actions without any review or awareness alone is scary.

However IAM isn’t really for humans. It is just really hard to reason about roles programmatically. Some of the new minimal rights discovery from cloud trail analysis leads to an interesting pattern I’ve not seen a lot of : in lower environments permissions are wide open, but a capture of the required roles happens pre-prod and is used and tested against in preprod then promoted to production. This seems like a really useful pattern, and it exposes where your integration tests are incomplete.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#79

Post by djbusby »

meinheld111 wrote: post #43
CharlesW wrote: post #27

Earlier quoted context omitted.

> …the cloud is total overkill for small startups and hobby projects. It absolutely can be, sure. But solutions like Vercel, Cloudflare Workers, Supabase, etc. can be excellent and inexpensive for those use cases.

And surely a vivid tech stack does more to make you look good in front of vc‘s than an overkill architecture does make you look incompetent

IME the investor cares more about Traction that Technology.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#80

Post by djbusby »

HatchedLake721 wrote: post #76
itsmemattchung wrote: post #2

> When looking at the cloud resources, we noticed many On-Demand EC2 instances with relatively low CPU utilization, which can be expected considering they don't have customers yet. As a software consultant myself, I'd probably stop the conversation right there and ask why they are building such a robust distributed system — SQS, SNS, etc — without any customers. Still want to be deployed in AWS? Toss the damn app on…

What SQS has to do with EC2? One is a queuing service, the other one is a VM. So instead of using SQS that has $0 cost when there are no customers, you suggest I install, configure and run RabbitMQ on an EC2, to save $0 when there are no customers? Or save $1 when I have 100 customers? SQS is dirt cheap. The point of SQS or any other usage-based AWS _developer_ service compared to DIY is that you can be up and runnin…

The question is: what are queueing for zero customers?
Post reply on HN