interesting post from RabbitMQ looking at RabbitMQ vs Apache Kafka (though we might be a bit biased lol) rabbitmq.com/docs/compare/ka…

I love Spring Boot so much. I love the autoconfiguration that provides useful out-of-the-box integrations with tons of libraries in an idiomatic, concise way. i love the incredibly rich production-worthy features. One of my favorite kinds of features, the kind that really drive home why a framework is a force-multiplier? It's when Spring Framework's "portable service abstractions" intersect with "cross-cutting concerns." Some examples:  - the new `InetAddressFilter` in Spring Boot 4.1 lets you restrict outbound HTTP requests, to limit for example calls to untrusted web sites. A simple enough contract, but we had to hook it into basically anywhere you might want to make an HTTP request (RestTemplate, RestClient, Apache HTTP Client, JDK HTTP Client, etc., etc.) in the entire portfolio.   - the `SslBundle` mechanism is a way to define and centralize "trust materials" like keys. Simple enough. But we had to then hook that in to _everything_ that could use it, or that even remotely has a notion of SSL. (Spoiler alert: basically everything does) This means: embedded webservers, REST clients, Cassandra, Couchbase, ElasticSearch, MongoDB, Redis, RabbitMQ (and RabbitMQ Streams), RSocket, etc. all now have consistent ways to secure them.  - ServiceConnections - want to live that `git-clone-run` life? Don't want to fiddle with configuration? Choose Docker Compose or Testcontainers on start.spring.io and then choose interesting middleware like RabbitMQ, PostgreSQL, etc., and Spring Boot will automatically start up a Docker Image and then connect to it without you doing a thing. Is dealing with one of these things in isolation such a big deal? No, not at all. But it's the death by a thousand cuts. And a great framework like Spring Boot, with the consistency it - and only it - can impose, is the salve that heals.