No more pets in IT

Remember the good old days, when IT got a new server. It was a special event – and naturally the naming game. Finding that special name for the server, which neatly fitted into the naming scheme adopted (be it Indian cities, Nordic mythology or cartoon characters).

This ought to be then, but the ceremony still happens regularly in many IT departments, where servers are treated with the same affection as with pets – and with all the bad side effects it may bring along.

Remember the “superman” server – it must not die – superman will live on forever- nor matter how much patching, maintenance and expensive parts replacements it need, we will care for that special pet server… and we would be wrong to do so.

Modern IT should not be that cozy farm from the 1950ies, but find their reflection in modern farming.

From pets to cattle

In a modern farm the cattle isn’t named individually and harsh at may seem – when one of the cows doesn’t perform, it replaced as the performance of the farm as a whole matter much more, than the individual care and nurture of the individual animals on the farm… and rarely are the individual animals named – perhaps in recognition that they will be replaced and the number of animals will be adjusted to align with the requirements of the farm.

Modern IT does have all the technology to adopt the modern farm metaphor and should do so as we move to virtual servers, containers, micro services and cloud-based infrastructure.

All these technologies (along with others) have enabled us to care much less about a specific server or service, and instead focus on what “server templates” are needed to support the services provided by IT – and mange the number of instances needed to support the requirements posed to IT.

Hardware as Software – From care to control

As servers move from a special gem to a commodity and we may need 10, 50 or 100 small servers in the cloud instead of a single huge “enterprise” spaceship in the server room, a key challenge is our ability to manage and control them – and the tools to do that is also readily available.

Using tools like Chef, Puppet or Docker(files) – as the enabler for our server templates from above – developers are able to describe a specific server configuration and use this template to produce as many identical copies as may be needed. Further more, as we’re moving to manage the herd of servers, the server templates should easily be manged using the standard version control software used to mange your source code already.

Using this template model, the developers take control (and responsibility) of making sure the complete stack needed to run the service, is coherent, and the operations can make sure to size (and resize) the resources available as needed.

Finally as we move to a “cattle” perception of servers, no one should ever need to login to a specific server and make changes – it all needs to go through the configuration management tools and tracking changes all changes to the production environment. If a server starts acting up, kill that the server and spin a new server up in your infrastructure.

(This post originally appeared on Linked)

Ephemeral Feature Toggles

At its simplest  feature toggle is a small if-statement, which may be toggled without deploying code, and used to enable features (new or changed functionality) in your software.

In an agile setup most developers love  having feature toggles available, as they often allow for a continuous delivery setup  with very little friction and obstacles. While this is true, it often seems developers forget to think of feature toggles as ephemeral, and doesn’t realize what a terrible mess, this can cause – given they don’t remove the toggles once the feature is launched and part of the product.

While feature toggles often is an extremely lean way to  introduce public features in software – short circuiting normal release ceremony, as it has already happened before the launch of the feature – which often literally is a button press in a admin/back end interface.

Feature toggles must be ephemeral when used to support Continuous Delivery.

Introducing feature toggles in source code is often just allowing an if-statement and toggling between two states. While it ought to be a single place a toggle occur in the source code, it may often be in views, models, libraries and/or templates – and thus leads to (potentially) a lot of clutter in the source code.

If feature toggles are allowed to live on, the next issue is often that feature toggles may become nested or unintentional crossed as various functions, components in the code, may depend on other features.

Feature toggles is a wonderful thing, but all toggles should not have a lifespan beyond the two sprints forward – allowing for the wins of the feature toggles, yet avoiding long term clutter and complications in the source code.

Other uses for feature toggles…

Feature toggles may exist as hooks for operations or to define various class-of-service for your users.

When used for operations, they may be used as hooks to disable especially heavy functionality during times of heavy load – black Friday, Christmas or whenever it may be applicable.

When used for Class-of-Service feature toggles can be used to determine which feature a basic and a premium user – or any other classes you may choose to have – have access to.

If you’re applying feature toggles as Operations hooks or class-of-service, don’t make them ephemeral, but have your developers mark them clearly in source code.