In the ever-evolving landscape of infrastructure management, one topic often sparks spirited debates: the practice of hosting only one service per server in a production environment. It's a mantra chanted by many, a design principle considered gospel by some. But what if we challenge this conventional wisdom, just a bit?
Recently, I found myself in a conversation with a new client, discussing the intricacies of infrastructure design. The client confidently asserted that having more than one service on a single host in a production setup is a cardinal sin of modern architecture. While I've always been an advocate for the scalability and elegance of the one-service-per-host approach, I couldn't help but wonder: does every rule have exceptions?
This discussion left me intrigued and yearning for a deeper understanding. What if there are scenarios, like the symbiotic relationship between an API and its caching companion (Redis or Memcached), where bucking the trend makes perfect sense? As I delved further into this topic, I began to wonder if I'm not alone in challenging the status quo.
If you're an engineer who has, at least once, contemplated the idea of cohabitating services on a single host, this post is for you. Let's explore the reasons, scenarios, and justifications for this approach, and engage in a discussion that may very well redefine some of our long-held beliefs about infrastructure.
Top comments (0)