Pets, Cattle, Insects
The Next Step in Technology History
Over the past five years, the “Pets vs. Cattle” analogy has been very popular and instructive. It’s helped people think differently about their infrastructures, and how they design, deploy, and manage their infrastructures and applications. It’s helped people think about creating systems that are far more tolerant of failure, and expose areas of their systems that are bottlenecks to upgrade or maintenance.
In simple terms, “Pets” are systems that cannot be replaced without significant cost. “Pets” are usually quite expensive to keep and will be kept until they die a natural death – and the end is when they get most expensive. The vet bills really add up at the end of a pet’s life. Same with systems that are treated like pets. If they’re critical to the business, they will be very expensive to replace.
“Cattle” on the other hand, are said to be raised to die. Their lifetimes are well prescribed, and they have a specific task to accomplish. Afterwards, they are sent to market and sold for parts. If something should go wrong with that cattle, the cost is absorbed pretty easily, and it’s sent early to market to be sold off for parts. What’s made this possible?
- Platform: Operating System on Metal
- Architecture: Monolithic Apps
- Tools: Shell Scripting
- Platform: Operating System Virtualization
- Architecture: Mix of Monolithic and Distributed Apps
- Tools: Robust Config Management/Orchestration
Pets and Cattle are all about cost and replacement. “Pets” are high cost and low capacity for replacement. “Cattle” have a lower cost and capacity for replacement. Virtualization and the new generations of configuration management and orchestration have made that possible. But what’s the next step?
Introducing “Insects” – Your MicroServices
Consider the noble insect. Insects’ lives are inseparable from their colony. They depend on the colony for the majority of their life sustaining resources. Also, they are living only for their specific purpose to the colony. Consider the worker bee, the queen bee, the worker ants, and queen ants. About Ant Colonies
- Platform: Containers
- Distributed apps that can self-organize
- Completely self-contained stand-alone apps
- Light Config Management
- Scheduler and Deployer
What you put in a container is basically one unit of work processing. One is free to define how large or small this unit is, but common factors apply.
In earlier blog posts, I started exploring the idea of FuncOps. I dissected the incredibly brilliant design principles of the unbreakably robust functional programming language Erlang, and presented them in the context of Operations. Some of those principles flow through to the ideas of the Insect class that we’ll be expressing here. But make sure to return to FuncOps to get the whole picture.
Most important to keep in mind when approaching the world of microservices is that each class of has a rigidly defined goal.
MicroServices: Role, Immutability, Evanescence, and Hive Dependence
It does one job and one job only, and it does it exceedingly well and efficiently. It also know how to discover and be discovered by other members of the application.
Ultra-short execution cycles in the insect class.
Containers rely on the host OS’s resources, like file access, network access, etc. It has so little of what it needs to survive on its own. But those services are abstracted out by managing the container format – Docker is defacto, for now.
Virtual Machines do not force us to rethink the architecture of our applications. Containers force us to reconsider.
Orchestration with resilient autoremedation
Pets had a 50 year life cycle,
Cattle have a 5 year life cycle,
Insect class – seamless autoremediative orchestration and automation
Application Transformation: Population Changes
Eliminate service persistency
In-Cluster Integration: Guests in the Hive
hypervisor into the firmware and microprocessor for app startup latency
You can go too far. Unikernels create single-purpose hardware, useful in some contexts, a waste in others.
Insect class is dependent on code can run anywhere, but always have a central service element.
What’s a Successful Hive Look Like?
Chargify and NetFlix
MicroServices at Netflix: https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/
MicroService and Service Oriented Architectures: https://thecattlecrew.net/2014/09/30/microservices-architectures-thoughts-from-a-soa-perspective/
RunDeck: (Because RunDeck): http://rundeck.org/index.html