How to farm your servers

… or the cloud-tale of pets, cattle and … insects?

There is quite an old anecdote in IT how to classify your servers running your services. And it still seems to hold true in the era of cloud computing — at least it has for now. It states, that you should divide your farm to pets and cattle and treat them accordingly.

Pets are something you care about deeply. You give them names. You take care of them as personal units and if one gets sick, you treat it and make it better. You will hold on to your pets for long periods of time.

Cattle is something you treat as disposable units. You treat them as a mass. You identify one from another based on a tag with numerical value or similar. When one gets sick or dies, you shoot it and replace it with another (cold — I know). When you need more, you bring more — when you need less, you get rid of the excess.

But as Kalle pointed out here, it is more of a spectrum, than strong dividend between the two. So sometimes you might care — maybe even too much some might argue — for a specific calf. Or on the other hand, you might treat some of your pets really poorly. Or when you want a new pet, you will get rid of the old one…

Let’s discuss this from a viewpoint of three currently most commonly used architecture scenarios: monolithic, service oriented and microservices architectures.

Monolithic architectures

Monolithic architecture is very old-school way of organizing a service. One thing tries to do more or less everything. Anything from mainframe era to application servers has it’s legacy in monolithic. Basically nobody does new things like this any more — at least I hope so.

This is a clear pet. An award winning priced specimen of it’s breed. Not only do you care about it a lot, but you have lot’s of time and money invested on it.

Service oriented architecture

When things got too complex to one server to take care of it all, service oriented architectures began to emerge. And this is still the de facto in the business. Most existing services represent some sort of interpretation of this architecture and this is still used for new projects and architectures. Even in the ages of the cloud computing, this is still a valid choice.

This architecture includes usually both pets and cattle. And if it does not, it usually at least has the potential to include both. Usually the data tier is more of an pet and the delivery tier is more of an calf.

Especially in elastic and autoscaling cloud architectures, there are lots of cattle coming and going.

Enter the microservices

And then — the next step. As architectures have evolved and virtualization, and later cloud computing, have made it possible to right-size resources and deploy smaller servers where it is feasible. And this has lead to the emerge of the microservices architecture.

In the microservices architecture the concept is that one server takes care of only one thing. And generally the components discuss with each other through defined and restful APIs. Technologically this is usually achieved by using either bunch of very small (or should I say, right-sized) virtual machines or containers (like Docker) to deploy services.

But this way of operations resembles actually more some some swarm based animals, like a bee hive or an ant colony. Some have suggested chickens or birds to this role, but for me it just does not seem as a reasonable analogue.

In microservices there are lots of workers doing only single and very standardized thing — but doing it very efficiently. So in my mind, maybe the ant colony is the best to describe this. Also the picture looks really lot like the architecture. And nothing like what chickens do. Which is basically not much 🙂

So the original cattle and pets starts to be a little bit hazy here. Even if the actual real life architecture might still include some pets and certain amount of cattle. In addition to the “insect” component.

The art of farming

So, how to farm your ranch then?

If you are running on top of cloud platform, you should definitely limit the amount of pets. Or even aim for zero, but this could prove to be sometimes challenging. Scaling and automatization definitely are geared towards cattle — or insect — types of approaches.

The more you approach the insect level, the less you are capable of maintaining it by hand. You definitely need automation to even start to approach microservices level.

There are lots of great tools to do this. Some of them are natively offered by cloud vendors, like Cloud Formation and OpsWorks in AWS. And then there are portable tools, like Ansible and Terraform, which can be used in a portable manner everywhere.

The next step — Serverless architectures

Well, here is then the next nut to crack. What do you call an animal that is not an animal. Server that is not a server. As some workloads are transitioning towards architectures, where things are consumed as services and not as servers, this above mentioned analogy might be going out of the door. Or we need to invent a new one.

Naturally microservices approach is not for all architectures and not for all services, but it can be seen already clearly, that the start of the paradigm shift is here.

Maybe I’ll have to get back to this with another blog post later 🙂