Select Page

We Raise Cattle

April 2020

We hate those subtle differences between dev, QA, UAT and prod environments which make replicating issues from prod to dev impossible as you can never be sure you have everything 100% configured the same to enable you to find the problem. After first-hand experience of these types of issues, we like to avoid them as much as possible.

Central Configuration

We alleviate this by storing our configuration in a central place, and when we create an environment, everything is built from the same template or recipe – application configuration can be different for each of our clients but the base server, OS and software level are guaranteed to be the same. We do this by treating our servers as cattle, not pets. If you have not heard of this phrase before then let me elaborate.

Servers as Pets

In traditional IT infrastructure, you purchase physical servers, configure them, drive them to a data centre, install them, and then hope that nothing goes wrong and you can do everything remotely. If things go wrong you try and fix it and hope you don’t have to go back out and visit the data centre. To get more horsepower you scale up by upgrading them with more memory of CPUs. You give your servers wonderfully crafted names that have to adhere to the complicated server naming policy and care for them – if they get ill you try your hardest to get them back up to full health – just like you would do a family pet.

Servers as Cattle

The alternative which is now becoming more common is to treat your infrastructure like cattle. The name is auto-generated. If you need more horsepower, you scale out and get more servers (rather than upgrading them). Each server as part of the herd is almost exactly the same as every other, and if one of them gets ill, you terminate it (stop it and start another). One failure doesn’t cause the rest of the herd to be impacted.

This gives us huge benefits by immediately ensuring our applications are highly available (HA) and have a shared-nothing design, meaning one failure doesn’t have a domino effect on the rest of the application.

Automated Test & Release Cycles

Raising cattle also gives us a big benefit of doing automated testing and release cycles, enabling us to practice the job of deployment several times over in a day with our crash and burn setups. This ensures that when we go to do an upgrade, we are certain it will work with a minimum amount of fuss – no more having six month or year-long projects just to do an upgrade from one version to the next. We can deploy more frequently ensuring you receive new features and enhancements as they are created rather than waiting to that special X.0 release.

Treating our servers as cattle enables us to give you new features and releases faster in our Fluid MDM platform, so contact us to see how we can speed up your deployment.

We promise we don’t send spam