News for hackers. Stuff that matters.
Re:Ask HN: Why do message queue-based architectures seem les... by Kirth on Wednesday June 19, 2024 @03:33AM (#40725808)
Genuine question: say you have 3-4 services and a bunch of databases that make up your product, what's the alternative to plemping them all into K8s according to you?
Re:Ask HN: Why do message queue-based architectures seem les... by Myoklov on Wednesday June 19, 2024 @04:13AM (#40726028)
Using cloud platform as a service options. For example, on Azure you can deploy such system with Azure App Service (with container deployment), or Azure Container Apps (very suitable for microservices). For database, you can use Azure Database for PostgreSQL (flexible), or Azure Cosmos DB for PostgreSQL.

This way, Azure does most of the heavy lifting you would otherwise have to do yourself, even with managed kubernetes.

Re:Ask HN: Why do message queue-based architectures seem les... by benterix on Wednesday June 19, 2024 @03:46AM (#40725881)
If you use AWS, it's probably easier to use ECS that takes away some of the complexity from you.
Re:Ask HN: Why do message queue-based architectures seem les... by sgarland on Wednesday June 19, 2024 @09:20AM (#40728040)
Maybe at first, but once you start building all of the IaC and tooling to make it useful and safe at scale, you might as well have just run EKS. Plus, then you can get Argo, which is IMO the single best piece of software from an SRE perspective.
Re:Ask HN: Why do message queue-based architectures seem les... by kaba0 on Wednesday June 19, 2024 @04:02AM (#40725969)
For personal stuff I simply run systemd services and that does scale quite a lot (as in, you can rely on it for more production services) I believe.
Re:Ask HN: Why do message queue-based architectures seem les... by sgarland on Wednesday June 19, 2024 @09:18AM (#40728024)
My hero.
Re:Ask HN: Why do message queue-based architectures seem les... by pcl on Wednesday June 19, 2024 @04:49AM (#40726238)
3-4 services and a bunch of databases?

Assuming there aren’t any particular scaling or performance requirements, if I were managing something like that, I would almost certainly not use k8s. Maybe systemd on a big box for the services?

Re:Ask HN: Why do message queue-based architectures seem les... by badcppdev on Wednesday June 19, 2024 @05:57AM (#40726684)
I agree with you and I'm always confused when people talk about process isolation as a primary requirement for a collection of small internal services with negligible load.

In addition the overhead and reporting drawbacks of running multiple isolated databases is vastly higher than any advantaged gained from small isolated deployments.

Re:Ask HN: Why do message queue-based architectures seem les... by k8sToGo on Wednesday June 19, 2024 @05:26AM (#40726483)
In my home environment I run a VM with docker for that.

In a commercial environment I’d still use kubernetes. But maybe something like k3s or if we are in a cloud environment something like EKS.

Usually with time other services get added to the stack (elastic, grafana, argocd, …)

Re:Ask HN: Why do message queue-based architectures seem les... by brazzy on Wednesday June 19, 2024 @05:38AM (#40726566)
Docker compose is another option.
Re:Ask HN: Why do message queue-based architectures seem les... by strken on Wednesday June 19, 2024 @09:29AM (#40728103)
If I had 3-4 services and a bunch of databases, I would look at them and ask "why do we need to introduce network calls into our architecture?" and "how come we're using MySQL and Postgres and MongoDB and a Cassandra cluster for a system that gets 200 requests a minute and is maintained by 9 engineers?"

Don't get me wrong, maybe they're good choices, but absent any other facts I'd start asking questions about what makes each service necessary.

Re:Ask HN: Why do message queue-based architectures seem les... by 62951413 on Wednesday June 19, 2024 @12:40PM (#40729904)
AWS Fargate is popular among large companies in my experience.

Some of them try to migrate from it to a unified k8s "platform" (i.e. frequently not pure k8s/EKS/helm but some kind of in-house layer built on top of it). It takes so long that your tenure with the company could end before you see it through.