Earlier quoted context omitted.
and mandates that virtually all new projects not directly use borg/kubernetes.
Can you extend it? How do they deploy, and where do they deploy their projects?
[deleted]
Ask HN: Why do message queue-based architectures seem less popular now?
151–160 of 376 posts
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#152Earlier quoted context omitted.
Need no. But it’s nice especially since I have the know how. Creating a new deployment is just super fast. Developers can deploy their own apps etc. And then there is Helm. If we only decide by “need” then most of the time we also wouldn’t need object oriented programming.
> And then there is Helm Right, who doesn't want to template hundreds of lines of code in a language that uses whitespace for logic and was never made neither for templating nor complex long documents(YAML)? What could possibly go wrong ("error missing xxx at line 728, but it might be a problem elsewhere").
Honestly, Helm kinda sucks (for all the reasons you mentioned).
But Kustomize is very nice. Although, their docs could be a bit better.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#153Earlier quoted context omitted.
Need no. But it’s nice especially since I have the know how. Creating a new deployment is just super fast. Developers can deploy their own apps etc. And then there is Helm. If we only decide by “need” then most of the time we also wouldn’t need object oriented programming.
> And then there is Helm Right, who doesn't want to template hundreds of lines of code in a language that uses whitespace for logic and was never made neither for templating nor complex long documents(YAML)? What could possibly go wrong ("error missing xxx at line 728, but it might be a problem elsewhere").
It’s not that bad if you need to deploy at least 3 things and for most cases it beats the alternatives. You can get away with a bootstrapped deployment yaml and a couple of services for most scenarios. What should you use instead? Vendor locked app platforms? Roll out your own deploy bash scripts?
Sure the full extend of Kubernetes is complicated and managing it might be a pain, but if you don’t go bonkers is not that hard to use it as a developer.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#154Earlier quoted context omitted.
Need no. But it’s nice especially since I have the know how. Creating a new deployment is just super fast. Developers can deploy their own apps etc. And then there is Helm. If we only decide by “need” then most of the time we also wouldn’t need object oriented programming.
> And then there is Helm Right, who doesn't want to template hundreds of lines of code in a language that uses whitespace for logic and was never made neither for templating nor complex long documents(YAML)? What could possibly go wrong ("error missing xxx at line 728, but it might be a problem elsewhere").
I wonder why people don't use fromYaml + toJson to avoid stupid errors with indent.
Yaml is for all intents and purposes a superset of JSON so if you render your subtree as JSON you can stick it in a Yaml file and you don't need to care with indentation.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#155We often use RabbitMQ like middle-ware, and it is boring because it has proven very reliable.
Most people that deal with Distributed systems is hard to get right, and there are a few key areas one needs to design right...
If I was to give some guidance, than these tips should help:
1. user UUID to allow separable concurrent transactions with credential caching
2. global UTC time backed by GPS/RTC/NTP
3. client side application-layer load-balancing through Time-division multiplexing (can reduce peak loads by several orders of magnitude)
4. store, filter, and forward _meaningful_ data
5. peer-to-peer AMQP with role enforcement reduces the producer->consumer design to a single library. i.e. if done right the entire infrastructure becomes ridiculously simple, but if people YOLO it... failure is certain.
6. automatic route permission and credential management from other languages can require a bit of effort to sync up reliably. Essentially you end up writing a distributed user account management system in whatever ecosystem you are trying to bolt on. The client user login x509 certs can make this less laborious.
7. redacted
8. batched payload 128kB AMQP messages, as depending how the consumer is implemented this can help reduce hits to the APIs (some user UUID owns those 400 insertions for example.)
9. One might be able to just use Erlang/Elixir channels instead, and that simplifies the design further.
Have a great day, =3
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#156I like a lot of the answers, but something else I'd add: lots of "popular" architectures from the late 00s and early 2010s have fallen by the wayside because people realized "You're not Google. Your company will never be Google." That is, there was a big desire around that time period to "build it how the big successful companies built it." But since then, a lot of us have realized that complexity isn't necessary for…
We also have much much bigger single machines available for reasonable money. So a lot of reasonable workloads can fit in one machine now that used to require a small cluster
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#157> RabbitMQ, ZeroMQ There is literally nothing in common between RabbitMQ and ZeroMQ except for the two symbols 'MQ' in the name.
Well, the one thing they have in common is that both projects were originally designed by the same person, Pieter Hintjens.
He was involved in the AMQP mess, not in designing RabbitMQ.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#158Earlier quoted context omitted.
In my experience monoliths don't reduce complexity, they just shift it. The main issue with monoliths is that they don't have clear and explicit separation of concern between domain concerns, therefore it's very easy for your monolith codebase to devolve into a mess of highly interconnected spaghetti code with time. This is especially true if you're building something large with a lot of developers who don't necessar…
These blanked statements about monoliths are what made every junior dev think that microservices are the only solution. If you cannot make a clean monolith, I have never seen any evidence that the same team can make good microservices. It is just the same crap, but distributed. The last 2 years I see more and more seasoned devs who think the opposite: monoliths are better for most projects.
monoliths are the postgres of architectures - keep it simple until you really can't, not until you think you can't.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#159Earlier quoted context omitted.
Microservices also introduce the issue of maintaining schema compatibility for messages between services which usually leads to additional code in order to maintain backward compatibility From a technical POV they are good for horizontally scaling different workloads which have a different resource footprint From my experience, when a company decides to go the microservice route, it's more for the sake of solving an…
This presupposes that there is more than one line manager. I see people trying to apply micro services architectures to a web app with a single developer. As in literally taking a working monolith written by one person and having that one person split it up into tiny services. It’s madness.
If your goal is to learn kubernetes instead of developing a product, then go for it IMHO, no better way. Just make sure everyone is on board with the idea.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#160Earlier quoted context omitted.
Amazing this was downvoted. The comment starts with "in my experience" and is hardly a controversial perspective. I beg the HN community, stop disincentivizing people from respectively providing a converse opinion, lest this become yet another echo chamber of groupthink.
We've swung back and it's trendy to hate on microservices now, so join in! /s
Patiently waiting for common sense to be fashionable. Alas, sensible people are too busy to advocate on the internet.