TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why I recommended ECS instead of Kubernetes to my latest customer

88 点作者 alien_将近 2 年前

19 条评论

itsmemattchung将近 2 年前
&gt; 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&#x27;t have customers yet.<p>As a software consultant myself, I&#x27;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 a single EC2 instance...
评论 #36244388 未加载
评论 #36244923 未加载
评论 #36244263 未加载
评论 #36244154 未加载
评论 #36246333 未加载
评论 #36244737 未加载
评论 #36245087 未加载
评论 #36245722 未加载
评论 #36244027 未加载
评论 #36244542 未加载
评论 #36244019 未加载
评论 #36244386 未加载
评论 #36244274 未加载
评论 #36245399 未加载
评论 #36245542 未加载
评论 #36244637 未加载
评论 #36244028 未加载
danpalmer将近 2 年前
More accurately: &quot;Given using AWS as a requirement, I recommended ECS instead of K8s&quot;.<p>It&#x27;s not really surprising that AWS&#x27;s K8S setup isn&#x27;t great, and their own implementation ties in more closely with other services they offer. It&#x27;s lock-in. AWS provides just enough K8S to tick the box on a spec sheet, but have little incentive to go beyond that.
评论 #36244415 未加载
评论 #36244712 未加载
评论 #36245059 未加载
waffletower将近 2 年前
The management of infrastructure via Terraform has a hidden engineering cost that should also be considered. Engineers can much more easily maintain, learn and introspect infrastructure via Kubernetes, despite its own complexity, given the immature, inconsistent and undeniably awkward qualities of the Terraform toolchain. Engineering time is expensive -- the morass of Terraform can easily quadruple engineering efforts.
评论 #36244456 未加载
评论 #36244227 未加载
评论 #36244808 未加载
评论 #36244587 未加载
honkycat将近 2 年前
I was not convinced by this article that ECS was the right choice. It felt more like a contrarian choice.<p>&gt; 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.<p>Have you ever built something in ECS? I have, and it is missing HUGE SWATHS of the convenient functionality that EKS provides. It lacks the network effect of being a widely-used product, so searching for issues is a constant issue. It breaks and nobody knows how to help.<p>&quot;Not far from their docker-compose setup...&quot; What are you even talking about? ECS is massively more complex than docker-compose and the main similarity I see between them is that they both run docker. It&#x27;s similar to docker-compose if you ignore the fact that you need permissions, load balancers, networking, etc. Which is the hard part, NOT running some containers on EC2, by the way.<p>It has it&#x27;s own bizarre and verbose container deployment spec that is less portable, less flexible, less feature-ful, and less widely used than EKS.<p>&gt; ECS will also offer ECS container logs and metrics out of the box, giving us better visibility into the application and enabling us to right-size each service based on its actual resource consumption, in the end allowing us to reduce the number of instances in the ECS cluster once everything is optimized.<p>Something you also get with EKS. So half of the reasons you have claimed ECS was the right choice are now in the garbage.<p>What you DON&#x27;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.<p>They are going to try and hire DevOps engineers, and they will all have to ramp up ( and likely complain about ) ECS instead of having people walk on already prepared and ready to start implementing high quality software on a system they already know.
评论 #36245566 未加载
rdsubhas将近 2 年前
What they didn&#x27;t appear to have considered – was the Dev side of DevOps. Kubernetes runs on developer machines and single-node CI agents. In my company, all CI agents are single-node k3s clusters, all our engineers kubectl apply their services there for integration and e2e testing, same environment from dev to prod. We provide the same single-node VMs for development on the cloud, and Podman desktop for local kubernetes. It has hooks to inject stuff (injecting centralized secrets, configuration, sidecars, etc) in a single way, no need to implement centralized features separately for CI and separately for Prod. It has hooks to validate &amp; reject stuff that doesn&#x27;t comply with org policies (e.g. limit only core workloads, upper bounds on cpu&#x2F;memory, volumes, validate everyone sticks to core workload specs and do not use any alpha&#x2F;beta APIs, etc) so that SRE can allow decentralization while still being in control of what runs and how.<p>ECS is a deployment tool. Kubernetes is a dev-to-ci-to-prod tool, providing same environment for standard workload specs across the full development cycle, and a single way to inject common features into the standard workloads.
lapser将近 2 年前
I find it really wild that anyone would ever recommend ECS. A developer deploying a service involves:<p>- Setting up certs (managed as TF) - Setting up ALBs (managed as TF) - Setting up the actual service definition (often done as a JSON, that is passed into TF)<p>Possibly other things I&#x27;m forgetting.<p>Some other things. It requires a *developer* to know about certs and ALBs and whatever else.<p>With EKS, this can all be automated. The devops engineer can set it up so that deploying a service automatically sets up certs, LBs etc. Why are we removing such good abstractions for a proprietary system that is *supposed* to be less management overheads, when in reality, it causes devs to do so much more, and understand so much more?
评论 #36244925 未加载
评论 #36247445 未加载
评论 #36244867 未加载
评论 #36244846 未加载
topspin将近 2 年前
I&#x27;m tracking cloud-hypervisor and kata containers closely. I&#x27;m convinced there is a unicorn opportunity here for the SME&#x2F;private-cloud world. An easily managed cluster of lightweight, live-migratable, hardware isolated VMs running containers (as opposed to just herding containers) solves problems people actually have, as opposed to the problems k8s solves. k8s is fine for the scale of enterprise for which it is actually intended and the problem space it was designed to address. It&#x27;s not fine for everything else.
评论 #36246565 未加载
评论 #36245423 未加载
LispSporks22将近 2 年前
The last company I worked at was building a Kubernetes cluster. It was the usual story – &quot;Heroku is way too expensive. How hard can it be to build our own Heroku?&quot; Classic trap. Fell right into it. Company size: maybe 200. Tried to tell them it will be a huge time suck, and they were doing it Azure, and then EKS IIRC. Tried to explain that massive companies have whole departments in charge of building and maintaining that and it&#x27;s an entire hobby for some masochists. I think they&#x27;re probably still building it.
e12e将近 2 年前
Interesting that the before and after figures are isomorphic as far as i can tell?<p>They introduced Terraform and dropped docker compose in favour of some Amazon proprietary container scheduler?
fwungy将近 2 年前
ECS is hardly perfect, but I&#x27;d use it before EKS for a client who wasn&#x27;t ready for that.
bdcravens将近 2 年前
We have run ECS with great success for several years. It has always appeared to me to be 80% of K8S for 20% of the effort, but for us, that 80% contained 100% of our need.
pid-1将近 2 年前
IMO ECS is in a weird position right now, because:<p>1 - It&#x27;s simpler thank K8s, but not that much simpler than your avg managed K8s offering<p>2 - It really locks you in the AWS ecosystem<p>3 - It is way less used than K8s or just running things on servers, so there are way less help &#x2F; learning resources<p>I really don&#x27;t see how using ECS is much better than EC2 + compose for small setups and this post didn&#x27;t provide many good arguments to convince me.
评论 #36245448 未加载
评论 #36245403 未加载
评论 #36246010 未加载
评论 #36245923 未加载
mediascreen将近 2 年前
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.<p>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&#x2F;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.
what-the-grump将近 2 年前
Static host stuff on an S3 bucket &#x2F; static web app. Blob storage account with a table, maybe an on-demand function app.<p>Sub $15&#x2F;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.<p>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.<p>You need a table and maybe 6 chairs who knows they might eat standing.
评论 #36255698 未加载
评论 #36254258 未加载
efnx将近 2 年前
I expected to read some wild story about Entity Component Systems but was disappointed to find it’s about picking the correct AWS services.
ddalcino将近 2 年前
Archive.org link: <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20230608135300&#x2F;https:&#x2F;&#x2F;leanercloud.beehiiv.com&#x2F;p&#x2F;recommended-ecs-instead-kubernetes-latest-customer" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20230608135300&#x2F;https:&#x2F;&#x2F;leanerclo...</a><p>I think it got the HN hug of death
sharkbot将近 2 年前
Mostly a note to self: it is interesting to read this account and connect it to the financial planning case studies that show up in personal finance blogs and articles. It seems like there’s a lot of shared terminology and practice between the domains.
mixxit将近 2 年前
we have retargeted some of our infrastructure from kubernetes and onto ecs fargate for the last 12 months and it has massively reduced errors and support tickets and also the cost<p>unfortunately this is a deal with the devil for vendor lock-in
pmarreck将近 2 年前
The article never mentions what ECS stands for, that’s not yet a TLA I’m familiar with
评论 #36244709 未加载