Cloud and DevOps

Because hand-configured infrastructure is not reproducible, and not being reproducible means nobody knows exactly what is in production. When an environment needs recreating, and one day it does, the difference between an afternoon and three weeks is this.

Also because it makes change reviewable. A configuration change made in a console is not reviewed, leaves no rationale and is not reliably reversible. The same change declared in code is read by another person before it happens, and that is what catches most configuration errors.

Where we find manual infrastructure, migration is phased and starts with what is most fragile rather than what is easiest. Declaring the development environment first and leaving production manual for a year is the comfortable path and solves precisely the problem that did not exist.

From the questions that need answering during an incident, rather than from what the tool can collect. The reverse order produces crowded dashboards and an inability to answer the only question that matters at three in the morning: what changed.

With alerts tied to user-observable symptoms rather than to internal metrics. An alert about processor utilisation wakes someone for a fact that may have no consequence; an alert about perceived latency wakes someone for a real problem. Alerts requiring no action should be removed rather than muted.

And with enough retention to investigate. Logs with seven days of retention are useless for an intermittent problem appearing every three weeks, and the discovery that retention is insufficient always happens during the investigation, which is when nothing can be done about it.

For European data subjects' personal data, the region where data resides matters and it is a configuration choice frequently left unmade. Managed services with global components can replicate metadata outside the chosen region, and that should be verified per service rather than assumed.

For Portuguese public sector clients the requirement is usually stricter and appears as an exclusion criterion in tenders. Designing the architecture with that constraint from the start costs little; adapting it after the tender is published costs the tender.

Administrative access is the other half of the question, and the more forgotten one. Data hosted in Europe and administered by a team outside the European Economic Area still involves a transfer, and the framework applies to access and not only to storage.

Migrating to cloud without measuring first. A stable, predictable workload can be more expensive on public cloud than on dedicated infrastructure, and migration only pays off where there is real elasticity to exploit. We say so before the bill rather than after.

And adopting container orchestration where the operation has neither the scale nor the team to maintain it. It is an excellent choice above a certain size and a source of permanent complexity below it, and the decision should be taken on your size rather than on common practice.