Blog anatomy - Managing cloud resources

Pets or cattle

This analogy highlights the different approach we take when managing resources.

Pets approach as equivalent of long-lived, manually managed resources

With pets, we care about their name, we tend to them regularly, and they get that special spot in our life. More importantly, we want them to live long, their loss will hurt and they're challenging to replace.

This is the equivalent of manually managed, long-lived resources that you don't want to rebuild because it may be:

• a very time-consuming process,
• a proess where confidence about the result being the same as the original is low.

As a result, you try to coexist without upsetting it. You can end up paying way too much attention to the state of it.

These resources often are created via GUI of the cloud provider.

Please note:
There is a related term "click-ops" which refers to managing the infrastructure via the GUI. Since we love using analogies I can think of "click-ops" being the equivalent of a "puppy farm" in this context 😅
Was this analogy enough to make you want to stop it?

Cattle as equivalent of resources towards which we have no attachment

With cattle, we're focussed on getting a good return out of them. They're somewhat disposable, and the loss of cattle will simply mean replacing it with another one of the same kind.

This is the equivalent of coded infrastructure.

The resources' name is not too important for as long as it fits some template. The entirety of the resource configuration is transparent, readily available, reviewable, auditable, and executable. We can destroy and create such resources without a drama. We can clone such resources easily. Replacing one that's down is not only straightforward but often done automatically.

Managing resources via the provider's UI has its advantages

If we worked closely together, you will know that I've got a strong dislike for pet resources, especially the ones managed with UI. That's a general sentiment as I do believe, there's a use for them, such as exploration, diagnostics, using bleeding edge of cloud offering, and other.

Exploration/learning

Using the UI will often guide you to the most correct and powerful use of the resource. The benefits of using UI (over IaC) for the exploration:

• the options on the web page are often constrained to valid ones. Think of prepopulated dropdowns, radio buttons, etc.
• fields are validated and can even throw warnings and errors as soon as you type the incompatible/incorrect value in,
• the fields are labelled meaningfully, the Iac tooling often uses cryptic names,
• the associated fields are grouped and ordered sensibly which often is missing in IaC tooling, especially where the SDK doesn't use OOD,
• more complex fields would be accompanied by localized tooltips with extra information,
• there's usually the interconnected web documentation as well.

If you want to learn about the most typical usage scenario of a resource, the UI may even offer you a guided "wizard" approach that will ask you all the relevant questions to help you set it up. I came across CLI tools attempting similar, but having GUI makes it very accessible and easy to follow.

Diagnostics/monitoring/recovery

UI provides aids to present the data to you in an efficient manner. It may be including filtering, grouping or searching for logs, plotting charts for metrics, presenting complex structures on diagrams, amongst others. With IaC it is less juicy, mainly textual info and reliance on CLI.

Sometimes when the code returns a confusing or briefly worded error message, it is possible to get more understanding by looking into the UI.

Often a failure can only be fixed via the UI. It is not uncommon for CloudFormation to require intervention via the UI upon failure.

Working with bleeding edge of cloud offering

The tools we use for creating resources with code are often created by third parties. They're usually modular, allowing us to write integrations with cloud providers' interfaces. These modules are often written by people not closely affiliated with the cloud provider or the toolmaker. That results in delays between the cloud capability is released and the module is supporting it. It is not unseen for the module to contain errors. So, for the above reasons, you may need to consider using a cloud provider's UI or their APIs or their provisioning tool to manage your resources.

Delegating management over a specific resource to a less technical owner

It can happen that the owner is perfectly capable of working the UI of a tool but is not a coder. In these cases UI is a saviour.

Once possible, transition manually managed resources into IaC

The above reasons for use of UI are valid, but most of them become less so with time. My default trend for management of cloud resources is to start as IaC, unless I need to learn. For anything manually managed, I consider converting the resources to IaC if that saves time or makes the process smoother or less error-prone or cheaper.

Also, keep in mind that IaC often becomes a must when there is a team involved. No one wants to be guessing what changes have been done to a service while their focus was elsewhere.

Approach taken for this site

This site has barely a few resources that are managed manually. Majority is managed with the use of Infrastructure as Code. More details and context will appear in the next post.