“This is a business-critical server. If it goes down, so does our business.”
Chances are you’ve heard this before. You may even have expressed this yourself. Our team has encountered, built and/or maintained several deployments fitting this description. In DevOps/Infrastructure, this is what we refer to as a pet. If you’re not already familiar with this concept, read on to learn more.
Pets
A pet is a server or group of servers that do not have easy scale-out ability, automation, repeatability or transience built into the architecture. If the server goes down, you invest the time and resources necessary to get it back to healthy operation. You treat it like you would a family pet. You nurse it back to health and perform preventative care. If it can’t meet the demand of the application running on it, you scale up; you give it more compute, memory or storage resources on the existing instance.
We’ve seen many deployments that fit this service model, typically because the application does not support the ability to scale out, resources were not available to incorporate the mechanisms, or the standards of the time did not take scaling and automation into consideration (e.g., legacy applications).
Typical Examples of Pets:
- Traditional Database Deployments
- Domain Controllers
- Load balancer pairs
- Any single server application
When an application does not scale, it’s important to evaluate the infrastructure stack to determine the possibility of adding this functionality and furthermore, automating it. If it cannot support this model, considerations can be made to add redundancy and/or failover capability to reduce single points of failure in the environment. Backups and disaster recovery plans are crucial in these scenarios as well.
Cattle
There’s another side to this analogy and that would be cattle. Applications running in this service model tend to be distributed across a fleet/farm of servers or containers behind a load balancer. If an instance is unhealthy, you replace it. They are transient, and when they go down, the business doesn’t notice. If you need more capacity, you scale out; you add more instances to meet demand.
Typical Examples of Cattle:
- Large arrays of instances running the same application
- Instances where applications are automatically deployed on startup
- Clustered databases
- Task based compute clusters
Instances can be replaced, added, or removed manually. However, automating this process really kicks things into overdrive. Building on cloud platforms such as AWS and leveraging native tooling can streamline this process. Wouldn’t it be great if you didn’t have to think about replacing instances when they become unhealthy or scaling out to meet demand?
Not all applications fit this model. To reiterate, it’s important to evaluate applications and infrastructure to determine the best fit and tailor solutions around that analysis.
Conclusion
Though the analogy “Pets vs. Cattle” can be a bit dark, the concept is widely known and it is helpful in framing service model architectures. GPIT engineers have years of experience performing this type of analysis. We can help your business determine the service model that fits best with your applications and tailor solutions accordingly. Businesses can see signficant increase in velocity when architecture is optimized. Spend less time on maintenance and break/fix. Free up valuable time and resources to focus on growth and enhancement.