frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

AI tooling must be disclosed for contributions

https://github.com/ghostty-org/ghostty/pull/8289
214•freetonik•1h ago•86 comments

How does the US use water?

https://www.construction-physics.com/p/how-does-the-us-use-water
26•juliangamble•7h ago•3 comments

Building AI products in the probabilistic era

https://giansegato.com/essays/probabilistic-era
37•sdan•1h ago•8 comments

Beyond sensor data: Foundation models of behavioral data from wearables

https://arxiv.org/abs/2507.00191
168•brandonb•5h ago•36 comments

An interactive guide to SVG paths

https://www.joshwcomeau.com/svg/interactive-guide-to-paths/
93•joshwcomeau•3d ago•10 comments

Miles from the ocean, there's diving beneath the streets of Budapest

https://www.cnn.com/2025/08/18/travel/budapest-diving-molnar-janos-cave
44•thm•3d ago•4 comments

DeepSeek-v3.1 Release

https://api-docs.deepseek.com/news/news250821
65•wertyk•1h ago•4 comments

Weaponizing image scaling against production AI systems

https://blog.trailofbits.com/2025/08/21/weaponizing-image-scaling-against-production-ai-systems/
266•tatersolid•7h ago•66 comments

My other email client is a daemon

https://feyor.sh/blog/my-other-email-client-is-a-mail-daemon/
40•aebtebeten•11h ago•11 comments

D4D4

https://www.nmichaels.org/musings/d4d4/d4d4/
405•csense•4d ago•46 comments

Using Podman, Compose and BuildKit

https://emersion.fr/blog/2025/using-podman-compose-and-buildkit/
211•LaSombra•9h ago•59 comments

Cua (YC X25) is hiring design engineers in SF

https://www.ycombinator.com/companies/cua/jobs/a6UbTvG-founding-engineer-ux-design
1•frabonacci•3h ago

The power of two random choices

https://brooker.co.za/blog/2012/01/17/two-random.html
19•signa11•3d ago•2 comments

Crimes with Python's Pattern Matching (2022)

https://www.hillelwayne.com/post/python-abc/
3•agluszak•28m ago•0 comments

The contrarian physics podcast subculture

https://timothynguyen.org/2025/08/21/physics-grifters-eric-weinstein-sabine-hossenfelder-and-a-crisis-of-credibility/
104•Emerson1•3h ago•103 comments

Show HN: OS X Mavericks Forever

https://mavericksforever.com/
243•Wowfunhappy•3d ago•98 comments

Launch HN: Skope (YC S25) – Outcome-based pricing for software products

29•benjsm•5h ago•26 comments

The Core of Rust

https://jyn.dev/the-core-of-rust/
96•zdw•3h ago•56 comments

Adding my home electricity uptime to status.href.cat

https://aggressivelyparaphrasing.me/2025/08/21/adding-my-home-electricity-uptime-to-status-href-cat/
27•todsacerdoti•4h ago•22 comments

Unity reintroduces the Runtime Fee through its Industry license

https://unity.com/products/unity-industry
175•finnsquared•5h ago•85 comments

Mark Zuckerberg freezes AI hiring amid bubble fears

https://www.telegraph.co.uk/business/2025/08/21/zuckerberg-freezes-ai-hiring-amid-bubble-fears/
566•pera•9h ago•531 comments

The unbearable slowness of AI coding

https://joshuavaldez.com/the-unbearable-slowness-of-ai-coding/
53•aymandfire•1h ago•27 comments

Show HN: ChartDB Cloud – Visualize and Share Database Diagrams

https://app.chartdb.io
70•Jonathanfishner•7h ago•9 comments

Why is D3 so Verbose?

https://theheasman.com/short_stories/why-is-d3-code-so-long-and-complicated-or-why-is-it-so-verbose/
79•TheHeasman•10h ago•48 comments

Show HN: Using Common Lisp from Inside the Browser

https://turtleware.eu/posts/Using-Common-Lisp-from-inside-the-Browser.html
85•jackdaniel•8h ago•21 comments

You Should Add Debug Views to Your DB

https://chrispenner.ca/posts/views-for-debugging
60•ezekg•4d ago•18 comments

A summary of recent AI research (2016)

https://blog.plan99.net/the-science-of-westworld-ec624585e47
19•mike_hearn•4h ago•0 comments

Margin debt surges to record high

https://www.advisorperspectives.com/dshort/updates/2025/07/23/margin-debt-surges-record-high-june-2025
183•pera•8h ago•229 comments

Unmasking the Privacy Risks of Apple Intelligence

https://www.lumia.security/blog/applestorm
78•mroi•4h ago•17 comments

Bank forced to rehire workers after lying about chatbot productivity, union says

https://arstechnica.com/tech-policy/2025/08/bank-forced-to-rehire-workers-after-lying-about-chatbot-productivity-union-says/
234•ndsipa_pomu•4h ago•89 comments
Open in hackernews

Ask HN: Is Kubernetes still a big no-no for early stages in 2025?

14•herval•1h ago
It's a commonly-repeated comment that early stage startups should avoid K8s at all cost. As someone who had to manage it on a baremetal infrastructure in the past, I get where that comes from - Kubernetes has been historically hard to setup, you'd need to spend a lot of time learning the concepts and how to write the YAML configs, etc.

However, hosted K8s options have improved significantly in recent years (all cloud providers have Kubernetes options that are pretty much self-managed), and I feel like with LLMs, it's become extremely easy to read & write deployment configs.

What's your thoughts about adopting K8s as infrastructure early on (say, when you have initial customer fit and a team of 5+ engineers) and standardizing around it? How early is too early? What pitfalls do you think still exist today?

Comments

delichon•1h ago
Same question. I'm a one man band who wants to be scalable, but doesn't want to get married to a particular cloud. So Kubernetes appears to be the default recommendation. Are there better alternatives?
vorpalhex•1h ago
Docker compose, docker swarm if you outgrow that.
herval•1h ago
I tried that in the past and found it extremely unreliable as a production environment. Documentation was also non-existent and I'd have to manually handle clusters, setup my own observability and log stack, etc. Any cloud provider these days gives you all that out of the box for K8s, so I'm, not sure the time one would invest on Swarm really makes sense?
vorpalhex•57m ago
You will be married to a particular cloud.

Either you go all in on someones setup or you get to do it all yourself.

That's true for any service. Either you drink the AWS/GCP/Axure koolaid or you make your own. Whether it's k8s or Swarm or whatever doesn't matter.

more_corn•48m ago
Heroku Vercel AWS ECS

What’s your business? Do you have product market fit? Do you benefit enough from the three things K8S does well to pay the cost in increased complexity, reduced visibility, and increased toil? If you can’t immediately rattle off those three things, you don’t need it.

Don’t you want to just focus on the problem you’re solving for your customers and not the infrastructure that makes your app go? Every startup I’ve seen doing k8s should not have been. Every startup I’ve seen not using k8s didn’t need it. (Except a startup who moved from beanstalk which nobody should ever use, and they could have done better by moving to something like ecs)

I’ve seen a startup lose their entire DevOps team and successfully go a year without it because their core app was on heroku. What’s that worth in dollars? What are those dollars worth in opportunity cost?

otterley•40m ago
> I'm a one man band who wants to be scalable, but doesn't want to get married to a particular cloud.

(AWS employee, but opinions are my own)

Just pick a cloud provider and move on. All of the top-tier providers can scale. Choose the one you're most comfortable with and move on. Focus on the things that matter for your business like building the right product and getting customers. If you have regret later, it's going to be because you were so wildly successful that it is now an actual business risk and/or your customers demand it. But don't make this decision based on a problem you don't have and are unlikely to have in the next 12-24 months, if ever. Cloud agnosticism is rarely a functional or strategic requirement of any given business, and it's usually very expensive to implement--more than any savings you might achieve by pitting providers against each other (which you can't do anyway unless you are big enough to be a strategic customer).

delichon•18m ago
I'm writing a public statement platform, and a core design priority is to avoid being Parlered, since human moderation is not an option. Responding to court orders is inevitable, but responding to cloud provider demands isn't quite, yet.
zekrioca•1h ago
It seems to me the issue is not really setting up and building around K8s as an infrastructure orchestrator, afterall k8s sells itself as a cluster API which is the de facto standard nowadays. The issue starts when you need to handle very specific use-cases, e.g., security. This requires very low-level experience not only with K8s, but with the whole stack (including OS + HW) + knowledge of safe resource and application scheduling, which is hard to find talent for.

PS. Edit for clarity.

Ethee•1h ago
The answer, as with everything, is going to be that it depends on your situation and use-case. If you have a bunch of engineers who are already familiar with K8s then using a different implementation just because others told you to doesn't make much sense. But if you're choosing K8s because you want a good future foundation, in dreams of 'scale', then you should stop and really consider what it is that you need from K8s. Most people I've seen who's infrastructure succeeds with K8s only moved to it as a necessity, usually away from some monolithic structure, they didn't start there. Build what you need, and only that much, not for some future need that might not come.
richwater•1h ago
Those same cloud providers usually have simplified container deployment mechanisms as well. You don't need Kubernetes to deploy containers.
carlhjerpe•39m ago
And then you can no longer deploy anywhere else, sounds perfect for the cloud provider!
vorpalhex•1h ago
What does it provide you?

Maybe you need a cluster per client and k8s is the only option.

Maybe you literally only need a few docker services and swarm/ecs/etc are fine forever.

What is the problem that K8s solves for you?

herval•1h ago
in my current case - the ability to deploy on-prem for some specific customers (on-prem meaning their own AWS or GCP account usually) + per-customer/multitenancy on the main product (ideally with segregated databases)

In general - scaling up a small number of microservices + their associated infra (redis/rabbitmq/etc)

vorpalhex•53m ago
You are basically stuck with k8s but you will end up having to "roll your own" (bring your own components) if you intend for operations to be consistent across different clouds/prems/etc.

Ideally start with an existing kube stack and slowly make it your own.

Operationalizing across hetereogenous clusters will be an unfortunate source of excitement.

languagehacker•1h ago
If you've already done the work figuring out how to knock out a basic web app deployment of kubernetes for a project that you think will grow, then I say go for it. It's not much cheaper than buying a reasonable minimum amount of compute with a company like Digital Ocean.

For hobby projects that I don't really plan to scale, I've recently gotten back into non-containerized workloads running off of systemctl in an Ubuntu VM. It feels pretty freeing not to worry about all the cruft, but that will bite me if something ever does need to live on multiple servers.

ebiester•1h ago
The biggest reason Kubernetes should be a big no-no is because you should have a much simpler architecture (monolith) that doesn't need K8s.
ruuda•1h ago
It depends of course, but probably Kubernetes is a solution to problems that you don't have, while it creates new problems that you don't currently have.
tnjm•1h ago
While I wouldn't dream of standing up k8s on a bare metal cluster without a devops team, I set up managed k8s using EKS several years ago for a client and... it just chugs along, self-healing, with essentially zero maintenance.

For my own projects I use a managed Northflank cluster on my own AWS account and likewise... just a fantastic experience. Everything that Heroku could and should have been. Yes the cluster is a bit pricey to stand up both in terms of EC2 compute and management layer costs, but once it's there, it's there. And the costs scale much more nicely than shoving side projects onto Heroku.

At this stage I consider managed k8s my default go-to unless it's something so lightweight I just want to push it to Vercel and forget about it.

signal11•1h ago
k8s isn’t worth the time and money for many small teams, until they cross a complexity bar.

Even in some very non-startup enterprises, Cloud Foundry and Open Shift get adopted for a reason: some teams don’t need the overhead.

For startups there’s fly.io, render.com, and of course Heroku, but really — you can get from MVP to pretty decent scale on AWS or GCP with some scripts or Ansible.

Use k8s if you need it. It’s pretty well-proven. But it’s not something you need to have FOMO about.

Dedime•1h ago
I'll add my opinion as a DevOps engineer, not a startup, so take it with a grain of salt.

* Kubernetes is great for a lot of things, and I think there's many use cases for it where it's the best option bar none

* Particularly once you start piling on requirements - we need logging, we need metrics, we need rolling redeployments, we need HTTPS, we need a reverse proxy, we need a load balancer, we need healthchecks. Many (not all!) of these things are what mature services want, and k8s provides a standardized way to handle them.

* K8s IS complex. I won't lie. You need someone who understands it. But I do enjoy it, and I think others do too.

* The next best alternative in my opinion (if you don't want vendor lock in) is docker-compose. It's easy to deploy locally or on a server

* If you use docker-compose, but you find yourself wanting more, migrating to k8s should be straightforward

So to answer your questions, I think you can adopt k8s whenever you feel like it, assuming you have the expertise and are willing to dedicate time to maintaining it. I use it in my home network with a 1 node "cluster". The biggest pitfalls are all related to vendor lock in - managed Redis, Azure Key Vault. Hyper specific config related to your managed k8s provider that might be tough to untangle. At the same time, you can just as easily start small with docker-compose and scale up later as needed.

time4tea•25m ago
You can run docker swarm easy peasy. Its not that trendy, but anyone can manage it, and you can migrate to k8s later if you need to. Of course it doesn't do some of the things that k8s does, and thats why its less complicated...

Edit: you can run a lot on one or two hetzner servers for almost no money. Compare €60/month, vs about $1000/month for a couple of replicated fargate services.

strls•19m ago
If PaaS or some "run container as a service" setup can work for your use case, I'd probably go with that. It takes care of many things K8s does without all the baggage. Also you are not investing into anything that doesn't port easily to K8s in the future.

On the other hand, if you are thinking of using bare VMs, then better go with managed K8s. I think in 2025 it's a draw in terms of initial setup complexity, but managed K8s doesn't require constant babysitting in my experience, unlike VMs, and you are not sinking hours into a bespoke throwaway setup.

Nextgrid•1m ago
If you need to go beyond what a single bare-metal server can offer, then consider it.

But don’t discount bare-metal first! I see a lot of K8s or other cluster managers being used to manage underpowered cloud VMs, and while I understand the need for an orchestrator if you’re managing dozens of VMs, I wonder - why do you need multiple VMs in the first place if their total performance can be achieved by a handful of bare-metal machines?