Same! Never bothered with the so-called HA setup after running a cluster for few months.
Making all messages durable + backups of underlying storage are sufficient, while the do not prevent an outage, at least bringing the system back to an operational state is fairly straightforward
I recommend reading this 3-part series on Mongo's marketing - it goes into a lot of detail why Mongo "won". https://www.nemil.com/mongo/1.html
As a former RethinkDB user (we have migrated to Postgres) I actually don't miss it as much as I would - JSONB in PG does what we need, and the real-time features of RethinkDB never really delivered because of various performance issues in the database itself.
ECS can be simpler if you stick to the default and use something like copilot - it effectively turns your compose file into a cluster with all of the networking etc
EnvKey user here - it looks exactly like EnvKey. Not sure what the underlying crypto primitives are - EnvKey relies on PGP/GPG style stuff and have a lot of documentation about it.
AFAIK there's no RabbitMQ-compatible broker, unless you use AMQP 1.0 in RabbitMQ right now. Their AMQP 0.9 implementation has a lot of RMQ-specific stuff and there's no equivalent.
One is fantastic but you have to be aware of it’s limitations - particularly around network connectivity, something that even OG MPC Live is better at.
Of course if it’s not a factor for you (it’s not for me, I like my One) - then it’s indeed amazing.
The closest thing you can get in irb, is to use Rails' `reload!` after making changes to your files. I don't remember if irb supports this kind of stuff out of the box, perhaps good old `require` works.
Differences:
- Clojure has namespaces, so you can reload just one unit rather than the whole code - I guess load/require would be closest
- You can also just evaluate a single form (e.g. a function definition) leaving everything else intact
- if you're using something like Component for state management, then you never restart the repl, just stop the system, refresh your repl state and start the system again - closest thing to 'refresh on request' from Rails' dev mode or PHP, but without the nasty surprises
The drawback is that restarting a repl is a slow process, but it's something you do very rarely. Some folks keep their repl process around for weeks.
I'd disagree - my team migrated from running containers on VMs (managed via Ansible) to ECS + Fargate (managed by Terraform and a simple bash script).
It wasn't a simple transition by any means, but one person wrapped it up in 4 weeks - now we have 0 downtime deployments, scaling up/down in matter of seconds, and ECS babysits the containers.
Previously we had to deploy a lot of monitoring on each VM to ensure that containers are running, we get alerted when one of the application crashed and didn't restart because Docker daemon didn't handle it etc etc.
Now, we only run stateless services, in a private VPC subnet, Load balancing is delegated to ALB, we don't need service discovery, meshes etc. Configuration is declarative, but written in much friendlier HCL (I'm ok with YAML, but to a degree).
ECS just works for us.
Just like K8S might work for a bigger team, but I wouldn't adopt it at our shop, simply because of all of the complexity and huge surface area.
An application usually has one connection, and many channels. Our pattern is to dedicate one channel for all publishing and then N channels mapped to consumer threads.
You don't have to pool connections as channels are multiplexed by them.
Things to watch out for:
- opening too many channels - these map to Erlang processes and can overwhelm your server if you go over ulimits
- sharing consumer channels between threads - you might see weird behavior (e.g. acking wrong messages etc)
We've built own library/framework for creating resilient consumers, and it enforces mapping 1:1 channels and consumer threads, as well as automatic reconnections and channel clean ups.
I'm not sure to be honest, I've been working with Clojure for 5 years now, and the only "help" I get from the editor I get is "highlight matching pair". I never got used to automatic paren insertion or things like paredit.
The document mentions using Raft for consensus and coordination - it's the same approach used by Etcd, Consul, Serf, RethinkDB and other systems. AFAIK it's easier to implement and understand than Zookeeper's consensus solution.
That's correct - being able to "rewind" a history of a topic (queue) is a powerful concept.
But, Kafka is a bit harder to operate than RabbitMQ in my experience.
(Somewhat related, one of our subsystems originally was built around Kafka, but later was migrated to RabbitMQ and Postgres)
Compojure - https://github.com/weavejester/compojure#usage is a very close equivalent of Sinatra. Ring (which most, if not all web libraries build on top of) is directly inspired by Ruby's Rack (I think Python and Node have a very similar, middleware oriented design).